When you see the need for a change, modify your process. Make the change for your team alone; though your team may be one of many, it’s OK to do things differently. Every team’s needs are different.
These changes require tuning. Think of them as experiments; make small, isolated changes that allow you to understand the results. Be specific about your expectations and about the measurements for judging success. These changes are sources of feedback and learning. Use the results of your experiments to make further changes. Iterate until you’re satisfied with the results.
Some experiments will fail, and others may actually make the process worse. Team members need to be flexible and adaptive. Your team needs to have the courage to experiment and occasionally fail.
Changing your process requires you to have a holistic view of what you do and why. New agile teams should be cautious about changing their process, as they don’t yet have the experience necessary to give them that holistic understanding. Once you have the experience, use the feedback from your changes to improve your process and your understanding of agility.
Tuning and adapting is implicit in XP; teams are supposed to make changes whenever they have a reason to do so. Many XP teams use retrospectives to give themselves a more explicit venue for considering changes. I’ve made retrospectives an explicit practice in this book as well.
The courage to adapt is an important principle, but it’s not explicit in any single XP practice. Rather, it’s a facet of XP’s Courage value. Similarly, the need for a holistic view has been an ongoing theme in this book, but no specific practice reflects that principle. Instead, it’s part of XP’s Feedback value.
My anecdote about changing our team’s release process made it sound like it went more smoothly than it really did. When the project lead left, he took with him much of the knowledge needed to produce a release, knowledge that existed only in his head and not in permanent documents anywhere. We knew this, but decided to take over the release process anyway.
Why? First, we had no choice if we wanted to return to monthly releases, even if there were problems with the process. More importantly, this was the best way we could think of to identify problems with our written process. If someone could follow the instructions to produce a full release, even if he had never made a release before, the instructions were good. If not, he could make a list of problems and we’d address them as a group.
That’s what happened. We discovered several problems—our distribution system wouldn’t distribute our release to the global mirrors, it didn’t index our files correctly, and our automatic installer completely failed to configure the source code for custom builds. Fixing each problem required us to improve our overall process.
We made some mistakes, but it was worth it. We’ve conducted several monthly releases so far. Though the first few were rocky, they’ve improved over time. It’s painless to release our software again.