How to stay sane when the world is changing

Agile lives up to its promise to put a spot light on organizational problems and inefficiencies. In our focus group meetings we’ve identified several processes that will have to change once we move to Agile. The discussions on these processes have accelerated with first Agile pilot project kick-off as the new team had to know how to deal with defects, how branches and build environment will support Agile environment, what Definition of Done is and how development artifacts are created an managed. 

We approached this by creating spinoff teams that consisted of folks from different teams and locations and were lead by Agile Focus Group members. Each team spend some time on researching their corresponding subject and came up with proposal for next steps. These proposals were presented to Agile Focus Group and actual action plan was put in place. In addition to being very effective way to address many issues in short period of time, this approach presented an excellent opportunity to be engaged in the Agile transformation to the team members who otherwise wouldn’t be involved in the transformation for several months. In addition, the energy and momentum were maintained at high levels, which was essential for keeping the program going at the good pace.

While changes to existing processes will be driven by problems uncovered and challenges presented by Agile, there will be much temptation for modifying the Scrum framework as certain things will not make sense initially.

A word of caution when making changes to the framework. I particularly like the following quote by Ken Schwaber “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them”.

One needs to be careful when considering adapting the framework to their own context. In my opinion, its paramount to keep an eye on Scrum values when making changes, and the likelihood of success will be much higher.

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