Agile Development Blog

This post has been a long time coming. I’ve started and restarted it at least a half-dozen times.

Quality – there may be no more multi-faceted and powerful attribute in successful software development. Quality is central to everything we do and seek.

• Higher quality leads to greater productivity, throughput and velocity
• Higher quality leads to increased responsiveness, reduced cycle-times, shorter lead-times
• Higher quality leads to improved customer satisfaction, employee satisfaction
• Higher quality leads to better predictability, reduced risk, improved decision making

Or at least that’s my hypothesis…

And that hypothesis is widely shared amongst the Agile and product development communities.  We’ve developed numerous principles, practices and techniques intended to improve quality:  Test Driven Development; Continuous Integration; Automated Build and Deploy; Pair Programming; Customer Demos; Behavior Driven Development; Acceptance Test Driven Development; and Set-based Design techniques are all at least partially focused on yielding quality improvements.

But quality can’t simply be viewed as a set of tools and techniques – independent variables/levers which we hypothesize will lead to improved business outcomes. Quality is also a business outcome unto itself.

This series emphasizes the need to focus on business outcomes (success) first – methods and practices second.  So, putting aside the methods and good practice assumptions of Agile, and focusing solely on the business outcome of improved quality:

Quality = Fewer Defects in Production

We apply Agile quality practices and techniques, because we believe that doing so will yield improved business outcomes – quality (fewer defects in production) being one of those outcomes – along with productivity, predictability, responsiveness, customer and employee satisfaction.

Large, manual, end-of-cycle execution of formal testing by an independent QA organization is also a method aimed at improving these business outcomes. I hypothesize that it is less effective than alternative Agile techniques. But I don’t take that on faith, and neither should you. We must test our hypothesis.

How Do We Measure Quality?

There are innumerable quality metrics that have been devised over the years – each with its own strengths and weaknesses.  In my experience, it’s important to keep metrics simple, and to not let great become the enemy of good enough. In other words, if you have a metric that does a good job of providing insight into the quality of your product/solution, and is simple to collect and interpret; that is likely better than chasing after a metric that will do a great job, but would be more complicated.

For my part, I’ve had success over the years using a couple relatively simple metrics:

• DEFECT DENSITY – # Defects / KLOC
• DEFECT ARRIVAL – # Defects Identified / Month

What Do We Consider a Defect?

In both cases, I include only defects in the production system.

Measuring defects found and eliminated during the development cycle may be useful for managing your development and quality processes.  But from a business outcomes perspective, our focus is reducing the number of defects that make it to production – not making assumptions about how or when to achieve that.

Not All Defects Are Created Equal

Any good metric should drive in more questions than answers.  I find it useful to tag defects with information about type and severity, so that we can consider some of those questions more deeply.

• Our defect density is high; but our severity 1 & 2 density is low. What is the impact on other outcomes (productivity, customer satisfaction, etc.) if we were to invest in reducing our low severity defects?
• Our defect arrival is very high immediately following a major release. But the defects are mostly Type = Usability. Why are our customers having such a tough time using our new features; and how can we ease them through the learning curve?

You may have some hypotheses based on these questions. Perhaps those hypotheses involve application or improved use of Agile tools and techniques. What experiments would you run to prove or disprove your hypothesis?  What new questions will those results yield?

This is the third post in our blog series, Measuring the Impact of Your Agile Investments. The series focuses on measuring the impact that Agile practices have on business outcomes.

Isaac Montgomery is the harried father of twin sons, a frustrated hack on the golf course, and an Agile Coach at Rally Software. He blogs at Leading Results, you can follow him on twitter at @iwmontgomery

Please help us find qualified candidates for an exciting new opening at Rally’s Boulder headquarters.  With compounding user growth, seven agile teams, four product lines, two development locations, as well as multi-tenant SaaS and on-premise deployments, it is time for us to hire a VP to help us continue to grow and thrive.

We have managed with various folks playing parts of this role over the last seven years, and now we need to add a skilled, servant leader and operator to our senior team to enhance functional management across the software value-delivery chain.

This person will be part of our senior management team and be responsible for all technical engineering and operations. As a peer to our VP of Products and supported by Zach’s four product line managers, you and your teams will collaborate with these managers to advance the product portfolio components and overall strategy.  This person will work with a world-class team of software, systems, operational engineers and scrum masters.   Service Level Agreements (SLA) with customers will measure success in this role with the goal of increasing overall engineering resource development, mentorship and flexibility to meet evolving products, features, and architectural needs.  Our intent is to continue growing this part of the business through organic, development partners and acquisitions.

A major part of personal success in this job comes from thriving in our culture of team collaboration, personal responsibility, high ethics, social give-back and intrinsic motivation.

