In this article, an excerpt of which originally appeared in the Iterations eNewsletter, Rob Myers writes of his experiences with difficult large-scale agile transitions and offers suggestions for avoiding disaster.
"Institutionalized flexibility," I said to my colleagues, only half joking, to describe what it seemed we had been hired to create. We were a group of very experienced agile coaches, hired by a huge client to transform the IT division into a lean and agile one. Only, we never really got to do much transforming.
Many larger software organizations are trying to "go agile," and many are taking this same strategy: Hire a group of agile mentors and coaches and have them help define what "agile" means to the organization. This has obvious benefits to the organization, as they want visibility into what multiple teams are doing. I've seen this done well; I've also seen this model for organizational transitions go terribly wrong. There are hurdles to jump and chasms to cross. Mostly, there are assumptions (and egos) to transcend. Here, I list some things I've seen go wrong fairly early in these transitions and suggestions on how to avoid them.
Remember Portfolio Management
"Which team should 'go agile' first? Do we choose our worst team or our best team? The team that's least busy? A project that isn't really important?"
This type of talk raises a Big Red Flag for me. Does the organization believe that this transition is going to provide return on investment (ROI), or is this some crazy make-work project for bored IT managers?
My answer is simple: What's the most important product under development? (Even for IT, there's essentially some "product," though organizations rarely seem to consider ROI here.) If we believe that agile can help, then we should probably be helping that team. Agile software development is a piece of a whole organizational transition leading to higher quality and better ROI. Before investing in radical changes to the software teams, take a good, hard look at organizational priorities. Ask why we assume that most of the burden of organizational transformation should be given to the development teams.
Don't Define Process without Experienced Feedback
"We need to tell the teams to what standards they'll be held accountable, how we'll enforce that, and how their productivity will be measured, before we have a single team 'go agile.'"
No one would actually say that, right? Yet, it's nearly an exact quote from an IT manager leading one of these transition teams. She wanted to know precisely what the agile process was going to look like, without ever letting a single team try any of it.
The transition team is often led by the IT department manager or director, who has read some books or taken a Certified ScrumMaster course. I think it's necessary that the person spearheading the transition should have some idea of where to take the organization, but if you've hired a gaggle of coaches, please be prepared to receive their input. I recently spent three days in presentations describing exactly what agile will look like for that client. We coaches were there "merely to implement" the changes! We didn't even have to think! (No extra charge for the sarcasm.)
When it comes to planning or modeling, flexibility and detail are inversely proportional. I've found repeatedly that those who try to gather more detail than is readily available end up sabotaging the very project they are trying to model. Of course, the model usually includes a rigorously detailed change-control process, and so remains blameless when everything collapses in a heap on the delivery date.
Focus on Information Retrieval, Not Data Storage
A number of these transition teams want to record "The Process" in documentation, using some industry-standard process-documentation tool.
Blame YouTube, perhaps, but our culture