Agile By The Book?

Recently I was asked to introduce a process to a very senior team that joined our company not long ago. The team did not have much process established in the first place, so the goal was not necessarily to transition from traditional (waterfall) to Agile/SCRUM, but rather to establish a process. Having a very talented and senior team, with decades of software development experience presented a challenge: should we go ahead and implement Agile “by the book” or should we consider a different approach? Additional challenge was multiple other changes happening in the group, in terms of the personnel and the development infrastructure. The risk of imposing too many changes and too rigid process was very real and could impede progress rather than facilitate it.

Armed with experience of introducing Agile “by the book” to 6 teams in the last two years, and knowing the challenges that specific team would have I decided to try a different approach. First, I have done Agile/SCRUM training, similar to what I usually do for a team that is about to begin their SCRUM implementation. At that point I stressed, that this is an overview/introduction only, and by no means a prescription to how we will implement Agile. In addition I have communicated in advance, that the entire team will be involved in designing their own process, building on some of the practices they learn from the Agile overview. Setting this expectation has helped a lot: there was no antagonism towards the attempt to introduce yet another change, after the stage was set this way. However, there was also a risk that when the time comes to design their own process they would take an easy way out and will chose only few practices to implement, not realizing the real benefit of implementing SCRUM.

The next day after an overview we got together to design the process to be implemented. The guiding principles were the following:

1. We have new product development ahead of us with time to market being most important. Practices that we choose should help us focus on working software at all times and allow for making frequent changes and getting frequent feedback.
2. We want to implement enough process to benefit from what Agile/SCRUM has to offer, without introducing too much process overhead.
3. No decision is cast in stone: the team would inspect and adapt often.

With these guiding principles agreed upon with the entire team, we went ahead and examined each SCRUM ceremony, artifact and role and have designed our new process.

At the end, the team and I were very happy with where we’ve ended, in terms of amount of the changes the team will need to absorb, potential benefits and amount of overhead.

If you were to ask me 2 years ago whether the approach I described above is recommended, I would probably say “no”, because all we’ve heard from Agile practitioners at that time was “start by the book, then adjust as you go”. In retrospect, I can see how both of the approaches can work well, and more importantly, each situation has its own context and no approach should be applied blindly, without carefully analyzing that context.