If this sounds like you, we would love to hear from you via the career section of our web site. There you will find a detailed job description as well as other benefit details.  (If you are not quite ready to apply, but want to have a quick confidential conversation with the management team, please send email to vpengops@rallydev.com. No recruiters please).  If this is not you, but you know someone who might be interested, please share this with your friends and with your networks using the “ShareThis” button below or through our LinkedIn post.

We are very excited to find the right addition to this agile engineering and operations group.

Ryan Martens is a the CEO of the Entrepreneur’s Foundation of Colorado, and CTO at Rally Software Development.

Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:

“We don’t have enough time to test, because the developers give us working builds way too late in the cycle.”

“I wish our quality was better, but it’s out of my control to change anything.”

“Poor quality must be our fault as testers, since we are the ones responsible for testing.”

“We should test more, or we should develop slower, or we should specify our requirements better – that should improve quality.”

Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are getting in the way of achieving higher quality.

You can certainly improve quality through changes in process (and many of those changes are at the center of Agile adoption), but more often when people ask me process questions, I hear teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.

The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of learning and improving.

It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings.

All of these thoughts prevent you from taking responsibility and ultimately moving into a mindset of learning and acting. Sound familiar?

This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.

To learn more, I encourage you to join me and Christopher Avery for our January 12th On Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about :

• the relationship between quality and ownership
• the difference between accountability and ownership, and how this difference affects quality
• how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
• how to apply the Responsibility Process to your development team

I’m really excited about what we’ve put together for this and would love to see all of you attend.[Reserve your spot now by CLICKING HERE]

About the Author: Zach Nies is a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.

Don't let this be your user!

Recently, my Rally colleagues Ben Carey and Ryan Martens delivered a great webinar about testing and quality.  What particularly struck me about the session was how Ben set up why we should, at a very personal level, care about testing and quality.

Enter Amy and her daughter Morgan.

As Ben told the story, Amy was a back office admin in a physician’s office. It was her responsibility to get billing out to insurance companies for the practice, and on one particular day, things were not going well.

She kept getting cryptic error messages. The batch just wouldn’t go through. Stress mounted. To add to Amy’s distress, it was nearing time for her to pick up her daughter Morgan at school. Morgan had just started school. Only 4 weeks in, Morgan was suffering some separation anxiety. Amy felt the urgency to be there for Morgan as soon as school let out. And yet, she was stuck at her desk dealing with these insurance issues.

Why should Ben be talking about Amy and Morgan in a webinar about testing and quality? Because Amy was Ben’s customer. Ben was on-site to see how his software was supporting the practice. And so, he personally felt Amy’s mounting stress in using the software HIS team had delivered and HER doctor’s office had paid for. When Amy started to cry, it was all over for Ben. He had to do something.

What does Amy and Morgan’s story tell all of us?

1. Users deserve better than this.

2. On an Agile team, quality is everyone’s job!

We often think of testing as an issue for the tester role alone.  But this stance sets a number of bad dynamics in motion:

• When we don’t fix defects, we declare doneness by “hiding” defects in a defect backlog
• Hidden defects accumulate into hidden technical debt
• Technical debt slows down our ability to deliver subsequent releases
• An ever-increasing defect backlog can be demoralizing for the entire team
• Engineering resents the business when being forced to deliver features when the engineers know defects exist
• Business resents engineering for not being better and faster at building features
• Testers resent testing left until the end because it puts business, engineering, and testing in a tight spot

So here is a thought: quality is not just an engineering issue; it is a systemic issue. That is, it is driven from the top down in a business not from within one part of the organization. A business policy about quality impacts our users by directly impacting their quality of life. Amy’s stress about picking up Morgan from school could be traced back to a testing and quality policy in engineering that was driven by a policy in the business: get features out.

As you adopt Agile, work vigorously to create rigor in your testing and quality goals. Why? Because your policy can hit hard in ways you don’t currently track. Pay attention to more than just the internal cost of technical debt. Let’s pay attention to the quality of life of our users.

The next time you are logging a defect versus fixing it, don’t forget about your Amy and Morgan.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Introducing Rally's Engineering Blog

As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.

This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.

I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams.  It is unique because of the open authoring model for all members of a fast growing set of agile teams.

With 15 posts published, and many more regular contributions on the way, I invite you to join me as a new subscriber to Rally’s Engineering Blog (click here to subscribe and here to visit the blog)

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Your company is insane and you might be insane, too.

I bet you’re suspicious right now, aren’t you? You think this sensational opener is there just to suck you in and get you to read something that’s totally unrelated. Well, I mean what I said. Let me explain.

