The Art of Agile Development

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.) I 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, 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. provides some classic definitions:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The traditional idea of success is delivery on time, on budget, and according to specification. provides some classic definitions:

Important

Despite their popularity, there’s something wrong with these definitions.

Successful: “Completed on time, on budget, with all features and functions as originally specified.”

Challenged: “Completed and operational but over budget, over the time estimate, [with] fewer features and functions than originally specified.”

Impaired: “Cancelled at some point during the development cycle.”

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 was 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 (see ). 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.

Figure : Types of success

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 (p. 220), and offshoring has hidden costs .

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What does it mean to “be agile”?

The answer is more complicated than you might think. Agile development isn’t a specific process you can follow. No team practices the Agile method. There’s no such thing.

Agile development is a philosophy. It’s a way of thinking about software development. The canonical description of this way of thinking is the Agile Manifesto, a collection of 4 values () and 12 principles ().

To “be agile,” you need to put the agile values and principles into practice.

Figure : Agile values

A method, or process, is a way of working. Whenever you do something, you’re following a process. Some processes are written, as when assembling a piece of furniture; others are ad hoc and informal, as when I clean my house.

Agile methods are processes that support the agile philosophy. Examples include Extreme Programming and Scrum.

Agile methods consist of individual elements called practices. Practices include using version control, setting coding standards, and giving weekly demos to your stakeholders. Most of these practices have been around for years. Agile methods combine them in unique ways, accentuating those parts that support the agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

Just as established agile methods combine existing practices, you might want to create your own agile method by mixing together practices from various agile methods. At first glance, this doesn’t seem too hard. There are scores of good agile practices to choose from.

However, creating a brand-new agile method is a bad idea if you’ve never used agile development before. Just as there’s more to programming than writing code, there’s more to agile development than the practices. The practices are an expression of underlying agile principles. (For more on agile principles, see .) Unless you understand those principles intimately—that is, unless you’ve already mastered the art of agile development—you’re probably not going to choose the right practices. Agile practices often perform double- and triple-duty, solving multiple software development problems simultaneously and supporting each other in clever and surprising ways.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A method, or process, is a way of working. Whenever you do something, you’re following a process. Some processes are written, as when assembling a piece of furniture; others are ad hoc and informal, as when I clean my house.

Agile methods are processes that support the agile philosophy. Examples include Extreme Programming and Scrum.

Agile methods consist of individual elements called practices. Practices include using version control, setting coding standards, and giving weekly demos to your stakeholders. Most of these practices have been around for years. Agile methods combine them in unique ways, accentuating those parts that support the agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Just as established agile methods combine existing practices, you might want to create your own agile method by mixing together practices from various agile methods. At first glance, this doesn’t seem too hard. There are scores of good agile practices to choose from.

However, creating a brand-new agile method is a bad idea if you’ve never used agile development before. Just as there’s more to programming than writing code, there’s more to agile development than the practices. The practices are an expression of underlying agile principles. (For more on agile principles, see .) Unless you understand those principles intimately—that is, unless you’ve already mastered the art of agile development—you’re probably not going to choose the right practices. Agile practices often perform double- and triple-duty, solving multiple software development problems simultaneously and supporting each other in clever and surprising ways.

Figure : Agile principles

Every project and situation is unique, of course, so it’s a good idea to have an agile method that’s customized to your situation. Rather than making an agile method from scratch, start with an existing, proven method and iteratively refine it. Apply it to your situation, note where it works and doesn’t, make an educated guess about how to improve, and repeat. That’s what experts do.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The core thesis of this book is that mastering the art of agile development requires real-world experience using a specific, well-defined agile method. I’ve chosen Extreme Programming for this purpose. It has several advantages:

Of all the agile methods I know, XP is the most complete. It places a strong emphasis on technical practices in addition to the more common teamwork and structural practices.
XP has undergone intense scrutiny. There are thousands of pages of explanations, experience reports, and critiques out there. Its capabilities and limitations are very well understood.
I have a lot of experience with XP, which allows me to share insights and practical tips that will help you apply XP more easily.

To master the art of agile development—or simply to use XP to be more successful—follow these steps:

Important

Teams new to XP often underapply its practices.

Decide why you want to use agile development. Will it make your team and organization more successful? How? (For ideas, see ” in Chapter 1.)
Determine whether this book’s approach will work for your team. (See ” in Chapter 4.)
Adopt as many of XP’s practices as you can. (See .) XP’s practices are self-reinforcing, so it works best when you use all of them together.
Follow the XP practices rigorously and consistently. (See .) If a practice doesn’t work, try following the book approach more closely. Teams new to XP often underapply its practices. Expect to take two or three months to start feeling comfortable with the practices and another two to six months for them to become second nature.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As you adapt XP to your situation, you’re likely to run into problems and challenges. I provide solutions for a wide variety of common problems, but you’re still likely to encounter situations that I don’t cover. For these situations, you need a mentor: an outside expert who has mastered the art of agile development.

If you can get an expert to coach your team directly, that’s even better. However, even master coaches benefit from an outside perspective when they encounter problems.

The hardest part of finding a mentor is finding someone with enough experience in agile development. Sources to try include:

Other groups practicing XP in your organization
Other companies practicing XP in your area
A local XP/Agile user group
XP/Agile consultants
The XP mailing list: extremeprogramming@yahoogroups.com

I can’t predict every problem you’ll encounter, but I can help you see when things are going wrong. Throughout this book, I’ve scattered advice such as: “If you can’t demonstrate progress weekly, it’s a clear sign that your project is in trouble. Slow down for a week and figure out what’s going wrong. Ask your mentor for help.”

When I tell you to ask your mentor for help, I mean that the correct solution depends on the details of your situation. Your mentor can help you troubleshoot the problem and offer situation-specific advice.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

“Welcome to the team, Pat,” said Kim, smiling at the recent graduate. “Let me show you around. As I said during the interview, we’re an XP shop. You may find that things are a little different here than you learned in school.”

“I’m eager to get started,” said Pat. “I took a software engineering course in school, and they taught us about the software development lifecycle. That made a lot of sense. There was a bit about XP, but it sounded like it was mostly about working in pairs and writing tests first. Is that right?”

“Not exactly,” said Kim. “We do use pair programming, and we do write tests first, but there’s much more to XP than that. Why don’t you ask me some questions? I’ll explain how XP is different than what you learned.”

Pat thought for a moment. “Well, one thing I know from my course is that all development methods use the software development lifecycle: analysis, design, coding, and testing [see ]. Which phase are you in right now? Analysis? Design? Or is it coding or testing?”

“Yes!” Kim grinned. She couldn’t help a bit of showmanship.

“I don’t understand. Which is it?”

“All of them. We’re working on analysis, design, coding, and testing. Simultaneously. Oh, and we deploy the software every week, too.”

Pat looked confused. Was she pulling his leg?

Kim laughed. “You’ll see! Let me show you around.

“This is our team room. As you can see, we all sit together in one big workspace. This helps us collaborate more effectively.”

Kim led Pat over to a big whiteboard where a man stood frowning at dozens of index cards. “Brian, I’d like you to meet Pat, our new programmer. Brian is our product manager. What are you working on right now?”

Figure : Traditional lifecycles

“I’m trying to figure out how we should modify our release plan based on the feedback from the user meeting last week. Our users love what we’ve done so far, but they also have some really good suggestions. I’m trying to decide if their suggestions are worth postponing the feature we were planning to start next week. Our success has made us visible throughout the company, so requests are starting to flood in. I need to figure out how to keep us on track without alienating too many people.”

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the most astonishing premises of XP is that you can eliminate requirements, design, and testing phases as well as the formal documents that go with them.

This premise is so far off from the way we typically learn to develop software that many people dismiss it as a delusional fantasy. “These XP folks obviously don’t know what they’re talking about,” they say. “Just last month I was on a project that failed due to inadequate requirements and design. We need more requirements, design, and testing, not less!”

That’s true. Software projects do need more requirements, design, and testing—which is why XP teams work on these activities every day. Yes, every day.

You see, XP emphasizes face-to-face collaboration. This is so effective in eliminating communication delays and misunderstandings that the team no longer needs distinct phases. This allows them to work on all activities every day—with simultaneous phases—as shown in .

Figure : XP lifecycle

Using simultanous phases, an XP team produces deployable software every week. In each iteration, the team analyzes, designs, codes, tests, and deploys a subset of features.

Although this approach doesn’t necessarily mean that the team is more productive, it does mean that the team gets feedback much more frequently. As a result, the team can easily connect successes and failures to their underlying causes. The amount of unproven work is very small, which allows the team to correct some mistakes on the fly, as when coding reveals a design flaw, or when a customer review reveals that a user interface layout is confusing or ugly.

The tight feedback loop also allows XP teams to refine their plans quickly. It’s much easier for a customer to refine a feature idea if she can request it and start to explore a working prototype within a few days. The same principle applies for tests, design, and team policy. Any information you learn in one phase can change the way you think about the rest of the software. If you find a design defect during coding or testing, you can use that knowledge as you continue to analyze requirements and design the system in subsequent iterations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Working solo on your own project—“scratching your own itch”—can be a lot of fun. There are no questions about which features to work on, how things ought to work, if the software works correctly, or whether stakeholders are happy. All the answers are right there in one brain.

Team software development is different. The same information is spread out among many members of the team. Different people know:

How to design and program the software (programmers, designers, and architects)
Why the software is important (product manager)
The rules the software should follow (domain experts)
How the software should behave (interaction designers)
How the user interface should look (graphic designers)
Where defects are likely to hide (testers)
How to interact with the rest of the company (project manager)
Where to improve work habits (coach)

All of this knowledge is necessary for success. XP acknowledges this reality by creating cross-functional teams composed of diverse people who can fulfill all the team’s roles.

XP teams sit together in an open workspace. At the beginning of each iteration, the team meets for a series of activities: an iteration demo, a retrospective, and iteration planning. These typically take two to four hours in total. The team also meets for daily stand-up meetings, which usually take five to ten minutes each.

Other than these scheduled activities, everyone on the team plans his own work. That doesn’t mean everybody works independently; they just aren’t on an explicit schedule. Team members work out the details of each meeting when they need to. Sometimes it’s as informal as somebody standing up and announcing across the shared workspace that he would like to discuss an issue. This

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As with any specialized field, XP has its own vocabulary. This vocabulary distills several important concepts into snappy descriptions. Any serious discussion of XP (and of agile in general) uses this vocabulary. Some of the most common ideas follow.

Important

There are multiple ways of expressing the same concept in source code. Some are better than others. Refactoring is the process of changing the structure of code—rephrasing without changing its meaning or behavior. It’s used to improve code quality, to fight off software’s unavoidable entropy, and to ease adding new features.

Imagine a customer rushing down the hallway to your desk. “It’s a bug!” she cries, out of breath. “We have to fix it now.” You can think of two solutions: the right way and the fast way. You just know she’ll watch over your shoulder until you fix it. So you choose the fast way, ignoring the little itchy feeling that you’re making the code a bit messier.

Technical debt is the total amount of less-than-perfect design and implementation decisions in your project. This includes quick and dirty hacks intended just to get something working right now! and design decisions that may no longer apply due to business changes. Technical debt can even come from development practices such as an unwieldy build process or incomplete test coverage. It lurks in gigantic methods filled with commented-out code and “TODO: not sure why this works” comments. These dark corners of poor formatting, unintelligible control flow, and insufficient testing breed bugs like mad.

The bill for this debt often comes in the form of higher maintenance costs. There may not be a single lump sum to pay, but simple tasks that ought to take minutes may stretch into hours or afternoons. You might not even notice it except for a looming sense of dread when you read a new bug report and suspect it’s in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

“I can see how XP would work for IT projects, but product development is different.” —a product development team

“I can see how XP would work for product development, but IT projects are different.” —an in-house IT development team

Before adopting XP, you need to decide whether it’s appropriate for your situation. Often, people’s default reaction to hearing about XP is to say, “Well, of course that works for other teams, but it couldn’t possibly work for us.”

Important

XP’s applicability is based on organizations and people, not types of projects.

Question that assumption. I’ve helped a wide variety of teams adopt XP: 20-person teams and 1-person teams; huge corporations and small startups; shrinkwrap, in-house, and outsourced software vendors; proprietary and open source developers. Through these experiences, I’ve learned that software teams are more similar than they are different. XP’s applicability has far more to do with your organization and the people involved than with the type of project you’re working on.

You can adopt XP in many different conditions, although the practices you use will vary depending on your situation. The practices in this book were chosen to give you the greatest chance of success. That leads to some prerequisites and recommendations about your team’s environment. You don’t have meet these criteria exactly, but it’s worth trying to change your environment so that you do. This will give you the best chance of succeeding.

As Martin Fowler said:

In this sense I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don’t have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails which really give the industry a jolt.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can adopt XP in many different conditions, although the practices you use will vary depending on your situation. The practices in this book were chosen to give you the greatest chance of success. That leads to some prerequisites and recommendations about your team’s environment. You don’t have meet these criteria exactly, but it’s worth trying to change your environment so that you do. This will give you the best chance of succeeding.

As Martin Fowler said:

In this sense I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don’t have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails which really give the industry a jolt.

In other words, if your organization puts a barrier between your work and success, don’t just put up with it—find a way to remove it. It’s your best path to success.

Similarly, if you want to practice XP, do everything you can to meet the following prerequisites and recommendations. This is a lot more effective than working around limitations.

It’s very difficult to use XP in the face of opposition from management. Active support is best. To practice XP as described in this book, you will need the following:

A common workspace with pairing stations (see ” in )
Team members solely allocated to the XP project (see ” in )
A product manager, on-site customers, and integrated testers (also discussed in ” in )

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Are you ready to adopt XP? Great! Your first step is to arrange for your open workspace (see ” in ). Start solving this problem now. It will probably take longer than you expect.

Next, find an appropriate project for the team to work on. Look for a project that’s valuable, but be wary of projects that will be under intense scrutiny. You need room to make mistakes as you learn.

Avoid taking a project with low value as a “learning opportunity.” You’ll have trouble involving customers and achieving an organizational success. Your organization could view the project as a failure even if it’s a technical success.

At the same time, figure out who will be on your team. ” in provides some suggestions for team structure. Talk with your project’s executive sponsor and other stakeholders about who to include as your on-site customers. (See ” in for ideas.) Be sure your team members want to try XP.

As you’re forming your team, consider hiring an experienced XP coach to work with the team full-time. Although a coach isn’t necessary—I learned XP by reading about it and trying it—a good coach will make things go more smoothly.

As your project start date draws near, you’ll need supplies for the team’s open workspace. The following is a good shopping list.

Equipment:

Pairing stations (see ” in ).
A dedicated build machine (see ” in ).
Noise-dampening partitions to define your team’s workspace and prevent noise pollution (see ” in ).
Plenty of wall-mounted whiteboards for discussions and charts (see ” in ). Ferrous (magnetic) whiteboards are best because you can stick index cards to them with magnets.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Suppose you’ve been using XP for a few months. How can you tell if you’re doing it properly? The ultimate measure is the success of your project, but you may wish to review and assess your approach to XP as well.

To help you do this, I’ve created a quiz that focuses on five important aspects of agile development. It explores results rather than specific practices, so you can score well even after customizing XP to your situation. If you aren’t using XP at all, you can also use this quiz to assess your current approach.

This quiz assesses typical sources of risk. Your goal should be to achieve the maximum score in each category—which is well within the grasp of experienced XP teams. Any score less than the maximum indicates risk, and an opportunity for improvement.

To take the quiz, answer the following questions and enter your scores on a photocopy of the blank radar diagram (). Don’t give partial credit for any question, and if you aren’t sure of the answer, give yourself zero points. The result should look something like . The score of the lowest spoke identifies your risk, as follows:

75 points or less: immediate improvement required (red)
75 to 96 points: improvement necessary (yellow)
97, 98, or 99: improvement possible (green)
100: no further improvement needed

Figure : Example assessment

The point values for each answer come from an algorithm that ensures correct risk assessment of the total score. This leads to some odd variations in scores. Don’t read too much into the disparities between the values of individual questions.

To see the XP solution for each of these questions, cross-reference the sections listed under “XP Practices” in Tables through .

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What’s wrong with this sentence?

What we really need is more keyboards cranking out code.

That’s a quote from a manager I once worked with. In a way, he was right: you will never give your customer what she wants without typing on a keyboard.

But that wasn’t our problem. I later realized our progress had a single bottleneck: the availability of our staging environment. More keyboards wouldn’t have helped, even if we had more programmers sitting at them. If we had realized this sooner, we would have been much more productive.

Sometimes the biggest gains in productivity come from stopping to think about what you’re doing, why you’re doing it, and whether it’s a good idea. The best developers don’t just find something that works and use it; they also question why it works, try to understand it, and then improve it.

XP doesn’t require experts. It does require a habit of mindfulness. This chapter contains five practices to help mindful developers excel:

Pair programming doubles the brainpower available during coding, and gives one person in each pair the opportunity to think about strategic, long-term issues.
Energized work acknowledges that developers do their best, most productive work when they’re energized and motivated.
An informative workspace gives the whole team more opportunities to notice what’s working well and what isn’t.
Root-cause analysis is a useful tool for identifying the underlying causes of your problems.
Retrospectives provide a way to analyze and improve the entire development process.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Programmers, Whole Team

We help each other succeed.

Do you want somebody to watch over your shoulder all day? Do you want to waste half your time sitting in sullen silence watching somebody else code?

Of course not. Nobody does—especially not people who pair program.

Pair programming is one of the first things people notice about XP. Two people working at the same keyboard? It’s weird. It’s also extremely powerful and, once you get used to it, tons of fun. Most programmers I know who tried pairing for a month find that they prefer it to programming alone.

This chapter is called Thinking, yet I included pair programming as the first practice. That’s because pair programming is all about increasing your brainpower.

When you pair, one person codes—the driver. The other person is the navigator, whose job is to think. As navigator, sometimes you think about what the driver is typing. (Don’t rush to point out missing semicolons, though. That’s annoying.) Sometimes you think about what tasks to work on next and sometimes you think about how your work best fits into the overall design.

This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator create higher-quality work more quickly than either could produce on their own.

Pairing also reinforces good programming habits. XP’s reliance on continuous testing and design refinement takes a lot of self-discipline. When pairing, you’ll have positive peer pressure to perform these difficult but crucial tasks. You’ll spread coding knowledge and tips throughout the team.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Coaches, Whole Team

We work at a pace that allows us to do our best, most productive work indefinitely.

I enjoy programming. I enjoy solving problems, writing good code, watching tests pass, and especially removing code while refactoring. I program in my spare time and sometimes even think about work in the shower.

In other words, I love my work. Yet put me on a team with unclear goals, little collective responsibility, and infighting, and I’ll wake up dreading going into work. I’ll put in my hours at the office, but I’ll be tempted to spend my mornings reading email and my afternoons picking at code while surfing through marginally related technical web sites.

We’ve all been in this situation. Because we’re professionals, we strive to produce quality work even when we feel demoralized. Still, consider the times of greatest productivity in your career. Do you notice a big difference when you wake up and feel blessed to go into work? Isn’t it much more satisfying to leave on time at the end of the day, knowing that you accomplished something solid and useful?

XP’s practice of energized work recognizes that, although professionals can do good work under difficult circumstances, they do their best, most productive work when they’re energized and motivated.

Important

Go home on time.

One of the simplest ways to be energized is to take care of yourself. Go home on time every day. Spend time with family and friends and engage in activities that take your mind off of work. Eat healthy foods, exercise, and get plenty of sleep. While you’re busy with these other things, your brain will turn over the events of the day. You’ll often have new insights in the morning.

If quality time off is the yin of energized work, focused work is the yang. While at work, give it your full attention. Turn off interruptions such as email and instant messaging. Silence your phones. Ask your project manager to shield you from unnecessary meetings and organizational politics.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Whole Team

We are tuned in to the status of our project.

Your workspace is the cockpit of your development effort. Just as a pilot surrounds himself with information necessary to fly a plane, arrange your workspace with information necessary to steer your project: create an informative workspace.

An informative workspace broadcasts information into the room. When people take a break, they will sometimes wander over and stare at the information surrounding them. Sometimes, that brief zone-out will result in an aha moment of discovery.

An informative workspace also allows people to sense the state of the project just by walking into the room. It conveys status information without interrupting team members and helps improve stakeholder trust.

Important

Simply poking your head into a project room should give you information about the project.

The essence of an informative workspace is information. One simple source of information is the feel of the room. A healthy project is energized. There’s a buzz in the air—not tension, but activity. People converse, work together, and make the occasional joke. It’s not rushed or hurried, but it’s clearly productive. When a pair needs help, other pairs notice, lend their assistance, then return to their tasks. When a pair completes something well, everyone celebrates for a moment.

An unhealthy project is quiet and tense. Team members don’t talk much, if at all. It feels drab and bleak. People live by the clock, punching in and punching out—or worse, watching to see who is the first one to dare to leave.

Besides the feel of the room, other cues communicate useful information quickly and subconsciously. If the build token is away from the integration machine, it’s not safe to check out the code right now. By mid-iteration, unless about half the cards on the iteration plan are done, the team is going faster or slower than anticipated.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Whole Team

We prevent mistakes by fixing our process.

When I hear about a serious mistake on my project, my natural reaction is to get angry or frustrated. I want to blame someone for screwing up.

Unfortunately, this response ignores the reality of Murphy’s Law. If something can go wrong, it will. People are, well, people. Everybody makes mistakes. I certainly do. Aggressively laying blame might cause people to hide their mistakes, or to try to pin them on others, but this dysfunctional behavior won’t actually prevent mistakes.

Instead of getting angry, I try to remember Norm Kerth’s Prime Directive: everybody is doing the best job they can given their abilities and knowledge (see ” later in this chapter for the full text of the Prime Directive). Rather than blaming people, I blame the process. What is it about the way we work that allowed this mistake to happen? How can we change the way we work so that it’s harder for something to go wrong?

This is root-cause analysis.

A classic approach to root-cause analysis is to ask “why” five times. Here’s a real-world example.

Problem: When we start working on a new task, we spend a lot of time getting the code into a working state.

Why? Because the build is often broken in source control.

Why? Because people check in code without running their tests.

It’s easy to stop here and say, “Aha! We found the problem. People need to run their tests before checking in.” That is a correct answer, as running tests before check-in is part of continuous integration. But it’s also already part of the process. People know they should run the tests, they just aren’t doing it. Dig deeper.

Why don’t they run tests before checking in? Because sometimes the tests take longer to run than people have available.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Whole Team

We continually improve our work habits.

No process is perfect. Your team is unique, as are the situations you encounter, and they change all the time. You must continually update your process to match your changing situations. Retrospectives are a great tool for doing so.

The most common retrospective, the iteration retrospective, occurs at the end of every iteration.

In addition to iteration retrospectives, you can also conduct longer, more intensive retrospectives at crucial milestones. These release retrospectives, project retrospectives, and surprise retrospectives (conducted when an unexpected event changes your situation) give you a chance to reflect more deeply on your experiences and condense key lessons to share with the rest of the organization.

These other retrospectives are out of the scope of this book. They work best when conducted by neutral third parties, so consider bringing in an experienced retrospective facilitator. Larger organizations may have such facilitators on staff (start by asking the HR department), or you can bring in an outside consultant. If you’d like to conduct them yourself, and are great resources.

Anybody can facilitate an iteration retrospective if the team gets along well. An experienced, neutral facilitator is best to start with. When the retrospectives run smoothly, give other people a chance to try.

Everyone on the team should participate in each retrospective. In order to give participants a chance to speak their minds openly, non-team members should not attend.

I timebox my retrospectives to exactly one hour. Your first few retrospectives will probably run long. Give it an extra half-hour, but don’t be shy about politely wrapping up and moving to the next step. The whole team will get better with practice, and the next retrospective is only a

Table of Contents

Important

Important

Important

Important

Important

Important