And the number #1 Characteristic of an Agile Organization is…
“The Commitment to be Great”
The ability to make the commitment to be more than just good comes from the ability to drive a culture of discipline that balances the metrics of profitability and reputation. Hopefully you have seen and heard that message come through in the other items in our top 10 list; I applied these concepts from Jim Collins’ in “Good to Great.”
“Greatness is not a function of circumstance. Greatness is largely a matter of conscious choice and discipline.”
In the world of software development, an agile organization does not settle for having agile stuck in ghettos. An agile organization makes the commitment to go up the learning curve and blow past amateurism. As Jim describes this takes an organization that can increase the discipline to support increasing levels and scale of agility. Discipline to:
Regularly plan at the five levels (daily, iteration, release, roadmap and long-term vision)
Regularly make and meet the commitments you make based on a sustainable pace
Regularly inspect the progress & metrics and adapt the plans at each level
Make decisions based on the data, culture, and purpose
As Alan talks about at Amazon, it was just the OK from management that was needed. As Israel talks about at BMC, it was a Social Contract. You know what kind of commitment you need at your organization to scale agile. You need to get it to really improve and make your transition happen. Please, don’t settle for a weak commitment. It leads to isolated adoption, ghettos, and a slow, muddling adoption process. Scaling agility beyond just the development teams can be simple and rewarding, as long as you start with the commitment.
Here is a quick refresher of the complete Top 10 list:
Part 2 in our discussion on successfully rolling-out Agile practices also comes from our Austin event where Jack Yang from Homeaway spoke about a team-by-team approach. (See part 1 for more background on the Austin event and Israel Gat’s post on the Agile roll-out at BMC.) You can attend an event like this yourself in Denver Mar 18, Los Angeles Mar 26 or New York City Apr 2. It’s free, but you do need to register on our web site.
Please chime in with your success stories, or horror stories, on Agile roll-outs.
Implementing Agile Principles – Trials and Tribulations of a Team-by-Team Approach, by Jack Yang
I’ve had the privilege helping to roll out Agile/Scrum adoption here at Homeaway and a few other companies. At HomeAway, the process of adoption wasn’t simple – we faced a series of obstacles and false-start attempts until achieving a mature company-wide development process. Throughout the technology world there are many proponents for and against “all in” or team-by-team approach. In retrospect, given the challenges we faced as a company, the team-by-team approach was ultimately the most successful for us. I have no doubt that, given a different set of starting parameters, a large full-scale implementation throughout an organization could be successful. My belief, however, is that most teams aspiring towards an Agile process (which ever flavor it may be), start with a grass roots movement that requires careful proof of value. This may preclude the ability for a large rollout. To get a better understanding on how the HomeAway development team rolled out Agile, it is important to understand the environment of the company and how we, as an organization, happened upon trying Agile and the various barriers we faced, and continue to face, in becoming and staying Agile.
Homeaway.com, was launched in June 2006 to consolidate a cottage industry of vacation rentals and transform the industry into competitive alternative towards traditional vacationing. It is important to note that HomeAway is an aggregate of five smaller companies. The consolidation of HomeAway’s smaller companies did not happen over several years, which may have allowed for careful absorption of technology and staff. Instead, it started with a large buy-up that continued over the next three years as we continued rapid growth through acquisition. Each company brought new technologies, differing levels of development experience, and cultural backgrounds. Business units that were formerly autonomous were now required to play in a larger field that had differing often competing interests. The headquarters suddenly became the “mothership.” Satellite offices were cautious of change and each of the formerly autonomous businesses were highly profitable and had been operating that way for some time. Ultimately, however, we needed to create a consolidated brand. That meant everyone had to effectively work together. The company’s executive team focused on getting the each brand (or business) running in the same direction. This meant the development staff was now committed to many releases and ad-hoc requirements that changed often
The early days at Homeaway were challenging. My team at the time consisted of four engineers and when they tired of the poor release code quality, a brittle production environment, and long deployment times (at times, it took the team up to nine hours to finally roll out to production), we were driven to come together and commit to a different process. The team was made up of several seasoned startup veterans and a few developers new to the startup environment. We decided as a group that our ad-hoc “Agile / Waterfall” process did not work. Instead, we needed to pick one methodology and stick with it. We began with the following mission, “Follow the book to the letter to start, slow down to one single story and get it done with quality” and a philosophy that our one QA team member was the most important person on our team. I had the fortune of having a Product Owner that understood and shared in my team’s frustrations, so I had buyoff.
Within a couple of months, we were one of the most productive teams in the organization, producing quality code that carried less than 10 defects from sprint-to-sprint. Going Agile was a big part of the success, while facilitating adoption and enforcing of best practices was the other piece. Our particular product didn’t generate the most revenue for the company, but the sudden boost in speed quickly drew attention from senior management.
At this point, the management team decided to split this team and reseed the rest of the development organization with Agile members to help spread out the knowledge all at once. We hired a coach who focused on certifications for a few U.S. developers first, and then went overseas to train and convert our European counterparts. So, we essentially tried to rollout Agile throughout the organization in an “all in” approach. However, this failed on a global scale.
Here is why that approach did not work:
The individual seeds had the monumental responsibility of convincing their new teams to do something new.
Development managers felt they were being told how to run their teams.
Product Owners were accustomed to using existing requirements binders and were unwilling to give them up.
Product Owners lost the ability to ask developers “can you just fit that one feature in?” and felt like they lost control over their product.
Evangelizing to an entire office that didn’t buy-in/understand the process resulted in many individuals paying lip service to the new process – “We’ll do it the old way when no one is looking.”
Developers were used to hacking in features and deferring technological debt. They were now being asked to cleanup as they went along. In their eyes, this meant they weren’t moving as quickly as before.
C-level executives didn’t see the same ramp up of quality and withdrew their support for Agile.
During this period, I was asked to form and staff up two new teams around key company initiatives. I was allowed two seed team members from my old team and then hired new employees. The failed attempt of Agile adoption across the organization put the newly-formed team at a heavy disadvantage when we elected to follow strict Scrum practice. However, the two new teams carried on, despite doubt and pushback from senior management and product teams.
Eventually, we launched the projects on time and with high quality. Using historical data, I was able to demonstrate costs on new projects and give visibility to team progress. This was a turning point for the company. With three teams having successfully implemented Agile, there was no question it could work and the first team’s success was no longer viewed as just a fluke. This time, with the support of the CTO, we resisted splitting the teams. And, the technological debts of “getting things out” and “not doing the right thing” caught up with the teams who were resistant to Agile practices. As each team got fed up with a lack of quality and inability to deliver, they began looking to the teams who were surpassing their goals and asking for help. This time change was socialized. More importantly, we were now rolling out teams in a methodical team-by-team approach, rather than trying to rollout all teams at the same time.
Here is my analysis of why we ultimately succeeded on this second attempt at rolling out Agile practices:
Teams that ask for help are more likely to implement, as it is “their idea.” The best way to encourage teams to ask for assistance is to show them how much better it can be.
Due to lower technology debt overhead, professionalism and disciplined work over the medium to long term will outpace “cowboy startup” teams.
C-level management responds to hard data and winning their support the second time around was critical to our ability to implement and manage the process across our global offices.
All Agile methodologies require discipline. From discipline comes professionalism and teams saw they were being treated as professionals instead of hackers.
Professional teams developed a high degree of trust, making them even more effective and eliminating egos.
As more teams come online the process of conversion accelerates.
In summary, I believe that most companies have a very traditional core belief system and value waterfall development. They tend to be afraid or not educated on the benefits of moving to an Agile philosophy. If this is true, the only way to spread Agile would be one of two ways:
Either through a team-by-team, grassroots approach as demonstrated above
Rollout Agile from the top down, with executive team support
Executive teams tend to be conservative when it comes to changing their core beliefs and will naturally wish to only “pilot” a team to begin. This obviously leads to a team-by-team approach. My view is the amount of change that needs to happen to perform an “all in” rollout within a large organization is riskier than the same approach used with a small company. The odds of failure anywhere in the system are high. However, when driving adoption, the consequences of failure were so high that we didn’t feel like we could risk an “all in” approach as we feared we would be in a worse place than when we had first initiated the change.
I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness. There are two reasons for this:
According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world. Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”
Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development. Like the story of “Good to Great” from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile. If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones. Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.
If you are working toward this, I believe you increase your business value by 4 to 10 times. I am going to make the case with the help of ROI models from David Anderson. (BTW, I love his book – it does a great job explaining the simple physics of Agile.)
From Chapter 2 - David Anderson's "Agile Management for Software Engineering"
This is a very simple model of software process. David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one. So, the rough equations to calculate the business benefit of the process are the following:
Net Profit = Throughput – Operating Expense
ROI = Net Profit / Investment
In the following four pages, I am going to look at how this equation plays out for four different scenarios:
Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
Intermediate Agile team in Pull with incremental releases of value
Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value
What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.
Here is the summary:
Good waterfall team – ROI – 0.8
Beginning Agile team in Flow – ROI – 1.4 (1.6 factor better than good waterfall team)
Intermediate Agile team in Pull – ROI – 2.6 (3.2 factor better than good waterfall team)
Advanced Agile team in Innovate – ROI – 6.3 (7.7 factor better than good waterfall team)
Factor or Four or better – that is why there is such a rush towards Agile development. Of course, you can’t have your cake and eat it too. Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.
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?
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 Adoptionwebinar 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 andwhen to take an “all in” approach.
About the Author: Ryan Martensis an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by emailor RSS.
RallyDev.com
And the number #1 Characteristic of an Agile Organization is…