There’s this old joke. I think it’s a joke. Maybe it’s a saying. Or it could be an adage. I’m pretty sure it’s not an axiom and I know it’s not a koan. Hmmm. Might be a riddle. Anyway, where was I?

Oh yeah. The joke. It goes like this:

Q. What’s the definition of insanity?
A. Doing the same thing over and over again and expecting different results.

OK, so maybe “joke” was stretching it a little, but it is kind of pithy, don’t you think?

Why do companies want to adopt Agile methods? After all, it’s expensive and painful what with all the training and change management and readjustments and FUD (Fear, Uncertainty, and Doubt) and so forth. And why do people come to CSM courses hoping to find new ways to build software? Because they’re bored and they want to get into arguments with their management? Probably not.

I think the reason is the same for both. It’s because pretty much everybody wants better (different) results from their software development efforts. Management wants more software to sell, and they want it to be higher quality, and to arrive faster, and to be more liked by their customers.

Employees would like at least an even chance of succeeding in what they do, and they’d like to feel like they are contributing the best that they have to offer as a valued part of their company. They want to feel like an accomplished, highly skilled professional and not some interchangeable cog in a soulless production machine.

OK, fine. So far so good. Everybody is aligned. It’s win-win all around. What could possibly go wrong? Well, here comes the funny part. Nearly all companies, nearly all management teams, and many employees don’t seem to understand that getting different results is going to require doing different things, or doing things differently (I’m not sure if those two are the same or not).

When I’m teaching the CSM course or introducing Agile at a company, the minute I bring something up that is actually, obviously different from what they are doing today, somebody gets upset.

When one of my students gets upset, they start raising objections such as:

“Oh, well, we can’t do it that way at our company.” (Betcha you can.)

“That’s not how it is at our company.” (Isn’t that what I’ve been trying to tell you?)

“But what about having the complete architecture before I start? I have to have that!” (Should I do this the nice way or the mean way?)

“We can’t do all of that testing. We don’t have testers.” (Gosh, I hadn’t thought of that. I guess you’re right. Just do the Agile without the testing and you’ll be fine. I’m sure no one will notice.)

“We don’t actually have anybody who could be the Product Owner.” (Do you hear what you’re saying?)

“We have a very mature phase-gate development process that we have to keep in place as we move to Agile.” (Say what????)

“I’m a manager and I’m paid to leverage my maturity and experience by telling people what to do so they don’t make mistakes. I’ll be doing that with the Agile teams, too.” (Don’t roll your eyes…don’t roll your eyes…)

“Our QA is in a separate group and they won’t talk to us until we have a complete set of specs to give them.” (And how’s that working for you, and them, and your company?)

And on and on and on. I talk about this when I teach Agile to new teams or new CSMs and CSPOs. Then later on during the class, when they start in with this stuff, I can get away with saying:

“Oh! So you mean your company is insane. They sent you here to learn a new way to build software, but they won’t let you build software in a new way!”

This is fun because I get to call companies and my students insane in a way that’s fun and also makes a point.

What to do about this is a serious question for those of us who coach, train, consult, or champion Agile within our organizations. Teams tend to get it, but I fear that companies of a certain size tend not to get it. And they keep not getting it while their Agile adoption loses steam, fails to deliver as well as it could, and finally fades away entirely. This is where many of those “scrum failed” stories come from. What happened was that in reality, they didn’t really try scrum because they were afraid to change anything.

Your company is insane because what they wish is that you could somehow get all the benefits of Agile without making any difficult or scary changes. You might be insane because you think some things can’t be changed and we can still get the benefits of Agile without changing them. As long as either you or your company is insane, neither of you will get the benefits of Agile adoption.

I guess that’s all I wanted to say.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last Thursday, Ben Carey kicked-off our latest and largest webinar on the topic “How Teams Succeed with Agile Quality and Testing.”

Thank you everyone for the great compliments; a majority of the compliments should go to Ben, Jessica, Bob and the folks from SQE for the quality effort.  Thanks to these great folks, it was technically perfect, visually pleasing, entertaining, impacting and backed up by great supporting content.  If you missed it, you can see the video reply to this webinar.  You can find the supporting content under the Learn Agile part of the Rally web site.

Following that webinar, I saw a twitter post from one of our customers about the meeting they had following our webinar. This “Lunch and Learn” session allowed the team to reflect on what the heard immediately following the webinar.

“Having a post-webinar discussion with our SQA group on the #rallydev seminar. Nicely done @RallyOn & @BenCarey”

This is a great example of self educating on this topic.  It is the first of four steps that we recommend in the webinar:

