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.

Learning Pays Off

There is no entry in this blog since December ’09 not because I was lazy, but because so many things have happened in context of our Agile Transformation, that I decided to wait and organize my thoughts.

In February I’ve held a 2-day offsite workshop for the entire Product Development team. It was a workshop and not a mere PowerPoint overview of Agile practices. We’ve analyzed our challenges, our vision and goals, learned through games and read articles about Agile adoption. We’ve discussed success factors, success criteria and recipe for failure. This was my first public speaking in front of such a large audience for such long period of time, so as much as it was educational for the entire group it was quite an experience for me as well.

It was extremely beneficial to walk the entire team through the vision and the goals and showing how with help of Agile we can get there. Once the group understood that we are not doing Agile for the sake of “doing it”, but Agile is just a means to an end everyone became more comfortable with the idea of adopting it. Especially it resonated with senior engineers, some of whom had pretty bad experiences with Agile in previous jobs, where Agile was shoved down the throat by the management. Everyone has appreciated the fact that we’ve learned Agile for almost 12 months and didn’t want to rush with it right after reading a book.

Armed with the basic understanding of where we are marching to and how will we get there we had additional onsite education for Engineering Management, Product Management and key engineers on the roles of Scrum Master and Product Owner. These were lead by external coaches. Not to forget about our offshore team in Ukraine, we also made sure to organize SCRUM training over there (some delivered by me, and some by local coaches).

As our major release was coming to an end we were at the right place as organization to begin our 1^st pilot project.