Step 2: Find the Practices that Address Your Goals1
This section contains a series of diagrams that help you determine which practices are most effective for which business value. These diagrams are built by aggregating experiences from several Agile adoption efforts. Each of these practices corresponds to a pattern that is documented Agile Adoption Patterns: A Roadmap To Organizational Success.
Let’s examine Figure 1 to understand how to read these business value charts. Arrows between practices indicate dependencies; therefore, refactoring depends on automated developer tests. Also, vertical ordering is important; the higher up a practice is, the more effective it is for the business value. Therefore, Iterations are more effective than Automated Developer Tests, and Test-First Development is more effective than Test-Last Development with respect to decreasing the time to market. Use these diagrams to determine what practices to consider adopting. Take the suggestions accompanying each diagram as just that - suggestions. All the practices in each diagram positively affect that business value, but not all practices work in all contexts. Sorry to repeat myself, but... in Agile Adoption Patterns: A Roadmap To Organizational Success each practice is documented and describes in detail what contexts fit each practice.
Figure 1 Time to Market practices
Small steps and failing fast are the most effective methods to get things out quickly. Weed out defects early, because the earlier you find them, the less they will cost, and you won’t be building on a crumbling foundation. That is why Iteration and Continuous Integration lead the practices that most positively affect time to market. They are both, however, dependent on other practices. Consider starting with automated tests and the Iteration trio - Iteration, Done State, and Iteration Backlog - when you want to improve time to market.
Figure 2 Product Utility practices
Figure 5-2 gives the practices that increase product utility. By far, the most effective practice is Customers Part of Team. Go there first. Then consider functional tests if you are already doing automated developer tests or an Iteration ending with a Demo.
Figure 3 Quality to Market practices
With Quality to Market Test-Driven Development and Test-Driven Requirements are king, of course, they both depend on other practices. So consider starting with one of the automated developer tests (preferably Test-First Development) and pair programming, closely followed by refactoring. Pair programming helps you come up to speed with these particularly difficult practices. Once you are comfortable with automated developer tests, aim for full-fledged Test-Driven Development and consider functional tests.
Figure 4 Flexibility practices
There are two general types of flexibility in software development: team flexibility and technical flexibility. Team flexibility is the team’s ability to recognize and respond to changes that happen. For a team to respond to changes by changing the software, there needs to be technical flexibility. Therefore, you need both team flexibility and technical flexibility. Start with automated developer tests, a self-organizing team, and the trio of Iteration, Done State, and Backlog. The testing gets you on your way to technical flexibility, and the remaining practices enable your team’s flexibility.
Figure 5 Visibility practices
The Backlog and information radiators are your first easy steps toward increased visibility. Depending on your need for increasing visibility, you can take an easy route and consider Iterations with a Done State and a Demo, or a more difficult but effective route with functional tests and test-driven requirements.
Figure 6 Reduce Cost practices
You can reduce cost in two ways: make the code easier to maintain, and write less code - that is, code for the most important features first. Automated tests, followed by refactoring, simple design, and evolutionary design, are your path toward reducing the cost of maintenance. A Backlog, Iteration, and Done State reduce the amount of code written.
Figure 7 Product Lifetime practices
Product Lifetime is inversely proportional to the cost of software maintenance. There are two ways that we know how to reduce maintenance costs: 1) build a safety net of tests that allow changes to the software system and reduce the cost of change and 2) spread the knowledge of the design of the software system. Automated developer tests are your key to (1), while pair programming and collective code ownership are good starts for (2).