1. Self-educate and discuss to set the context
2. Find an external driver for your change to keep from having drifting goals (customer, competitor, benchmark)
3. Make a commitment as a team to move forward
4. Find your first practice to adjust and adjust just that one only

If you liked the webinar and content, I encourage you to set up a lunch and learn to view and discus these topics on your team or program.  If you are interested in more depth, you might consider our next webinar in the series, Pulling Quality Forward: Agile Testing and Tooling for Embedded Software Development. The live presentation will take place on Wednesday, September 30th at Noon MDT with Zach Nies, VP of Product Development at Rally and Paul Henderson from WindRiver/Intel .  You can register on-line and learn more about the details.

I have found the quality topic to be great for team lunches.  It is can be a sticking point especially for functionally divided teams and quality has to be owned by the whole team.  I encourage you to take advantage of either of these webinars to hold a “lunch and learn” topic for your team. Maybe after your next demo and before your next retrospective.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

#3 in our list of the Top Characteristics of an Agile Organization is Quality and Faster.

Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.

Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.

For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…

Nipper on RCA's first color tv set - the CT 100

Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.

Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?

And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?

In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.

That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.

And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.

We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making and #4 Flexibility and Rhythm. Stay tuned for #2 “Creating Your Own Reality” and Corporate Vision.

The LA Agile Success Tour concluded with 5 open space sessions. For my other live posts from the LA event, see:

• 5 Stories of Agile Success
  
• What Would You Ask Your CEO to Bring in Agile?

Did you find these posts valuable?  Any advice on how we can improve this for next time?

Agile 101, led by Christophe Louvion

What is your pain? Command and control, changing priorities during the sprint, hybrid process, making decisions outside the team that affect the team, improper tooling, moving resources around.

Root causes: Lack of self organization caused by lack of education, lack of an Agile driver, internal or external customer pressure, lack of executive vision, fear of change, skill set mismatches, ask teams to do things that don’t work well, lack of action items with a clear owner and clear deadlines.

Christophe had people in his breakout commit to action items. Christophe is going to call each of these people and verify if they accomplished their action items, like Lisa who committed to requesting a coach to come into their company and help them with their hybrid Agile process.

Get something small, but get it done!

Socializing Agile, led by Israel Gat

Pains: The sausage factory syndrome, the business doesn’t want to know how the software is made, but give me what I ask for when I need it. Market dynamics like drops in ad revenue and other drops in the market.

Solution: Innovation is now affordable because we can all experiment, try something in your sprint and if it doesn’t work out you only have 2 weeks invested. Read the book Innovators Dilemma by Clayton Christenson.

Risk management is important to executives, and Agile reduces it significantly. Money quantification, understand the value of what you’re delivering. Look at Capers Jones and his 2008 book Applied Software Measurement and his 2007 book Estimating Software Costs.

Agile Governance and Compliance, led by Laureen Knudsen

Pains: People live in rigid environments and don’t want to change. People don’t want to show their work because it’s too raw and there is fear around failing fast by validating your work with actual customers. There were questions about what is the earliest point to show things to customers.

Agile Collaboration, led by Jean Tabaka

Organizationally what is happening to enable collaboration? Organizations need to communicate down about vision, and the teams need to communicate up areas of process improvement. There was talk about servant leaders, and how command and control managers actually make people dumber. Most Agile teams start with iteration planning, standups and the end of the iteration demo.

Jean has a different view, called the 5 Levels of Planning.

Start with a Vision, this is the first level of planning that the leadership team owns.

Then move to a Roadmap where you talk about themes of releases. It’s important to talk in themes and the Product Council is the feedback mechanism for that process.

Then Release planning is next. It is important for everyone to be involved in the Release planning.

Then think about taking the Release theme and how the Iterations build toward that goal.

Then Daily examine what you did toward that goal yesterday, what you are going to do today, and what is getting in your way.

Each level then provides a feedback loop to the higher level of planning. At Rally everyone is involved in these 5 levels of planning within every department in the company.

Quality and Testing, led by Zach Nies (me)

Pains: Integrating testing teams in with development teams, making testing teams more effective and how to introduce Test Driven Development into the development team. An important way to integrate testing and development is to integrate and involve both roles in planning sessions. Testing should be part of the definition of done and involve testers in creating a story’s acceptance criteria.

The group talked about how to break down the walls between testers and developers, by focusing on the reality that everyone owns the quality of the software being developed. When testing is integrated into the process it makes them more effective. Finally, a few teams are trying to use Test Driven Development. Test Driven Development can’t be imposed onto the team, the key developers on the team need to lead by example by embracing TDD practices.

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:

1. Either through a team-by-team, grassroots approach as demonstrated above
2. 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.