Meet the team behind CircuitTrak

CircuitTrak is a fast-growing startup that builds software that gyms, yoga studios, and martial arts dojos use to keep track of classes and attendance.

Gary’s the founder and CEO

He’s a former college football player who went on to coach high school and, later, college teams. He started the company in his garage two years ago. It’s been successful almost since day one, and they just moved into an office downtown. Gary’s proud of the company he built, and wants to keep it growing.

Ana and Ryan are the lead engineers

There wouldn’t be a CircuitTrak without Ana and Ryan. They were the company’s first two employees, and have been around since the beginning, when it was just the three of them working out of Gary’s garage. CircuitTrak is up to nine people now—in the last year they hired four other engineers and two sales people—but Ryan and Ana are still the core of the team.

Ana was Gary’s first hire. She played lacrosse, softball, and soccer in high school, and got a softball scholarship to put herself through college, where she majored in computer science. Not long after Gary hired her, she recommended that he also hire her college classmate, Ryan. He graduated from the same computer science program a year after she did, and was also a college athlete.

Late nights and weekends lead to code problems

Ryan and Ana built the first two versions of CircuitTrak by working 90-hour weeks filled with grit, determination, and lots of caffeine. Now that sales are growing and they’re working on version 3.0, they thought they’d be able to relax a little—but they still work plenty of nights and weekends... and Ryan’s worried about the effect it’s having on the code.

Ana: What’s the problem? And let’s make this fast, I need to get back to coding.

Ryan: That’s my point! We’re always up against some deadline.

Ana: Well, it’s a startup. What do you expect?

Ryan: I expected this for the first year, maybe. But we’ve got customers now. We’re growing the team. We shouldn’t be scrambling like this.

Ana: That’s just how software projects are, right?

Ryan: Maybe. But look at what it does to the code.

Ana: What do you mean?

Ryan: Like, look at what we did here. Remember when we had to change the way we stored group identifiers in the trainer management service?

Ana: Yeah, that was ugly. We still needed the old ID in some parts of the code.

Ryan: Right, so some code uses the old format, and some uses the new format.

Ana: Wait, weren’t we supposed to clean that up?

Ryan: Add it to the long list of things we were “supposed to” clean up.

Ana: Well, it’s basically working, right? If we clean it up now, we’ll fall behind.

Ryan: So... what? We’ll keep adding lousy code, and never get to clean it up?

Ana: I don’t know what to tell you. I think that’s just how it is.

XP brings a mindset that helps the team and the code

XP (or Extreme Programming) is an agile methodology that’s been popular with software teams since the 1990s. XP is focused not just on project management (like Scrum is), but also on how teams actually build code. Like Scrum, XP has practices and values that help teams get into an effective mindset. XP’s mindset helps everyone become more cohesive, communicate better, and do a better job planning—which allows for enough time to build the code right.

Iterative development helps teams stay on top of changes

The second principle behind the Agile Manifesto is a good description of how XP teams think about change:

But wait a minute... didn’t we talk about this principle earlier in the book? Yes, we did—it’s also a good way to explain iterative development and the idea of making decisions at the last responsible moment. So it shouldn’t be a surprise that XP is an iterative and incremental methodology. XP uses practices that should feel very familiar to you now that you’ve learned about Scrum. XP teams use stories, just like Scrum teams do. They plan a backlog using a quarterly cycle, which is broken into iterations called the weekly cycle. In fact, the only new planning idea here is a simple practice called slack that XP teams use to add extra capacity to each iteration.

XP teams use stories to track their requirements

It’s no surprise that XP teams use stories as one of their core practices, because they’re a really effective way to keep track of what you’re planning to build. They work exactly the same way that they do in Scrum.

Many XP teams use the “As a... I want to... so that” story format, and often write their stories on index cards or sticky notes.

They’ll also typically include a rough estimate of how long the story will take. It’s not uncommon to see an XP team use planning poker to come up with that estimate.

XP teams use one-week iterations

The weekly cycle practice is a one-week iteration in which the team chooses stories and builds working software that’s “Done” at the end the week.

Each cycle starts with a meeting where they demo the working software and plan out what they’re going to accomplish by:

• Reviewing the progress they’ve made so far, and doing a demo of exactly what they did last week

• Working with the customer to pick the stories for this week

• Decomposing the stories into tasks

XP teams sometimes assign the individual tasks when they plan the weekly cycle, but they’ll often self-organize by creating a pile of tasks and have each team member pull his or her next task off of the pile.

The weekly cycle starts on the same day each week, usually a Tuesday or Wednesday (Mondays are avoided, so that the team doesn’t feel pressured to work over the weekend), and the planning meeting is typically held at the same time each week. The customer is typically a part of the meeting to help the team select the stories, and to stay on top of the progress.

Courage and respect keep fear out of the project

XP, like every agile method, depends on a team that has the right mindset. That’s why XP comes with its own set of values. The first two values are courage and respect. Do those values sound familiar? They should—they’re exactly the same values that you learned about earlier in Chapter 3, because Scrum teams also value courage and respect.

XP and Scrum each focus on different aspects of software development.

XP, like Scrum, is an iterative and incremental methodology. But it doesn’t have the same strong focus on project management that Scrum has—especially since it doesn’t focus on empirical process control, which is a really powerful tool for teams to improve the way they manage their projects. It’s also why Scrum teams feel very structured: each sprint starts and ends with their timeboxed meetings, and every day there’s another timeboxed meeting at the same time.

The “P” in XP stands for programming, and everything in XP is optimized to help a programming team improve the way they work. XP is different from Scrum because it’s focused on getting the team to work well together. XP has a lighter focus on project management, and more focus on improving the way the team builds code.

XP includes enough project management to get the job done.

What ties them together are common ideas and shared values like the ones in the Agile Manifesto. And since iteration in XP works like it does in Scrum, and XP shares the values of courage and respect with Scrum, many agile teams use a hybrid of Scrum and XP by combining the empirical process control of Scrum with XP’s focus on team cohesion, communication, code quality, and programming.

Venn Magnets

You spent all night arranging magnets on your fridge into a really useful Venn diagram that shows which practices and values (and even a couple of concepts) are specific to Scrum, which are specific to XP, and which are shared by both... and then someone slammed the fridge door and all the magnets fell off. Can you put them back in the right places?

Venn Magnets Solution

XP teams have a different attitude towards planning than Scrum teams do, and it’s reflected in the practices and values that they share and the ones that they don’t.

there are no Dumb Questions

Q: How do stories get estimated?

A: Planning poker is very popular among XP teams, but they also use a lot of other methods for estimation. Early versions of XP included a practice that was called the planning game that guided the team through decomposing stories into tasks, assigning them to team members, and turning them into a plan for the iteration, which is still in use on a few XP teams here and there. But for most teams, estimation in XP is no different from estimation in Scrum. Techniques like planning poker are really useful, but in the end estimation is a skill: the results get better as the team gets more practice.

Q: How does a methodology “focus” on one thing or another?

