Missed the other parts? Read them here: Part 1 or Part 2
Organizational Agile Transformation – Big Bang Approach?
In my last post in the series, I thought I would have a little fun. 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 actually 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 bodies they want to leave behind in the process.” However, the more I thought about his question, the more I wanted to challenge my initial answer. Rolling out Agile in a big bang approach really seems counter-intuitive considering what we are rolling out. However, rolling Agile out iteratively brings up the concern on how well Agile can scale. An Agile roll-out out to an enterprise can involve several hundred people made up of a multitude of cross functional teams. Should we expect Agile to scale to this level?
From my industry experience, I’m finding more and more CIO/CTO types wanting to take this big bang approach. They want to make the leap and they want to make it now! However, the approach we take for roll out 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.
1. Communication
Increased and valuable communication is a key Agile principle. Agile works great within enclosed 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 have to interact. It’s extremely difficult to get somebody from another geographical location, participating in a project, trying to be friendly, and trying to get information at request. Agile just doesn’t seem to be designed to scale.
2. Lack of documentation
Because of the increased communication and conversation, 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 through Agile principles doesn’t seem to be the right way to go.
3. Self- Organizing Teams
The concept of self-managing teams organizing around goals given constraints works excellent on smaller Agile teams of 10-15 people works. However, an army of people cross-functionally based and geographically dispersed, just simply needs some order in order to function healthy. At the enterprise level, lack of formalism doesn’t lower chaos, it actually ensures chaos.
All in all, I still came away thinking that my initial answer was correct. Either path likely faces the above challenges. It’s a question of what makes more sense for your organization and is likely to gain more support among leadership: rip off the band-aid, have short-term pain in the hopes of long-term gain; or pilot your way into it so as to manage the risk of disruption, but risk losing support if tangible progress can’t be demonstrated and other agendas begin competing for resources.
An enterprise roll-out of Agile, does require some up-front planning and clear communication and structure. Yes, a more pragmatic, iterative (RUP like) approach would probably seem to be the best way to go. I know I may receive hate mail on this one, but dare I say, I recommend running an enterprise Agile rollout through your neighborhood PMO. I’m actually blogging about the PMO’s involvement during an Agile transformation at http://www.actuationconsultingllc.com/blog/
Regardless of which path you take, be sure to go in with eyes wide open!
This is the last in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting.  Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven. |
Agile methodologies have become a component of everyday conversation in the product development world. While widely adopted, confusion remains about what Agile really means and how to best utilize these methodologies. In fact, 
