Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.* I know of one company that has already changed its name to Agili-something in order to ride the bandwagon. (They called me in to pitch their “agile process,” which, upon further inspection, was nothing more than outsourced offshore development, done in a different country than usual.) fully expect the big consulting companies to start offering Certified Agile Processes and Certified Agile Consultants—for astronomical fees, of course—any day now.
Please don’t get sucked into that mess.
In 1986, [Brooks] famously predicted that there were no silver bullets: that by 1996, no single technology or management technique would offer a tenfold increase in productivity, reliability, or simplicity. None did.
Agile development isn’t a silver bullet, either.
In fact, I don’t recommend adopting agile development solely to increase productivity. Its benefits even the ability to release software more frequently—come from working differently, not from working faster. Although anecdotal evidence indicates that agile teams have above-average productivity,† that shouldn’t be your primary motivation. Your team will need time to learn agile development. While they learn—and it will take a quarter or two—they’ll go slower, not faster. In addition, emphasizing productivity might encourage your team to take shortcuts and to be less rigorous in their work, which could actually harm productivity.
Agile development may be the cool thing to do right now, but that’s no reason to use it. When you consider using agile development, only one question matters.
Will agile development help us be more successful?
When you can answer that question, you’ll know whether agile development is right for you.
The traditional idea of success is delivery on time, on budget, and according to specification. [Standish] provides some classic definitions:
“Completed on time, on budget, with all features and functions as originally specified.”- Despite their popularity, there’s something wrong with these definitions. A project can be successful even if it never makes a dime. It can be challenged even if it delivers millions of dollars in revenue.
“Completed and operational but over budget, over the time estimate, [with] fewer features and functions than originally specified.”
“Cancelled at some point during the development cycle.”
CIO Magazine commented on this oddity:
Projects that were found to meet all of the traditional criteria for success—time, budget and specifications—may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business.
… Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value. For example, at a financial services company, a new system… was six months late and cost more than twice the original estimate (final cost was $5.7 million). But the project ultimately created a more adaptive organization (after 13 months) and was judged to be a great success—the company had a $33 million reduction in write-off accounts, and the reduced time-to-value and increased capacity resulted in a 50 percent increase in the number of concurrent collection strategy tests in production.
There has to be more to success than meeting deadlines… but what?
When I was a kid, I was happy just to play around. I loved the challenge of programming. When I got a program to work, it was a major victory. Back then, even a program that didn’t work was a success of some sort, as long as I had fun writing it. My definition of success centered on personal rewards.
As I gained experience, my software became more complicated and I often lost track of how it worked. I had to abandon some programs before they were finished. I began to believe that maintainability as the key to success—an idea that was confirmed as I entered the workforce and began working with teams of other programmers. I prided myself on producing elegant, maintainable code. Success meant technical excellence.
Despite good code, some projects flopped. Even impeccably executed projects could elicit yawns from users. I came to realize that my project teams were part of a larger ecosystem involving dozens, hundreds, or even thousands of people. My projects needed to satisfy those people … particularly the ones signing my paycheck. In fact, for the people funding the work, the value of the software had to exceed its cost. Success meant delivering value to the organization.
These definitions aren’t incompatible. All three types of success are important. Without personal success, you’ll have trouble motivating yourself and employees. Without technical success, your source code will eventually collapse under its own weight. Without organizational success, your team may find that they’re no longer wanted in the company.
The Importance of Organizational Success
Organizational success is often neglected by software teams in favor of the more easily achieved technical and personal successes. Rest assured, however, that even if you’re not taking responsibility for organizational success, the broader organization is judging your team at this level. Senior management and executives aren’t likely to care if your software is elegant, maintainable, or even beloved by its users; they care about results. That’s their return on investment in your project. If you don’t achieve this sort of success, they’ll take steps to ensure that you do.
Unfortunately, senior managers don’t usually have the time or perspective to apply a nuanced solution to each project. They wield swords, not scalpels. They rightly expect their project teams to take care of fine details.
When managers are unhappy with your team’s results, the swords come out. Costs are the most obvious target. There are two easy ways to cut them: set aggressive deadlines to reduce development time, or ship the work to a country with a lower cost of labor. Or both.
These are clumsy techniques. Aggressive deadlines end up increasing schedules rather than reducing them [McConnell 1996] (p. 220), and offshoring has hidden costs [Overby].
Do aggressive deadlines and the threat of offshoring sound familiar? If so, it’s time for your team to take back responsibility for its success: not just for personal or technical success, but for organizational success as well.
Will agile development help you be more successful? It might. Agile development focuses on achieving personal, technical, and organizational successes. If you’re having trouble with any of these areas, agile development might help.
Agile methods achieve organizational successes by focusing on delivering value and decreasing costs. This directly translates to increased return on investment. Agile methods also set expectations early in the project, so if your project won’t be an organizational success, you’ll find out early enough to cancel it before your organization has spent much money.
Specifically, agile teams increase value by including business experts and by focusing development efforts on the core value that the project provides for the organization. Agile projects release their most valuable features first and release new versions frequently, which dramatically increases value. When business needs change or when new information is discovered, agile teams change direction to match. In fact, an experienced agile team will actually seek out unexpected opportunities to improve its plans.
Agile teams decrease costs as well. They do this partly by technical excellence; the best agile projects generate only a few bugs per month. They also eliminate waste by cancelling bad projects early and replacing expensive development practices with simpler ones. Agile teams communicate quickly and accurately, and they make progress even when key individuals are unavailable. They regularly review their process and continually improve their code, making the software easier to maintain and enhance over time.
Extreme Programming, the agile method I focus on in this book, is particularly adept at achieving technical successes. XP programmers work together, which helps them keep track of the nitpicky details necessary for great work and ensures that at least two people review every piece of code. Programmers continuously integrate their code, which enables the team to release the software whenever it makes business sense. The whole team focuses on finishing each feature completely before starting the next, which prevents unexpected delays before release and allows the team to change direction at will.
In addition to the structure of development, Extreme Programming includes advanced technical practices that lead to technical excellence. The most well-known practice is test-driven development, which helps programmers write code that does exactly what they think it will. XP teams also create simple, ever-evolving designs that are easy to modify when plans change.
Personal success is, well, personal. Agile development may not satisfy all of your requirements for personal success. However, once you get used to it, you’ll probably find a lot to like about it, no matter who you are:
Executives and senior management
They will appreciate the team’s focus on providing a solid return on investment and the software’s longevity.
Users, stakeholders, domain experts, and product managers
They will appreciate their ability to influence the direction of software development, the team’s focus on delivering useful and valuable software, and increased delivery frequency.
Project and product managers
They will appreciate their ability to change direction as business needs change, the team’s ability to make and meet commitments, and improved stakeholder satifaction.
They will appreciate their improved quality of life resulting from increased technical quality, greater influence over estimates and schedules, and team autonomy.
They will appreciate their integration as first-class members of the team, their ability to influence quality at all stages of the project, and more challenging, less repetitious work.
Working on agile teams has provided some of the most enjoyable moments in my career. Imagine the camaraderie of a team that works together to identify and deliver products of lasting value, with each team member enthusiastically contributing to a smooth-running whole. Imagine how it feels to take responsibility for your area of expertise, whether technical, business, or management, with the rest of the team trusting your professional judgment and ability. Imagine how pleasant it is to address the frustrations of your project and to see quality improve over time.
Agile development changes the game. Developing and delivering software in a new way will take a lot of work and thought. Yet if you do it consistently and rigorously, you’ll experience amazing things: you’ll ship truly valuable software on a regular basis. You’ll demonstrate progress on a weekly basis. You’ll have the most fun you’ve ever had in software development.