A: Scrum is focused on project management and product development because the practices, values, and ideas of Scrum are specifically aimed at the problems of project management: determining what product will be built, and planning and executing the work. Scrum practices are primarily built to help the team get organized, to manage the expectations of the users and stakeholders, and to make sure everyone is communicating.

XP has a more limited approach to project management. It’s still iterative and incremental, and the practices you’ve seen so far in this chapter—quarterly cycle, weekly cycle, slack, and stories—are an effective way to plan and manage those iterations. But they lack the structure and rigidity of Scrum: there aren’t daily meetings, the meetings aren’t timeboxed, and everything just feels “loose” compared to Scrum. A lot of teams find that the structure of Scrum works really well for them, so they’ll opt for a Scrum/XP hybrid where they replace XP’s quarterly cycle, weekly cycle, and slack with a complete implementation of Scrum. That means including all of the events, artifacts, and roles of Scrum.

Q: Wouldn’t a “hybrid” of XP and Scrum break the rules of one of them?

A: Yes—but it’s OK! If your team adopts a hybrid of XP and Scrum by replacing the planning practices of XP with the ones in Scrum, then obviously you’re not performing every single practice in XP. But remember, the rules of a methodology are there to help you run your projects well. A lot of teams run into trouble when they modify an agile methodology because they don’t really understand exactly why that methodology works. They often change or remove an element that may seem minor to them, but don’t realize that it’s one of the pillars that keeps the whole methodology up—like when teams try to replace the Product Owner in Scrum with a committee, which removes a critical piece of Scrum. Luckily, replacing XP’s weekly cycle, quarterly cycle, and slack practices with a complete and unmodified implementation of Scrum impacts only the planning part of XP, and it doesn’t remove any of the other pillars that make XP work, which is why so many teams have had success doing it.

Teams build better code when they work together

A software team is more than just a group of people who happen to be working on the same project. When people work together, listen to each other, and help each other solve problems, they write a lot more code (sometimes 10 times as much!), and the code they build is much higher quality. XP teams know this, and the whole team practice helps to get them there. This practice is about everyone functioning as a team together. It means doing whatever it takes to make people feel like they belong, and helping each person support everyone else on the team.

A whole team is built on trust

When people on an XP team encounter obstacles, they all work together to overcome them. When they’re facing an important decision that affects the direction of the project, that decision is made together. That’s why trust is so important to XP teams. Everyone on the team learns to trust the rest of the team members to figure out which decisions can be made individually, and which decisions need to be brought to the rest of the team.

XP teams don’t have fixed or prescribed roles

There are a lot of different jobs to do on any software project: building code, writing stories, talking to users, designing user interfaces, engineering the architecture, managing the project, and more. On an XP team, everyone does a little bit of everything—their roles change depending on the skills they bring to the table. That’s one reason why XP teams don’t have fixed or prescribed roles.

Roles can keep people from feeling a sense of belonging on the team. For example, it’s not uncommon on a Scrum team for a Product Owner or Scrum Master to feel like they’re not really part of the day-to-day work, as if their “special” role puts pressure on them to be more interested than committed. (Remember pigs versus chickens? Sometimes it’s almost as if giving someone’s role on the team a name can encourage some people to be more “pig” and others to be more “chicken” on the project.)

Teams work best when they sit together

Programming is a highly social activity. Yes, really! Sure, we’re all familiar with the image of the lone coder who sits in the dark for hours on end, emerging from his hole after weeks with a complete, finished product. But that’s not really how teams build software in the real world. Take another look at this agile principle:

When you’re on a software team, you need information all the time: you need to know what you’re building, how you and your team plan to build it, how the piece you’re working on will fit into the rest of the software, and so on. And that means you’re going to have a lot of face-to-face conversations.

XP teams sit together because it’s a lot easier for programmers to innovate when they can easily talk to each other, and don’t have to spend a lot of time walking around in order to get the information they need.

So what happens if you and your team sit in entirely different parts of the office? This is really common: for example, when the person laying out the office space has the “coder in the dark hole” image of software development, the space gets laid out to give managers a lot of office space, and the programming team is sprinkled into whatever space is left over. This is a really ineffective environment for a software team.

That’s why XP teams sit together. That’s a simple practice where everyone on the team sits in the same part of the office so that it’s easy and convenient for each person to find his or her teammates and have a face-to-face conversation.

XP teams value communication

People on XP teams work together. They plan together, collaborate to figure out what they’re going to build, and even code together. If you’re on an XP team, you truly believe that when you’re faced with a problem, you’ll come up with the best solution if you communicate with your teammates. That’s why communication is one of the XP values. One way that XP teams improve the way that they communicate is by having an informative workspace. This is an XP practice where the team sets up their working environment so that it’s impossible not to constantly absorb information from those around them.

Team programming is social. It’s not an isolated activity.

Programmers don’t like being interrupted—and for good reason. When you’re on a roll coding, you get into a kind of “zone,” a state of high concentration where work seems to just flow. In fact, a lot of people have a name for this state: flow. It’s actually pretty much the same thing as when an athlete is “in the zone” (where players feel like the baseball is the size of a watermelon, or the basketball hoop looks like it’s 10-feet wide). This effect has actually been studied, and those studies found that it can take 15 to 45 minutes for a programmer to reach that state. An interruption, like a phone call or an annoying email, can completely break you out of flow. If you get two phone calls an hour, you can sit at your desk all day and get nothing done.

So wait a minute—doesn’t that mean that to achieve maximum flow, the team should work in an environment of absolute silence? No—just the opposite! It’s actually hard to concentrate in dead silence, because every time someone coughs or rustles some papers it feels like it’s a freight train went by. If there’s a little activity around you all the time, it’s actually easier to tune it out. (And after all, athletes can get themselves in the zone even in front of screaming fans!)

Teams work best with relaxed, rested minds

Software teams need to innovate all the time. Every day brings new problems to solve. Programming is a really unique job, because it’s a combination of designing new products, implementing new ideas, understanding what people need, solving complex logical problems, and testing what you built. This kind of work requires a relaxed and rested mind. XP’s energized work practice helps everyone on the team needs to stays sharp and focused every day. Here are some ideas for how to energize your work:

there are no Dumb Questions

Q: I don’t believe this “energized” and “sustainable” stuff. Isn’t it just an excuse that programmers use so they don’t have to stay late?

A: Absolutely not! Modern workplaces didn’t come up with a 40-hour week by accident. There have been many, many studies over the years run across many different industries that found that while teams can work long hours for a short burst, it doesn’t take long for their productivity and quality to drop off a cliff. And if you’ve ever had to work three 7-day, 70-hour weeks in a row, you know exactly why—your brain gets tired, and is in no condition to do the kind of demanding intellectual work needed to build great software. That’s why people on XP take work-life balance really seriously: they go home at a reasonable time every day, and have lives and families outside of the job.

Q: No, I still don’t buy it. Isn’t programming mainly just typing?

A: Programmers may spend the day in front of a keyboard, but building code is a lot more than just typing. A programmer can write anywhere from a dozen to a few hundred lines of code in a day. But if you hand that programmer a piece of paper with a few hundred lines of code on it, it might take 10 or 15 minutes to actually type them into a computer. The “work” of programming isn’t the typing, it’s figuring out what the code actually needs to do, and making it work correctly and efficiently.

