Agile Software: Business Impact and Business Benefits

  1. Posted on July 29, 2008 12:38:PM by Steve McConnell to 10x Software Development
  2. Methods & Processes, project management, Agile, Management

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."

Corey Reid said:

July 29, 2008 2:09:PM

>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.

Of course, the waterfall methodology doesn't really do a better job at this. I absolutely agree with your comments on how not all Agile practices are suitable to all development situations -- XP, for example, suits systems development better than product development -- it has real problems making space for a marketing plan and a roll-out (things you need some real predictability to manage properly).

Commercial product development needs a strong driving vision, and a lot of Agile practices don't make room for that need. I'm in the process of leading a product team into some Agile practices, but we really had to strip everything down to the "bare metal" of the processes before we could start layering on process, and it's still not clear exactly what processes we're going to need.

The biggest lesson I've taken away from the development of Agile methods is that there is no One True Way for software development -- and that means teams have to be always assessing their own processes and adjusting them as time goes by. There's just no substitute for people paying attention to what's happening around them.

Aaron Korver said:

July 29, 2008 3:39:PM

I'm a little confused.  XP is an engineering practice.  So your story is saying that 200 engineers used XP.  They were able to have working code.  They were also able to produce what the business wanted.  But the project ultimately failed, because the business felt there was no plan?  

Is that the fault of "agile" or is that simply a Project Management problem?

I don't think it matters what software development process is used if there is no overall vision of what we are building.  Given your description of the project, I question if the project should have even been started at all.

Steve McConnell said:

July 29, 2008 3:47:PM

> Of course, the waterfall methodology doesn't really do a better job at this.

I think it's important to remember that Waterfall and Agile aren't the only two options. "Agile" is a very large umbrella that includes many, many practices. "Waterfall" is one specific way of approaching projects that's in the broader family of "sequential" development practices. Staged delivery, spiral, and design to cost are three other members of the sequential family. I agree that waterfall will only rarely do better at providing predictability than agile practices will. But there are other non-Waterfall practices within the sequential family that eliminate 90%+ of the weaknesses of waterfall and that are more applicable than full-blown agile practices in many contexts. (By full blown, I mean like the project in the cautionary tale--fully iterative requirements, etc.)

I agree iwth your conclusion--There is no One True Way. When people think about the fact that there's software in toasters, airplanes, video games, movies, medical devices, and thousands of other places, it seems kind of obvious that the best approaches are going to arise when people pay close attention to the needs of their specific circumstances and then choose appropriate practices.

Steve McConnell said:

July 29, 2008 3:54:PM

Aaron wrote:

> They were also able to produce what the business wanted.

The point is they *didn't* produce what the business really wanted. By getting their requirements in such a piecemeal fashion they always saw the trees; they never saw the forest. I.e., they never got the right big picture. So they never learned what their business really wanted because the specific way XP goes about gathering requirements isn't well suited to the kind of project they were working on.

I agree that poor project management was a contributing cause to the problems. But the specific XP technical practices didn't provide a safety net for the bad management; they actually made the problem worse.

> But the project ultimately failed, because the business felt there was no plan?

Not quite. The project failed because it went for two years without getting close to producing saleable software. One of the underlying causes of that was lack of planning.

Keith Braithwaite said:

July 29, 2008 4:29:PM

This 200 person project sounds like a terrible botch, but what has it to do with "agile"?

For example, where did anyone get the idea that XP has an "emphasis on defining requirements only one iteration at a time"?

I don't like appeal to authority much, but it seems apposite here. In Extreme Progamming Explained (2nd ed) Beck talks quite explicitly about planning a quarter ahead, with the clear inference invited that you have enough stories around form which to select only that subset that you think will be delivered in the next three months. And that there will be several quarters. That's very different from having stories for only the next iteration. Someone hasn't read the book. What other basic research did they not do before embarking on this project?

And where did anyone get the idea that XP by itself will work for 200 staff? That's at least an order of magnitude too big and anyone with any experience of XP would have been able to tell them that.

This looks to me like a story about bad management decisions made in the name of a casually chosen and wildly misunderstood buzzword. No wonder that they failed. Let's note that the particular buzzword chosen will likely not have had a particularly strong influence in that failure.

Steve McConnell said:

July 29, 2008 5:34:PM

Keith,

I'm not sure why you'd say a staff of 200 people is at least an order of magnitude too large for anyone doing XP. We've seen numerous companies take on projects that size using variations of Scrum and XP.

On the point about the project team not "reading the book," I didn't include the project timeline but it was completed a year before XP 2nd Edition was published, so the company wasn't able to take advantage of what Kent Beck had learned about XP between v. 1 and v. 2. The focus in XP v. 1 combined with the general agile admonition to favor "responding to change over following a plan" lead to thinking of "one iteration at a time."

I don't think the company wildly misunderstood the buzzword. On the contrary, I think they tried too slavishly to do XP "by the book," without thinking through which parts made sense for them and which parts didn't.

And that's my point -- applying "Agile" is risky until you identify which specific agile practices you're talking about. In the Cautionary Tale, they didn't think hard enough about which parts applied to them and which parts didn't.

