Agile methods are more than a list of practices to follow. When your team has learned how to perform them effectively, you can become a great team by using the practices to modify your process.
Throughout this book, I’ve drawn attention to places where the way you perform XP may vary from how I explain it. No two teams are exactly alike. You’ll do some things differently because you have different people and different needs. As you master the art of agile development, you’ll learn how and when to modify your process to take advantage of your specific situation and opportunities.
To improve your process, you must understand how it affects your project. You need to take advantage of feedback—from the code, from the team, from customers and stakeholders—so you can understand what works well and what doesn’t. Always pay attention to what’s happening around you. Ask “why”: why do we follow this practice? Why is this practice working? Why isn’t this practice working?
Ask team members for their thoughts. There’s an element of truth in every complaint, so encourage open discussion. As a team, reflect on what you’ve learned. When you discover something new, be a mentor; when you have questions, ask a mentor. Help each other understand what you’re doing and why.
XP is full of feedback loops—giant conduits of information that you should use to improve your work. Root-cause analysis and retrospectives clearly improve the team’s understanding, and other practices reinforce the principles in more subtle ways.
For example, sitting and working together as a whole team gives team members opportunities to observe and absorb information. This is tactical feedback, and it can reveal strategic issues when something unexpected happens. Stand-up meetings and the informative workspace contribute to an information-rich environment.
Perhaps counterintuitively, the practices of energized work, slack, and pair programming also spread useful information. When team members are under pressure, they have trouble thinking about ways they can improve their work. Energized work and slack reduce that pressure. Pair programming gives one person in each pair time to think about strategy.
Test-driven development, exploratory testing, real customer involvement, iteration demos, and frequent releases all provide information about the project, from code to user response.
Large and successful free and open source software projects often see a lot of turnover. In the five years I’ve worked on one of these projects, dozens of people have come and gone. That’s normal, especially for volunteers. It can take some time and effort to manage that change in personnel.
Recently, the project lead and our most prolific contributor had to reduce their time commitments. It took us a few months to realize we had lost ground, especially because no one had taken over the project lead’s job of producing timely releases. With everyone else reviewing changes and implementing features, our process assumed the lead was still making releases.
This experience helped us see that tying such an important task to a single person was a mistake. To fix it, we all agreed to divide the work. Every month, one of us takes final responsibility for creating the release; this person produces the final tested bundle, makes the appropriate announcements, and uploads the bundle to the master distribution site. With six people available and a release schedule planned to the day, we’ve found a much healthier rhythm for making regular releases. If one or more developers are unavailable, several other people can perform the same function. It’s worked—we’ve regained our velocity and started to attract new developers again.