Q: Doesn’t osmotic communication interrupt people’s work? Isn’t it hard to work in a noisy environment?

A: Osmotic communication works best when people on the team are used to some noise. Our ears tend to perk up when someone is talking about something important and relevant—like how you can hear your name in a crowded room—so it’s not hard to tune out conversations around you if you’re used to them. It doesn’t work so well in a “dead quiet” office environment where everyone feels compelled to whisper, or just not talk at all.

Q: I’m still not clear on how planning works in XP. When does the team meet? How do the stories get estimated?

A: The team estimates stories together during the quarterly planning meeting which happens at the beginning of the quarterly cycle, and they talk about those estimates during the weekly planning meeting at the start of the weekly cycle. They’ll also discover stories along the way, so they meet up and estimate those stories together. As far as how stories are estimated, it’s pretty common to see XP teams using planning poker, but they might also just talk about the story and come up with an estimate that makes sense.

Q: When does the team demo the software to the users?

A: At a meeting at the beginning or end of the weekly cycle, where the users see the software and discuss what the team will work on next. The relationship between the team and the users isn’t as formal as it is in Scrum, which has a specific role—Product Owner—for a customer representative who can accept the software. XP doesn’t have prescribed roles, but XP teams recognize that it’s ideal to have real customers involved. Really effective XP teams feel that the “whole team” practice means treating users who help them understand what to build as a true part of the team.

Q: So wait—XP really doesn’t have prescribed roles?

A: No, it doesn’t. One of the basic ideas in XP is that if there’s a job to do, someone will step up and do it. Everyone on the team brings something unique to the table, and each person’s individual role on the project will change based on what’s needed, and what their expertise is.

Q: I’ve heard programmers complain about being assigned “maintenance” tasks, like fixing bugs in old systems. Is that really creative or innovative?

A: Actually, maintenance work can be some of the most intellectually challenging work there is for a software team. Think about what “maintenance” actually means: fixing bugs, often in code you didn’t even write yourself. That means taking a machine, one that may be really complex, figuring out how it works (often without much documentation and nobody to ask for help), tracking down how it’s broken, and figuring out a way to fix it. Programmers often groan about having to do maintenance, and that gives it a reputation as being “grunt” work: it’s intellectually demanding and, unlike coming up with a cool new feature, it’s rarely rewarded or complimented by your boss or coworkers.

People on XP teams take work-life balance really seriously: they go home at a reasonable time every day so they can keep up a sustainable pace.

Yes! XP teams give themselves space to build great code.

Everything we’ve talked about so far has been about removing things that kill the team’s momentum. Iteration, slack, and stories help the team build the right software, and protect them from unnecessary schedule pressure. An energized workspace, a supportive team, and an informative team space give them the best possible environment to get work done. It’s not an accident that XP focuses on these things—they’re at the root of the vast majority of team problems, and eliminating them gives the team fertile ground for innovation.

So now the stage is set, and the team is ready. It’s time to dig into the code.

Question Clinic: The “which-is-NOT” question

Ana: Quit your whining, Ryan.

Ryan: Hey, don’t give me that attitude. This affects you, too.

Ana: OK, I’m listening. What’s the problem?

Ryan: You won’t like this. It’s a change to personal trainer schedules on the mobile app.

Ana: Customers getting notifications about personal training sessions. What’s the problem?

Ryan: The problem is they don’t just want to get notifications. They want to schedule classes from the mobile app too.

Ana: Oh no. No, no, no. That is not going to work with the way we built this.

Ryan: Tell that to Coach. He’s been promising that to the customers.

Gary: Did I hear someone mention me?

Ana: You promised customers that we’d let them schedule classes from the app?!

Gary: What’s the problem, guys? How hard can it be to add that?

Ana: We’re going to have to completely redesign the way data goes into the system.

Ryan: You know what’s frustrating? If you’d just told us this was coming a few months ago, we would have built a completely different backend for the last version.

Ana: Now we have to rip out the database entry code and replace it with a new service.

Gary: I know you guys can do it.

Ryan: Of course we can. But rewriting that much code will leave us with a giant mess.

Ana: You know how they say rework creates bugs? This is a prime example.

Ryan: And that means a lot of totally avoidable late nights. This stinks.

XP teams embrace change

Here’s a basic fact about software projects: they change. A lot. Users ask for changes all the time, and typically have no idea how much work any one change will require. This wouldn’t be too bad, but there’s a problem: a lot of teams build code that’s difficult to modify: changes require code modifications that are painful to make, and leave the code in very bad shape. This often leads to teams that push back against those changes. When teams resist change, the project suffers. The XP values and practices fix this problem at its source by helping teams to build code that’s easier to modify. And when the code is easy to modify, programmers don’t feel the need to resist change. That’s why XP has practices and values that are focused on programming. Because these practices help teams build code that’s easier to modify, XP helps them reach a mindset where they embrace change instead of resisting it.

People on software teams resist changes when they’ve had bad experiences with rework causing bugs... but rework doesn’t have to do that. XP helps teams embrace change with practices and values that help them to build software that’s easier to modify.

Frequent feedback keeps changes small

Talk to a group of programmers, and it often doesn’t take long before someone starts to complain about how users always change their minds. “They ask for one thing, but when we build it exactly like they wanted they turn around and tell us they need something totally different. Wouldn’t it be easier if we just built the right thing in the first place?”

But ask that same group of programmers how often they designed and built an API, only to find that some of the functions were awkward and difficult to work with. Wouldn’t it be easier if we just built the right API in the first place? Obviously. But you don’t really know if the interface you designed and built is easy to use until someone writes code that actually uses it.

When you put it that way, programmers recognize that it’s really rare to build anything right the first time, so they try to get feedback early and continue to get it frequently. That’s why XP teams value feedback.

And feedback comes in many forms:

Iteration

You’ve already seen a really good example of feedback: iteration. Instead of planning six months of work doing one big demo at the end of it, your team will do a small chunk of work and then get feedback from the users. That lets you continually adjust the plan as the users learn more about what they need.

Teammate reviews

Open source teams have an old saying: “Given enough eyeballs, all bugs are shallow.” Your team is no different. Getting feedback from your teammates helps you catch problems with your code—and it helps them understand what you built so they can work on it later.

Integrating code

When code files on your computer are out of date with the rest of your team, it can lead to frustrating problems. When you integrate your new code frequently with your teammates’ code, it gives you early feedback. The more frequently you integrate, the earlier you catch conflicts, which makes them a lot easier to resolve.

Unit tests

One really effective way to get feedback is to build unit tests, or automated tests that make sure the code that you built works. Unit tests are typically stored in files along with the rest of the code. When you make a change to your code and it breaks a test, that’s some of the most valuable feedback you can get.

Bad experiences cause a rational fear of change

There’s very little that’s more frustrating to a programmer than being halted in your tracks by an annoying, frustrating problem. Most developers will recognize these very common—and very frustrating—problems that Ryan and Ana are running into.

XP practices give you feedback about the code

