In the fall of 2007, the product and development management team for Inovis met in the offices of their newest acquisition, an Austin Ventures startup in Austin, Texas.  The question before the group was how to change the way Inovis builds and delivers software to support the broader organizational transformation being led by a strong, growth oriented CEO.  Inovis was a traditional waterfall shop, with multiple product lines, stemming mostly from acquisitions.  There was pressure from the business to deliver faster, more predictable, and with greater direct market input.  While the Agile decision itself is outside the scope of this post, it was an obvious answer.  What wasn't so obvious was how to roll it out: incremental or "all in".  The debate is not unique to Inovis.  Across the Agile community, the conventional wisdom of organic adoption is being challenged.  Through the Inovis anecdote, I hope to provide a starting point for a broader conversation.

Considerations

The debate in Austin about rollout strategy took three days.  In the end, we decided to burn the life boats and execute the All In Approach.  There were a number of considerations that went into the decision, but at the highest level, we analyzed the upside advantages of All In vs. the downside risk.  This was also fueled by my personal worries around potential causes of failure.

The clear and most pressing advantage we viewed with the All In approach was speed to business value.  The company was undergoing a transformation, attacking several new markets and building an aggressive sales and marketing engine.  Product and Development was feeling significant pressure to respond and support that effort.  The need to get more developers "in the fight" faster was clearly evident.

Next, there were massive "new development" initiatives in front of the team.  The pent up demand far outstripped capacity, and the waterfall value delivery model would essentially mean that much of that value realization would be significantly delayed with large release cycles.  The flexibility of agile's smaller releases and focus on value driven prioritization meant that with an All In conversion, while we would not be able to deliver all the requested features, we would quickly deliver those that would have the most meaningful impact on sales and marketing’s plans.  Delaying the rollout would essentially be ceding some product/markets to competitors.

Third, while the go to market strategy was clear, the specific market requirements weren't.  Once lighthouse customers were engaged (which had happened recently), it was clear that we didn't know everything that we needed.  Leaving some teams or products in a waterfall model would have meant losing our ability to react to those clarifying market insights were were getting.

While the upside to a more aggressive rollout was clear, we were very concerned with three key risks: Execution, Culture, and Attrition.

• The largest and most controversial risk was execution risk.  The was significant fear that if our entire execution capability attempted to adopt agile simultaneously, a failure in the rollout could cripple the companies ability to deliver software.  As we dug into this concern, we concluded that the actual risk was significantly lower than one might think.  In aggregate, there was little chance of total failure.  Out of the twelve teams we were launching, one was currently executing well in an agile mode.  An additional three had team members that had historical agile experience.  Additionally, we concluded that even if deliver was significantly degraded, the fact that delivery was prioritized by business value, and iterations were limited to two weeks gave confidence that we could fail a dozen times (iterations) or more and still ensure delivery of the most critical business value faster than would have been the case in our existing waterfall process (nine to twelve months).  Additionally it ensured that delivery risk was lowest for the most critical features, an attribute that is not typically shared in waterfall delivery.

We were also concerned about the cultural risk associated with an All In rollout.  Having grown up through acquisition, Inovis had a strong development culture with many regional flavors.  An agile rollout might be such a shock to the system that the culture would either cause it to be rejected or would create enough human resources distractions to render the project a ineffectual (vs. a more gradual adoption).  At the end of the day, we decided that culturally, cutting the cord and burning the life boats was the best way to minimize culture shock.  We had watched other companies struggle with months and years of infighting with the non agile teams stiffening their resistance and weakening momentum.  With everyone signing up for Agile success, we all sink or swim together.

• Finally, we were very concerned about attrition.  We had heard horror stories of people quitting with 20-50% rates.  Prior to the rollout, we did not ever get comfortable with this.  However, after the rollout, we found the worry was mostly unfounded.  Agile reinvigorated many of our team members.  It eliminated many process issues and inefficiencies that were the root of internal dysfunction.  At the end of the day, I do not know of a single person that left as a result of Agile.

Enablers

While our All In approach was successful, and I strongly believe it is, in most circumstances, the best approach, Inovis had some critical enabler that made the All In approach viable and successful.  

First, we had strong executive support.  From the CEO on down, there was an understanding and support of what our goals were and how Agile would help achieve them.  We buttressed this by ensuring that in those first few iterations, we delivered features for each stakeholder that they had been urgently requesting.  

Second, we timed the rollout with a company wide strategic planning session.  The entire management team (over one hundred product managers, architects, dev managers, and QA managers) were in one location to understand what we were doing, why we were doing it, and how we were going to make it successful.  This provided us galvanizing buy in across all sites (over half a dozen).

Third, we had strong training and rollout support.  From its inception, we brought in my good friend Israel Gat to educate our management team on Agile.  During our strategic planning session, we brought in Rally to educate the management team.  Finally, we brought consultants into almost every team to help with the first sprint.

Fourth, we made things as simple as possible.  We used simple processes (Scrum in our case).  We used a best in class ALM tool to manage the process execution and collaboration (Rally in our case).  We simplified our product management processes (user stories).

Results

The results speak for themselves.  In addition to compelling productivity and quality improvements, we also had profound unanticipated benefits.  Within a few sprints, we were using development as a competitive weapon, bringing development to bear to influence the outcome of individual (strategic) sales cycles.  We dramatically increased our innovation through market dialog.  With almost 25000 customers, Inovis struck up quite a market conversation!  Finally, we found that Agile started driving alignment between teams and sites, facilitating tremendous cross product synergy and value.

I look forward to continuing the dialog on rollout strategy.  Let the conversation begin.