The Power of Commitments
Doing what you say you will do, when you say you will do it, is one of the key ways to build a relationship of trust. Conversely, nothing erodes trust more quickly than a couple of missed deadlines or broken promises.
The ability to make and keep commitments is one of the hallmarks of a true Software Craftsman. Likewise, the most effective teams harness the power of commitment to forge strong and healthy partnerships with their customers. This is a surprisingly rare skill, but one that can be learned and improved.
In this session we'll look at the different kinds of commitments we make as individuals and teams. We'll distinguish between commitments and predictions. We'll reflect on why we sometimes commit when we shouldn't and vice versa. Most importantly, we'll practice some crucial "commitment conversations."
Outline/structure of the Session
- Making & keeping commitments is a key part of any trust relationship
- Keeping commitments is essential for building trust
- Failing to keep commitments is one of the fastest ways to break trust
- Inherent uncertainty associated with creative work
- Stakes are often high
- Might be tempted to avoid commitments
- But failing to commit also has a high cost
- Have to balance uncertainty and commitment
- Knowing how to make & keep commitments in the face of uncertainty is one of the hallmarks of a true Software Craftsman
- Ability to make commitments on an individual level rolls up to the ability to make meaningful commitments as a team
- Team's ability to make & keep commitments is a key component of project success
- Being able to make and keep commitments addresses one of the biggest pain points of SW development
- We can get better at this—it is an important skill
- Visualize your commitments
- Limit “Work in Progress”
- Say “no”
- Distinguish between commitments and predictions
- Use historical data & probability
- Incorporate “stretch” stories
- Reset commitments periodically
- Renegotiate as necessary
- Explain the relationship of commitments and trust
- Acknowledge commitments that you make as an individual/developer
- Describe common commitments for agile teams
- List commitment anti-patterns
- Use tools for knowing when and how to commit appropriately
Participants on Agile Teams
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Implementing Effective Testing for Behavior Driven Development using Cucumber-JVMMax Saperstone
schedule 2 years agoSold Out!
Behavior Driven Development allows for high level, plain English tests to be written, and to describe and exercise a system. Unfortunately it is difficult to have these tests encompass all interfaces of a software system, and to reuse them in multiple scenarios. Specifying these tests to run at different levels and times without duplicating work is non-trivial, and frequently produces lots of rework. This presentation will focus on cucumber to provide a robust framework for BDD, but any BDD framework can easily be substituting following guildelines and practices covered in this talk. This is not your typical Cucumber tutorial. We will mostly be focusing on how to utilize Cucumber's flexible structure in combination with the Java language how to write singular tests to run over multiple testing interfaces. This framework will build on the Cucumber basics to provide a generic model that also builds on the standard reports, giving additional information for debugging and traceability purposes. Test runners and inputs will also be discussed, to understand how to create more dynamic testing scenarios.
Developing Security In with Static AnalysisGene Gotimer
schedule 2 years agoSold Out!
Security is a lot like quality and performance. You can’t tack them on at the end of the development cycle and expect it to be effective. All of them have to be built in along the way, in every phase of every cycle. But even though many companies claim that security is a priority, that doesn’t always translate to supporting security initiatives in the software development process. Security code reviews are often overlooked or avoided, and when development schedules fall behind security testing is often dropped to help the team "catch up". And there is almost never any money in the budget for buying new tools.
So the first step of building secure applications has to be making security part of the regular development process, but at the same time there isn't time or budget to do so. Developers have to get some quick, easy wins with security without expending a lot of time, money, or effort. Like any agile practice, continuous and rapid feedback is critical.
Static analysis tools look at source code or compiled code, looking for common errors, unused variables, style and formatting variations, and similar items. Most modern languages have a selection of open-source static analysis tools that can scan source code looking for predictable problems. SQL injection, cross-site scripting, and hard-coded passwords are common vulnerabilities that can often be detected by static code analysis. Static analysis tools can also look at the third-party libraries that the source code depends on, identifying components that have known vulnerabilities.
With a continuous integration practice, it is easy to run some of these static code analysis frequently, beginning early in the development cycle. We can make these tools part of the developer's normal routine, heading off potential security problems before it is too late.
Gene talks about his experiences with using open-source static analysis tools to build security into the development process without spending much time or effort, but still adding plenty of security value.
Making a Better Salad: Behavior-Driven Development with Lettuce
Is your organization still using brittle GUI driven-tools to ensure applications can be tested? Do you find these difficult to map to the user stories that describe product owner/business needs? One of the current Agile practices to doing this is Behavior-Driven Development (aka Acceptance Test-Driven Development) and writing user stories and acceptance criteria in a Specifications by Example format. This has real power in that business people can understand the tests and the delivery team can ensure the code meets the tests, thus they serve as an example.
This tutorial will give a short background on Specs by Example/BDD and the show you how to write such tests in Lettuce. You will gain a deeper understanding of how you can apply this to writing your applications.
Why Kanban May Be Your Most Effective Tool for Improving Efficiencies in Operations and Maintenance, Business Process Management, and COTS ImplementationsDragos Dumitriu
schedule 2 years agoSold Out!
Are you finding the demands to your team overwhelming and the process chaotic? Are your customers saying your team takes too long to deliver or that they have no idea what your team is busy doing? Do you have a growing backlog with requests months to years old? Are people with critical skills not available when you need them? Do you feel like priorities are changing all the time? On top of your ever-growing delivery workload, are you able to develop the capabilities of your team?
The situations above reflect common challenges for software development teams and for IT Organizations in both private and public sectors. Kanban is being used worldwide as a management method that helps teams pull themselves out of these sinkholes and dramatically reduce work delivery times, increase productivity and improve project visibility. The method’s rapid success is based on its adaptability to existing situations and on its evolutionary capabilities to evolve along with the challenges it must solve. When implemented correctly, it is relatively easy to adopt, encounters minimal resistance to change and quickly enhances morale and trust in organizations.
This presentation aims to provide an introduction to Kanban core practices and why they work and practical insights into where the method might best fit within your organization or agency.
Secure Software in an Agile WorldJeffery Payne
schedule 2 years agoSold Out!
It's a falacy that software built using an agile process cannot be made secure but this statement is often heard. Reasons given by naysayers often include: Sprints are too short to integrate security analysis, agile doesn't value formalizing the architecture/design and security analysis needs this, and agile doesn't value the types of documentation necessary for security to be validated. In this presentation, Mr. Payne dispells these myths and discusses an approach for integrating security analysis into an agile development process. Participants will learn how to identify both bugs and flaws during agile software development and how disciplined continuous integration / continuous delivery significantly assists the security process. Topics discussed within an agile context will include: secure requirements, threat modeling, architectural risk analysis, secure code review, security testing, penetration testing. Examples of building and deliverying secure software for both commercial and government agencies will be given.