A lot of agile practices are crafted to give the team feedback early and often—like the ones focused on iteration, which give the team feedback about the product they’re planning to build and the work involved. Each iteration gives them more information, and they use that information to improve how they plan the next iteration. This is an example of a feedback loop: the team learns from each round of feedback, and makes adjustments and self-corrects, which changes what they learn about in the next round. These next four XP practices are especially good tools because they give the team really good feedback about how they design and build the code.

Ready to take a closer look at each of these practices? Flip the page!

XP teams use automated builds that run quickly

There’s nothing more frustrating to a programmer than waiting. That’s a good thing: a lot of innovation starts with a programmer saying, “I can’t stand how long this takes.” So it’s especially frustrating when it takes a lot of time and effort to build the code—and very few things can kill a team’s innovation as quickly as frustration. When something repeatedly takes a long time, the first thing that a good programmer thinks is, “How do I automate that?”

That’s where the 10-minute build practice comes in. The idea is straightforward: the team creates an automated build, usually using a tool or scripting language specifically made for automating builds—and they do it at the beginning of the project. The key here is that they make sure the whole build runs in under 10 minutes. That’s pretty much the limit of patience most programmers have to wait for the build to finish—and it’s long enough so that you can kick off a build, then go grab a cup of coffee and think. By keeping the build under 10 minutes, there’s no hesitation in running it, which helps find build problems quickly.

When the build requires a lot of manual effort or takes longer than 10 minutes to run, it puts stress on the team and slows down the project.

Continuous integration prevents nasty surprises

When you work on a team building code and committing it to a version control system, your day-to-day work follows a pattern. You do some work, then you update your working folder with the latest changes your teammates have pushed, then you push your own changes back to the version control system. Work, update, push... work, update, push... work, update... merge conflict! Uh-oh—one of your teammates made changes to the same line and committed it since the last time you updated. The version control system had no way of knowing whose change is right, so it modified the code files in your working folder with both sets of changes. Your job is to resolve the conflict: you’ll look at them, figure out what the code is supposed to do, modify it so that it’s correct, and commit the resolved change back to the repository:

Every merge conflict is like a little puzzle, and sometimes those puzzles can be annoying to solve because you’re not sure exactly what your teammate was trying to do.

Now flip back to “Bad experiences cause a rational fear of change”. Do you see why Ana ran into so much trouble?

Her teammate hadn’t updated his working folder in weeks. Instead, he just kept making changes to an old version of the code—which got more out of date every day—and then committed all of those changes at once. Ana spent the last few hours working on a change to many of those same files. But instead of having one or two little puzzles to solve, now she has to contend with dozens of files marked up with conflicts. Few things are more frustrating to a programmer than resolving many merge conflicts at once.

When everyone keeps their working folders up to date, the merge conflicts tend to be small and manageable.

That’s why XP teams use continuous integration. It’s a really simple practice: every person on the team integrates and tests their changes every few hours, so nobody’s working folder is ever out of date. When everyone on the team does continuous integration, they’re all working on a current version of the code. There will still be merge conflicts, but they’re almost always small and manageable, and never a giant, frustrating monster of a change like the one that Ana has to deal with.

The weekly cycle starts with writing tests

For many developers, XP brings a different way of working. One of the most obvious changes is that the team does test-driven development (or TDD). That’s a practice where programmers write unit tests before they write the code that it tests. When you’re in the habit of writing unit tests first, you think about what it means for your code to work correctly, which helps you write code that’s “Done” done.

Unit tests change the way the team designs the code

All programmers have had the experience of writing code, only to wish later that they had written it a little differently—looking back, you might realize that a different argument would have worked better for a particular function, or that you could have used a different data structure, or made other choices. But now the code you wrote is called from five other places, and it will be more work to change it than it will be to just live with the poor decision.

In other words, some of the most annoying code problems happen when you make a bad design choice, then you add other code that depends on it. Do this enough and eventually you get that “shotgun surgery” feeling every time you touch that part of the code.

Unit testing helps prevent that problem. Design problems in your code often become apparent the first time that you write code that uses it. And that’s exactly what you’re doing when you write a unit test first: you use the code that you’re about to write. And you do it in small increments, one bit at a time, smoothing out design problems as you encounter them.

Agile teams get feedback from design and testing

Agile teams have great design and testing tools that help the teams get more feedback throughout the project. They can use wireframes to sketch out user interfaces before building them, spike solutions to figure out difficult technical problems, and usability testing to make sure they’ve made effective design choices. Some teams write a charter and list of test objectives as a very lightweight plan and then set out to break the feature or product that was just developed as a way of finding new combinations of actions that the developer might not have thought about. This kind of testing is called exploratory testing and it can be really effective at finding issues that users will run into. All of these tools are great at generating feedback, which is why XP teams integrate them into their weekly cycles—and rely on them to get feedback to help plan the next weekly cycles.

Build spike solutions to get an idea of a feature’s technical difficulty

It’s not uncommon for a team to have trouble estimating a specific feature because they just don’t know enough about what’s involved in solving specific technical problems. That’s where spike solutions come in handy. A spike solution is code written by a team member specifically meant to figure out a specific technical problem. The only purpose of the spike solution is to learn more about the problem, and the code is usually thrown out after it’s done.

Note

When teams talk about usability they’re trying to measure how easy it is to learn and use the software. It’s really common to discuss the usability of a program’s user interface, or the visual interface (like windows or web pages) that users interact with to use the system.

Note

A small change to the user interface can have a huge impact on usability. That’s why wireframes and usability testing are so important.

Pair programming

XP teams use a pretty unique practice called pair programming, where two people sit at a single computer and write code together. This is a new experience for people who are used to thinking of programming as a solitary activity. But it can really be an effective tool for building high-quality code very quickly, because many people who do pair programming report that pairs get more work done together than they do when they work separately.

Pair programming keeps everyone focused, helps the team catch bugs, makes it easy to brainstorm, and gets everyone on the team involved in every part of the codebase.

there are no Dumb Questions

Q: The “sit together” and “pair programming” practices require everyone to be in the same office. Does that mean global or distributed teams can’t use XP?

A: Many global and distributed teams use XP. XP teams know that when they sit together, they have more face time, have fewer interruptions from phone calls, and can share an informative workspace. A distributed team where everyone works in different offices and communicates via email and phone can’t take advantage of these things. But an important part of the XP mindset is that every practice is about making the team work better. If there are some practices that are simply impossible, they’ll work with what they’ve got.

Q: But doesn’t that mean they aren’t doing “pure” XP?

A: Really effective teams know that there’s no such thing as “pure” XP. XP teams are always looking for ways to improve. There’s no “perfect” state that they’re trying to get to; they’re just trying to get better at what they do together. Mindlessly adhering to practices will de-energize the environment really quickly. And making people feel bad about not being “pure” enough is disrespectful. Nagging people about XP “purity” is counterproductive. It makes people feel like you’re judging them and their work. That won’t make anyone change—it’ll just make them resent you, and resent XP.

Q: So does that mean it’s OK to throw out practices I don’t like?

