RallyDev.com
Late last year, we held an event in Austin where four customers spoke about their experiences with Agile development.
One of the big discussions that we had centered around how to successfully roll-out Agile across a team or organization. In the posts that follow, authored by several speakers from the event, you’ll find some different takes on Agile roll-outs. I’ve also posted video segments from the event.
We launched that pilot event into a nationwide tour in 2009, of which the first stops are Denver Mar 18, Los Angeles Mar 26 and New York City Apr 2. Depending on your city, speakers are AOL, Avaya, Beatport, BMC, Condé Nast Digital, eCollege, Gorilla Nation, MPower IT, NBC Universal, Qualcomm, Real Capital Markets and Spatial.
It’s free, but you do need to register on our web site.
(UPDATE : new event dates are being added regularly and can be found here)
How did you roll-out Agile development – team-by-team, all-in, another way? And what did you learn from the experience?
Rolling Out Agile Team-by-Team, by Israel Gat
There has been an ongoing debate in the Agile/Scrum world on how to implement and roll-out Agile. Some advocate a deliberate, department by department or project team by project team approach, while others are fans of an “all in” rollout.
The roll-out of Agile at BMC Software was fast paced. With help from the Rally Services organization, we grew from zero to 350 Scrum users in one year. Today, four years after we started rolling Agile, BMC has about 1,000 Agile users in various business units.
As fast as that the roll-out was, it was definitely gradual by design. As a matter of fact, the momentum the Agile roll-out generated made some of the more passionate potential Agilists unhappy with me when I told them “Don’t start Agile yet; your time will come.” Some actually told me they were experimenting with “pseudo Agile” (whatever that might mean) in preparation for a full-fledged Agile training, coaching and implementation regimen. I actually suspect that an “all in” Agile rollout might have carried the day in Spring 2005 if the business unit employees were allowed to choose. “There has never been a thought towards returning to Waterfall – we only think about is how to be more Agile – how to do this better. No one wants to go back!” was the overarching mood throughout the product management, development and quality assurance organizations.
Despite the popularity of an “all in” rollout, I decided to implement Scrum team by team. This decision was based on the following reasoning:
- The nature of software. My fundamental view of software is that is craftsmanship. If you accept this premise, apprenticeship is probably the best paradigm for learning how to do quality software. I had a few Rally “masters” available to me - consultants like Jean Tabaka, Ryan Martens, Dean Leffingwell and Hubert Smits. I looked to these masters to develop the Agile experts at BMC Software. These experts, in good time, propagated the art of Agile to other BMC teams.
- The nature of the software process. In my humble opinion, software evolves in a continuous manner, one feedback loop after another. Hence, I expected the Agile process model itself to evolve. However, I did not know in what way(s) it would. As I learned along the way, each of the three product lines in the business units developed their own variant of Agile.
- Development of institutional knowledge. I did not want each team to reinvent the wheel. I was betting on being able to leverage the shared learning across teams. This learning and knowledge sharing required some things to go in a sequential manner.
- Phased unlearning. Numerous deeply rooted Waterfall practices had to be unlearned. I deemed massive parallel unlearning too risky.
- Distributed Agile. In addition to US-based development labs in Austin, TX, Houston, TX and Sunnyvale, CA, the business unit had development labs in Tel Aviv, Israel, Tel Hai, Israel and Pune, India. I did not believe I knew enough in late 2004 and early 2005 to effectively rollout full-fledge distributed Agile. In 2006, however, I read Jeff Sutherland’s paper on Fully Distributed Scrum. This convinced me that I needed to expand Scrum across the pond(s) along the lines Jeff proposed. For more information on distributed Agile teams, review Jeff’s slides from his talk at Agile 2008.
- Cultural uncertainty. For an ”all in”approach to succeed, the approach to Agile needed to be fully integrated with BMC’s core culture. Since I had only been at BMC for a few months when I began the Agile implementation, I did not feel confident that I knew the BMC culture well enough then. Hence, I preferred to roll gradually.
Sometime in the Fall of 2008 I received a review copy of Jean Tabaka’s Leaning IT: Applying the Principle of Pull to Scale Agile Teams. It was immensely gratifying for me to discover the Agile roll-out paths Jean identified as dead-ends. My retrospective hunch is BMC would have hit one or more of these dead-ends had we been too aggressive in deploying Agile in early 2005. Jean and Ryan also did a Secrets of Agile Adoption webinar on this topic that readers may find of interest when considering which approach to take.
Clearly I am a proponent of a team-by-team implementation approach. However, the “all in” implementation demonstrated by Erik Huddleston at Inovis is intriguing to me. Knowing Erik very well, I have absolutely no doubt he made the right decision for the set of circumstances, constraints and business imperatives that prevailed at Inovis in 2007. I am anxious to learn of his considerations for a “all in” rollout. I am very much hoping that between Erik, me and various readers of the blog we will develop a framework, along with a set of considerations for assessing when to go team by team and when to take an “all in” approach.
About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.
