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.

Pattern for Agile Adoption

After leading a transformation for over a year I'd like to make one point. People often take Agile Transformation too lightly and think about it as yet another process being introduced into the Engineering organization. What I've experienced is that Agile Transformation is not much different than any other large-scale organizational change, and as such deserves to be managed accordingly. One has to consider that moving to agile is a significant mental shift in the way people approach problem solving and performing their daily jobs. People that are the core of the change process need to be well prepared and allowed to fail as they learn.
For us it took 1 year from introducing the idea to the management to starting with the 1st sprint. At times it seemed like we are dragging our feet, but in retrospective I can say it was worth investing all the time we spent learning the subject, talking to practitioners, analyzing applicability to our context and identifying obstacles, challenges and plans of attack. This due-diligence has paid off when we started the project.
If I would need to define a successful pattern for planning and managing Agile Transformation here would be the major steps in that pattern:
1. Get a focus group to self-learn Agile. The group has to include at least 1 member from each product development team (dev, qa, pm, ...)
2. Create a shared Vision (see my post “Vision matters”)
3. Focus group meets with practitioners, members attend events and share what they’ve learned
4. Information is digested, obstacles identified and plan of attack for these obstacles being developed
5. Propose a recommendation (go/no go)
6. Get Executive buy-in
7. Start with education for all relevant locations. I've held initial 2-day workshop for everyone, then invited coach to do SM and PO classes.
8. Spinoff teams on obstacles, challenges, processes identified in #4 above.
8. Hire a coach (see my post “Hiring a coach”)
9. Find a good pilot project (it's another topic on how to choose the right one)
10. Have coach facilitate 1st sprint
11. Communicate to the world about the progress