- The Practices
- Patterns of Agile Practice to Business Value Mappings
- Crafting Your Agile Adoption Strategy
- Where Next?
- Theory to Practice: Building Your Own Agile Practice Adoption Strategy
This chapter is from the book
This chapter is from the book
This chapter is from the book
Patterns of Agile Practice to Business Value Mappings
Let's start with the meat of the chapter. Figures 5-1 through 5-7 provide diagrams for each business value and the practices that improve that business value. These mappings, like all the patterns in this book, are built by aggregating experiences from several Agile adoption efforts. Each of these practices corresponds to a pattern that is documented later in this book. Don't worry if you don't know exactly what some of these practices are at this point in time.
)
Figure 5-1 Time to Market practices
)
Figure 5-2 Product Utility practices
)
Figure 5-3 Quality to Market practices
)
Figure 5-4 Flexibility practices
)
Figure 5-5 Visibility practices
)
Figure 5-6 Reduce Cost practices
)
Figure 5-7 Product Lifetime practices
Lets examine Figure 5-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, and you may discover upon reading the details of the suggested practices that they do not apply in your particular context.
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 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.
Although 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.
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.
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.
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.
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).
Patterns of Agile Practice to Smell Mappings
There are two types of smells: business smells and process smells. The business smells are inverses of business values, and their patterns of Agile practice mappings are identical:
- Quality Delivered to Customer Is Unacceptable: Quality to Market
- Delivering New Features to Customer Takes Too Long: Time to Market
- Features Are Not Used by Customer: Product Utility
- Software Is Not Useful to Customer: Product Utility
- Software Is Too Expensive: Reduce Cost
The remaining smells have their own mappings to patterns of Agile practices (see Figures 5-8 through 5-15).
)
Figure 5-8 Us Versus Them practices
)
Figure 5-9 Customer Asks for Everything practices
)
Figure 5-10 Direct and Regular Customer Input Is Unrealistic practices
)
Figure 5-11 Management Is Surprised—Lack of Visibility practices
)
Figure 5-12 Bottlenecked Resources—
)
Figure 5-13 Churning Projects practices
)
Figure 5-14 Hundreds (Possibly Thousands) of Bugs
)
Figure 5-15 Hardening Phase
The Us Versus Them smell can best be alleviated by having frequent conversations about the true nature of the project. Start with increasing visibility by creating information radiators that show the key points in your development. Create a prioritized backlog by involving the whole development team—including the customers. Use these practices to increase visibility and build trust. When you are ready, take it further and build more trust by delivering often by adopting the iteration, demo, and done state trio.
Understand that when the customer asks for everything, it is a symptom of lack of trust from the customer that the features will be delivered promptly and a legacy of change-management barriers in traditional development. The best way to address this issue is to bring the customers in as part of the development team. Have them build the Backlog with the teams input and be responsible for its prioritization.
If direct input from the customer is not possible, mitigate this problem by reducing the number of communication errors. You can do this by building functional tests and slowly working toward test-driven requirements, where the customer's requirements document becomes an executable specification. This particular practice will take a long time to adopt correctly, so start early and be patient. In the meantime, create a backlog and start delivering work incrementally, with iterations ending with a demo.
To keep management from being surprised, you need to do two things: 1) build your application incrementally from end to end and 2) communicate your true progress. Address 1) by defining a done state that is as close to deployment as possible and then working in iterations. Communicate your true progress by working through information radiators showing your true progress and using a demo at the end of every iteration.
Bottlenecked resources happen because of specialization. Pair programming is your single most effective method to share knowledge and spread the specialization. This, in turn, allows more than one person to address issues that were previously the domain of a single expert. Automated developer tests help this in another way—they allow people to work in code they do not know well and rely on a safety net of tests to tell them if they have broken any previously working code. This should be your second step toward alleviating resource bottlenecks.
Projects churn when there is no clear prioritization. Prioritize requirements by creating and maintaining a backlog. To make sure that the backlog is an accurate reflection of customer needs, make your customers part of your team and put together a cross-functional team that can build those requirements end to end. This will give you and your customers a better understanding of requirements, their priorities, and a feedback loop to make course corrections quickly.
Hundreds of bugs need to be reduced. Start with automated developer tests supported by pair programming to reduce the number of bugs you are introducing and start building a safety net of tests. Then work with iterations with a done state to find as many bugs as possible. Don't put off painful issues such as integration. Fix things early.
If you have a hardening phase, you've let a significant number of defects accumulate. Stop doing what you've been doing and add tests as you develop code via automated developer tests. Choose a good done state—one that takes you as close to deployment in every iteration as possible—to weed out those difficult-to-find bugs early.