A: No, that’s not OK. The XP practices are carefully designed to work with each other, and when they’re used together they help the team integrate XP values into their mindset. For example, teams really start to understand the XP value of communication when they sit together and have an informative workspace. When teams decide to throw out a practice, it’s usually because their mindset is incompatible with one of the values, and that causes the practice to feel uncomfortable. When that happens, a really good thing to do is to make a genuine effort to try the practice. Often, that helps the team shift their mindset, which in turn helps everyone work better together and build better software.

Q: Doesn’t continuous integration just mean setting up a build server?

A: No. A build server is a program that periodically retrieves the latest code from the version control system, runs the automated build, and alerts the team if there are any failures. It’s a really good idea, and almost all agile teams use one. But a build server isn’t the same thing as continuous integration. Continuous integration means that every person on the team actively (and continuously!) integrates the latest code their teammates wrote into his or her own working folder. The reason this is often given the same name as a build server is that the server is constantly “integrating” code from the version control system into its own repository, and will alert the team any time code is committed that won’t compile or causes test failures. But that’s no substitute for having each person keep his or her working folder up to date.

Q: I don’t get it. If we have a build server that constantly integrates the code, isn’t that less work for everyone?

A: It’s true that having every member of the team continuously integrate the latest code from the version control into their working folder is more work than just setting up a build server. But if they just rely on email alerts from a build server to tell them when they’re out of sync, it often ends badly. For example, you might discover that when you commit code that breaks the build, everyone gets really mad at you, so you commit your code a lot less frequently than you normally would. Or the team might just be so used to “broken build” emails from the build server that they start ignoring them and filing them into folders. On the other hand, if every person feels like they have a responsibility to stop what they’re doing every few hours and integrate code from the version control system back into their own working folders, a broken build is rare—and when it happens, the team notices quickly and works together to fix it.

Q: So is doing continuous integration just a matter of making sure the team has enough discipline?

A: Not quite. When a team is really good at using practices like continuous integration, 10-minute builds, or test-driven development, from the outside it looks like they’re really disciplined. But it’s not really a matter of discipline at all. The team does those things because they make sense to everyone. Everyone on the team simply feels that the work will slow down if, say, they don’t take the time to make the build faster, or build a unit test before writing code. They don’t need to be nagged, yelled at, or reprimanded—in other words, disciplined—because it wouldn’t occur to them not to do those things.

Q: I work with a QA team. Does test-driven development mean testers write my unit tests while I write the code?

A: No. You write your own unit tests first, then you write the code to make them pass. The reason that the unit tests should be written by the same person who writes code is that when you write the tests, you learn a lot about the problem that you’re working on, which makes the code better.

Pair programming is actually a really efficient way to code.

Pairing up keeps you focused and eliminates a lot of distractions (like popping open a browser or checking your email). And there’s always another set of eyeballs to catch bugs early instead of wasting time tracking them down later. But more importantly, it means you’re constantly collaborating with your teammates. Programming is an intellectual activity: writing code means solving problems and puzzles all day long, one problem or puzzle after another. Talking through those puzzles and problems with one of your teammates is a really effective way to solve them.

A practice “just doesn’t feel right” when it clashes with your mindset.

Do you think of yourself as a better programmer than everyone around you? Is coding a solitary activity in your mind? If so, then you’ll have an irrational dislike of pair programming. Do you think of yourself as a “rock star” surrounded by idiots who couldn’t code their way out of a paper bag? Then you’ll have an extremely strong irrational hostility to pair programming. The key word here is irrational: yes, you can think of reasons and rationalizations for disliking pair programming, but at the heart of it what you really have is a feeling that it’s just not right for you or your team. And that’s the definition of irrational: decisions driven by feelings, not reason.

But it turns out that a lot of really good programmers on real-world projects have discovered that not only can their “lesser” teammates (surprisingly!) keep up with them, but when they genuinely try pair programming—not just go through the motions, but really try to make it work—coding really does go a lot faster. Not only that, but their “slower” teammates start to pick up many of the skills and techniques they’ve learned, and the whole team improves together.

Then you and your team don’t value the same things that XP teams do.

XP teams value focus, respect, courage, and feedback. If you really value these things, pair programming makes a lot of sense. When you value focus, you appreciate how pair programming helps keep you and your teammates on track. When you value respect, you won’t have an irrational response to the idea of pairing up with your teammates, because you have respect for them and their abilities. When you value courage, then you’ll be willing to look past your own feelings of discomfort and try something that could potentially help the team. And when you value feedback, then having two eyes on every line of code that’s written feels like a really great idea.

On the other hand, if the last few sentences seem cliché, oversimplistic, overly idealistic, or even stupid, then you don’t share the same values as effective XP teams.

When you try to adopt a practice that doesn’t match your mindset or the culture of your team, it usually doesn’t “take” and you just end up going through the motions.

Adopting new practices takes work, and shared values motivate everyone to do that work.

When teams try to adopt a methodology with values that don’t match the team’s culture, it usually doesn’t end well. The team will try adding some of the practices, and a few of them may work out temporarily. But eventually it will just feel like you and your team are simply “going through the motions” of the practices. They’ll feel like a burden without much benefit, and within a few weeks or months the team will go back to the way things were before.

But that doesn’t mean there’s no hope! It just means that you and your team should talk about the values before you try the practices. If you start working on the culture issues from the beginning, it makes XP (or any methodology!) a lot easier to adopt, and gives the whole effort a much better chance of sticking.

Speaking of improving the way the team functions, let’s check in on Ryan and Ana

Ryan: Ha ha! Good one! ... um ... wait, you’re not joking, are you?

Ana: No, I’m being serious here. We’re adding a lot more code, but now we’re building some pretty complex stuff.

Ryan: Yes!

Ana: That’s not necessarily a good thing.

Ryan: Uh... what?

Ana: Like this centralized common automated build script that you created.

Ryan: How’s that a problem? We had a bunch of nearly identical build scripts. That’s a lot of duplicated code. I fixed it.

Ana: Yeah, you saved like 12 lines of code duplicated in eight different build scripts...

Ryan: OK.

Ana: ...by building this 700-line monstrosity that’s impossible to debug.

Ryan: Um...OK?

Ana: And now any time I need to modify the build, I have to spend hours trying to debug through that enormous script. It’s really painful.

Ryan: But it saves...well...OK. It saves like 12 duplicate lines in a couple of scripts. I get your point—duplicate code is usually bad, but in this case it would be a lot easier to maintain a few duplicate lines than keep working with the script I wrote.

Ana: And it’s not just the builds. We built this super complex unit test framework.

Ryan: I see where you’re going with this. I had to debug through it the other day because I had to update the test data for just one unit test. It took me two hours to do a really simple job that should have taken five minutes.

Ana: You know what? I think adding these new XP practices helped speed up our coding. But I’m starting to think that all of this complexity is starting to slow us down.

Ryan: So what do we do about it?

Complex code is really hard to maintain

As systems grow, they often become big and complicated, and complex code tends to get more complex as you work with it. And when code gets more complex, it gets harder to work with, which causes developers to take shortcuts that make the problem worse. That’s exactly what happened when Ryan tried to make a change that customers needed:

