Agile literature focuses on the benefits Agile provides to developers and development teams, with a secondary focus on the benefits Agile provides customers. Much of the Agile literature also asserts that Agile practices are more responsive to business needs.
Many businesses are embracing Agile and seeing significant benefits. Many other businesses are embracing Agile and regretting it. Why the different results?
A Cautionary Tale of Agile Development
At a previous Construx Software Executive Summit, one of the executives attending the event told the following story. In 2001 a major division of a well-known software company embraced Extreme Programming (XP) as the development approach they would use for a product development initiative involving a technical staff of about 200 people. The development team followed XP closely. They developed their software in short iterations. They sought close collaboration with customers and customer representatives. They kept quality high at all times. They had working software to demonstrate throughout the project. They were highly responsive to customer inputs and agile in changing direction based on those inputs.
Development went on for about two years. While the team was being highly responsive to customer input, that wasn't good enough. The cumulative total of its work was not converging to anything resembling a saleable product. Eventually the company concluded that the team was never going to produce a product, at which point most of the 200 people were laid off and the company reported a $50 million loss on the project.
What Went Wrong?
For this business some of the specific practices in XP were simply not well matched to the company's business needs. In particular, XP's emphasis at that time on defining requirements only one iteration at a time didn't provide for an overall product vision (aka roadmap, aka product definition) that would result in a compelling product. Many of the other XP practices probably worked fine. But the lack of comprehensive requirements combined with an emphasis on "embracing change" just enabled the company to move more quickly in the wrong direction. For this company, contrary to the Agile Manifesto, "responding to change" was not more important than "following a plan."
This is representative of other misfires we've seen in implementing Agile development. Technical leadership assumes Agile equals "good." But Agile doesn't equal "good"; it equals "more suitable for some circumstances" and "less suitable for other circumstances." Applying Agile in the wrong circumstances can cause major problems. A related issue is that "Agile" has become quite a large umbrella that covers dozens of specific practices. The more time goes by, the less useful the Agile buzzword becomes and the more meaningful it is to discuss specific practices instead.
Agility and Predictability
True agility--which means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands--conflicts with predictability. Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable. This was the problem that the company in the cautionary tale experienced. They got flexibility, but what they really needed was predictability.
Whether agility or predictability is more important depends both on what a business's customers are requesting and on how long-range the request is. Customers say, "I want this capability." In an ideal world, the business will be able to say, "OK, here it is right away." Being able to say "here it is right away" is what agility is all about.
Sometimes the work is too big to say "Here it is right away." In those cases, the business needs to say something like, "Sure, we can go that direction. This is a big piece of work and we can have that ready for you 22 weeks from now." That is where predictability starts to matter. When you say you'll deliver something in 22 weeks, you'd like to know that you really will deliver it in 22 weeks.
Agility and Multi-Site Development
Multi-site development has become increasingly common during the same period that Agile development has been on the rise, and these two trends are not always compatible. When a client tells me "we want our distributed teams to be more Agile," warning buzzers start going off in my head. Of the dozens of practices that can be called "Agile" some will help multi-location teams and some will undermine them.
Agile development commonly includes the major focuses of reducing paperwork, increasing the frequency and bandwidth of face-to-face communications, and emphasizing informal, incidental communication. Those focuses inherently run counter to spreading people out geographically, which reduces face-to-face time, reduces incidental communication, and in general reduces communication bandwidth. So some Agile practices are not a good match for multi-site teams.
Many other Agile practices can work fine in multi-site teams. For example the practice of breaking work up into smaller chunks and delivering it more often than has been done traditionally is an Agile practice that provides discipline that's valuable to multi-site teams. Other valuable practices include daily builds or continuous builds, daily stand-up meetings, automated regression testing, developer unit testing, time box development, small cross-functional teams, intensive short-term planning, involved coach/manager, and frequent retrospectives, just to name a few.
Introducing Agile Practices to a Business
When we introduce Agile to a new company the first thing we do is make sure that Agile software development is really what the business needs. Because "Agile" has become an all-encompassing term, we encourage our clients to be specific about what benefits they are looking for. If Agile turns out not to be what the business really needs, we work on building strengths in other areas.
With companies that do have a business justification for Agile, we look at specific practices:
- We identify which practices will best address the areas that are experiencing the most pain.
- We determine which specific Agile practices are going to provide the most bang for the buck for that company.
- We assess which Agile practices have the highest chances of being accepted within that company's existing technical culture and business culture.
The software industry has a long history of taking good, incremental improvements in development practices and then overextending them. Agile development is not the exception to the rule. In many cases, Agile development practices can help companies raise the bar on their software development efforts. By focusing on business needs first, and technical solutions second, companies can avoid Agile becoming the proverbial "solution in search of a problem."