The Chronicles of an Enterprise Agile Transformation (Part Seven)
I was recently talking with a peer about the challenges organizations face when rolling out Agile. He mentioned that he was talking to a client later in the day and wanted to know what my recommendation was. I said “in my experience, you have to take an Agile approach to rolling out Agile to an organization. Agile brings about change, and depending on the culture of the organization, it may take time to fully adopt. An incremental approach is the best way to roll it out.”
He asked, “what if the client wants to rip the band-aid off and roll it out all at once?” I responded half-jokingly “well it depends on how many people they want to leave behind in the process.”
My response was admittedly tongue-in-cheek, however, the more I thought about his question, the more I wanted to modify my initial answer. Rolling out Agile in a big bang approach really seems counter intuitive considering what we’re rolling out. However, rolling Agile out iteratively brings up the specter on how well Agile can scale. An Agile roll-out to an enterprise can involve several hundred people and a large number of cross- functional teams. Should we expect Agile to scale to this level?
I’m finding more and more CIO’s and CTO’s want to take the big bang approach. They want to make the leap – growing pains and all – and they want to make it now! However, the approach taken can make or break its success. Is the best approach in rolling out Agile to an organization done through actually running the roll-out like an Agile project or is a big bang approach better?
I’ve attempted to break down some of the key components of Agile to try and answer this question.
Communication
Increased communication is a key Agile principle. Agile works great with teams of 10-20 people. Because of the smaller team size, most team members actually (dare I say) develop friendships. Agile doesn’t necessarily work when thousands need to interact. Agile just doesn’t seem to be designed to scale.
Lack of documentation
Because of the increased communication, the need to document in an Agile project isn’t really required. Agile is very light weight and is about “just enough” documentation. However, at the enterprise level, rolling out a new methodology (Agile) requires communication to be crisp, coordinated, and concise. Because of the different perspectives, constraints, and cross-functional priorities, a roll-out needs to be managed very tightly. A roll-out of this size requires that things get documented. Again, I would have to say that running an enterprise Agile roll-out via Agile principles doesn’t seem to be the right way to go.
Self- Organizing Teams
The concept of self-managing teams, organizing around goals, works great on smaller Agile teams of 10-15 people. However, an army of people – cross-functionally based and geographically dispersed – requires order to function effectively. At the enterprise level, lack of structure doesn’t lower chaos – it ensures chaos.
All in all, I came away thinking that my instinctive answer was correct. Either path faces challenges. It’s a question of what makes more sense for your organization: rip off the band-aid and endure short-term pain in the hopes of long-term gain; or pilot your way through it in an attempt to manage the risk of disruption, but risk losing support if tangible progress can’t be demonstrated.
An enterprise roll-out of Agile requires up-front planning, clear communication, and structure. Yes, a more pragmatic, iterative (RUP like) approach would seem to be the best way to go. I know I may receive a large number of comments on this one, but dare I say, I recommend running an enterprise Agile roll-out through your PMO.
Regardless of which path you take, be sure to go in with eyes wide open!