Programming Practices

Two of the primary XP practices are aimed directly at programmers, and help those programmers write better code: test-first programming and pair programming. They’re focused on several important aspects of software development. By writing automated tests before writing the code that gets tested, teams establish a higher level of quality in their software. Working in pairs, with two developers at a single workstation, helps get more eyes on the software to catch bugs before they’re built into the code.

When a programmer does test-first programming, also known as test-driven development (or TDD), it means that before he writes code, he builds an automated test. Since the product code hasn’t been written yet, the test fails. He knows that the code is working when the test passes. This creates a tight feedback loop that helps to prevent defects: write failing tests, build code to make them pass, find problems and learn more about how you’ll solve them, then write more failing tests. These automated tests are usually called unit tests. The word “unit” makes sense: in almost every programming language, code is cleanly broken down into units (classes, methods, functions, subroutines, modules, etc.), and almost every language has at least one way of building and running automated tests that are tied to each of those units. By building the tests first, the programmer makes sure that each unit does what it’s supposed to do.

Test-first programming makes sure each individual unit of code works, but it does more than that. It also helps the team prevent some of the most common—and most serious—problems that can make a codebase difficult to maintain. It’s very easy to make a change to one part of the code, only to have a seemingly unrelated bug pop up in a completely unrelated feature because the developer didn’t realize the two shared a dependency. When a programmer writes unit tests that are run every time the code builds, those automated tests help prevent dependencies from going undetected by immediately failing, and the tests help the programmer spot the problem before it’s embedded in the codebase and too difficult to remove. Unit tests also help programmers write code that is easier to reuse; it’s easy for a programmer to build a Java class, for example, that has a structure that makes it unintuitive to work with: confusing names, clumsy initialization, or other structural problems can easily sneak into anyone’s code. When the programmer builds a unit test that has to use that class, the flaw can become obvious, and because the contents of the class haven’t been written yet, the programmer can change it quickly. The unit test then becomes part of the codebase, so other developers can refer to it to see how the method was meant to be used.

The second primary XP practice that’s focused on building code is pair programming. In a team that does pair programming, two developers sit together at a single workstation when writing code. In most cases, one programmer types, while the other watches—and they constantly discuss what’s going on. Teams working in pairs inject far fewer bugs, because there are two sets of eyes looking to catch the bugs all the time. Pairing can also help reduce fatigue, because one programmer can take over typing when the other gets a little mentally tired. An effective pair programming team will discuss ideas and approaches, constantly brainstorm, and, as a result, be more innovative. They will also hold each other accountable for good practices: it’s easy for one programmer to sweep a bad shortcut under the rug, but he’ll be much less likely to take that shortcut when his pair partner is watching. We’ve spoken with developers on many different teams who told us that they’ve found that pairs build much more code—and much better code—working together than they would have if working separately.

Integration Practices

There are two primary XP practices that we put in the “integration” category. The first is the 10-minute build: the team creates an automated build for the entire codebase that runs in under 10 minutes. This build includes automatically running all of the unit tests and generating a report of which tests passed and which failed.

Ten minutes may sound like an arbitrary length of time, but it makes sense from a team’s perspective. If a build takes more than 10 minutes to run, team members are much less likely to run it often. Running the build often is very valuable to the team, because it makes problems immediately obvious. For example, the build runs the unit tests, so after the build runs, the team knows whether or not they’ve reached the level of quality they set up in the automated tests. In other words, it gives a relatively quick answer to the question, “Is our code working so far?” And because it’s short enough that the team will run it often, everyone on the team has a continuously updated view of the quality of the code.

The other integration practice is continuous integration, and it’s a practice built around tools that teams use to let many people work on a single set of source code files simultaneously. If you have a team, and everyone needs to work with the same files all the time, team members can’t work on the same physical copies of the files at the same time—they’d constantly overwrite one another’s changes. So the team will use a version control system that has a central (or decentralized) master set of files, which individual developers will check out, or copy into a private copy of the entire codebase that’s only used by that programmer (often called a sandbox). The developer will work on the copy of the code in her sandbox, and periodically check it back into the repository.

The problem is that very often when a developer checks in her changes, she’ll find that another of her team members made conflicting changes since she checked out her code. A lot of the time, those conflicts will show up immediately when she tries to build her local copy of the code, and it no longer compiles. But sometimes the problems are more severe, and the software no longer behaves correctly because of conflicting code that was checked in since her sandbox was last updated. These problems will all show up when she integrates the latest code from the repository back into her sandbox before checking in her changes.

And that’s where continuous integration comes in: the team will constantly run the build and monitor for compiler errors or unit test failures. Many teams will set up a build server that periodically checks out the latest code from the repository, runs the automated build, and notifies the team if there are any errors. But setting up a continuous build server is only one part of continuous integration. Integrating continuously means that each team member constantly keeps his or her own copy of the codebase up to date. Team members periodically integrate the latest code from the repository back into their sandboxes. Teams that use pair programming will sometimes have a physical build token, like a stuffed plush toy or a rubber chicken (it’s useful to make it something silly, so it’s clear who has it), that they pass from pair to pair; when a pair gets the token, they take the next opportunity to integrate the latest code from the repository, fix any integration problems they find, then pass it on to the next pair. This ensures that integration problems are found and repaired as early as possible.

Planning Practices

XP teams use iterative development to manage their projects. Like Scrum, the XP planning practices are based on a larger cycle for long-term planning, broken into shorter iterations. In the weekly cycle practice, the XP team uses one-week iterations, and it works closely with the stories practice (which is identical to the user stories that you’ve already learned about). Each cycle starts with a planning meeting, where the team members review the progress they’ve made on the project, work with the customers to pick the stories for the iteration, and then break the stories into tasks that are estimated and assigned to developers.

This should sound familiar, because it’s very similar to the Scrum planning meeting; in fact, many XP teams will adopt the exact Scrum planning practices (which accounts for the popularity of the Scrum-XP hybrid reported on the VersionOne State of Agile survey that you read about in Chapter 2). Once the planning is done, the team spends the first part of the iteration writing automated tests for the stories and tasks, and the rest of the iteration writing code to make the tests pass. However, instead of self-organizing, some XP teams will stack up all of the tasks for the iteration and have each developer take the next task in the stack when his current task is done. This helps ensure that developers don’t cherry-pick their favorite tasks, and distributes the tasks evenly among all developers.

XP teams use the quarterly cycle practice to do long-term planning. Once a quarter, the team meets to take a look at the big picture. XP teams will talk about themes, or larger ideas in the real world that they can use to tie their project’s stories together. Discussing themes helps the team figure out what stories will need to be added to the project, and keeps them connected to the real-world business problems that they’re solving with the software. The team also steps back and talks about internal and external problems that they’re experiencing, nagging bugs, and repairs that haven’t been addressed yet. They take the time to reflect on the progress they’ve made so far, how well they’re meeting their users’ needs, and how the project is going overall. Some XP teams will use the same retrospective practice that Scrum teams use.

The final primary XP practice focused on planning is slack. This practice has the team add minor, lower-priority stories to each weekly cycle. These stories are broken down into tasks during the planning meeting, but those tasks are left for the end of the iteration. That way, if the team runs into unexpected problems, it’s very easy for them to cut out those “slack” stories and still deliver complete, working software at the end of the cycle—and like all iterative development, XP teams only deliver software that’s “done done” at the end of the cycle, which means that it works, all tests pass, and it can be demonstrated to the users.

Team Practices

XP isn’t just about programming. It’s about how teams work together, and it includes two primary practices that help teams gel that we grouped into a “team practices” category. The first is sit together, and it’s pretty self-explanatory. Teams work best when they sit near each other, and have easy access to everyone else on the team. Many people don’t realize that while programming as an individual is often done in isolation (when not done in pairs), working as a developer on a programming team is a highly social activity. Team members constantly consult each other about problems, ask each other for advice, and alert each other to problems. If the team sits together in an open workspace, this socialization is naturally encouraged. There’s a lot of debate over just how open the workspace should be, because programmers also need to be shielded from distractions in order to work efficiently, and many programmers value the privacy of having a screen that can’t be seen by people walking by. A popular solution to this is the “caves and commons” office layout, described by Steward Brand in his book How Buildings Learn.⁴⁰ In this layout, developers have private or shared offices that open out into a large common area with meeting tables and workstations for pairing.

The next primary XP team practice is informative workspace, where the team’s working environment is set up to automatically communicate important project information to anyone who happens to be working in it. One popular way of making a workspace informative is to have a large task board and burndown chart posted prominently on a wall that everyone can see. By putting all of the information about the project in plain sight all the time, every single person on the team knows where the project stands, and that helps everyone make better decisions. Visible, always-in-your-face charts and other things that teams use to display data and make the workspace more informative are called information radiators because they automatically “radiate” current information about the project to anyone who happens to be nearby.

Large, visible charts aren’t the only way to make a workspace informative. When team members have questions, run into problems, or raise issues, they have discussions. When those discussions take place in a shared workspace instead of closed conference rooms, the people around them overhear, and will absorb information about what’s going on. When team members automatically absorb project information, whether it’s from charts or from overheard conversations, it’s called osmotic communication.While teams need to balance the value of that communication against the potential distraction of overheard discussions that can interrupt a developer’s train of thought and slow down development, effective XP teams will find a good balance that helps keep everyone up to date.

Why are informative workspaces important? The idea is to help the team make better decisions, and to give them more control over how the project is run—just like task boards help Scrum teams. What’s important here is that the information is for the whole team, not just for the team leads or managers. It’s democratized, and spread out to everyone on the team without filtering. The more information about the project is shared, the more each individual on the team is able to influence the direction of the project.

Why Teams Resist Changes, and How the Practices Help

Nobody likes writing code, and then having to change it because the person who asked for it changed his mind. Making changes late in the game can range from irritating to actually insulting—and even borderline disastrous, if you have to work weekends for the next month and a half because someone asked you and your team to build something, but didn’t bother thinking it through all the way.

Figure 6-2. Every project manager recognizes the helpless feeling of needing a change and not being able to get the developers to make it, and every developer knows the anxiety of a seemingly innocuous code change ballooning into a monster that takes way too much time.

This is why developers often complain about how those annoying business users keep changing their minds. It’s really common to hear complaints partway through a project like this: “Wait, you want that change? If I’d known that, I’d have built the code completely differently! Why can’t you just tell us exactly what you want at the beginning of a project?”

And who can blame them? Teams resist these changes, especially late in the project⁴¹, because it’s work. And not just normal work—the worst, most irritating kind of work. Changes make you pick up something that you thought was finished, rip it apart, and rebuild large parts of it from the ground up. Moreover, it’s not just the work of changing the code that’s frustrating. Your whole team put a lot of mental effort into it, thinking through many problems and coming up with the most elegant solution you could find. Now you’re being told to tear down your Taj Mahal, because someone really wanted an Eiffel Tower instead.

But there’s more than one side to this story. The user or manager who asked for one thing and then changed his mind late in the project usually isn’t doing it purposely to disrupt the team. We learned earlier in the book that fractured perspectives lead to poor project results, so let’s try to look at this problem from his perspective. He needs software built so he can do his job, and that means he needs to work with the development team. Now he’s being asked to come up with answers to questions that he may not fully understand: “Who should have access to this feature?” “How many simultaneous users will use this system?” “How much time is acceptable between when the ‘Go’ button is clicked and when the results are displayed?” “Do they need to choose these options and then make those selections, or vice versa?”

What started as a meeting where the user tried to explain his problem somehow ended up with him having to answer a seemingly unending stream of technical questions that he doesn’t really know how to answer. And there’s a ticking clock; he feels that if he doesn’t give answers to every question, the team will delay the project—and blame him for the delay. (And, let’s be honest, they probably will.) Everyone knows that building software is expensive, and he’s not an expert in it, so he’ll give the best answer that he can so that the meeting ends and he doesn’t keep the team from moving forward and burning more budget.

How do we resolve this? Who’s right?

The thing that agile methodologies—and XP in particular—do really well is admit up front that we don’t know exactly what we’re going to build, and that the most efficient way we have of figuring this out is to build it. They’ll use working software instead of comprehensive documentation, because the most effective way they have of getting feedback from a user is to build part of the software first and get it into that user’s hands.

So instead of setting your team up to try to shoot every change down, is it possible to create an environment where the team can actually handle those changes—gracefully, and without the disastrous weekend work or emotional strife? Nobody likes making changes, but maybe you can find a way to limit the impact each change has on the project, not only on the integrity of the code but also on the emotional state of the team and the users.

XP teams do this. They call it embracing change. An XP team doesn’t just treat changes as a necessary evil; they recognize that the only way they can build the best software for their users is to get feedback often and respond to that feedback quickly. They expect change; it’s on their calendar. It’s not just bad news that always manages to show up, followed by a witch hunt to try to figure out who missed the requirement. Getting to the right mindset for XP means not just accepting changes, but explicitly asking for them.

Embracing change has two aspects: on the scope of the project, and on the codebase itself. The impact of changes on the code can be serious—a change that seems like it should be small can often surprise the team by requiring a frustrating and invasive rewrite. Teams will talk about “ripping out code” and plugging the hole with “duct tape, paperclips, and chewing gum.” We’ll delve into this aspect of embracing change in Chapter 7. For now, we’ll concentrate on how XP teams embrace changes to the scope, functionality, and behavior of the software.

So how do the primary practices of XP help teams do that?

Planning

When teams plan iteratively, and deliver working software at the end of every iteration, they constantly get feedback. Everyone on the team knows that they’re actively asking for that feedback—changes—and it’s a lot easier to deal with changes emotionally when you’re the one who asked for it in the first place.

Team

Problems are a lot easier to deal with when you’ve got people around you to help. When teams sit together, they pick up on problems a lot earlier. And an informative workspace helps make sure that everyone is thinking about the same problems. This gives everyone on the team the ability to take control of those changes when they happen, and not be caught off guard by an unexpected change. This gives the individual team members the autonomy they need to make choices that affect their code—and their lives.

Integration

One of the most frustrating problems caused by unexpected changes is how those changes ripple out through the entire codebase. If you’re working on a change, it helps me, as your team member, to find about it early—that’s why the team practices are really useful. But I’ll still be caught off guard if a change you make to one part of the codebase causes an unexpected bug in the part that I’m working on. By continuously integrating (which is made easier because our build runs quickly), we’ll find out about that problem very quickly, and fix it early—before it has a chance to surprise us and cause headaches later.

Programming

How does continuous integration help us find those changes? We’ve built a suite of unit tests that we run every time we integrate the code. So when you’re integrating your change, you run all of the tests, including the ones for the part of the code I’m working on. If one of those tests fails, then we can work together—and even pair up—to fix the problem in both parts of the code.

If all of these practices are in place, then changes—even big ones—have a smaller impact. This helps the team learn that changes can be handled more easily.

XP Helps Developers Learn to Work with Users

A lot of teams following a BRUF waterfall methodology find success with the first release, and often the second release too. This shouldn’t be too surprising. Before the project starts, there’s usually been a lot of discussion. There’s a specific need that’s well understood, and pressing enough to actually get the company to put money and resources behind the project. That means the first version of the requirements often reflect all of that discussion, and incorporate the best ideas that everyone came up with. In fact, usually the topic has been talked to death, and people are relieved that the team has actually started to build it. This is a great way of preventing changes and rework: because so much thought has gone into the requirements already, it’s pretty likely that they don’t need to be changed much. What’s more, the second version probably mostly contains valuable features that the team just didn’t have time to put into the first version. So it’s a pretty common pattern for BRUF teams to have some early success, and build a first version of the software that works well and doesn’t require many changes.

The problem is that when the project reaches the second, third, and fourth releases, people have been using the software. And we already know that delivering working software is a great way to elicit feedback from users (which, again, is why agile teams favor working software over comprehensive documentation). Now the users have some good feedback, and a lot of times implementing that feedback requires rework.

So what happens if the team built the software in a way that is difficult to change? They’ll go through their planning, evaluate the requests, and determine that making those changes has a high risk of injecting defects into the code, which will cause the change to require a lot of time to implement. This will give them a very rational, well-deserved fear of changes. And it will force the users, clients, and stakeholders to find ways to change their requirements so that they can be implemented with the existing codebase. The great partnership that emerged in the first version of the software between the users and the team can easily turn into an antagonistic relationship—one that turns the requirement elicitation into a contract negotiation, and makes it difficult to have customer collaboration.

XP gives the team a way past this problem by providing practices which, if applied by a team with the right mindset, help them build a codebase that is easy to change. (You’ll learn more about this in Chapter 7.)

But XP also changes the way that everyone on the team thinks about quality. Quality isn’t just about avoiding bugs. It’s about giving users software that meets their needs—even if that software isn’t exactly what they originally asked for. Traditional BRUF teams separate the functional design (what the software does) from the technical design (how it’s constructed). The functionality is written into a spec, which is then handed to the team to implement. If the programmers have questions, or if the functionality seems wrong, they can go back and ask the person who wrote the spec for clarification. Then a game of “telephone” happens—the spec writer asks the users, managers, and whoever else they elicited requirements from, and “translates” the results back into language that the programmers can understand. Interestingly, BRUF teams consider that to be very efficient, because it doesn’t “waste” the developer’s time by forcing him to talk to users. (And everyone knows that programmers don’t have any social skills, right?)

The “trick” that XP pulls is forcing the developer to think like a user—starting with having the developer actually talk to the users. (What?!) If the developers don’t have the skills to talk to the users, they’ll start to build them. The XP practices actually help with this. For example, take test-driven development. The developers write tests first. This prevents bugs. But it also forces each developer to think, “What does this code have to do?” before writing it. A developer who gets into the habit of thinking about functionality like this before writing any code will start to ask the same thing when planning each weekly cycle.

XP also avoids the CYA inherent in a specification.  It’s straightforward for a developer to implement exactly what’s in the spec as written, without ever thinking about whether it really meets the needs of the user. But if he’s developed the habit of always asking “What is it supposed to do?” before writing code, he’ll start spotting problems—and will feel comfortable demanding answers, because he needs those answers in order to write the tests. He won’t just push that responsibility off onto whoever wrote a specification and handed it to him. When everyone on an XP team does this, they constantly ask for clarification from the users, and do their best to figure out what the software needs to do so that the users can do their jobs. They do this directly with the users, rather than through a single intermediary, which saves a lot of time.

In other words, BRUF lets you build what you intended. XP helps you build what your users actually need. And everyone is happier: the team members are happier because they can spend their time solving real problems instead of fighting with the code to make changes, and users are happier because they get what they want (and not what they thought they wanted six months ago). And what emerges is a whole team—including the users, customers, and stakeholders—where they don’t have to commit to knowing exactly what they’ll need in six months or a year, and instead concentrate on building the best software they can for the most important needs they know about today.

So how does XP do this?

Practices Only “Stick” When the Team Truly Believes in Them

The practices of XP help you concentrate on the quality of the code that you’re building before you’ve put a lot of code in place. Where Scrum is all about making sure that your customers know what you can produce and what you can’t, XP is about making it possible for you to make changes as quickly and as defect-free as possible. And that helps everyone on the team to develop an attitude toward quality that permeates all of the development work in your project.

This is a new way of thinking for many technical people, even very experienced “rock star” developers. It’s often not hard to get the technical people on the team behind Scrum, especially a “better-than-not-doing-it” version of Scrum, if they feel like poor planning causes the problems on the project. And it’s true that Scrum is a great way to improve the way that a team plans projects. But what happens when each individual developer looks at the XP practices, and discovers that those practices actually ask him or her to change the way they code?

Figure 6-3. A very common reaction to XP is that it sounds good in theory, but practices like pair programming and test-driven development “just won’t work for our team.” It’s not necessarily an argument against those practices, as much as it is a feeling that this will be a difficult change.

One of the most basic facts about building software: there are an almost unlimited number of ways that you can write a program. Ask two developers to build exactly the same unit (class, function, library, or whatever applies to the language or framework being used), and it is highly unlikely that they’ll both produce the same code. Is it too difficult to imagine that one of them might produce much better code than the other?

Obviously, programming skill has a lot to do with it. But skill isn’t everything. And, in fact, many teams with very highly skilled developers have found themselves maintaining lousy code. Often, this lousy code happens when the developers are rushed to make a lot of changes that they hadn’t planned for. And the end result is a lot of bugs... and a fear of changes and rework that permeates the team.

This is a pretty common reason that causes teams to turn to XP. And what a lot of those teams—and especially their managers—will focus on are the XP practices that are specifically aimed at catching and preventing bugs. Pair programming is a good idea, because it’s like having a constant code review—and more eyes on the code means more bugs caught before they go in. Test-driven development means that the team will write and maintain tests to catch bugs that get added along the way, and continuous integration means that those tests will be run all the time. This all sounds like a great idea, right? And it will definitely catch more bugs.

A team that gets better-than-not-doing-it results with XP will find that pair programming prevents defects from getting into the software, and test-driven development and continuous integration catch defects when they’re added. But a team like that will usually think of these practices as “nice-to-haves.” The bare minimum that they have to do to get the project out the door is write code. There’s always a tendency when teams get behind schedule to just do that bare minimum, and cut out all of those extra bells and whistles. They’ll say things like, “We’re running late, so we don’t have time to write unit tests,” or “It would be great if we had the capacity to dedicate two programmers to each task, but we just don’t have that kind of manpower if we want to hit our deadlines.”

This is not an unusual mindset for a team that first comes in contact with XP. The problem with this mindset is that these great practices end up being treated like going on a diet or exercising: things that are a really good idea, and if we didn’t have such a busy lifestyle, we would definitely be doing them. But even for the people who do it religiously, if these practices feel optional, then when schedules get tight or projects run into problems, they’ll get dropped.

This is also why it’s counterproductive for teams to treat the XP practices like a checklist—or, even worse, try to assign a “percentage of XP we’ve put in place” value based on how many practices that they’ve adopted. This is treating the XP practices like the end itself, rather than a means to an end. This is a big, red, flashing warning sign that the team has a mindset that’s not yet ready for XP.

A team that doesn’t have the right mindset for XP will have to shift the way they think. That mindset shift can seem like a big deal to a team, especially if they don’t really accept the idea that the practices are truly worth their time. So what causes a team to treat XP practices as “first-class citizen” practices that are vital for building great software, rather than optional add-ons that are a good idea, but not truly necessary?

The XP Values

Communication

Each team member is aware of the work everyone else is doing.

Simplicity

Developers focus on writing the most simple and direct solutions possible.

Feedback

Constant tests and feedback loops keep the quality of the product in check.

Courage

Each team member is focused on making the best choices for the project, even if it means having to discard failing solutions or approach things differently.

Respect

Every team member is important and valuable to the project.

These all sound like great, abstract ideas. Who could disagree with them?

(You may find out shortly that you do... and that’s OK, as long as you keep an open mind about them.)

Paved with Good Intentions

When a team starts their XP adoption, everyone is optimistic. They know there are problems with code quality, they’re sick of the headaches and the bugs, and it seems like the XP practices will finally fix them.

Then real life creeps in. Intuitively, it feels very expensive having someone sit with you as you go through the thought process of writing code. If the only benefit to pair programming is an extra set of eyeballs to catch bugs, then there are more efficient ways to go about that. A code review after the code is written will probably catch almost as many bugs (and there’s no reason you couldn’t do one after a pair programming session). But if you’re pressed for time because of a looming deadline, it’s easy to convince yourself that a code review is almost as good as pair programing. “I’m sort of pairing, because I’m getting someone else involved!”

Almost every XP practice has a similar shortcut. You don’t have to sit together; you can just have daily meetings. You don’t need to have your team members continuously integrate in their sandboxes; you can just set up a server to do it automatically for you. You don’t need to write tests first; you can do it after the fact, and still catch bugs when the tests fail.

All of those things are true. And in every case, it’s better than not doing anything—so you’ll get better-than-not-doing-it results.

Flip back to the quote from Kent Beck earlier in this chapter: “Practices by themselves are barren. Unless given purpose by values, they become rote.” This is similar to what Ken Schwaber said about Scrum, self-organization, and collective commitment: each XP practice does much more than simply bring extra eyeballs to the code, or get people to sit in the same room, or add tests to the codebase. They help the team bring the values of XP into the project.

That’s why shortcuts that seem to do the same thing as the XP practices will only get better-than-not-doing-it results. They change the mechanics of how the team does their work, but they don’t change the intent or the mindset of the team.

It’s very common among teams that first encounter XP to skip past the values, because the practices seem more interesting. Many developers will literally open a book about XP, take a quick look at the XP values, and then flip straight to the section on the practices.

Practices are concrete. You can look at a practice and imagine yourself doing it, and you can understand the impact it has on your project. And practices are isolated—you can add an individual practice to your project without having to change the way that you think about everything that you and your team do.

Values are harder for teams to get their heads around. They’re more abstract, and they affect the entire project and the way everyone thinks about it. You can technically add practices to your project without understanding the values (which gives you better-than-not-doing-it results). It’s more difficult to understand the values without first having some experience with the practices.

This isn’t unique to XP. It affects Scrum as well. It’s very typical for an introductory Scrum training class to have one or two slides on the Scrum values, spend a few minutes talking through them, and then rush straight into the “meat” of the training—the practices. But we shouldn’t be hard on the trainers about this. It’s much easier to train people to learn individual XP or Scrum practices than it is for a trainer to use the values to change how they think. Most trainers know from experience that if they give a class that’s focused on the values, they’ll often get feedback from developers that it’s “too theoretical” and doesn’t give them practical information that they can use on their projects. And again, this is also an understandable reaction—it’s hard to see why the values are practical until you actually understand them, and it’s not immediately obvious why the practices don’t really work without the values, so the developers are in a catch-22.

Flip back to the ongoing story about Justin, Danielle, and their fantasy basketball project. They barreled straight into adding XP practices before really taking the time to understand the XP values. Even though you don’t have all of the details about how they did their work every day, see if you can spot ways that they went wrong with their attempt to adopt XP. Here are a few examples that we found:

Communication

Danielle and Justin didn’t talk about dropping the practices they thought they needed. And they definitely didn’t talk to Bridget about the real status of the work—which is fine with her, because when the project has problems, she’ll be happy to blame them for not letting her know earlier.

Simplicity

Justin’s code is looking increasingly complicated, even convoluted. He’s capable of writing better code, but he just doesn’t feel like he has time to do it. 

Feedback

When they stopped pair programming together, Justin and Danielle basically stopped meeting at all. If Danielle had looked at his code earlier and given him some feedback, maybe it wouldn’t be such a mess. And even though the workspace is more informative, the information that’s being distributed isn’t about helping people make better decisions about the project. Figuring out “how XP they are” doesn’t actually make the software better.

Courage

When the team is “not remotely likely” to finish on time and they know it, it takes a lot of courage to tell the truth to everyone—especially if it means the messenger will be shot. Danielle and Justin don’t have that kind of courage.

Respect

There’s very little in professional life that’s more disrespectful than expecting a team to deliver on an impossible schedule.⁴⁴ Bridget repeatedly set deadlines that were ridiculously aggressive. Even worse, she didn’t feel the need to be around to see them through—like the time she called a meeting late on Friday and demanded that the team deliver a bunch of fixes by Monday morning, then had the team work through the weekend while she went on vacation. (That part wasn’t actually in the story earlier in this chapter, but we have it on good authority that it happened.)

When the XP values aren’t truly internalized by each person on the team, they’re likely to get better-than-not-doing-it results (at best!). They’ll talk about how some of the practices—most often, pair programming and test-driven development—“just won’t work for our team.” The team members won’t really make an argument against those practices, as much as share a feeling that this will be a difficult change to make, and will favor a checklist approach that starts with other practices first.

A good XP team has the right mindset when they really get the values. And when they do, something interesting happens to the way the team thinks about XP: the practices start to make sense.

For example, here’s what often happens when a team starts doing continuous integration. A lot of teams avoid it at first, because they think that it requires them to set up a build server (which requires time, and a computer to run it on). But continuous integration can be done with nothing more than a build token, like a silly toy or stuffed animal. Imagine that a team that’s new to XP starts doing this. The first person who receives the token takes a few minutes to integrate the code from the version control system back into her sandbox, does whatever testing she needs to do to make sure that the program still works, and then checks the code back into version control. The token is passed from developer to developer, and each time the developer integrates the code into her sandbox, tests, checks it back in, and then passes the token on to the next developer.

How will this help the team learn about XP values?

Often, the build token will repeatedly stop with the same developer for a long time, because that person feels like he just can’t interrupt what he’s doing right now. The rest of the team needs to find a way to communicate about this, and let that developer know that continuous integration is important to them—this will teach them about communication, and help them value it more. And that stubborn developer will learn about the value of respect, because he’ll need to prioritize the team’s continuous integration ahead of whatever current task he thinks is more important. There are other lessons about the values that can be learned by adopting continuous integration. The team can learn about feedback (when integrating today causes a big problem to come to light early, saving the team time down the road), courage (because if that problem is someone else’s fault, you actually have to talk to them about it—and that’s not always easy, especially for an introverted person), and more.