I don't think it's only bad management. The bad management in my view was allowing a methodology that hadn't been proved successful on a small scale be rolled out on a large scale. But technical staff were convincing management to roll out the untried methodology, and they're to blame too. And then of course the methodology failed to produce saleable software, so it's also to blame. In short, there's lots of blame to spread around.

Keith Braithwaite said:

July 29, 2008 5:56:PM

Steve,

I can well believe that you've had large teams successfully using variations of Scrum and XP (and, I'll bet, Scrum and XP together at the same time). That's not what your case describes. If that's what they did then the case is misleading.

Slavishly trying to do XP by the book for two years without adjustment to local conditions is to wildly misunderstand what they were supposed to be doing, if they were supposed to be doing XP.

I absolutely agree with your overall point about carefully choosing which practices should be deployed in a given setting, And I absolutely agree that commercial IT efforts should focus on business needs ahead of technical solutions. To adopt "Agile" methods as I understand the term requires both of those things. What I don't understand is what your case has to do with any of this. The lesson from it seems to be that if you do it wrong it won't work.

I'm sure you have lots of other cautionary tails about organisations that focussed too much on the need for predictability, to plan far into the future, to compile "comprehensive requirements" and never actually got anything done. I know i have. And what would such stories teach us? Do it wrong and it won't work.

Steve McConnell said:

July 29, 2008 6:27:PM

Keith, I don't think you can characterize this company as "doing it wrong." They tried to do XP by the book, which was perceived as "doing it right." They "did it right," and it still didn't work.

Your interpretation of Agile sounds intelligent and wise, but I don't think it's very representative of most of what's been published in the Agile literature. We see many, many cases in which teams adopt Agile because "responding to change is good for the business." But they don't really know that; they assume it without asking their business stakeholders.

When their business stakeholders start to express dissatisfaction with what they're getting -- because they're getting flexibility but not predictability -- a common response is for the "Agile" team to try to be *more agile* (e.g., more iterative in their requirements), because they think that agile, per se, is good for the business. "The reason it isn't working and our partners are dissatisfied must be because we're not doing it right. Therefore we'll try harder to do it right." And that can turn into a vicious circle.  

What was really needed was a much deeper discussion about the business's needs and the technical practices that are best equipped to satisfy those business needs.

Bottom line: my point is that sometimes even if you do it *right* it won't work. You need to be sure that you're doing the right thing, not just doing the thing right.

Ondrej Maler said:

July 30, 2008 10:17:AM

The question is: What would happen if they would choose some "sequential"/"plan driven" methodology and tried to do it also by book? I am not sure that choosing another kind of methodology would guarentee success to them.

Barry Boehm nad Richard Turner wrote excellent book comparing agile and plan driven methodologies (www.amazon.com/.../0321186125)

John Rutter said:

July 31, 2008 2:13:AM

Regarding the statement: "we want our distributed teams to be more Agile," - it makes a big difference to the viewpoint if you use a lower-case or an upper-case 'A' in there.

However, I certainly agree with the importance of having clearly defined aims or vision for a project/product, even if delivered in an iterative/Agile way.

Grahame said:

July 31, 2008 11:04:AM

I have found it workable to look at the components of the various methodologies, whether Agile or not, as tools and to use whatever tools are appropriate to the job.

The various Agile methodologies are convenient packages of tools but you don't have to be bound by those packages.  If needed you can and should create your own.

Nick Knutzen said:

August 1, 2008 9:06:AM

It seems like everyone is in agreement that "cut to fit" is the best approach. The best position is to understand all of the methodologies available and then pick and choose what practices suit the project and team that you are working with. I work for a large aerospace company, and for software that is deployed around the globe to airlines, it seems like a sequential methodology is appropriate. You do get the feeling that progress is happening slowly, but that is a neccessary evil when dealing with the regulatory, political, and technical complexity of a global deployment.

Jim Cooper said:

August 4, 2008 10:11:AM

> Of course, the waterfall methodology doesn't really do a better job at this.

I don't think anyone has ever used pure waterfall. IIRC, the paper that introduced the term did so in order to make exactly that point. I remain unconvinced it is even theoretically possible :-)

I also don't think there's a continuum with waterfall at one end and some sort of extreme agile at the other. It's more a multi-dimensional solution space, IMO.

"Agile" is certainly becoming too broad a term. It's obvious that any development process has to cope with change (ie be agile in the broadest sense). So it only really makes sense to talk about particular practices.

Alan Skorkin said:

August 17, 2008 6:45:AM

I think the problem in this situation was that the company tried to use agile in the same way they would have used a more heavyweight process.

The reason that most heavyweight processes fail is because the try to describe exactly how to build software, but it is an impossible task, you can't think of everything and foresee every situation. Even if you could the response to a particular situation if often contextual (depends on your environment), a solution that works in one situation will not work in another.

With agile, the approach is different, it assumes that people would use some common sense when developing software. I don't believe agile advocates having no high level vision, I think this vision is assumed. It would be silly to try and build anything without knowing what you want to achieve, right?

No process is perfect, the XP practices are only there to support the main ideals of agile development. You can't succeed with agile by only following the practices, you need to use your experience and common sense.

And of course if the development team is attempting to use agile while the business is unaware, doesn't buy-in or doesn't care, your job is that much harder.

Post a Comment:

 
 

Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laude, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve