Implementing Agile: You're either in or you're out

There are many reasons an organization’s Agile implementation will stall, abort, or even fail, but I’ll wager that every one of those reasons involves one fundamental underlying missing element: buy-in. 

My quickest successful implementation of Agile was when the Technology Director and I had the greenlight and full empowerment from the CEO and COO to fully change the paradigm of the production division.  Folks within the division were all so worn out from the wheel-spinning and bickering, they were primed to try something new.  Everyone else was told to do it or get out. (A bit harsh, but sometimes a line must be drawn.)  Well, with across-the-board buy-in, that division was transformed in two months, and delivered a large-scale complex project early and bug-free in three. 

And, I’ve experienced the other side of it: initial executive lip service given toward Agile, zero reinforcement across the departments producing a robust dose of grumbling, consistent lack of follow-through, eventual nose-thumbing at the Agilist leaders soon perceived of as the Gestapo, ending in an angry mob cursing and throwing firebombs at this paralyzed, misunderstood beast called Agile.  By the way, this sort of  scenario is most likely to occur in a weak or balanced matrixed organization, which is why I recommend a strong matrix, or a projectized environment, but more on that later. 

There are countless examples, but here's one key concept where buy-in must be present:  MVP or, Minimum Viable Product.  In traditional Waterfall software development, full requirements are gathered, developers are left alone to work, then the final result is delivered.  Break that mold.   EVERYONE needs to think in terms of iteratively delivering a MINIMALLY VIABLE product sprint-by-sprint.  That means, account managers, don’t promise clients, partners and vendors bells and whistles in two weeks, let alone revenue based on those bells and whistles.  Product Owners, don’t focus on building requirements that include the bells and whistles.  Do focus on what basic product will deliver the biggest value in the shortest time.  Developers, don’t think in terms of building out for the next 10 months the perfect database or back-end that can support the product that will be in 5 years.  Do think about building JUST enough of the foundation that will support and deliver that product to be delivered in 2 weeks.  Scrum Masters, nee Project Managers, don't expect to full requirements mapped to a timeline from start-to-finish.  See how that works?  You won’t be delivering the crust of the pie, you’re delivering a tasty sliver of the full pie:  bit of foundation, a bit of filling, a bit of whipped topping, a bit of cherry.  Something your customer can consume at regular invervals, while looking forward to more.

How can you get everyone to jump into the murky deep-end all at once?  There are a number of ways to set up Agile successfully, and though you need full buy-in fairly quickly, to start, you actually only need a some key proponents, executive buy-in, and the rest will become believers soon thereafter, as they start seeing positive results unfolding before their eyes.