Being the champion of using agile in your company can be a challenging, frustrating and rewarding experience. Too often the frustration is too much and the champion gives up, or worse, leaves the company. Some of these problems could have been avoided if the focus of the champion is on the people rather than on "agile".
One of the Agile Manifesto values is "Individuals and interactions over processes and tools". I originally took a more shallow view of this value to mean "agile practices over non-agile processes and tools". Later on I realized that the "processes" part could also include the agile label as well.
A champion is the first to be educated about agile practices. They are enthused. They see the light at the end of the tunnel of adopting the new practices. This is great, but the problem lies in how things go from there. Too many times the buy in of agile is harmed by the focus on the process over individuals. People resist change and when you tell them to change "because Scrum says to do it this way" you lose them. Agile gets labeled and resisted. The champion becomes more resisted and can be labeled as well. Their reward for trying to improve the way things are done is frustration.
A champion has to learn to be a coach. They have to communicate that the road of adopting agile is about constantly improving the product and how people work together one step at a time, and introduce some practices that can help them take steps on the road. They need to realize that there is no "light at end of the tunnel". It's all about making things brighter from day one and never stopping. The goal is about improving the product and the way we work together, not "being agile".
2 comments:
Having a champion reading manifesto as "agile practices over non-agile processes and tools" is not that rare and can indeed be harmful.
However, I've heard a lot of the success adoption stories utilizing the "we implement it by the book first" approach. The key is that people get tired of change and with gentle coaching and slow adoption they are going to see the first reasonable benefits, when they are already tired of all these "new processes". The big bang adoption does create some pain, but only temporary. Naturally for this approach to work there has to be a huge management buy-in.
Agreed. In fact I recommend a by-the book adoption strategy (GDC presentations and 2/07 GDM article). The point I was making is that the champion shouldn't shove it down the throat of the team all in the name of agile. Management AND team buy-in are both critical in "big-bang adoption" (I like that phrase).
I'm not sure what you mean about people being tired of change. Is that in support or against big bang adoption? I think you'll get that regardless of adoption strategy. Teams adopting agile should get used to change (see my next post).
Post a Comment