A big, complex system gets more and more complex one little hack at a time.

When teams value simplicity, they build better code

When you’re solving a programming problem, there are an almost infinite number of ways that you can code the solution. Some of those ways are a lot more complex than others. They might have a lot more interconnections between units or add extra layers of logic. Units can grow far too big to understand all at once, or can be written in a way that’s too convoluted to read and comprehend.

On the other hand, everything works better When your code is simple. It’s easier to modify your code to add new behavior, or to modify it to change the way it works. When the code is simple, there are fewer bugs, and they’re easier to track down when they happen.

So how do you know if a particular unit—like the TrainerSchedule Java class that Ryan was working on, for example—is getting too complex? There’s no hard-and-fast rule that governs complexity. That’s why instead of a rule, XP teams have a value. Specifically, people on XP teams value simplicity. Of the many ways to solve any particular coding problem, someone on an XP team will choose the simplest one that he or she can think of.

Code gets complex when it does too many things.

One of the most common ways that your code can get complex is when one unit does too many things. Units of code tend to be organized by their behavior. When one unit does too many things, one of the most effective ways of reducing complexity is to separate it into smaller units that each do just one thing.

Refactor existing code to make it less complex.

There’s no single “right” way to build a specific unit of code—there are many right answers, and it’s rare to write code optimally the first time. That’s why XP teams refactor their code as often as they need to. When they refactor (or modify the code to change its structure without altering its behavior), the code almost always ends up less complex than before.

Great habits are more effective than discipline.

If you try to nag your teammates (or yourself) into using practices like test-driven development or tools like refactoring, they typically won’t stick. Instead, people on effective XP teams develop great habits. For example, they get into the habit of refactoring every time they see code that can be refactored, just like they get into the habit of writing unit tests first. This is part of the XP mindset.

Simplicity is a fundamental agile principle

Let’s take a closer look at one of the twelve principles behind the Agile Manifesto:

Hmm... “maximizing the amount of work not done” sounds like a philosophical musing, or something the caterpillar said in Alice in Wonderland. What does that really mean?

When units are tightly coupled, it adds complexity to the project

When you’re renovating a house, the most damaging thing that you can do is to take a sledgehammer and knock down a wall. That’s one way that writing code is different from engineering physical objects: if you delete a bunch of code, it doesn’t cause permanent damage to the project—you can easily recover it from the version control system.

If you really want to make your code worse, build some new code, modify a bunch of existing units so that they depend on it, and then modify some additional units so they’re all tightly coupled to the ones you modified. That’s practically a guarantee you’ll spend many frustrating hours jumping from one unit to another trying to track down a problem.

An effective way to maximize the amount of work not done is to only write code for a specific, concrete purpose that you know about right now. Avoid writing code just in case you might need it later.

Every team accumulates technical debt

Little problems with your code add up over time. It happens to every team. All developers—even really good, highly skilled developers—write code that can stand to be improved. This is natural: when we’re writing code to solve a problem, we often learn more about that problem as we work on it. It’s very natural to write code that works, look at the results, think about it for a while, and then realize that there are ways that you can improve and simplify it.

But a lot of times developers don’t always go back and improve their code—especially when we feel like we’re under enormous pressure to get code out the door as soon as possible, even if it isn’t as “done” as it could be. And the longer those “unfixed” design and code problems linger in the codebase, the more problems compound, which leads to complex code that’s painful to work with. Teams refer to these lingering design and code problems as technical debt.

XP teams “pay down” technical debt in each weekly cycle

Are you surprised to learn that programmers often don’t get code right the first time they write it? It’s true! Developers don’t just “spit out” code and then move on to the next problem. Just like great artists, craftspeople, and artisans create sketches and preliminary designs before refining them into finished products, great programmers create initial versions of their code and then refactor that code, often many times.

That’s why really effective XP teams make sure that they add time to every weekly cycle to “pay down” their technical debt and fix those lingering problems before they start to pile up. And the most effective way to do that is to refactor your code. XP teams have a name for this great habit: refactor mercilessly.

Incremental design starts (and ends) with simple code

The practices we’ve talked about are really good for helping everyone on the team to develop habits to help them create small, decoupled units that work independently of each other. As they start to build up those habits, they can start practicing incremental design. This XP practice is exactly what it sounds like: the team creates the design for their project in small increments, building only the next bit of design needed for the current quarterly cycle, and concentrating mainly on what’s needed in this weekly cycle. They build small, decoupled units, refactoring as they go to remove dependencies, separate units that get too big, and simplify the design of each unit.

When an XP team uses incremental design, the first set of units that they build typically evolve into a small, stable core. As the system grows, they add or modify a small number of units in each weekly cycle. They’ll use test-driven development to make sure that each unit has minimal dependencies on the other units, which in turn makes the whole system easier to work with. In each iteration, the team adds only the design needed to build the next set of stories. When units interact in a simple way, it lets the whole system grow organically, bit by bit.

All designs change. Incremental designs are built to change.

Generations of software engineers were taught in school that the design of a system needs to be complete before the team can start coding. This idea is built into the waterfall process: the project needs to complete the design phase before moving on to the development phase. Incremental design works when teams make design decisions at the last responsible moment, exactly the same way that teams using iterative development make planning decisions.

Incremental design really does work in the real world. One of the most successful examples is the Unix toolset (the set of Unix shell commands—cat, ls, tar, gzip, etc.). These tools weren’t all developed at once. Instead, the Unix tools were based on a philosophy of simplicity: each tool does one specific, straightforward job, producing output that every other tool can use as input. This allowed thousands of different people to contribute to the entire toolset over many years. It grew incrementally, with individual tools being added one by one as the need for them arose.

XP teams take a very similar approach, starting with the same idea of embracing the value of simplicity. And just like with the Unix toolset, it’s an effective way to work.

That’s right. And software that’s designed to be modified makes it easy for the team to embrace change.

The whole point of XP is to improve the way that the team writes code, and just as importantly, to improve and energize the working environment. When everyone on the team really “gets” incremental design, the whole system becomes much easier to work with. That makes the work much more satisfying: the most tedious parts of the software development job are reduced and often eliminated.

All of this leads to a very positive feedback loop: the weekly cycle and slack give the team enough time to do the work and constantly refactor the code, which lets them incrementally create a simple design, which helps everyone stay energized and approach problems with a fresh and clear mind, which lets them make progress quickly, which gives them success in the company. That success lets the team work with the business more effectively, and that gives them the ability to keep planning the project using weekly cycles and slack.

That feedback loop is what drives an XP team’s ability to embrace change.

there are no Dumb Questions

Q: Does XP really make the job more satisfying?

A: Yes, really! Keeping the workplace energized means everyone watches for signs of exhaustion, boredom, and agitation. Those feelings are often indicators that team members are dealing with avoidable code problems, or are being forced to work late because of irresponsible planning.

Q: How do you know that Ryan’s studio schedule change was a hack?

A: There were a few glaring warning signs. The first one was that he copied an entire class, left a bunch of it intact, and just deleted the bits he didn’t need. That led to a lot of duplicate code. And then he added “special case” code to other parts of the system. That’s code that looks for a particular state—in this case, scheduling a whole studio instead of a single yoga or martial arts class—and performs specific behavior just for that case. Developers try to avoid those things because they make the system more difficult to maintain. There’s almost always a more elegant way to solve a problem like that.

Q: OK, now I’m confused about duplicate code. Ryan shouldn’t have made a complex build script just to avoid a few duplicated lines, but he also shouldn’t have made that hack with a class that had a lot of duplicate code. So is duplicate code good, or is it bad?

A: There’s very little that’s more aesthetically unpleasant to a programmer than a block of code that’s duplicated in two (or worse, more!) places. It’s almost always better to reuse the duplicate code by moving it into its own unit (like a class, function, module, etc.). But sometimes the situation isn’t so straightforward. A few lines of duplicate code aren’t necessarily particularly easy to reuse. Occasionally it takes a lot of work to extract them into their own unit. When we’re coding, we sometimes go to such great lengths to avoid a small block of duplicate code that we end up adding complexity instead of removing it. That’s the trap Ryan fell into with his build script.

Q: Hold on... “aesthetically unpleasant?” Since when do aesthetics have anything to do with code?

A: Code aesthetics matter a lot! If you’re not a developer, it might seem weird to talk about code being “aesthetically pleasing” or not. But one sign of a great developer is a sense of aesthetics and even beauty in the code that he or she writes. Duplicate code is particularly aesthetically offensive to developers, because it’s almost always a sign that something can be simplified.

Q: So how do I know if my code is too complex, or not simple enough? Is there a rule that I can apply?

A: No, there’s no rule about how much complexity is too much. That’s why simplicity is a value, not a rule. The more experience you have as a programmer on a team that values simplicity, the better you get at making your code simple. That said, there are definitely warning signs that your code might be too complex. For example, you know a block of code is probably too complex if you’re afraid to touch it, or if there’s a scary comment that says Don’t edit this! at the top. Build scripts and unit tests are too complex if you find yourself avoiding a change because the change itself is easy, but modifying the build script or unit test will be really difficult or annoying.

Q: I still don’t get the point about test-driven development and simplicity. Does writing unit tests first really help keep code simple?

A: Yes. A lot of complexity happens when you build units of code that have many dependencies on other parts of the system. If you can avoid adding those dependencies, it makes your whole system a lot easier to maintain, and helps you avoid that “shotgun surgery” feeling when you’re working on the code. Unit tests are really good at helping you avoid unnecessary dependencies, because a test for a single unit has to provide all of the input that the unit needs. If that unit has a lot of dependencies, it makes the test extremely annoying to write—and it becomes very obvious exactly which dependencies you really need. Often, that will also show you another part of the system that could be refactored. And it gives you incentive to do that refactoring immediately, because it will make the job at hand less annoying, tedious, or frustrating.

Q: And reducing annoyance and tedium... that’s good for the team, right?

A: Yes! One of the best ways to make your team more productive is to make the work everyone is doing less annoying, tedious, boring, or frustrating. That’s a really effective way to build an energized workplace. It’s why people on XP teams really can’t imagine working any other way.

Exhaustion, boredom, and agitation can be early indicators of code problems that can be avoided.

Answers in “ JUDGMENT CALL”

Exam Questions

1. Which of the following is NOT true about how XP teams plan their work?

   1. XP teams often self-organize by having team members pull their next tasks from a pile of index cards

   2. XP teams use week-long iterations

   3. XP teams focus on code, so they do very little planning

   4. XP is iterative and incremental

2. How do XP’s values and practices help teams embrace change?

   1. By helping them build code that’s easier to modify

   2. By placing strict limits on how users request changes

   3. By enforcing a change control process

   4. By limiting the amount of contact between the business users and the team

3. Amy is a developer on a team that builds mobile apps for commuters. They’ve adopted XP, but instead of using weekly cycles, quarterly cycles, and slack, they hold a Daily Scrum, do sprint planning, and hold retrospectives. Which of the following BEST describes Amy’s team?

   1. They do not do adequate planning

   2. They are in the process of adopting XP

   3. They use a hybrid of Scrum and XP

   4. They are transitioning from XP to Scrum

4. Which of the following are NOT common to both XP and Scrum?

   1. Roles

   2. Iterations

   3. Respect

   4. Courage

5. Which of the following is a valid way for XP teams to do estimation?

   1. Planning poker

   2. The planning game

   3. Traditional project estimation techniques

   4. All of the above

6. Evan is a project manager on an XP team. He noticed that over the last few weekly cycles, everyone had their headphones on and listened to music all day while coding. Evan is concerned that the lack of osmotic communication is making the workspace less informative. He called a team meeting to explain XP’s informative workspace practice, and suggested that they adopt a rule against wearing headphones at work.

   Which BEST describes this situation?

   1. The team is not performing the informative workspace practice

   2. Evan has a responsibility to help the team adopt XP, and is demonstrating servant-leadership

   3. Evan needs to improve his understanding of the XP values

   4. The team is using a hybrid of Scrum and XP

7. Which of the following is true about test-driven development?

   1. Unit tests are written immediately after writing the code that they test

   2. Writing unit tests first can have a profound impact on the design of the code

   3. Test-driven development is used exclusively by XP teams

   4. Writing unit tests causes the whole project to take longer because the team spends more time writing code, but it’s worth it for the extra quality

8. What is involved in continuous integration?

   1. Setting up a build server that constantly integrates new code into a working folder and alerts the team on build or test failures

   2. Using iteration to continuously produce working software

   3. Each person on the team keeps their working folders up to date with the latest code from the version control system

   4. Continuously reducing technical debt by improving the structure of the code without modifying its behavior, and integrating those changes back in

9. Which of the following is NOT an example of an information radiator?

   1. The team sitting together so they can absorb information from conversations that happen around them

   2. Posting a burndown chart in a place where everyone can see it

   3. Keeping the team’s task board on a wall in a common area

   4. Maintaining a list of stories the team has finished so far in the weekly cycle on a whiteboard that everyone can see

10. The following practices all establish feedback loops for XP teams except:

    1. Test-driven development

    2. Continuous integration

    3. 10-minute build

    4. Stories

11. Why do teams use wireframes that are low fidelity?

    1. Users give more feedback when a user interface mock-up looks less polished

    2. Agile teams rarely build software that contains detailed audio

    3. The team only builds and reviews one set of wireframes per weekly cycle

    4. They’re only used for less complex user interfaces, and XP teams value simplicity

12. Which of the following promotes sustainable development?

    1. Thoroughly planning the next six months of work so that there are no surprises for the team

    2. Making sure everyone gets everything right the first time they build it, so no rework is required

    3. Making sure everyone leaves on time and nobody feels pressured to work weekends, so the team doesn’t burn out

    4. Setting tight deadlines, so everyone is motivated to meet them

13. Which of the following is NOT a benefit of pair programming?

    1. Everyone on the team gets experience working with many different parts of the system

    2. There are two sets of eyes on every change

    3. Pairs help each other stay focused

    4. People take turns working, so fatigue is reduced

