James Shore

Agile Friday: "Done Done" Now Online

Fri, 12 Mar 2010 00:00:00 PST

12 Mar 2010

James Shore/Blog

"Done Done" won the poll for this week's Art of Agile Development release. I've posted the full text online.

I'm working a bit ahead (yay, vacation!), so I need to get your thoughts on two more weeks' worth of excerpts. I'd like your suggestions for the "Developing" chapter excerpt, which will be posted on March 26th:

We also need to choose April 2nd's excerpt, which loops back around to the "Thinking" chapter:

This week's winner, "Done Done", surprised me. I thought Ten-Minute Build or Continuous Integration would win the day, since they're so central. But they tied for fourth place. In retrospect, getting to "done done" is something I see a lot of teams struggle with, and while I've seen people write about the importance of getting to "done done," I haven't seen a lot of people writing about how to do it. Perhaps that's why there was so much interest.

The final results:

Results are also in for next week's excerpt. Slack will be posted on March 19th.

Comments

The Art of Agile Development: "Done Done"

Fri, 12 Mar 2010 00:00:00 PST

12 Mar 2010

James Shore/Agile-Book

in 99 words

A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.

To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.

Commentary

The Cornerstone of Agile Planning

Full Text

"Done Done"

Audience: Whole Team

We're done when we're production-ready.

"Hey, Liz!" Rebecca sticks her head into Liz's office. "Did you finish that new feature yet?"

Liz nods. "Hold on a sec," she says, without pausing in her typing. A flurry of keystrokes crescendos and then ends with a flourish. "Done!" She swivels around to look at Rebecca. "It only took me half a day, too."

"Wow, that's impressive," says Rebecca. "We figured it would take at least a day, probably two. Can I look at it now?"

"Well, not quite," says Liz. "I haven't integrated the new code yet."

"Okay," Rebecca says. "But once you do that, I can look at it, right? I'm eager to show it to our new clients. They picked us precisely because of this feature. I'm going to install the new build on their test bed so they can play with it."

Liz frowns. "Well, I wouldn't show it to anybody. I haven't tested it yet. And you can't install it anywhere—I haven't updated the installer or the database schema generator."

"I don't understand," Rebecca says irritably. "I thought you said you were done!"

"I am," insists Liz. "I finished coding just as you walked in. Here, I'll show you."

"No, no, I don't need to see the code," Rebecca says. "I need to be able to show this to our customers. I need it to be finished. Really finished."

"Well, why didn't you say so?" says Liz. "This feature is done—all coded up. It's just not done done. Give me a few more days."

Production-Ready Software

You should able to deploy the software at the end of any iteration.

Wouldn't it be nice if, once you finished a story, you never had to come back to it? That's the idea behind "done done." A completed story isn't a lump of unintegrated, untested code. It's ready to deploy.

Partially-finished stories result in hidden costs to your project. When it's time to release, you have to complete an unpredictable amount of work. This destabilizes your release planning efforts and prevents you from meeting your commitments.

To avoid this problem, make sure all of your planned stories are "done done" at the end of each iteration. You should be able to deploy the software at the end of any iteration, although normally you'll wait until more features have been developed.

What does it take for software to be "done done"? That depends on your organization. I often explain that a story is only complete when the customers can use it as they intended. Create a checklist that shows the story completion criteria. I write mine on the iteration planning board:

Tested (all unit, integration, and customer tests finished)
Coded (all code written)
Designed (code refactored to the team's satisfaction)
Integrated (the story works from end to end—typically, UI to database—and fits into the rest of the software)
Builds (the build script includes any new modules)
Installs (the build script includes the story in the automated installer)
Migrates (the build script updates database schema if necessary; the installer migrates data when appropriate)
Reviewed (customers have reviewed the story and confirmed that it meets their expectations)
Fixed (all known bugs have been fixed or scheduled as their own stories)
Accepted (customers agree that the story is finished)

Ally: The XP Team

Some teams add "Documented" to this list, meaning that the story has documentation and help text. This is most appropriate when you have a technical writer as part of your team.

Other teams include "Performance" and "Scalability" in their "done done" list, but these can lead to premature optimization. I prefer to schedule performance, scalability, and similar issues with dedicated stories (see Performance Optimization in Chapter 9).

How to Be "Done Done"

Make a little progress on every aspect of your work every day.

XP works best when you make a little progress on every aspect of your work every day, rather than reserving the last few days of your iteration for getting stories "done done." This is an easier way to work, once you get used to it, and it reduces the risk of finding unfinished work at the end of the iteration.

Allies: Test-Driven Development; Continuous Integration; Ten-Minute Build

Use test-driven development to combine testing, coding, and designing. When working on an engineering task, make sure it integrates with the existing code. Use continuous integration and keep the ten-minute build up to date. Create an engineering task (see Iteration Planning in Chapter 9) for updating the installer and have one pair work on it in parallel with the other tasks for the story.

Just as importantly, include your on-site customers in your work. As you work on a UI task, show a customer what the screen will look like, even if it doesn't work yet (see Incremental Requirements in Chapter 9). Customers often want to tweak a UI when they see it for the first time. This can lead to a surprising amount of last-minute work if you delay any demos to the end of the iteration.

Ally: Exploratory Testing

Similarly, as you integrate various pieces, run the software to make sure they all work together. While this shouldn't take the place of testing, it's a good check to help prevent you from missing anything. Enlist the help of the testers on occasion and ask them to show you exploratory testing techniques. (Again, this review doesn't replace real exploratory testing.)

Ally: No Bugs

Throughout this process, you may find mistakes, errors, or outright bugs. When you do, fix them right away—then improve your work habits to prevent that kind of error from occurring again.

When you believe the story is "done done," show it to your customers for final acceptance review. Because you reviewed your progress with customers throughout the iteration, this should only take a few minutes.

Making Time

This may seem like an impossibly large amount of work to do in just one week. It's easier to do if you work on it throughout the iteration rather than saving it up for the last day or two. The real secret, though, is to make your stories small enough that you can completely finish them all in a single week.

Many teams new to XP create stories that are too large to get "done done." They finish all of the coding, but they don't have enough time to completely finish the story—perhaps the UI is a little off, or a bug snuck through the cracks.

Remember, you are in control of your schedule. You decide how many stories to sign up for and how big they are. Make any story smaller by splitting it into multiple parts (see Stories in Chapter 8) and only working on one of the pieces this iteration.

Creating large stories is a natural mistake, but some teams compound the problem by thinking, "well, we really did finish the story, except for that one little bug." They give themselves credit for the story, which inflates their velocity and perpetuates the problem.

If a story isn't "done done", don't count it towards your velocity.

If you have trouble getting your stories "done done," don't count those stories towards your velocity (see Estimating in Chapter 8). Even if the story only has a few minor UI bugs, count it as a zero when calculating your velocity. This will lower your velocity, which will help you choose a more manageable amount of work in your next iteration.

You may find that this lowers your velocity so much that you can only schedule one or two stories in an iteration. That means that your stories were too large to begin with. Split the stories you have and work on making future stories smaller.

Questions

How does testers' work fit into "done done"?

Ally: Exploratory Testing

In addition to helping customers and programmers, testers are responsible for nonfunctional testing and exploratory testing. Typically, they do these only after stories are "done done". They may perform some non-functional tests, however, in the context of a specific performance story.

Regardless, the testers are part of the team, and everyone on the team is responsible for helping the team meet its commitment to deliver "done done" stories at the end of the iteration. Practically speaking, this usually means that testers help customers with customer testing, and they may help programmers and customers review the work in progress.

What if we release a story that we think is "done done," but then we find a bug or stakeholders tell us they want changes?

Ally: Slack

If you can absorb the change with your slack, go ahead and make the change. Turn larger changes into new stories.

Ally: Release Planning

This sort of feedback is normal—expect it. The product manager should decide whether the changes are appropriate, and if they are, he should modify the release plan. If you are constantly surprised by stakeholder changes, consider whether your on-site customers truly reflect your stakeholder community.

Results

When your stories are "done done," you avoid unexpected batches of work and spread wrap-up and polish work throughout the iteration. Customers and testers have a steady workload through the entire iteration. The final customer acceptance demonstration takes only a few minutes. At the end of each iteration, your software is ready to demonstrate to stakeholders with the scheduled stories working to their satisfaction.

Contraindications

Allies: Iteration Planning; Stories; The XP Team; Sit Together; Incremental Design And Architecture; Test-Driven Development

This practice may seem advanced. It's not, but it does require self-discipline. To be "done done" every week, you must also work in iterations and use small, customer-centric stories.

In addition, you need a whole team—one that includes customers and testers (and perhaps a technical writer as well) in addition to programmers. The whole team must sit together. If they don't, the programmers won't be able to get the feedback they need in order to finish the stories in time.

Finally, you need incremental design and architecture and test-driven development in order to test, code, and design each story in such a short timeframe.

Alternatives

Allies: Release Planning; Trust; Energized Work

This practice is the cornerstone of XP planning. If you aren't "done done" at every iteration, your velocity will be unreliable. You won't be able to ship at any time. This will disrupt your release planning and prevent you from meeting your commitments, which will in turn damage stakeholder trust. It will probably lead to increased stress and pressure on the team, hurt team morale, and damage the team's capacity for energized work.

The alternative to being "done done" is to fill the end of your schedule with make-up work. You will end up with an indeterminate amount of work to fix bugs, polish the UI, create an installer, and so forth. Although many teams operate this way, it will damage your credibility and your ability to deliver. I don't recommend it.

Comments

The Art of Agile Development: Chapter 7: Releasing

Fri, 12 Mar 2010 00:00:00 PST

12 Mar 2010

James Shore/Agile-Book

Full Text

Releasing

What is the value of code? Agile developers value "working software over comprehensive documentation."¹ Does that mean a requirements document has no value? Does it mean unfinished code has no value?

¹The Agile Manifesto, http://www.agilemanifesto.org/

Like a rock at the top of a hill, code has potential—potential energy for the rock and potential value for the code. It takes a push to realize that potential. The rock has to be pushed onto a slope in order to gain kinetic energy; the software has to be pushed into production in order to gain value.

It's easy to tell how much you need to push a rock. Big rock? Big push. Little rock? Little push. Software isn't so simple—it often looks ready to ship long before it's actually done. It's my experience that teams underestimate how hard it will be to push their software into production.

To make things worse, software's potential value changes. If nothing ever pushes that rock, it will sit on top of its hill forever; its potential energy won't change. Software, alas, sits on a hill that undulates. You can usually tell when your hill is becoming a valley, but if you need weeks or months to get your software rolling, it might be sitting in a ditch by the time you're ready to push.

In order to meet commitments and take advantage of opportunities, you must be able to push your software into production within minutes. This chapter contains seven practices that give you leverage to turn your big release push into a ten-minute tap:

"Done Done" ensures that completed work is ready to release.
No Bugs allows you to release your software without a separate testing phase.
Version Control allows team members to work together without stepping on each others' toes.
A Ten-Minute Build builds a tested release package in under ten minutes.
Continuous Integration prevents a long, risky integration phase.
Collective Code Ownership allows the team to solve problems no matter where they may lie.
Post-hoc Documentation decreases the cost of documentation and increases its accuracy.

"Releasing" Mini-Etude

The purpose of this étude is to examine pushing your software into production. If you're new to agile development, you may use it to create a map of all the steps involved in releasing software, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 13 and use this étude to help you modify your process to remove communication bottlenecks.

Conduct this étude for a timeboxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.

You will need red and green index cards, an empty table or magnetic whiteboard for your value stream map,² and writing implements for everyone.

Step 1. Start by forming heterogeneous pairs—have a programmer work with a customer, a customer work with a tester, and so forth, rather than pairing by job description. Work with a new partner every day.

Step 2. Timebox this step to 10 minutes. Within pairs, consider all of the activities that have to happen between the time someone has an idea and when you can release idea to real users or customers. Count an iteration as one activity, and group together any activities that take less than a day. Consider time spent waiting as an activity, too. If you can't think of anything new, pick an existing card and skip to Step 3.

Choose at least one task, and write it on a red card. Reflect on all of the times you have performed this activity. If you have released software, use your experience; do not speculate. How long did it take? Think in terms of calendar time, not effort. Write three times down on the card: the shortest time you can remember, the longest time you can remember, and the typical time required. (See Figure.)

Figure. A sample card.

Step 3. Timebox this step to 10 minutes. Discuss things that your team can do to reduce the time required for this activity or eliminate it entirely. Choose just one idea and write it on a green card.

Step 4. Timebox this step to 10 minutes. As a team, discuss your cards and place them on the table or whiteboard in a value stream map. Place activities (red cards) that must happen first before activities that can happen afterward. (See Figure.) If you're using a whiteboard, draw arrows between the cards to make the flow of work more clear. Place green cards underneath red cards.

Consider these discussion questions:

At which step does work pile up?

Which results surprise you?

Who is the constraint in the overall system? How can you improve the performance of the overall system?

Are there green cards with ideas you can adopt now?

Figure. A sample value stream map.

²The value stream map was inspired by [Poppendieck & Poppendieck].

Comments

The Art of Agile Development: Sit Together

Fri, 05 Mar 2010 00:00:00 PST

05 Mar 2010

James Shore/Agile-Book

in 99 words

Sitting together fuels team communication. This has impressive results, cutting time-to-market by two thirds in one field study^*. It enables simultaneous phases, eliminates waste, and allows team members to contribute insights to others' conversations.

To sit together, create an open workspace. This takes longer than you expect. Organize your workspace around pairing stations, locating people according to conversations they should overhear. Provide plenty of whiteboard space. Make sure there's room for personal effects and a place for private conversations.

Open workspaces are hard for some to accept. Get team members' permission before switching, or they may rebel.

^*Teasley, Stephanie, Lisa Covi, M. S. Krishnan, Judith Olson. 2002. "Rapid Software Development Through Team Collocation." IEEE Trans. Softw. Eng. 28(7):671-83. http://dx.doi.org/10.1109/TSE.2002.1019481

as haiku

mulch builds the soil;
herbs bring bees, bulbs repel grass:
come autumn, apples

Behind the Scenes

Time-Lapse Author

Full Text

Sit Together

Audience: Whole Team; Coaches

We communicate rapidly and accurately.

If you've tried to conduct a team meeting via speakerphone, you know how much of a difference face-to-face conversations make. Compared to an in-person discussion, teleconferences are slow and stuttered, with uncomfortable gaps in the conversation and people talking over each other.

What you may not have realized is how much this affects your work.

Imagine you're a programmer on a nonagile team and you need to clarify something in your requirements document in order to finish an algorithm. You fire off an email to your domain expert, Mary, then take a break to stretch your legs and get some coffee.

When you get back, Mary still hasn't responded, so you check out a few technical blogs that you've been meaning to read. Half an hour later, your inbox chimes. Mary has responded.

Uh-oh... it looks like Mary misunderstood your message and answered the wrong question. You send another query, but you really can't afford to wait any longer. You take your best guess at the answer—after all, you've been working at this company for a long time, and you know most of the answers—and get back to work.

A day later, after exchanging a few more emails, you've hashed out the correct answer with Mary. It wasn't exactly what you thought, but you were pretty close. You go back and fix your code. While in there, you realize that there's an edge case nobody's handled yet.

You could bug Mary for the answer, but this is a very obscure case. It's probably never going to happen in the field. Besides, Mary's very busy and you promised that you'd have this feature done yesterday. (In fact, you were done yesterday, except for all these nitpicky little details.) You put in the most likely answer and move on.

Accommodating Poor Communication

As the distance between people grows, the effectiveness of their communication decreases. Misunderstandings occur and delays creep in. People start guessing to avoid the hassle of waiting for answers. Mistakes appear.

To combat this problem, most development methods attempt to reduce the need for direct communication. It's a sensible response. If questions lead to delays and errors, reduce the need to ask questions!

The primary tools teams use to reduce reliance on direct communication are development phases and work-in-progress documents. For example, in the requirements phase, business analysts talk to customers and then produce a requirements document. Later, if a programmer has a question, he doesn't need to talk to an expert. He can simply look the answer up in the document.

It's a sensible idea, but it has flaws. The authors of the documents need to anticipate which questions will come up and write clearly enough to avoid misinterpretations. This is hard to do well. In practice, it's impossible to anticipate all possible questions. Also, adding up-front documentation phases stretches out the development process.

A Better Way

In XP, the whole team—including experts in business, design, programming and testing—sits together in an open workspace. When you have a question, you need only turn your head and ask. You get an instant response, and if something isn't clear, you can discuss it at the whiteboard.

Consider the previous story from this new perspective. You're a programmer and you need some information from your domain expert, Mary, in order to code an algorithm.

This time, rather than sending an email, you turn your head. "Mary, can you clarify something for me?" you ask.

Mary says, "Sure. What do you need?"

You explain the problem and Mary gives her answer. "No, no," you reply. "That's a different problem. Here, let me show you on the whiteboard."

A few minutes later, you've hashed out the issue and you're back to coding again. Whoops! There's an edge case you hadn't considered. "Wait a second, Mary," you say. "There's something we didn't consider. What about...."

After some more discussion, the answer is clear. You're a little surprised: Mary's answer was completely different than you expected. It's good that you talked it over. Now, back to work! The code is due today, and it took 20 whole minutes to figure out this nitpicky little issue.

Exploiting Great Communication

Sitting together eliminates the waste caused by waiting for an answer, which dramatically improves productivity. In a field study of six colocated teams, [Teasley et al.] found that sitting together doubled productivity and cut time to market to almost one third of the company baseline.

Those results are worth repeating: the teams delivered software in one-third their normal time. After the pilot study, 11 more teams achieved the same result. This success led the company to invest heavily in open workspaces, by building a new facility in the US that supports 112 such teams and making plans for similar sites in Europe.

How can sitting together yield such impressive results? Communication.

Although programming is the emblematic activity of software development, communication is the real key to software success. As [Teasley et al.] report, "Past studies have indicated that less than 30 percent of a programmer's time is spent on traditional programming tasks and less than 20 percent of the time is spent on coding. The rest of the time is spent on meetings, problem resolution with the team, resolving issues with customers, product testing, etc."

My experience is that programmers on XP teams spend a far greater percentage of their time programming. I attribute that to the increased communication effectiveness of sitting together. Rather than sitting in hour-long meetings, conversations last only as long as needed and involve only the people necessary.

Teams that sit together not only get rapid answers to their questions, they experience what [Cockburn] calls osmotic communication. Have you ever been talking with someone in a crowded room and then heard your name out of the blue? Even though you were focusing on your conversation, your brain was paying attention to all of the other conversations in the room. When it heard your name, it replayed the sounds into your conscious mind. You not only hear your name, you hear a bit of the conversation around it, too, in a phenomenon known as the cocktail party effect.¹

¹The best layman's description of the cocktail party effect I've seen is on Wikipedia: http://en.wikipedia.org/wiki/Cocktail_party_effect, accessed 17 July 2006.

Imagine a team that sits together. Team members are concentrating on their work and talking quietly with their partners. Then somebody mentions something about managing database connections, and another programmer perks up. "Oh, Tom and I refactored the database connection pool last week. You don't need to manage the connections manually anymore." When team members are comfortable speaking up like this, it happens often (at least once per day) and saves time and money every time.

When I see an adversarial relationship between separate groups in a team, I suggest that they sit together.

There's another hidden benefit to sitting together: it helps teams jell and breaks down us-versus-them attitudes between groups. Distance seems to encourage adversarial relationships and blaming "those people." Whenever I see this (for example, between programmers and testers), I suggest that they sit together. This helps the groups interact socially and gain respect for each other professionally.

Secrets of Sitting Together

To get the most out of sitting together, be sure you have a complete team (see The XP Team in Chapter 3). It's important that people be physically present to answer questions. If someone must be absent often—product managers tend to fall into this category—make sure that someone else on the team can answer the same questions. A domain expert is often a good backup for a traveling product manager.

Similarly, sit close enough to each other that you can have a quick discussion without getting up from your desk or shouting. This will also help encourage osmotic communication, which relies on team members overhearing conversations.

Ask for help when you're stuck.

Available instant help doesn't do any good if you don't ask for it. Many organizations discourage interruptions, I encourage them on my XP teams. There's no sense in banging your head against a wall when the person with the answer is right across the room. To support this attitude, many teams have a rule: "We must always help when asked."

Interruptions disrupt flow and ruin productivity, so this rule may sound foolish. It takes a programmer 15 minutes or more to get back into flow after an interruption [DeMarco & Lister 1999].

Ally: Pair Programming

Fortunately, with pair programming, flow works differently. The delay doesn't seem to occur. One programmer answers the question and the other keeps thinking about the problem at hand. When the interruption is over, a quick "Where were we?" gets work moving again.

Pairing helps in a few other ways, too. Osmotic communication depends on a buzz of conversation in the room. If people aren't pairing, there's less talking. Pairing also makes it easier for programmers to ignore irrelevant background conversations.

Making Room

Sitting together is one of those things that's easy to say and hard to do. It's not that the act itself is difficult—the real problem is finding space.

Start arranging for a shared workspace now.

A team that sits in adjacent cubicles can convert them into an adequate shared workspace, but even with cubicles, it takes time and money to hire people to rearrange the walls.

When I say "time", I mean weeks or even months.

In a smaller company, you might be able to take matters (and screwdrivers) into your own hands. In a larger company, you could run afoul of Facilities if you do that. That may be a worthwhile cost, but talk to your project manager first. She should have some insight on the best way to get a shared workspace.

While you're waiting for construction on your dream workspace to finish, a big conference room is a good alternative. One team I worked with set up shop in the company boardroom for six weeks while they waited for their workspace to be ready.

Designing Your Workspace

Your team will produce a buzz of conversation in its workspace. Because they'll be working together, this buzz won't be too distracting for team members. For people outside the team, however, it can be very distracting. Make sure there's good sound insulation between your team and the rest of the organization.

Within the workspace, group people according to the conversations they most need to overhear. Programmers should all sit next to each other because they collaborate moment-to-moment. Testers should be nearby so programmers can overhear them talk about issues. Domain experts and interaction designers don't need to be quite so close, but should be close enough to answer questions without shouting.

The product manager and project manager are most likely to have conversations that would distract the team. They should sit close enough to be part of the buzz but not so close that their conversations are distracting.

Leave room for individuality in your workspace.

An open workspace doesn't leave much room for privacy, and pair programming stations aren't very personal. This loss of individuality can make people uncomfortable. Be sure that everyone has a space they can call their own. You also need an additional enclosed room with a door, or cubes away from the open workspace, so people can have privacy for personal phone calls and individual meetings.

Ally: Informative Workspace

As you design your workspace, be sure to include plenty of whiteboards and wall space for an informative workspace. Try to have at least 24 linear feet of whiteboard space, magnetic if possible. You can never have too many whiteboards.

Some teams include a projector in their workspace. This is a great idea, as it allows the team to collaborate on a problem without moving to a conference room.

Finally, the center of an XP workspace is typically a set of pairing stations. I like to have the stations facing each other so people can see each other easily. A hollow triangle, square, or oval setup works well. Provide a few more pairing stations than there are programming pairs. This allows testers and customers to pair as well (either with each other or with programmers) and it provides programmers with space to work solo when they need to.

For information on building a good pairing station, see Pair Programming in Chapter 5.

Sample Workspaces

The sample workspace in Figure was designed for a team of 13. They had six programmers, six pairing stations, and a series of cubbies for personal effects. Nonprogrammers worked in cubbies close to the pairing stations so they could be part of the conversation even when they weren't pairing. Programmers' cubbies were at the far end: they typically sat at the pairing stations. For privacy, people adjourned to the far end of the workspace or went to one of the small conference rooms down the hall.

Figure. A sample workspace

In addition to the pairing stations, everybody had a laptop for personal work and email. The pairing stations all used a group login so that any team member could work at them.

Before creating this workspace, the team sat in cubicles in the same part of the office. To create the workspace, they reconfigured the inner walls.

This workspace was good, but not perfect. It didn't have nearly enough wall space for charts and whiteboards and non-programmers didn't have enough desk space. On the plus side, there was plenty of room to accommodate people at the pairing stations, which meant that customers paired with programmers frequently, and there were also extra cubbies for bringing people into the team temporarily.

A Small Workspace

The small workspace in Figure was created by an up-and-coming startup when they moved into new offices. They were still pretty small so they couldn't create a fancy workspace. They had a team of seven: six programmers and a product manager.

Figure. A small workspace

This team arranged its pairing stations along a long wall. They had a table on the side for meetings, and charts and whiteboards on dividers surrounding them. The programmers had a pod of half-cubicles to the other side for personal effects, and there were small conference rooms close by for privacy.

This was a great workspace with a serious problem: the product manager wasn't in earshot and didn't participate in team discussions. The team couldn't get ready answers to its questions and struggled with requirements.

Adopting an Open Workspace

Some team members may resist moving to an open workspace. Common concerns include loss of individuality and privacy, implied reduction in status from losing a private office, and managers not recognizing individual contributions. Team members may also mention potential distractions and noise, but I find that this is usually a cover for one of the other concerns.

As with pair programming, people come to enjoy the benefits that sitting together provides, but it can take a few months. In [Teasley et al.]'s study, team members initially preferred cubicles to the open workspace, but by the end of the study, they preferred the open workspace.

Don't force people to sit together against their will.

However, forcing people to sit together in hopes that they'll come to like it is a bad idea. When I've forced team members to do so, they've invariably found a way to leave the team, even if it meant quitting the company. Instead, talk with the team about their concerns and the tradeoffs of moving to an open workspace. Discuss how team members will be evaluated in the new system and what provisions for privacy you can make. You may be able to address some concerns by providing a shared workspace in addition to existing offices and cubicles.

If a large portion of the team is against the open workspace, sitting together is probably not a good choice. If you only have one or two adamant objectors and the rest of the team wants to sit together, you may wish to sit together anyway and allow the objectors to move to a different team.

Questions

How can I concentrate with all that background noise?

A team that's working together in a shared workspace produces a busy hum of activity. This can be distracting at first, but most people get used to it in time.

Pairing makes background conversations fade away.

Ally: Pair Programming

For programmers, pair programming is an excellent way to focus your attention away from the background noise. You won't notice it if you're pairing. Nonprogrammers can work in pairs too.

If you work alone and find the background noise distracting, put on headphones, wear earplugs, or sit further away from the team for a time. You'll miss out on osmotic communication, but at least you'll be able to concentrate.

Sometimes, the team gets a little noisy and rambunctious. It's okay to ask for quiet—the sound in the team room should be a hum, not a full-throated chorus. Some teams have a bell for team members to ring when they want the team to be more quiet.

When one person is interrupted, the whole team stops what they're doing to listen. What can we do to prevent people from being distracted so easily?

Especially in the beginning of the project, it's possible that the whole team really does need to hear these conversations. As time goes on, team members will learn which conversations they can comfortably ignore.

If this is a continuing problem, try stepping a little further away from the pairing stations when a conversation lasts more than a few minutes. Interested team members can join the conversation and the rest of the team can continue working.

What if I need privacy for phone calls?

Some people, particularly customers and project managers, need to take a lot of calls as they work. Either situate them further away from the rest of the team or arrange for an enclosed office with a door. Keep the door open as often as possible to allow information to flow smoothly.

Results

When your team sits together, communication is much more effective. You stop guessing at answers and ask more questions. You overhear other people's conversations and contribute answers they may not expect. Team members spontaneously form cross-functional groups to solve problems. There's a sense of camaraderie and mutual respect.

Contraindications

The hardest part about sitting together is finding room for the open workspace. Cubicles, even adjacent cubicles, won't provide the benefits that an open workspace does. Start working on this problem now as it can take months to resolve.

Don't force the team to sit together against their will. Adamant objectors will find a way to leave the team, and possibly the company.

Be careful about sitting together if programmers don't pair program. Programming alone requires a quiet workspace. Pair programming, on the other hand, enables programmers to ignore the noise.

Alternatives

Multisite teams are difficult and expensive.

Sitting together is one of the most powerful practices in XP. It's important for communication and team dynamics. Sitting apart tends to fray fragile relationships, particularly between different functional groups, and puts your team at a disadvantage. If your team is in a single location, you're better off figuring out how to sit together.

If you have a multisite team, consider turning each site into its own team. For example, if programmers are in one site and customers are in another, the programmers may engage some business analysts to act as proxy customers. In this scenario, the customers and development team should still work together, face-to-face, for several weeks at the beginning of each release.

If you have multiple teams of programmers, consider separating their responsibilities so that each works on entirely different codebases. [Evans] has an excellent discussion of the options for doing so.

You can practice XP with a single, multi-site team, but it requires a lot of travel. [Yap] has a good experience report describing how her team made this work 24 hours a day across three time zones. She focused on maximizing communication by regularly flying team members to a single location for several weeks at a time. They also conducted daily phone calls between locations.

If you can't sit together, talk to your mentor about your options.

If your whole team cannot sit together and you still wish to practice XP, talk to your mentor (see "Find a Mentor" in Chapter 2) about your options and hire experienced XP coaches for each site.

Agile Friday: "Sit Together" Now Online

Fri, 05 Mar 2010 00:00:00 PST

05 Mar 2010

James Shore/Blog

It's Friday! I've posted the full text of Sit Together from The Art of Agile Development on the book's site.

You might have noticed that I'm not posting the practices in order. One of my motivations in putting the book online is that I want to provide a reference that people can easily link to. So I'm starting with the practices that I think people will reference most frequently.

I want your help! Next week, I'm posting a practice from the "Releasing" chapter. Which one do you think will be the most useful? Vote below, then explain your reasons in the comments.

Poll closed. Winner: "Done Done" (to be posted March 12th).

I also need to prepare the following week's release. Which practice from the "Planning" chapter should I post next?

Poll closed. Winner: Slack (to be posted March 19th).

Comments

The Art of Agile Development: Chapter 6: Collaborating

Fri, 05 Mar 2010 00:00:00 PST

05 Mar 2010

James Shore/Agile-Book

Full Text

Collaborating

Sometimes I like to imagine software development as a pulsing web of light, with blips of information flowing along lines from far-flung points. The information races towards the development team, which is a brilliant, complex tangle of lines, then funnels into a glowing core of software too bright to look at.

I'm a little weird that way.

There's truth to the idea, though. Software development is all about information. The more effectively your programmers can access and understand the information they need, the more effective they will be at creating software. The better information customers and managers have, the better they can manage the schedule and the flow of feedback to the programmers.

Communication in the real world is a lot more messy than it is in my image. There are no glowing lines to sterilely transport information from one brain to another. Instead, people have to work together. They have to ask questions, discuss ideas, and even disagree.

This chapter contains eight practices to help your team and its stakeholders collaborate efficiently and effectively:

Trust is essential for the team to thrive.
Sitting together leads to fast, accurate communication.
Real Customer Involvement helps the team understand what to build.
A Ubiquitous Language helps team members understand each other.
Stand-Up Meetings keep team members informed.
Coding Standards provide a template for seamlessly joining the team's work together.
Iteration Demos keep the team's efforts aligned with stakeholder goals.
Reporting helps reassure the organization that the team is working well.

"Collaborating" Mini-Etude

The purpose of this étude is to explore the flow of information in your project. If you're new to agile development, you may use it to help you understand how collaboration occurs in your project, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 12 and use this étude to help you modify your process to remove communication bottlenecks.

Conduct this étude for a timeboxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.

You will need white, red, yellow, and green index cards; an empty table or magnetic whiteboard for your information flow map; and writing implements for everyone.

Step 1. Start by forming pairs. Try for heterogeneous pairs—have a programmer work with a customer, a customer work with a tester, and so forth, rather than pairing by job description. Work with a new partner every day.

Step 2. (Timebox this step to 10 minutes.) Within your pair, discuss the kinds of information that you need in order to do your job, or that other people need from you in order to do their job. Choose one example that you have personally observed or experienced. If you can't think of anything new, pick an existing card and skip to Step 3.

Information usually flows in both directions. For example, during an iteration demo as the example, the flow may be the developers asking if the software behaves correctly. Alternately, it may be the customer asking what the software actually does. Choose just direction.

Reflect on all of the times you remember needing or providing this information. How long did it take? For information you needed, think of the calendar time needed from the moment you realized you needed the information to the moment you received it. For information you provided, think of the total effort that you and other team members spent preparing and providing the information.

Next, think of the typical time required for this piece of information. If the typical time required is less than ten minutes, take a green index card. If it's less than a day, take a yellow index card. If it's a day or longer, take a red index card. Write down the type of information involved, the group that you get it from (or give it to), the role you play, and the time required, as shown in Figure.

Figure. Sample Cards

Step 3. (Timebox this step to 10 minutes.) Within your pair, discuss things that your team can do to reduce or eliminate the time required to get or provide this information. Pick one and write it on a white card.

Step 4. (Timebox this step to 10 minutes.) As a team, discuss all of the cards generated by all of the pairs. Consider these questions:

Where are the bottlenecks in receiving information?

Which latencies are most painful in your current process?

Which flow is most important to optimize in your next iteration?

What is the root cause of those latencies?

What will you do next iteration to improve information flow?

After everyone has had a chance to share their cards, add them to the table. Place colored cards on the table so that the cards visually show information flow. For example, if an interaction designer gets information about usage from real customers and gives it to the development team, those two cards would be placed side by side. Place white cards underneath colored cards.

Next: Trust
Previous: Retrospectives
Up: Table of Contents

Comments

Alternatives to Acceptance Testing

Mon, 01 Mar 2010 00:00:00 PST

01 Mar 2010

James Shore/Blog

Updated 3 Mar 2010: Clarified "Customer Examples" section.

My essay on the problems with acceptance testing caused a bit of a furor. (Gojko Adzic, George Dinwiddie, Ron Jeffries.) The biggest criticism was that, without acceptance testing, how do you know that the software continues to work? The classic approach, manual regression testing, is a huge burden that only increases over time.

It's true. Manual regression testing is not a good idea. I'm not recommending it. But that's only one of the alternatives to automated acceptance testing.

Every software development practice has a cost and a benefit. The trick in designing your ideal method is to choose families of practices that combine to maximize benefits and minimize costs. When I said, "acceptance testing tools cost more than they're worth. I no longer use it or recommend it," I meant that I've found alternatives that provide the same benefit for lower cost.

This is what I do instead.

My Goal

When it comes to testing, my goal is to eliminate defects. At least the ones that matter. (Netscape 4.01 users, you're on your own.) And I'd much rather prevent defects than find and fix them days or weeks later.

I think of defects as coming from four sources: programmer errors, design errors, requirements errors, and systemic errors. When trying to eliminate defects, I look for practices that address these four causes.

Programmer errors occur when a programmer knows what to program but doesn't do it right. His algorithm might be wrong, he might have made a typo, or he may have made some other mistake while translating his ideas into code.

Design errors create breeding grounds for bugs. According to Barry Boehm (PDF), 20% of the modules in a program are typically responsible for 80% of the errors. They're not necessarily the result of an outright mistake, though. Often a module starts out well but gets crufty as the program grows.

Requirements errors occur when a programmer creates code that does exactly what she intends, but her intention was wrong. Somehow she misunderstood what needed to be done. Or, perhaps, no one knew what needed to be done. Either way, the code works as intended, but it doesn't do the right thing.

Systemic errors make mistakes easy. The team's work habits include a blind spot that lets subtle defects escape. In this environment, everybody thinks they're doing the right thing--programmers are confident that they're expressing their intent, and customers are confident that programmers are doing the right thing--yet defects occur anyway. Security holes are a common example.

I use the following techniques to eliminate these sources of errors. Although there are a lot of practices here, nearly all of them are practices my teams already use. I get them for free. Also, a long list doesn't translate to high cost. My experience with acceptance testing is that it's high cost, even though it doesn't take much time to describe. These practices, despite taking a lot of time to describe, are low cost. Many of them, such as TDD and fixing bugs promptly, actually decrease costs.

Finally, and most importantly, I can't take credit for these practices. Most of them are standard XP practices. All I've done is tweak the package a bit so I get the benefits of acceptance testing without the cost.

1. Preventing Programmer Errors

Test-Driven Development (TDD) is my defect-elimination workhorse. Not only does it improve the quality of my code, it gives me a comprehensive regression suite that I can use to detect future errors. My criteria for TDD is that I need to continue to write tests until I'm confident that the code does what I think it does and that the tests will alert me of improper changes in the future.

A lot of people think that TDD is just for unit testing. I don't use it that way. As I use TDD, I write three kinds of tests:

Unit tests, which are focused on a single class or set of interrelated classes. These tests don't cross process boundaries, don't involve I/O, and should run at a rate of hundreds per second. The number of tests scales linearly with the size of the code. Typically, 30-50% of my codebase is unit test code.

Focused integration tests, which test specific integration points in my program. For example, if I have a library that provides a database abstraction, I'll write tests that prove that I can connect to a database, perform queries, insert rows, and so forth. These tests run at a rate of tens per second. The number of tests scales proportionally to the number of ways my code talks to the outside world.

End-to-end integration tests, which test all layers of the application, from UI to database. Typically, the test will act like a user of the program, entering text and clicking buttons (or simulating clicks in the presentation layer), and then check the result by looking at the database or checking the program's output. These tests are very slow--seconds or even minutes per test--and tend to break when the program changes. I keep these to the minimum necessary for me to be confident that all of the pieces of the program fit together properly. Legacy systems written without TDD require a lot more end-to-end tests, but my goal is to replace them with unit tests and focused integration tests.

In addition to TDD, Pair Programming helps prevent programmer error through continuous code review. Two brains are better than one. Pairing also improves design quality, which reduces design errors.

I also implement policies that enable Energized Work. Tired, burned-out programmers make dumb mistakes. I use sensible work hours and encourage people to go home on time.

2. Preventing Design Errors

The techniques for eliminating programming errors also benefit the design, but I use additional practices to continually improve the design.

Simple Design emphasizes creating small, focused designs that only solve the problems we're facing today. Keeping the designs focused makes them easier to understand, reducing the likelihood of creating a bug breeding ground.

Incremental Design and Architecture works hand-in-hand with Simple Design by enabling us to grow our initial, simple designs as our needs become more complex. The two practices together are sometimes called Evolutionary Design.

Refactoring is an essential tool that allows us to change existing designs. Not only does it enable Incremental Design and Architecture, we can use it to improve poor quality designs. Even the best design gets crufty over time. I build Slack into every iteration and use the extra time to refactor away technical debt.

And finally, when my teams find a bug, we fix it right away--or decide that it isn't ever worth fixing. Not only do bugs get more expensive to fix over time, they're probably in the 20% of the code that causes 80% of the defects. After writing a test to reproduce the bug and fixing it, we look for ways to refactor the code so similar bugs are less likely in the future.

3. Preventing Requirements Errors

Acceptance tests are mostly about requirements. Since I don't use acceptance tests, I need lots of collaboration instead.

Whole Team

First, a Whole Team is essential. My teams are cross-functional, co-located, and have the resources necessary to succeed. In particular, my teams include customers and testers on-site as part of the team.

"On-site customers" is a broad term that includes product managers, product owners, domain experts, business analysts, interaction designers, and others. Essentially, these are the people on the team who understand and generate the software's requirements. Sometimes they make requirements up out of whole cloth, but more often they supplement their work with lots of stakeholder feedback.

When programmers need to understand requirements, they simply turn their head and ask the on-site customers. For anything that can't be explained easily, the customers provide concrete examples, cunningly called Customer Examples, to illustrate the point.

Customer Examples

Examples turn out to be a very powerful form of communication, and it's the legacy of Fit that's provided me with the most value. Typically, when you ask an on-site customer to explain something, she will try to explain the general principle. For example, she might say, "when a customer buys a ringtone, we either debit his pre-paid account or charge his credit card, but if he's using a credit card and the ringtone costs less than one dollar, we batch up the charges until the end of the month or until his total expenses are more than twenty dollars." Not only is this hard to understand, customers often leave out important details.

Instead, I have the customers illustrate their descriptions with concrete examples. I'll say, "Okay, so we have a customer named Fred, and he's paying with a credit card. He buys a ring-tone that costs fifty cents. He's already purchased 12 dollars of merchandise this month. How much do we charge his card for?" Once the dam has broken, the customers are able to provide additional examples in the same vein, and we keep going until we have examples for all of the edge cases we need.

Examples aren't just for domain rules. I also ask for work-flow examples and UI examples, such as screen mock-ups. Any non-trivial requirement can benefit from a concrete example. They can be informal, such as a discussion at a whiteboard, or formal, such as a Powerpoint mockup. I let the on-site customers decide how much formality they need--they often keep some of the examples for later reference.

The programmers use these examples to guide their work. Sometimes they'll use the examples directly in their tests. Domain rule examples are most likely to map directly to programmer concepts, particularly if the team uses Domain-Driven Design, a Ubiquitous Language, and Whole Value.

More often, though, the examples are too high-level to be used directly in the tests. Workflow examples, in particular, often correspond to the end-to-end integration tests I prefer to avoid. Instead, programmers use the examples as a guide, writing a multitude of more focused, programmer-centric tests as they use TDD. (As they're working, they're likely do a few manual walk-throughs of the program to make sure things come together as expected, but these "tests" aren't saved or repeated in any way. They're just part of the conscientious, paranoid programmer's workflow.)

The programmers stop when they're confident that the software reflects the customers' goals, as illustrated with the examples. Because they use TDD, they've also created a sophisticated suite of regression tests that are far more complete and thorough than the original examples. Even though the examples themselves aren't coded as tests, the regression suite will fail if the software breaks.

There's one problem with this approach: it doesn't close the feedback loop. Programmers work from customers' examples, and talk with the customers when they have questions, but how do they confirm that they really understood what the customers wanted? That's where Customer Review of the completed software comes in.

Aside: Customer Confidence

If tests are for the programmers' confidence, what gives the customers confidence? This was one of the hardest lessons for me to learn. I would show customers passing Fit tests, and they would say, "How do I know that the program is really doing what this says? How do I know you didn't just program it to give the right answer for these examples?" It was so frustrating! We were essentially being accused of fraud. I wanted to shout, "Just trust us!" But, of course, that was the problem. They didn't.

The question of customer confidence isn't one that any tool can resolve. It all comes down to interpersonal relations. Customers that don't trust the programmers aren't going to be assuaged by a test run. Customers who do trust the programmers don't need a test run to bolster that confidence.

In my experience, a reliable track record of shipping defect-free software is what improves customer confidence. Nothing more; nothing less. (Sorry.)

Customer Review

The check on the programmers' interpretation of requirements is continuous customer review. As programmers finish parts of the system, they pair with on-site customers to walk through the new functionality. This review often reveals minor flaws--sometimes purely cosmetic--that nobody thought to mention. Sometimes customers realize that what they asked for wasn't quite right. Reviews happen as soon as programmers have something to show, which exposes errors in time to be corrected. In addition, stories aren't marked "done done" until the on-site customers agree they're done.

Bring Testers Forward

Although examples help communicate complex requirements, customers typically have trouble thinking of edge cases. Programmers can help them spot holes, but I've experienced even better results from bringing testers into the mix.

In my experience, some testers are business-oriented testers: they're very interested in getting business requirements right. These testers work with the customers to uncover all the nit-picky details the customers would otherwise miss. They'll often prompt the customers to provide examples of edge cases during requirements discussions.

Other testers are more technically-oriented. They're interested in test automation and non-functional requirements. These testers act as technical investigators for the team. They create the massive testbeds that look at issues such as scalability, reliability, and performance.

4. Preventing Systemic Errors

If everyone does their job perfectly, the previous practices yield a system with no defects. Too bad perfection is so hard to come by. The team is sure to have blind spots: subtle areas where they don't do everything they need to, but they don't know it.

Escaped defects are a clear signal of problems in paradise. Although defects are inevitable--TDD alone has programmers finding and fixing defects every few minutes--defects that are found by end-users have "escaped." Every escaped defect is an indication of a flaw somewhere in the process.

Of course, we don't really want our end-users to be our beta testers. (Not usually, anyway.) That's where exploratory testing comes in.

Exploratory Testing

Exploratory Testing is a technique for finding surprising defects. Testers use their training, experience, and intuition to form hypotheses about where defects are likely to be lurking in the software, then they use a fast feedback loop to iteratively generate, execute, and refine test plans that expose those defects. It appears similar to ad-hoc testing to an untrained observer, but it's far more rigorous.

Some teams use exploratory testing to check the quality of their software. After a story's been coded, the testers do some exploratory testing, the team fixes bugs, and repeat. Once the testers don't find any more bugs, the story is done.

I do it differently. If the team is preventing defects like they should be, their code should be defect-free without additional testing. Instead, I use exploratory testing as a check on the quality of the process, not the software. Any defects found through exploratory testing are considered "escaped defects," indicating a flaw in the process. Only completed stories go through exploratory testing. In fact, once the team has demonstrated that it produces nearly zero defects, they release at-will, without a separate testing phase.

Fix the Process

Every escaped defect, whether found in exploratory testing or found by end-users, is a indication of a flaw in the process. When we find one, we fix our process.

The first thing is to analyze the defect, write a test that reproduces it, and fix it. While we're fixing it, we look at the design of the code and see if it needs improvement, too.

Next, we conduct Root-Cause Analysis. We ask ourselves, "What about our process allowed this defect to escape?" We continue asking "why" until we get to the root cause. Once we find it, we make changes to prevent that entire category of defects from happening again.

Sometimes we can prevent defects by changing the design of our system so that type of defect is impossible. For example, if find a defect that's caused by mismatch between UI field lengths and database field lengths, we might change our build to automatically generate the UI field lengths from database metadata.

When we can't make defects impossible, we try to catch them automatically, typically by improving our build or test suite. For example, we might create a test that looks at all of our UI field lengths and checks each one against the database.

And lastly, we might change our process to make defects less likely. For example, we might add an item to our "done done" checklist that reminds us to double-check any field lengths we changed.

'Tude

I also encourage an attitude among my teams... a bit of eliteness, even snobbiness. It goes like this: "Bugs happen to other people."

In a lot of teams, bugs are a way of life. But when you have the attitude that defects are inevitable, you aren't motivated to prevent them. They're just a nuisance to be fixed and forgotten as quickly as possible.

All of the practices I've described here take discipline and rigor. They're not necessarily difficult, but they break down if people are sloppy or don't care about their work. A culture of "No Bugs" helps the team maintain the discipline required, as does pair programming, a co-located team, and collective ownership.

The Complete Package

So that's how I achieve low defects without using acceptance tests. As I said in my previous essay, I've found acceptance testing to be high cost and low value. This set of practices, though long, is mostly free for teams using XP. For those teams, it costs less than acceptance testing and does a better job of preventing defects.

It's not easy, by any means. To achieve the value I'm describing here, you have to be rigorous in your approach to TDD and you have to commit wholeheartedly to having a cross-functional, co-located team. It's really based on a rigorous application of XP. If you can't do that, then perhaps automated acceptance tests are your best alternative.

But if you can to do this instead, I think you'll find that it gives you better results. It has for me.

Comments

The Art of Agile Development: Chapter 5: Thinking

Sun, 28 Feb 2010 00:00:00 PST

28 Feb 2010

James Shore/Agile-Book

Full Text

Thinking

What's wrong with this sentence?

What we really need is more keyboards cranking out code.

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

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

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

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

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

"Thinking" Mini-Etude

The purpose of this étude is to practice mindfulness. If you're new to agile development, you may use it to help you understand the XP practices, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 11 and use this étude to consider how you can go beyond the practices in this book.

Conduct this étude for a time-boxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.

You will need multiple copies of this book (if you don't have enough copies on hand, you can make photocopies of specific practices for the purpose of this exercise), paper, and writing implements.

Step 1. Start by forming pairs. Try for heterogeneous pairs—have a programmer work with a customer, a customer work with a tester, and so forth, rather than pairing by job description. Work with a new partner every day.

Step 2. (Timebox this step to 15 minutes.) Within your pair, pick one practice from Part II of this book and discuss one of the following sets of questions. Pick a practice that neither of you have discussed before, even if you didn't get to lead a discussion yesterday. Timebox your discussion to fifteen minutes. It's okay not to finish the section, particularly if you haven't read it before. You'll have the chance to read it again.

If you aren't using the practice:

What about the practice would be easy to do? What would be hard? What sounds ridiculous or silly?

How does it differ from your previous experiences?

What would have to be true in order for you to use the practice exactly as written?

If you are using the practice:

What aspects of the practice do you differently than the book says? (Observations only—no reasons.)

If you followed the practice exactly as written, what would happen?

What one experimental change could you try that would give you new insight about the practice? (Experiments to prove that the practice is inappropriate are okay.)

Step 3. (Timebox this step to 15 minutes.) Choose three pairs to lead discussions of their answers. Try to pick pairs so that, over time, everyone gets to lead equally. Timebox each presentation to five minutes.

Comments

The Problems With Acceptance Testing

Sat, 27 Feb 2010 00:00:00 PST

27 Feb 2010

James Shore/Blog

Gojko Adzic wrote to ask about my experiences with acceptance testing. For those who don't know, I was the coordinator of the Fit project for a while and co-author of the C# version. Fit is Ward Cunningham's brainchild and (as far as I know) inspired a lot of the current Agile acceptance testing tools, such as Selenium, Cucumber, and FitNesse. FitNesse, in particular, started out as a fork of Fit.

When Ward first introduced me to Fit, I was very excited about the possibilities. I embraced it wholeheartedly (as evidenced by my participation in the project) and introduced it to my consulting clients. Over the years, my enthusiasm dimmed. It just didn't work as well in practice as it was supposed to. Here's what I had to say to Gojko:

My experience with Fit and other agile acceptance testing tools is that they cost more than they're worth. There's a lot of value in getting concrete examples from real customers and business experts; not so much value in using "natural language" tools like Fit and similar.

The planned benefit of those tools is that the customers are supposed to write the examples themselves, thus improving communication between customers and programmers. In practice, I found that customers (a) weren't interested in doing that, and (b) often couldn't understand and didn't trust tests that were written by others. Typically, responsibility for the tests gets handed off to testers, which defeats the whole point.

Furthermore, acceptance testing tools are almost invariably used to create end-to-end integration tests, which are slow and brittle. Fit works best for targeted tests that describe the domain, but that's not how it's used. Also, tools like Fit don't work with refactoring tools. Once you have a lot of tests, they become a real maintenance burden.

These two problems--that customers don't participate, which eliminates the purpose of acceptance testing, and that they create a significant maintenance burden, means that acceptance testing isn't worth the cost. I no longer use it or recommend it.

Instead, I involve business experts (on-site customers) closely throughout the iteration. I do have them create concrete examples, but only when faced with particularly complex topics, and never with the intention that they be run by a tool like Fit. Instead, the programmers use those examples to inform their test-driven development, which may or may not involve creating automated tests from the examples, at the programmers' discretion.

I also have the on-site customers conduct ad-hoc review of the software as programmers complete it. They pair with a programmer, look at what's been created, and ask for changes that the programmer implements on the spot.

The Art of Agile Development: Pair Programming

Fri, 26 Feb 2010 00:00:00 PST

26 Feb 2010

James Shore/Agile-Book

in 99 words

It's more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.

The driver types. She focuses on tactics--writing clean code that compiles and runs. The navigator focuses on strategy--how the code fits into the overall design, which tests will drive the code forward, and which refactorings will improve the entire codebase.

Pairs self-organize by selecting partners who can best help with the current task. They switch every few hours to share perspectives and knowledge.

as haiku

Summer bakes the earth
Heads together, we ponder
Aha! An insight.

Behind the Scenes

Iterative Writing

Poster

Full Text

Pair Programming

We help each other succeed.

Audience: Programmers; Whole Team

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

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

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

Why Pair?

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

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

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

¹One study found that pairing takes about 15% more effort than one individual working alone, but produces results more quickly and with 15% fewer defects [Cockburn & Williams]. Every team is different, so take these results with a grain of salt.

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

You'll also spend more time in flow—that highly-productive state in which you're totally focused on the code. It's a different kind of flow than normal because you're working with a partner, but it's far more resilient to interruptions. To start with, you'll discover that your office mates are far less likely to interrupt you when you're working with someone. When they do, one person will handle the interruption while the other continues his train of thought. Further, you'll find yourself paying more attention to the conversation with your programming partner than surrounding noise; it fades into the background.

If that isn't enough, pairing really is a lot of fun. The added brainpower will help you get past roadblocks more easily. For the most part, you'll be collaborating with smart, like-minded people. Plus, if your wrists get sore from typing, you can hand off the keyboard to your partner and continue to be productive.

How to Pair

I recommend pair programming on all production code. Many teams who pair frequently, but not exclusively, discover that they find more defects in solo code. A good rule of thumb is to pair on anything that you need to maintain, which includes tests and the build script.

When you start working on a task, ask another programmer to work with you. If another programmer asks for help, make yourself available. Never assign partners: pairs are fluid, forming naturally and shifting throughout the day. Over time, pair with everyone on the team. This will help improve team cohesion and it will spread design skills and knowledge throughout the team.

Get a fresh perspective by switching partners.

When you need a fresh perspective, switch partners. I usually switch when I'm feeling frustrated or stuck. Have one person stay on the task to help bring the new partner up to speed. Often, even explaining the problem to someone new will help you resolve it.

It's a good idea to switch partners several times per day even if you don't feel stuck. This will help keep everyone informed and moving quickly. I switch whenever I finish a task. If I'm working on a big task, I switch within four hours.

When you sit down to pair together, make sure that you're physically comfortable. Position your chairs side by side, allowing for each others' need for personal space, and make sure the monitor is clearly visible. When you're driving, place the keyboard directly in front of you. Keep an eye out for this one—for some reason, people pairing tend to contort themselves to reach the keyboard and mouse rather than moving them closer.

Ally: Test-Driven Development

Paired programmers produce code through conversation. As you drive or navigate, think out loud. Take small, frequent design steps—test-driven development works best—and talk about your assumptions, short-term goals, general direction, and any relevant history of the feature or project. If you're confused about something, ask questions. The discussion may enlighten your partner as much as it does you.

When a pair goes dark—talks less, lowers their voices, or doesn't switch off with other pairs—it's often a sign of technical difficulty.

Ally: Energized Work

Expect to feel tired at the end of the day. Pairs typically feel that they have worked harder and accomplished more than when working alone. Practice energized work to maintain your ability to pair every day.

Driving and Navigating

Pairing will feel natural in time.

When you start pairing, expect to feel clumsy and fumble-fingered as you drive. You may feel that your navigator sees ideas and problems much more quickly than you do. She does—navigators have more time to think than drivers do. The situation will reverse when you navigate. Pairing will feel natural in time.

When navigating, expect to feel like you want to step in and take the keyboard away from your partner. Relax; your driver will often communicate an idea with both words and code. He'll make typos and little mistakes—give him time to correct them himself. Use your extra brainpower to think about the greater picture. What other tests do you need to write? How does this code fit into the rest of the system? Is there duplication you need to remove? Can the code be more clear? Can the overall design be better?

As navigator, help your driver be more productive. Think about what's going to happen next and be prepared with suggestions. When I'm navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of an issue, I write my ideas on the index card and wait for a break in the action to bring them up. At the end of the pairing session, I tear up the card and throw it away.

Ally: Spike Solutions

Similarly, when a question arises, take a moment to look up the answer while the driver continues to work. Some teams keep spare laptops on hand for this purpose. If you need more than a few minutes, research the solution together. Sometimes the best way to do so is to split up, pursue parallel lines of inquiry, and frequently come back together to share what you have learned. Spike solutions are a particularly powerful approach.

As you pair, switch roles frequently—at least every half hour, and possibly every few minutes. If you're navigating and find yourself telling the driver which keys to press, ask for the keyboard. If you're driving and need a break, pass the keyboard off to your navigator.

Pairing Stations

To enjoy pair programming, good pairing stations are essential. You need plenty of room for both people to sit side by side. Typical cubicles, with a workstation located in a corner, won't work. They're uncomfortable and require one person to sit behind another, adding psychological as well as physical barriers to peer collaboration.

You don't need fancy furniture to make a good pairing station; the best ones I've seen are just simple folding tables found at any good office supply store. They should be six feet long, so that two people can sit comfortably side-by-side, and at least four feet deep. Each table needs a high-powered development workstation. I like to plug in two keyboards and mice so each person can have a set.

Splurge on large monitors so that both people can see clearly. Some teams mirror the display onto two monitors, which makes things a little easier to see, but you may find yourself pointing to the wrong monitor. Others prefer to spread one desktop across two monitors.

For ideas about where to put the pairing stations, see "Sit Together" in Chapter 6.

Challenges

Pairing can be uncomfortable at first, as it may require you to collaborate more than you're used to. These feelings are natural and typically go away after a month or two, but you have to face some challenges.

Comfort

It bears repeating: pairing is no fun if you're uncomfortable. When you sit down to pair, adjust your position and equipment so you can sit comfortably. Clear debris off the desk and make sure there's room for your legs, feet, and knees.

Some people (like me) need a lot of personal space. Others like to get up close and personal. When you start to pair, discuss your personal space needs and ask about your partner's.

Similarly, while it goes without saying that personal hygiene is critical, remember that strong flavors such as coffee, garlic, onions, and spicy foods can lead to foul breath. Decide as a team, before any issues come up, how to notify people of challenging personal habits respectfully.

Mismatched Skills

Pairing is a collaboration between peers, but sometimes a senior developer will pair with a junior developer. Rather than treating these occasions as student/teacher situations, restore the peer balance by creating opportunities for both participants to learn. For example, if you know you'll be pairing with a junior developer, you could ask him to research a topic that no one else knows, such as the inner workings of a library that the team depends on. Give everyone a chance to be an expert.

Communication Style

Ally: Test-Driven Development

New drivers sometimes have difficulty involving their partners; they can take over the keyboard and shut down communication. To practice communicating and switching roles while pairing, consider ping-pong pairing. In this exercise, one person writes a test. The other person makes it pass and writes a new test. Then the first person makes it pass and repeats the process by writing another test.

The flip side of too little communication is too much communication—or rather, too much blunt communication. Frank criticism of code and design is valuable, but it may be difficult to appreciate at first. Different people have different thresholds, so pay attention to how your partner receives your comments. Try transforming declarations (such as "This method is too long") into questions or suggestions ("Could we make this method shorter?" or "Should we extract this code block into a new method?"). Adopt an attitude of collaborative problem solving.

Tools and Keybindings

Ally: Coding Standards

Even if you don't fall victim to the endless vi versus emacs editor war, you may find your coworkers' tool preferences annoying. Try to standardize on a particular toolset. Some teams even create a standard image and check it into version control. When you discuss coding standards, discuss these issues as well.

Questions

Isn't it wasteful to have two people do the work of one?

In pair programming, two people aren't really doing the work of one. Although only one keyboard is in use, there's more to programming than that. As Ward Cunningham said, "If you don't think carefully, you might think that programming is just typing statements in a programming language."² In pair programming, one person is programming and the other is thinking ahead, anticipating problems, and strategizing.

²http://en.wikiquote.org/wiki/Ward_Cunningham, accessed 12 December 2006.

If you're looking for hard data, [Williams] has a chapter on pairing research. Keep in mind that the number of variables in software development make it notoriously difficult to conduct large-scale controlled studies. Sometimes the best way to know whether something will work for your team is just to try it.

How can I convince my team or organization to try pair programming?

Ask permission to try it as an experiment. Set aside a month in which everyone pairs on all production code. Be sure to keep going for the entire month, as pair programming may be difficult and uncomfortable for the first few weeks.

Don't just ask permission of management; be sure your fellow team members are interested in trying pairing as well. The only programmers I know who tried pairing for a month and didn't like it are the ones who were forced to do it against their will.

Do we really have to pair program all the time?

This is a decision that your whole team should make together. Before you decide, try pairing on all production code (everything you need to maintain) for a month. You may enjoy it more than you expect.

Regardless of your rule, you will still produce code that you don't need to maintain. (Spike solutions are one example.) These may benefit from individual study.

If you're bored while pairing, consider how you can make your design less repetitive.

Ally: Simple Design

Some production tasks are so repetitive that they don't require the extra brainpower a pair provides. Before abandoning pairing, however, consider why your design requires so much repetition. It could be an indication of a design flaw. Use the navigator's extra time to think about design improvements and consider discussing it with your whole team.

How can I concentrate with someone talking to me?

When you navigate, you shouldn't have too much trouble staying several steps ahead of your driver. If you do, ask your driver to think out loud so you can understand her thought process.

As driver, though, you may sometimes find that you're having trouble concentrating. Let your navigator know—she may have a suggestion that will help you get through the roadblock. At other times, you may just need a few moments of silence to think through the problem.

If you have trouble concentrating, try taking smaller steps.

Ally: Test-Driven Development

If you find yourself in this situation a lot, you may be taking steps that are too large. Use test-driven development and take very small steps. Rely on your navigator to keep track of what you still need to do (tell him if you have an idea; she'll write it down) and focus only on the few lines of code needed to make the next test pass.

Ally: Spike Solutions

If you are working with a technology you don't completely understand, consider taking a few minutes to work on a spike solution. You and your partner can work on this together or separately.

What if we have an odd number of programmers?

Ally: Exploratory Testing

A programmer flying solo can do productive tasks that don't involve production code. She can research new technologies, or learn more about a technology the team is using. She can pair with a customer or tester to review recent changes, polish the application, or do exploratory testing. She could be the team's batman (see "Iteration Planning" in Chapter 8).

Alternatively, a solo programmer may wish to spend some time reviewing the overall design—either to improve his own understanding, or to come up with ideas for improving problem areas. If a large refactoring is partially complete, the team may wish to authorize a conscientious programmer to finish those refactorings.

If your team is on the smaller side, you may run out of useful solo tasks. In this case, consider relaxing the "no production code" rule or bringing in another programmer.

There are only two (or three) of us. Should we still pair all the time?

Even a saint will get on your nerves if you have to pair with him day-in, day-out. Use your own judgment about when to pair and when you need time to yourself. If you feel fine but your pair is getting cranky, don't escalate; just say you're tired and need a break.

I pair-programmed with the same person for three months straight during a two-person project. I think it helped that we had a large office and a big desk: it gave us room to move around. We also kept a mini-fridge stocked with goodies.

Even with these comforts, I had my cranky moments. Perhaps the most important factor was that my partner was a very laid-back, easy-going person who put up with my occasional bad mood.

We get engrossed in our work and forget to switch pairs. How can we encourage more frequent pair switching?

One approach is to remember that you can switch when you feel stuck or frustrated. In fact, this is a perfect time to switch partners and get a fresh perspective.

Some teams use kitchen timers to switch partners at strictly defined intervals. [Belshee] reports interesting results from switching every ninety minutes. While this could be a great way to get in the habit of switching pairs, make sure everybody is willing to try it.

How can we pair remotely?

You can use a phone headset and a desktop sharing tool such as VNC or NetMeeting to pair remotely. I have heard of teams who use individual workstations with shared screen sessions and VoIP applications.

When I tried this, I found it to be a poor substitute for pairing in person. XP teams usually sit together, so remote pairing isn't often necessary.

Results

When you pair program well, you find yourself focusing intently on the code and your work with your partner. You experience fewer interruptions and distractions. When interrupted, one person deals with the problem while the other continues thinking. Afterward, you slide back into the flow of work immediately. At the end of the day, you feel tired yet satisfied. You enjoy the intense focus and the camraderie of working with your teammates.

The team as a whole enjoys higher quality code. Technical debt decreases. Knowledge travels quickly through the team, raising everyone's level of competence and helping to integrate new team members quickly.

Contraindications

Pairing requires a comfortable work environment (see "Sit Together" in Chapter 6 for design options). Most offices and cubicles just aren't set up that way. If your workspace doesn't allow programmers to sit side-by-side comfortably, either change the workspace or don't pair program.

Similarly, if your team doesn't sit together, pairing may not work for you. Although you can pair remotely, it's not as good as in-person.

Programmer resistance may be another reason to avoid pairing. Pairing is a big change to programmers' work styles and you may encounter resistance. I usually work around this by asking people to try it for a month or two before making a final decision. If they still resist, you're probably better off avoiding pairing rather than forcing anyone to pair against their will.

Alternatives

Pairing is a very powerful tool. It reduces defects, improves design quality, shares knowledge amongst team members, supports self-discipline, and reduces distractions; all without sacrificing productivity. If you cannot pair program, you need alternatives.

Formal code inspections can reduce defects, improve quality, and support self-discipline. However, my experience is that programmers have trouble including inspections in their schedules, even when they're in favor of them. Pairing is easier to do consistently, and it provides feedback much more quickly than scheduled inspections. If you're going to use inspections in place of pairing, add some sort of support mechanism to help them take place.

Inspections alone are unlikely to share knowledge as thoroughly as collective code ownership requires. If you cannot pair program, consider avoiding collective ownership, at least at first.

If you'd still like to have collective code ownership, you need an alternative mechanism for sharing knowledge about the state of the codebase. I've formed regular study groups in which programmers meet daily for a timeboxed half-hour to review and discuss the design.

Ally: Energized Work

I'm not aware of any other tool that helps reduce distractions as well as pair programming does. However, I find that I succumb to more frequent distractions when I'm tired. In the absence of pairing, put more emphasis on energized work.

James Shore

Agile Friday: "Done Done" Now Online

The Art of Agile Development: "Done Done"

in 99 words

Commentary

Full Text

"Done Done"

Production-Ready Software

How to Be "Done Done"

Making Time

Questions

How does testers' work fit into "done done"?

What if we release a story that we think is "done done," but then we find a bug or stakeholders tell us they want changes?

Results

Contraindications

Alternatives

The Art of Agile Development: Chapter 7: Releasing

Full Text

Releasing

"Releasing" Mini-Etude

The Art of Agile Development: Sit Together

in 99 words

as haiku

Behind the Scenes

Full Text

Sit Together

Accommodating Poor Communication

A Better Way

Exploiting Great Communication

Secrets of Sitting Together

Making Room

Designing Your Workspace

Sample Workspaces

A Small Workspace

Adopting an Open Workspace

Questions

How can I concentrate with all that background noise?

When one person is interrupted, the whole team stops what they're doing to listen. What can we do to prevent people from being distracted so easily?

What if I need privacy for phone calls?

Results

Contraindications

Alternatives

Further Reading

Agile Friday: "Sit Together" Now Online

The Art of Agile Development: Chapter 6: Collaborating

Full Text

Collaborating

"Collaborating" Mini-Etude

Alternatives to Acceptance Testing

My Goal

1. Preventing Programmer Errors

2. Preventing Design Errors

3. Preventing Requirements Errors

Whole Team

Customer Examples

Aside: Customer Confidence

Customer Review

Bring Testers Forward

4. Preventing Systemic Errors

Exploratory Testing

Fix the Process

'Tude

The Complete Package

The Art of Agile Development: Chapter 5: Thinking

Full Text

Thinking

"Thinking" Mini-Etude

The Problems With Acceptance Testing

Further Reading

The Art of Agile Development: Pair Programming

in 99 words

as haiku

Behind the Scenes

Poster

Full Text

Pair Programming

Why Pair?

How to Pair

Driving and Navigating

Pairing Tips