This is how adopting an XP practice helps shape the mindset of the team.

But you don’t need to start adopting practices to learn if your team has an XP-compatible mindset. You can also play “Are you OK with?” for XP:

• Is the team actually OK with building software and throwing it out because they learned that it won’t work? What about the boss?

• If the boss wants a tighter deadline, does the team truly believe that writing unit tests is the fastest way to meet it, even if it means writing more code?

• If a junior programmer takes on a task, is the rest of the team OK giving him the authority to finish it? What if they disagree with his approach? What if someone else thinks he can do it faster? Is it OK if the developer fails and learns from it?

So what do you do when your team doesn’t quite “get” the XP values?

The Principles of XP

These principles are useful to help you understand some of the specific practices that XP uses—and when you start exploring the practices, they help you understand the principles.

Just like with the XP values, it’s tempting for people who are new to XP to gloss over the principles and skip straight to the practices. This is the path of least resistance for several reasons. You can add a practice without having to acknowledge that anything is wrong with your project. (“We’re doing great, but we can do even better!”) If you skip past the values and principles and jump straight into the practices, you can easily take a “checklist” approach to XP, adding each practice to a list and checking it off once teams are going through the motions for that practice. If your goal is to have a “complete” adoption of every XP practice, that approach works very well.

But if your goal is to help your team build better software, then the checklist approach to XP adoption will fail. You’ll get better-than-not-doing-it results at best, and over time the practices will probably start to fade away as the team reverts to the way they’d always done things. That’s a very familiar pattern for both XP and Scrum teams, and in the real world we’ve talked to many people on many different teams who have experienced it. Team members typically start to blame the methodology: “We’re putting all of this effort into writing tests (or pair programming, or Daily Scrum meetings, etc.), and it’s not buying us much. This methodology must not work.”

The principles help us understand why this happens. Principles are about self-reflection. They force you to take a step back and think about how you and your team do your jobs. When you take the time to understand the values and principles, you start to learn where your team has problems. This is uncomfortable, and it’s often a negative experience. For example, you might look at the principle of failure and realize that your team has a culture where failure is not an option. Even admitting that you ran into a problem will cause your boss to yell at you. Your team members may start to disrespect you as the person who always makes mistakes. There are many companies where simply admitting that you made a mistake will have serious professional consequences.⁴⁵

This is why it’s completely rational for people on many teams to ignore the values and principles, or pay lip service to them without actually making any changes. Put yourself in the position of someone who understands that their team’s culture is at odds with the XP principle of failure. What happens if you raise the issue, and demand that people change the way they work? You might be able to change the culture of your team. Or your team members and your boss might get so mad at you that you get fired. We’ve seen the latter happen more often than the former. When you hear people say that agile is hard, this is one reason why.

Figure 6-4. Scrum and XP are similar, but different.

XP Principles Help You Understand Planning

Roles on a mature XP team aren’t fixed and rigid. The goal is to have everyone contribute to the best he has to offer to the team’s success. At first, fixed roles can help in learning new habits, like having technical people make technical decisions and business people make business decisions. After new, mutually respectful relationships are established among the team members, fixed roles interfere with the goal of having everyone do his best.

Kent Beck Extreme Programming Explained, 2nd Edition

It’s not a coincidence that mindset problems stemming from a clash between the team and the methodology’s values affects both Scrum and XP. Many of the values and principles of XP are shared with Scrum. But there are a lot of differences, too. Like roles—Scrum has the roles of Product Manager and Scrum Master, while a mature XP team doesn’t have fixed roles. A useful way to learn about XP is to concentrate on the principles that it doesn’t share with Scrum. That can be especially valuable when learning about how XP teams plan projects.

A lot of Scrum is about planning: planning the big picture using the product backlog, planning an iteration using the sprint backlog, and getting everyone on the team to collaborate on the plan using the Daily Scrum and other Scrum practices. XP uses similar iterative practices: the quarterly cycle is used to plan the big picture, the weekly cycle is used to manage iterations, and the team uses an informative workspace that contains tracking tools like a task board.

But planning and tracking an XP project is not the same as planning and tracking a Scrum project, and the principles help us understand why. Why doesn’t an XP project have specific roles? This is where XP teams take opportunity and diversity very seriously. It’s rare (although not unheard of) on a Scrum team for a Product Owner or Scrum Master to jump in and work on the software architecture and design, just like it’s rare for a team member to take the lead in working with users or grooming the backlog. XP teams explicitly reject a separation of roles for two reasons. The first reason is that shutting someone out of a role means passing up an opportunity for him or her to contribute if he or she happens to have something to contribute. And the second is that anyone on the team might bring a fresh perspective, and that perspective could be the key to unraveling a tricky problem. Sometimes a highly technical developer has a very good idea for a user, or a project manager might have some valuable input on architecture—specifically because she’s been thinking about the project from a completely different perspective than the people working on those aspects of it.