14. Joanne is a developer on a team that constantly refactors, does continuous integration, writes unit tests first, and does many other XP practice. What BEST explains this team’s culture?

    1. They have a strict manager who enforces the rules of XP

    2. They have good habits

    3. They are highly disciplined

    4. They are worried about getting fired if they don’t work this way

15. What happens when a build takes longer than 10 minutes to run?

    1. It causes errors in the packaging process

    2. Team members run the build infrequently

    3. Merge conflicts occur that are difficult to resolve

    4. The unit tests fail

16. Joy is a developer working on a team building a mobile operating system. She tried to commit code for a feature that she’s been working on, but the version control system won’t let her complete the commit until she resolves many conflicts. Which practice will BEST prevent this problem in the future?

    1. Sustainable pace

    2. Continuous integration

    3. 10-minute build

    4. Test-driven development

17. Kiah is a developer on an XP project. Her team is doing quarterly planning. One of the features is extremely important, and failing to deliver it will have serious consequences for the project. Kiah is the expert on this part of the project, and she’ll be the one doing the programming work. She feels that the design is relatively straightforward, and she’s pretty sure that she knows exactly how to build it.

    What is the BEST action for Kiah and her team to take?

    1. Add a story for an architectural spike to an early weekly cycle

    2. Build a low-fidelity wireframe to get early feedback

    3. Add a story for a risk-based spike to an early weekly cycle

    4. Do extra usability testing

Exam Answers

1. Answer: C

   XP teams might not focus on project management to the extent that Scrum teams do, but XP is still an iterative and incremental methodology that values self-organizing teams. Those reasons are part of why it’s an agile methodology.

2. Answer: A

   It’s a lot easier for teams to embrace change when they know those changes won’t be a headache for them to make. XP helps with this by including practices and values that help teams build code that’s easier to modify.

   Note

   This also helps keep rework from causing quite so many bugs.

3. Answer: A

   Teams that use a Scrum/XP hybrid have replaced the planning-related XP practices with a complete implementation of Scrum. Amy’s team hasn’t done that. They adopted some of the Scrum practices, but since they dropped the quarterly cycle without adding any sort of product backlog, they’ve pretty much stopped doing any sort of long-term planning.

   Note

   They also don’t have a Scrum Master or Product Owner. What other Scrum practices have they ignored? What do you think all of this indicates about the mindset among Amy’s team members?

4. Answer: A

   XP and Scrum both value respect and courage, and both use timboxed iterations for planning. But XP has no fixed roles, while Scrum teams must always have team members who fill the Product Owner and Scrum Master roles.

5. Answer: D

   XP teams use many different technique for estimating, and there is no specific rule that says the team must use any specific technique. So all of the techniques listed are valid. So is having the team simply meet and talk about how long they think the work will take.

   Note

   The planning game is a practice that was part of an early version of XP. It guided the team through creating an iteration plan by helping them decompose stories into tasks and assign them to team members. It’s still in use by a few teams, but planning poker is a lot more popular.

6. Answer: C

   Evan has decided that the team is doing something wrong because they are not following his personal interpretation of the XP practices. When he called the team meeting and proposed a rule against wearing headphones, he was ignoring the fact that this is how the team prefers to work. This is very disrespectful, and shows that he doesn’t trust them to find an effective way to work. Respect is a core XP value, and when people ignore it, that hurts the whole team by stirring up resentment and other negative feelings.

   Note

   It may seem weird to talk about feelings at work, but they’re actually really important for getting a team to run smoothly. It’s really difficult to innovate and do the difficult intellectual and creative work when you’re distracted by negative feelings like resentment.

7. Answer: B

   When you write unit tests first, it can have a profound impact on the design of the code. The reason is that when you’re writing the tests, awkward constructions and unnecessary coupling between units can become much more apparent. Test-driven development is not exclusive to XP teams—many teams do it, even on waterfall projects. And even though it requires developers to write more code overall, most people who do test-driven development find that it actually saves time overall because it makes fixing bugs and making changes much, much faster.

   Note

   The total time teams spend writing the extra code for the unit tests is more than made up for by the time saved making changes. This isn’t a long-term effect—it’s easily noticeable within days or even hours.

8. Answer: C

   Continuous integration is a straightforward practice that can have an outsized effect on the project. The team continuously integrates the latest code from the version control system into their working folders every few hours. This prevents them from having to deal with time-consuming and annoying merge conflicts that span many files at the same time.

9. Answer: A

   An information radiator is any sort of visual tool or display that conveys useful information about the project and is highly visible so that team members can’t help but absorb the information on it as they walk by. The first answer describes osmotic communication.

   Note

   Osmotic information and information radiators are both tools that can help with the informative workspace practice.

10. Answer: D

    Stories are very useful, but they don’t really establish a feedback loop the way some practices like test-driven development, continuous integration, or 10-minute builds do. The reason is that most of the time the story doesn’t change very much once it’s written, so there’s no opportunity for feeding information back into it repeatedly. The other three practices establish feedback loops that occur many times over the course of a weekly cycle.

11. Answer: A

    Wireframes are often low fidelity, which means they look like rough sketches or hand-drawn mock-ups. Users are often a lot more willing to give feedback about a sketch that looks like it was easy to draw than they are for a highly polished, accurate mock-up, because it feels intimidating to ask for changes to a design that looks like it required a lot of work. A low-fidelity wireframe can still capture all of the detail of a rich user interface, and is no more complex or simple than a mock-up that’s highly polished.

    Note

    Low-fidelity wireframes are usually a lot less work than ones that are a lot more polished, which lets teams review several different versions with the users. They can help the team try out several iterations of the same UI in a single weekly cycle.

12. Answer: C

    Sustainable development happens when the team works at a pace that they can comfortably manage, which almost always means working normal 40-hour weeks.

    Note

    A lot of teams have one or two people who make a point of staying late to show how “committed” they are (or to impress the boss). This often puts a lot of pressure on everyone else to stay late, too, which can easily create an unsustainable pace and burn the team out.

13. Answer: D

    Pair programming is a very effective and efficient practice because two people working at the same computer keep each other focused, constantly collaborate, catch many problems, and get more done than if they were working alone. But both people are always working together at the same time—they don’t take turns working.

14. Answer: B

    XP teams use great practices every day because they have great habits. They don’t do it out of a sense of discipline, and they certainly don’t do it out of fear. Raw discipline and fear can cause temporary, short-term changes to the way teams work, but eventually teams revert back to their habits.

15. Answer: B

When an automated build takes a really long time to run, the team runs it a lot less frequently. That means the team gets less frequent feedback about the state of the build.

16. Answer: B

Continuous integration is a simple practice in which the team members keep their working folders up to date with the latest changes in the version control system. That prevents many merge conflicts, which can needlessly waste the team’s time and cause a lot of frustration.

17. Answer: C

A risk-based spike is a spike solution that the team undertakes specifically to reduce project risk. In this case, Kiah already knows the technical approach that she will take, so there’s no need for an architectural spike. But since the risk for this particular feature is very high, it makes sense to add a risk-based spike to a weekly cycle early in the project. That way the risk will be eliminated early on.