Institutionalized Agility

[article]
Trying to Bottle Lightning Can Do More Harm than Good
Summary:

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

Pages

About the author

Rob Myers's picture Rob Myers

With more than twenty-five years of professional experience on software development teams, Rob Myers has consulted for leading companies in aerospace, government, medical, software, and financial sectors. He has trained and coached teams in XP and Scrum development practices since 1999. Rob now continues these activities as Agile Coach at Salesforce.com. His courses, talks, and workshops are always infused with deep technical experience and techniques for preserving sanity in the workplace. He prefers to speak with people face-to-face, but the occasional blog post appears at PowersOfTwo.agileinstitute.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Apr 29
Apr 29
May 04
Jun 01