At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.
We did this while continuing to inspect and adapt our development and our strategy execution processes. We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company. As the CTO, I have my focus on our strategic planning and execution process.
As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)
Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.
This process worked well, but we had some issues including:
A moving definition of done based on different standards of work (research, implementation, campaigns..)
A delay in the feedback loop on strategic efforts made it hard to check and close well
Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)
None of these are different than what most teams experience with going Agile. So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.
These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired. Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum. Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.
As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks towards that goal.
Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output. This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.
We focused a quarterly rock on checking to make sure that we are done-done-done with our True North goal for the year. We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning. This PDCA-driven rock is a major milestone for me personally. It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team. As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms, our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback. This was simply an increase in process maturity that was mandated by our continuing growth.
To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process. This team steered the transition and proposed our quarterly rocks based on the PDCA process. And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.
I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes. Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility. In addition to doing lots of growing, we have another difference that started when we began back in 2003. We built Agile and Lean principles into our core values. You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.
Specifically our core values are:
Create your own reality
Make and meet commitments
Theory-driven decision making
Treat people with respect
Support our community and give back
Maintain a healthy work/life balance
This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.
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:
The next round of Agile Success Tours starts next week as Rally customers share their stories in a community-building event. We coordinate these events for the purpose of learning from do-ers. This is not a Rally sales pitch or a parade of “experts”; this is a place where software and IT leaders can share with their peers the best practices and roadblocks to Agile adoption. Peggy Reed, one of our phenomenal speakers from the Denver event and Avaya’s Director of Contact Center Reporting, said:
“I would totally recommend this event to people who are moving from another methodology to Agile. There are moments of truth when you move to Agile that are really tough for organizations. Having some help in a community that shares those moments of truth and change makes it understandable. You can see your progress if you share your journey with other people.”
In addition to the speakers below, Israel Gat, former VP of Development at BMC Software, will be at all three events sharing his enterprise Agile adoption story. The event is free, but registration is required.
June 4, 2009 – Santa Clara, CA
Leigh Anne Glasson, VP IT Applications Engineering, VMware
This and other great questions from the LA Agile Success Tour below. My next post will cover the open space breakout sessions.
Question: What would you ask your CEO to bring Agile into your organization?
Christophe – Are you ready to get rid of 50% of your managers? Jean – Agile brings about organization change, 20% of engineers won’t adjust. Israel – What are you trying to accomplish? Pick one and focus on it. Chris – Why just Agile in engineering? The whole business can use Agile throughout the whole organization. Laureen – Are you really committed to the change?
Question: What metrics do you ask the teams and upper management to embrace?
Chris – Measure what you want to improve and care about like: velocity, unit test coverage for the team. For the executives, align business metrics with your development metrics and make it as public as possible. Laureen – Make sure you have a goal before you come up with your metrics. What do the metrics mean to us? Data should support your goals. David – Had no metrics before Agile, now we can have value based metrics that the business can use. Israel – Establish a baseline before you do any process changes – you need to know where you stand. Pick the metrics to help you know where you stand and establish that baseline. Christophe – One tracked 3 metrics: dollars, customer satisfaction, and time to market.
Question: What do you believe is the #1 discipline that had to change or understand to enable successful Agile adoption?
Chris – The toughest and most important one is getting the development team to embrace continuous integration, it reveals so many of the improvement areas within the development team. This is hard because it can expose so many sacred cows within the organization. Getting to a point where you are always ready to release is key. Israel – Changing how the sales force and marketing departments sell products. Getting these groups able to sell value and benefits to the customer rather than a pure feature focus. This is key to end-to-end Agile. Laureen – Agile isn’t just another process with associated documents; it’s a change with how people interact with each other on a day to day basis. If people don’t want to grow and change with the business, then they may need to leave your organization. Christophe – Are you good at multitasking? Instead ask: Are you good at single tasking? Limit the amount of work in progress! Nothing gets done when you focus on too many things. The most difficult thing is to get teams to focus on one thing at a time. David – Moving away from an upfront requirements document to user stories that can change over time. A key piece was to break the stories down into smaller and smaller stories that can be worked during the iterations. Even people who thought they understood this process of breaking stories down struggled.
Question: How do you educate clients to Agile in a service provider based businesses?
Israel – Involve your customers with the iterations, the release planning events, and the end of iteration demos. The commitment is small from the customer and the benefits are tremendous in that the customer can be involved in the development process. Chris – Agile is such a wonderful and easy way to get customer involvement. Each iteration, they deploy to an external environment where they get feedback. Create a feedback loop with your customer so they can see how their feedback affects the direction of the product.
Question: How do you do performance management in a highly functional organization?
Christophe – I don’t do formal performance appraisals in my organization. Do the right thing for your team. Jean – Look at performance with this question: In what ways did you contribute to the success of this team? David – Unlike Christophe, it’s a little different in big organizations with SOX issues. If you have managers that span Scrum teams, make sure they understand what’s going on in the Scrum teams. Your focus as a manager totally shifts from micromanagement to one of removing impediments, roadblocks, and preparing the team for the next project. Israel – Keep information about how the team is doing secret to the team. Decouple the performance appraisal process from the process improvement within the team.
Question: How do you estimate how much work will go into a release and do more development and do it faster?
Christophe – Make sure you fix the date of your release and vary scope. David – I agree, resources are fixed, time is fixed and scope varies. Laureen – We use a train analogy. There is no question when the train is leaving, the question is what features will be on the train. David – When we started we had about 60% estimation accuracy. We now have over 90% accuracy in our estimates. A key point is DON’T LOAD YOURSELF TO 100% CAPACITY. Give yourself some flexibility, someone might get sick.
I’m live here at the LA Agile Success Tour with the success stories of our panelists. In my next post, I’ll cover the Q&A.
Israel Gat – Cutter Consortium member on Agile, former VP from BMC, IBM, Microsoft and EMC
Software is becoming pervasive in our lives. The key will be how we align the functionality of that software with what the customers actually need, not our guesses about what we think they might need.
A key component of this is agility in the process between developing software and getting that value into our customer’s hands. He used Flickr and IMVU as examples of the power of using constant deployment as a method to effortlessly deliver software, and ultimately value, to customers.
Introduced to Agile in 2000 as a reaction to his “death march” experience at another company, where his team worked 100-hour weeks. He moved into a development management role and took on the goal of delivering projects on schedule, in a way that was healthy for the team. One of his development leads discovered the XP methodology and they never looked back.
Tracking project metrics was an important part of his role at one company. He shows empirical evidence of the benefits of Agile. With waterfall, time = 31 weeks, 16 critical defects and 153 stories. With Agile, time = 19 weeks, 0 critical defects and 234 story points. He was most proud of 0 critical defects into the market.
Benefits from Agile – faster development, more manageable codebase, fewer defects. Industry average is 15 to 50 bugs per 1,000 lines of code. With each release, through refactoring and Agile development, they are decreasing the size of their code base. Yes, that’s right, more features, with higher quality, with 100,000 fewer lines of code.
Laureen Knudsen – Sr. Dir. of Program Management at Qualcomm
The Denver Agile Success Tour continued with four open space sessions. For about 20% of the room, this was the first open space session they have ever participated in. Groups broke into discussions on leadership, testing, scaling and tooling and then did a read-out to share their conclusions with the larger audience. (For my other live posts from the Denver event, see 5 Stories of Agile Success and What’s On Your Mind?)
#1 Open Space – Executives and Agile Adoption, led by Israel Gat
This group included new as well mature Agile folks and teams of 9 to 280 people – Given that spread, there was an overwhelming agreement that “our executives do not understand it” and “I, the executive, wants the whole iron triangle fixed – time, budget and scope.” For executives who do not understand agile, it is very hard for people to communicate “What is in it for the executive?”
Conclusion – Socializing Agile is as important as doing Agile well. Your adoption will regress if your executives are not sold. Without time spent with executives, there is a bitter slide back down coming for the team. A slide like this is really hard to recover from.
Recommendation – At the point of scaling your agile adoption, contract up-front with your executive on the results, but only pick only one dimension. (Productivity, Time-to-Market or Quality)
#2 Open Space – Testing, Quality and Leadership, led by Zach Nies and Peggy Reed from Avaya
Topic time spent on willingness of test teams to move to Agile and what does pulling testing forward mean? Can I be Agile if I do not test inside the iteration? At Avaya, they do a lot of testing outside the iteration due a large matrix of configurations.
Conclusion – Make sure testing team is at iteration planning and release planning. Always honor your time box and retrospect on your testing coverage.
Recommendation – Focus on making story sizes smaller to bring testing into the iteration.
#3 Open Space – Scaling and Large Scale Adoption, led by Evan Campbell
Topics focused on collecting metrics while the guerrilla insurgency is working and before they get “busted” doing Agile. The result of not collecting metrics means getting stuck in an “Agile Ghetto.” Top-down adoption approaches are becoming more common, but came back to Rally’s Enterprise Adoption model called Flow-Pull-Innovate that is based on Lean.
Conclusion – It is inevitable that you are going to have to evangelize the Agile adoption. Start building the case from day 1.
Recommendation - Focus on the change management process for large scale adoption. Practices are a key focus for small teams, but not the key focus of large scale adoption.
#4 Open Space – Tooling Agile, led by Karen Kagiyama and Amy Wiley
Tools enable best practices, and integrations are inevitable because one tool cannot support all types and nuances of development teams and technology needs. Continuous integration, build management and test coverage metrics and reports correlate into the context of iteration, release, and program of teams are critical for know “where are we right now?”
Conclusion – The ultimate goal is a single dashboard to support the insights and planning.
I’m live here at the Denver Agile Success Tour on yet another warm, blue sky day downtown by the Convention Center. I will blog what I pick up as the key takeaways from our speakers and after the event we’ll get them to chime in with their own thoughts.
A Modus of our Time – The industry has “One foot in cold water and one foot in hot water”
Tons of enthusiasm about Agile given years of outsourcing, while also having lots of hard data showing how time-to-market, productivity and quality are improved with Agile.
But, still falling short by not pulling in the customer. We assume we know the customer problem and work hard to develop the solution. The speed and reach of software is immense.
Ray Bagley – Director of Development of 3D Modeling solutions at Spatial
Spatial – 20 year old products with 4 million lines of code. Developers spread across 3 offices (Colorado, UK, Pune). Top-down adoption started with a new VP two years ago.
“Product Owner is not Product Manager” – Read all the books on Agile. Early on divided up the product managers to support multiple scrum teams, but tons of pathology happened. The Product Managers stopped looking outward! Then, a collision of two product managers on one product. Finally, the senior and highly skilled development team felt like they lost all their decision making and influence.
Iteration 2 – Created Meta Scrums that met every two development iterations and life got much better. Added more product owners. Life is much better thanks to Rally and Enthiosys content - I wish we had found that material two years ago!
“There is a difference between a real customer and a virtual customer on two different products” – “Real customers engage on day 1, not with a beta!” The case of these two products was night and day – night (solved the wrong problem after 8 months) and day (driving revenue from the first release).
“Humble lessons learn the hard way!”
Lloyd Star – VP Development at Beatport – Digital download network like iTunes but specifically for DJ’s. Several internal teams and two offshore teams in India with stakeholders in Denver, Berlin and London.
20 months into adoption – “Many great changes, but far from complete with our adoption.”
There have been four clear “states” of our Agile adoption so far. (Cool state transition diagram of these states – If you read this blog often, you know how much I love state transition diagrams for Agile adoption. It is really about taking incremental moves to change the engines while the airplane is in air!)
State 1 – Iterations and weak backlog. Just jumped in, but we did not whip our quality issues and 3 week release process.
State 2 – Discovered the Product Owner role and the value of meetings when way up (CEO and CTO are both DJ’s and act as customers). “We understood the need for well elaborated stories and acceptance criteria.”
State 3 – Got the stakeholder more involved and made the backlog more clear and stopped over-elaborating far off stories. “The best part is the collaboration and negotiation went way up!” The art of software was starting to appear and drive trust across the company.
First two states were focused on the software team, but now states 3 and 4 are focused on the larger team and company.
State 4 – Integrating vision and release planning to drive enterprise architecture. Moved Research into Development and got IT/Operations team in synchronization with the development release cycles. Huge increase in throughput of new working code to market.
See what State 5 of the transition is but have not started this. All focused on enterprise architecture in state 4 to manage all these moving pieces and keeping them aligned with the business. Don’t confuse the Agile development process with the architectural process.
Clear call to actions:
Keep your release small and focused
Hired a very experienced Agile product owner
Have your architecture “live with your team”
Planning takes time, but it critical for alignment
Peggy Reed – Director of Performance Solutions at Avaya – 30 years of experience in software started in 1979 in writing Motorola code
Beautiful Software – Readability, Simplicity, Functional Locality, Single Function, System Minimality, Appropriate Form, Cooperative
NOT DOES IT WORK! – Is it pleasant, comfortable, seductive? It has to be something a customer wants to use!
Beautiful teams make beautiful software – Needs shared vision, deep understanding, harmony in the Scrum, empathy of the customer perspective.
Beautiful teams must – Keep the base stable through Agile development of frequent public builds that integrate across the whole. Have to always be testing with an equal balance. Completion is a measured by ALL parts of the team. Sometimes this is hard for existing teams to break the old habits.
Beautiful software teams talk a ton about their failures. What we wished we had done. Talk about dependencies on each other. Talk about feature-itis and which features really drive revenue. Talk about teamwork and team awareness. No longer software development by solos and prayer.
Value of us comes from creating beautiful teams that create beautiful software in a creative way – a way that can not be outsourced or automated!
Peter Fisher – MIS Product Manager at eCollege – Working on Scrum for the last two years Pearson eCollege online learning with teams in Denver and Sri Lanka
Were a very large waterfall team with huge business requirements document – Informal adoption started in 2007 and formal training started in mid 2008. Four releases since mid-2008 versus 1 and no more “bug builds.” Have been able to build the quality in from day 1.
Now developers are focused on building what they need to meet the tests and not their own vision. Key to this was delivering to the integration server continuously. As a result, the “come backs” of release went way down. Only released to staging and production once.
This dramatically increased the speed of the team and clear visibility has allowed us to react at each two week iteration with strict prioritization. As a result, were not delivering the wrong or unwanted features. Throughput is going up.
Israel Gat – on his adoption experience at BMC Software
Four simple principles make the secret sauce of enterprise scale adoption at BMC. It is all about mindset and not the practices.
In year 1 from zero to 350 scrumers in Rally at BMC. He now showed the Cutter Consortium / QSMA slide of BMC Productivity Index of 27 versus an average of 6 to 16 in other software types.
“How many of your teams come to work on Monday determined to produce poor quality software?” Agile teams do not have this mindset.
Principle 1 – Leadership and social contract with the team.
Principle 2 – Know How – I used Rally with a 50/50 spend on professional services and coaching while the other 50% was used for Rally’s application – this combination was critical to go as fast as we did.
Principle 3 – Flexibility - You have to take the adoption incrementally and iteratively.
Principle 4 – Patience - You can not Agile the Agile – you are changing the software, the process and the organizational structure.
I’ve been talking with colleague and friend Israel Gat about the upcoming Rally Success Tour March 18 in Denver. In anticipation of the event, Israel has been talking with some of the people to be involved in both a panel discussion and breakout sessions. One of the panelists, Peggy Reed, R&D Director of Performance Solutions with Avaya, is someone I have known for several years. With 30 years in the software industry, Peggy has expertise in many areas of software development. This includes enterprise integration, data visualization, data warehousing, and product development. She began her career in 1979 writing Motorola assembly language and has since moved into development management. She holds a degree in Computer Science from Colorado State University.
I know of Peggy’s passion around organizations, teams, software, and Agile in particular. She holds a conviction that this Agile forward thinking is the true foundation of delivering better software faster. So, it was great to hear from Israel that Peggy spoke with him about something she calls “Beautiful Software.” I had an immediate warm reaction to this! Only Peggy could come up with such an intriguing notion about software.
In this post, I interview Israel about that very enticing notion that Peggy mentioned to find out his reactions and experiences in the world of “Beautiful Software.” We promise to not giveaway any spoilers from the upcoming event. We just want to poke around what ideas come to us with the term “Beautiful Software.”
Jean: Israel, thanks for joining me here. First of all, could you tell us a little about yourself?
Israel: I was born and raised in Israel. I served in the paratroop corps there and fought in the ’67 and ’73 wars. I came to the United States in ’76 and have lived here for most of the time since. I thought it would be good when I came in ’76, but little had I realized then how good it would actually be. I am very thankful to the country and the people for helping me make the United States my home. I actually feel that by sharing my Agile expertise I pay back my “debt” to the United States and to its software industry. For the better part of my professional career I have been doing system management. Since I got exposed to Agile in 2003, my passion for it has been steadily growing. About two years ago my passion for Agile had surpassed my passion for system management. As of the beginning of this year I am devoting all my cycles to Agile, particularly with respect to consulting and coaching on enterprise level Agile deployments.
Jean: Great, Israel. Can you tell me about some of what struck you most about your interview with Peggy?
Israel: The PASSION. While I could not see her body language (this was a telephone interview) her passion for software was radiating through the receiver. I felt privileged and honored to speak with a professional who put so much of both her mind and her heart to software.
Jean: Thinking about Peggy’s passions and then about your own experience in the world of software, how do you think this term “Beautiful” applies? I mean, isn’t it a rather provocative and unusual description to ascribe to software?
Israel: I had a revelation many years ago when I first read the Cluetrain Manifesto: The End of Business as Usual. I realized then that I was a craftsman, not an assembly line worker. A true craftsman is proud of the intricacies of his/her work, striving for excellence and elegance while respecting the nature of the medium with which he or she is working. To borrow the title of a recent book, a software craftsman dreams in code. This sense of great discovery I had savored so long ago (while reading the Cluetrain Manifesto) was rekindled in me while I was listening to Peggy.
Jean: I don’t want to give away too much here about what Peggy will bring us next week. Still, can you tell me where, in your experience, a notion of “Beautiful” impacts organizational structure and business motivators?
Israel:Jim Highsmith talks of Intrinsic Quality versus Extrinsic Quality. Peggy’s notion of the beauty of the software is in some ways conceptually similar to Jim’s Intrinsic Quality. It is like the visceral feeling you get while holding an iPod in the palm of your hand – you know you are touching something very special! I will restrain myself not to get deeper on the subject here as I might unintentionally steal some of Peggy’s thunder. I definitely plan to dive deep into Beautiful Software → Intrinsic Quality topic during the March 18 event in Denver. Stay tuned…
Jean: Well, thanks Israel for giving us some of your reactions and feedback. For people in the Denver area, I encourage you to come meet Peggy and the other panelists yourself March 18 for more about Agile adoption, Agile practices, and yes, even “Beautiful Software.” Meanwhile, Israel and I will check-in here again after the event to report how others learned about and reacted to “Beautiful Software.” See you then!
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.
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
Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output. This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.
And the number #1 Characteristic of an Agile Organization is…