Understanding the principles in this way changes how you perform the practices. In the fantasy basketball project, Danielle learned that pairing with a brand-new developer who had never seen the code brought a completely different perspective. This is diversity at work: good ideas come from everywhere, even the new guy. That’s why many XP teams rotate pair programming partners, rather than staying with the same pairs all the time. It brings diversity to the pairs and means bringing fresh eyes and fresh perspectives, which helps catch more problems and can spark innovation. And the principle of humanity comes into play as well: bringing different people in, and having them work together constantly, helps create an environment where everyone is giving feedback to each other all the time, and it helps each person learn to accept feedback and even criticism from their teams while still respecting them as people. And it helps give junior team members the courage to speak up when there are problems, even if they’re paired with more senior team members. Principles like diversity and humanity combine with values like communication, respect, and courage to help a team make pair programming an effective tool for them.

Principles can also help us understand why XP doesn’t have a specific after-action review practice, the way Scrum has retrospectives. XP places value on improvement and reflection, and XP teams constantly talk about how they’re doing and how they can improve. But XP teams tend to be very conscious of “navel-gazing”—taking reflection too far and getting distracted from continuously delivering work. So XP teams tend to mix their reflection in with the work. This is something that pair programming is very good at: getting developers to talk about what they’re doing while they’re doing it. The principle of baby steps helps this a lot: instead of setting a large, overarching goal (“let’s adopt all of the XP practices”), the team can take a small step toward it (“let’s start pair programming, and we’ll make sure we talk every day about how we’re improving”).

XP Principles Help You Understand Practices—and Vice Versa

XP teams use stories, and if you look at any story that an XP teams uses, it looks exactly like a story that would be used by a Scrum team. But while the practice is basically identical on both kinds of teams, you can learn a lot about how XP teams use those stories by applying the principles.

Figure 6-5 shows a typical story that an XP team might use on a project. XP, like Scrum, does not impose a universal format for user stories. In this case, the team decided to use a free-form sentence (rather than the “As a... I want to... So that...” format), and write the number of hours they thought it would take to implement the story on the front of the index card.

Figure 6-5. XP teams use the same stories as Scrum teams, but apply their own values and principles to them.

You already know how a Scrum team would use this story. It would be created as part of the backlog, incorporated into a sprint, and put on a task board. How would an XP team use the principles to integrate this story into their project? They might do very similar things. But they would also use the XP principles to help them understand how to incorporate the story into the project:

Economics

The customers pick the stories for the team to build next. This keeps the project team focused on building only the highest-value stories.

Failure

Stories are small and self-contained. The team can build a story and get it into the hands of the customer quickly, so if it’s the wrong software they can work together to make whatever changes are needed.

Accepted responsibility

A programmer read this card and estimated how long it would take to do. Now he’s responsible for the work.

Communication

Writing a story in users’ language helps them to prioritize the work.

Quality

Thinking about how you’ll test the story up front helps you to deliver a higher quality product.

Because you already understand how user stories work, and how project teams use them, you can use that as a good starting point to help you understand these principles.

Feedback Loops

One way that XP and Scrum are similar is that both methodologies place a lot of value on feedback. We already saw how Scrum uses feedback loops to get continuous communication between the team and the customer. Scrum teams and XP teams share very similar values in openness (Scrum) and communication (XP). They have very similar ways of thinking about how people on software teams communicate.

But XP has more to say about feedback. XP teams aim for a very short iteration—the weekly cycle—to increase feedback and shorten the feedback loop. We learned with Scrum that to iterate effectively, the team has to take an active role in understanding what the users need and what’s valuable to them. To keep feedback loops short, they continuously reflect on how the project is going. If there’s a problem then the team will talk about it. Osmotic communication from sitting together helps spread that feedback around the team. When all of these things combine, the team can achieve flow, the XP principle that’s about having a direct and efficient path through the project that delivers a constant stream of high-functioning, high-quality software.

You can see how many different pieces of XP—sit together, osmotic communication, feedback loops, communication, reflection—combine to help teams figure out an efficient and productive path through the project. But flow happens only when many moving parts work together: practices, principles, ideas, and, most of all, good software design and coding. When teams achieve flow, the whole team gets a feeling that they’re releasing an uninterrupted delivery of software. As they communicate more and get more continuous feedback, they start seeing bottlenecks in the way they’re building software, and they learn to work around obstacles together as a team. As they remove those bottlenecks, the flow becomes unencumbered.

Figure 6-6. When the team has the right mindset for XP, its practices feel like the most effective way to build software.

This isn’t something that teams can achieve overnight. They need to spend time not just building software, but also talking about how they build software, and learning how each principle and practice can help them improve. And again, “baby steps” help the team feel comfortable setting a goal—like shorter feedback loops that lead to flow. The methodology as a whole becomes an adoption roadmap: the team can add practices one at a time, using the values and principles to guide each adoption. This week they might find a way to increase reflection, or find a way to improve their environment by sitting together, or pair more effectively. As long as the whole team is taking steps in the right direction, they know that they’re improving how they plan, track, and execute the project. And this means that they’re getting better every day—not just at XP, but at building software.