Agile Software Development Feeds: Extreme Programming, Scrum, Test Driven & Lean Software Development

In team software development, we create a collective work that is greater than any individual could create on his own. Arguing about style gets in the way.

When creating a coding standard, your most important achievement will be learning how to disagree constructively. To succeed, create the minimal set of standards you can live with. Focus on consistency and consensus over perfection. Remember that few decisions are irrevocable in agile development.

Assume your colleagues are professional and well-meaning. If they deviate from the standard, discuss reasons rather than placing blame. No coding standard can substitute for professional judgement.

as haiku

Fists fly, dust billows--
Tomatoes die, peas cry, as
we choose rose's hue.

Rant Get a Life! Full Text

Coding Standards

Audience: Programmers

We embrace a joint aesthetic.

Back in the days of the telegraph, as the story goes, telegraph operators could recognize each other on the basis of how they keyed their dots and dashes. Each operator had a unique style, or fist, that experts could recognize easily. Programmers have style, too. We each have our own way of producing code. We refine our style over years until we think it's the most readable, the most compact, or the most informative it can be.

Individual style is great when you're working alone. In team software development, however, the goal is to create a collective work that is greater than any individual could create on his own. Arguing about whose style is best gets in the way; it's easier if we work together in a single style.

XP suggests creating a coding standard: guidelines to which all developers agree to adhere when programming.

Beyond Formatting

I once led a team of four programmers who had widely differing approaches to formatting. When we discussed coding standards, I catalogued three different approaches to braces and tabs. Each approach had its own vigorous defender. I didn't want us to get bogged down in arguments, so I said that people could use whatever brace style they wanted.

The result was predictable: we had three different approaches to formatting in our code. I even saw two different ways of indenting within a single, short method.

You know what surprised me? It wasn't that bad. Sure, the layout was ugly, and I would have preferred consistency, but the code was still readable. In the end, the rest of our coding standard mattered much more than formatting.

We all agreed that clearly named variables and short methods were important. We agreed to use assertions to make our code fail fast, not to optimize without measurements, and never to pass null references between objects. We agreed on how we should and shouldn't handle exceptions, what to do about debugging code, and when and where to log events. These standards helped us far more than a consistent formatting style would have because each one had a concrete benefit. Perhaps that's why we were able to agree on them when we couldn't agree on formatting styles.

Don't get me wrong: a consistent formatting standard is good. If you can agree on one, do! However, when you're putting together your coding standard, don't fall into the trap of arguing about formatting. There are more important issues.

How to Create a Coding Standard The most important thing you will learn is how to disagree.

Creating a coding standard is an exercise in building consensus. It may be one of the first things that programmers do as a team. Over time, you'll amend and improve the standards. The most important thing you may learn from creating the coding standard is how to disagree constructively.

To that end, I recommend applying two guidelines:

Create the minimal set of standards you can live with.
Focus on consistency and consensus over perfection.

Hold your first discussion of coding standards during the first iteration. The project will typically start out with some discussion of stories and vision, then some release planning and iteration planning (see Go! in Chapter 4). After iteration planning, customers and testers will continue working on the release plan. That's a great time for programmers to talk about coding standards.

The best way to start your coding standard is often to select a industry-standard style guide for your language. This will take care of formatting questions and allow you to focus on design-related questions. If you're not sure what it should encompass, starting points include:

Development practices (start with the practices in Chapter 9 and Chapter 7)
Tools, keybindings, and IDE
File and directory layout
Build conventions
Error handling and assertions
Approach to events and logging
Design conventions (such as how to deal with null references)

Focus on agreements.

Limit your initial discussion to just one hour. Write down what you agree on. If you disagree about something, move on. You can come back to it later.

I like to write each item that we agree upon on a flip chart so we can tape it to a wall in our open workspace. If you can find a neutral observer to take notes (such as your project manager), so much the better.

If you have trouble, take a step back and talk about your goals for the software and the results you would like to see. Agree about these issues first, even if you disagree about specific approaches. You will have many opportunities to improve your standard. Make the most important decisions now, and move on.

Depending on your team, this may be a contentious discussion. In that case, consider bringing in a professional facilitator to redirect the discussion to your team goals when things gets heated. Your HR department might be able to provide someone, or you can use an outside consultant.

Plan to hold another one-hour coding standard meeting a few days later, and another one a few weeks after that. The long break will allow you to learn to work together and to try out your ideas in practice. If there's still disagreement, experiment with one approach or the other, then revisit the issue.

Ally: Retrospectives

Hold these initial meetings as often as they're useful. After that, change the standard at any time. Just stand up, announce your intention to the team, and, if everybody agrees, change the flip chart. Retrospectives are another good time to discuss changes to the coding standard.

The thumb vote is a quick way to check for consensus. Someone asks a question and everyone holds their thumb up (meaning "I agree"), sideways ("I'll go along with the group"), or down ("I disagree and want to explain why").

Over time, some of the items in the standard will become second nature. Cross them off to make room for more important issues. As you work together, you will recognize ways in which new standards can help. Add these new standards to the list in the same way as before, as long as everybody agrees to try them.

No matter what standards you choose, someone will be probably unhappy with some guideline even with a consensus-based approach. You'll probably find some practices jarring and grating at first. Over time, you'll get used to it. Coding standards are, in many ways, an aesthetic choice: it doesn't really matter what the standard is, as long as it's consistent and thoughtful. One of the marks of a professional is the willingness to put aside personal aesthetics for a team aesthetic.

Dealing with Disagreement

It's possible to pressure a dissenter into accepting a coding standard she doesn't agree with, but it's probably not a good idea. Doing so is a good way to create resentment and discord.

Instead, remember that few decisions are irrevocable in agile development; mistakes are opportunities to learn and improve. Ward Cunningham put it well:1

1http://en.wikiquote.org/wiki/Ward_Cunningham

It was a turning point in my programming career when I realized that I didn't have to win every argument. I'd be talking about code with someone, and I'd say, "I think the best way to do it is A." And they'd say, "I think the best way to do it is B. I'd say, "Well no, it's really A." And they'd say, "Well, we want to do B." It was a turning point for me when I could say, "Fine. Do B. It's not going to hurt us that much if I'm wrong. It's not going to hurt us that much if I'm right and you do B, because, we can correct mistakes. So [let's] find out if it's a mistake."

Go ahead and leave the contested item out of the standard. Maybe lack of standardization in that area will lead to a mess. If it does, the team will learn from the experience and you can change the standard.

Adhering to the Standard

Allies: Pair Programming; Collective Code Ownership

People make mistakes. Pair programming helps developers catch mistakes and maintain self-discipline. It provides a way to discuss formatting and coding questions not addressed by the guidelines. It's also an excellent way to improve the standard; it's much easier to suggest an improvement when you can talk it over with someone first.

Collective code ownership also helps people adhere to the standard, because many different people will edit the same piece of code. Code tends to settle on the standard as a result.

There are less effective approaches. Some teams use automated tools to check their source code for adherence to the coding standard. Others program their version control system to reformat files upon check-in. I don't like either approach: to me, the latter says that you don't trust people to make good decisions on their own, and the former tends to raise false warnings.

Assume your colleagues are professional and well-meaning.

I've also heard of teams who elevate their coding standards to requirements and punish infractions. The idea of enforcing a coding standard leaves a bad taste in my mouth. Your teammates are presumably professionals who pride themselves on doing good work. No coding standard can substitute for professional judgment. Try not to get too upset when you see people deviating from the standard.

Assume your colleagues are professional and well-meaning. If someone is not following the standard, assume that there's a good reason—even if all the evidence is to the contrary. Your challenge is to find that reason and address it. This approach shows respect for others and this will improve others' respect for you.

Before you do anything, ask yourself whether the coding standard was really a team effort. If everybody agreed to every item, they should have no problem following the standard.

Start by talking with your colleague alone to see if there's a disagreement. Take an attitude of collaborative problem solving: instead of saying "Why aren't you propagating exceptions like we agreed?" ask, "What do you think about the 'propagate exceptions' standard we agreed on? Should we keep it?" Give objections full consideration, raise them with the rest of the team, and consider changing the standard.

If the objector agrees with the standard but isn't applying it, it's possible that the standard isn't appropriate in every situation. Ask about specific cases you've noticed. Again, be collaborative, not confrontational. Say something like, "I think we're on the same page regarding the importance of propagating exceptions. In that case, can you explain what's happening in this method? I don't understand why this code doesn't propagate the exception here."

During this discussion, you may learn that the objector doesn't understand the standard. By this time, you should be in a good situation to discuss the standard and what it means. If he's a junior programmer and needs more help, coordinate with the rest of the team to make sure he gets plenty of pairing time with experienced developers.

There is another possibility for teams new to XP. Switching to XP is a big change and can make people feel like they've lost control. Sometimes they react by picking small things that they refuse to change. An obstinate desire to stick with a particular coding standard, regardless of the wishes of the rest of the team, might be a symptom of this reaction.

In this case, your best solution may be to let the infractions slide for several months. Over time, as team members become more comfortable with the changes in their environment, they'll relax and be more willing to compromise.

Questions We have legacy code that doesn't fit our standard. Should we fix it?

Leave old code alone if it works and you don't need to read or touch it otherwise. It's expensive and risky to spend a lot of time fixing legacy code upfront. Instead, as you modify and refactor those sections of code, bring them up to the new coding standards. When you fix a bug, add a feature, or improve abstraction and factoring, use the new standards on everything you modify.

You can also use an automated tool to perform large-scale formatting changes. Don't spend too much time on this, but if you can do it easily, you might as well. I prefer to integrate immediately before and after such an operation, because reformatting changes tend to disguise other changes. Be aware that making such large-scale changes can render your version control system's change history much more difficult to read.

Results

When you agree on coding standards and conventions, you improve the maintainability and readability of your code. You can take up different tasks in different subsystems with greater ease. Pair programming moves much more smoothly, and you look for ways to improve the expressability and robustness of your code as you write it.

Contraindications

Don't allow coding standards to become a divisive issue for your team.

Alternatives

Some teams work so well together they don't need an written coding standard; their coding standard is implicit.

If you have a new team, create a written coding standard even if everybody gets along well. New teams often go through an initial honeymoon period in which team members are reluctant to disagree with each other. Eventually, disagreements will come out. It's much better to create a standard before problems escalate.

Comments

Categories: Blogs

Agile Friday: "Coding Standards" Now Online

Fri, 09/03/2010 - 10:00

03 Sep 2010 James Shore/Blog

Coding Standards, this week's Art of Agile Development release, is now available.

In our discussion of coding standards, Shane and I say that one of the most important things you may learn from coding standards is just how to disagree constructively. I think we were right on target with that one. Coding standards themselves have very little value, I've come to believe. You only really need them if you're having repeated design disagreements--especially if they occur in the guise of repeated refactoring/reversion cycles.

If you're having those sorts of disagreements, coding standards won't resolve the problem. But discussing coding standards might help. It's the discussion that has value, not the standard. The standard merely serves to record the result. If people use the standard as a club, that's your clue that the discussion failed.

Next Week

I'll post a practice from the Releasing chapter next week. There are only two choices left:

Which one should I post? As usual, make your vote in the comments.

Comments

Categories: Blogs

Let's Play TDD #3: Cleaning Up My Mess

Thu, 09/02/2010 - 10:00

02 Sep 2010 James Shore/Blog/Lets-Play

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more.

Comments

Categories: Blogs

Let's Play TDD #2: Peering Dimly Into the Future

Wed, 09/01/2010 - 10:00

01 Sep 2010 James Shore/Blog/Lets-Play

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more.

Comments

Categories: Blogs

Let's Play: Test-Driven Development

Tue, 08/31/2010 - 10:01

31 Aug 2010 James Shore/Blog/Lets-Play

I'm trying a little experiment: a screencast of me working on a real project, from scratch, using test-driven development. I've called it "Let's Play: Test-Driven Development" in honor of all the Let's Play videos I love watching.

Like a "Let's Play" video, this is a live, stream-of-consciousness recording of my successes and slip-ups as I work. (So far, mostly slip-ups.) I'm hoping this will be an interesting view into how test-driven development works when you take it out of the classroom. As the series continues, I'm sure you'll see quite a bit of incremental design and architecture, too.

As I said, this is an experiment. I'm going to do several episodes and see what the response is like. So if you like it, let me know by leaving a comment on my blog, subscribing to my new Youtube channel, or helping spread the word. Feedback from people like you is how I'm going to judge whether I should keep going.

I hope you enjoy it.

Episode #1: "How Does This Thing Work, Again?"

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more. For the first few comments on this entry, see the original announcement.

Comments

Categories: Blogs

Let's Play: Test-Driven Development (Placeholder)

Tue, 08/31/2010 - 10:00

31 Aug 2010 James Shore/Blog

I've moved this entry. I'm keeping this placeholder to preserve the comments.

Comments

Categories: Blogs

Agile Friday: "Is XP Right For Us?" Now Online

Fri, 08/27/2010 - 10:00

27 Aug 2010 James Shore/Blog

One of the things about The Art of Agile Development that I'm most proud of is our continuous acknowledgement that one size doesn't fit all. We were writing a cookbook, after all, with specific instructions and guidance. We could have easily pretended that our advice was The One Right Way to practice Agile.

I'm glad we didn't fall to that temptation. It's not true, of course; there are many good ways to practice Agile. (Sadly, there are an infinite number of bad ways to practice Agile, and they're easier to find than good ways.) So we had to do what authors have always had to do: choose between being narrow and deep, or broad and shallow.

Obviously, we chose "narrow and deep." This week's excerpt, Is XP Right For Us?, was our attempt to have our cake and eat it too. We couldn't go broad, but we could at least be clear about what we were covering and what we weren't. Doing so gave us the opportunity to discuss the tradeoffs involved, too. I'm very happy with the result.

Next Week

The Thinking chapter is completely online, as I've mentioned, so next week's excerpt will be from the Collaborating chapter. We have four practices left to put online from that chapter. Which one would you like next week?

I'll look for your vote in the comments.

Comments

Categories: Blogs

The Art of Agile Development: Chapter 4: Adopting XP

Fri, 08/27/2010 - 10:00

27 Aug 2010 James Shore/Agile-Book

Full Text

Adopting XP

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

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

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

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

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

Comments

Categories: Blogs

The Art of Agile Development: Is XP Right For Us?

Fri, 08/27/2010 - 10:00

27 Aug 2010 James Shore/Agile-Book

in 99 words

You'll need support, from managers and colleagues. Work together, in the same room, and include business experts. Keep the team small--five to twenty people. Don't ignore practices: they're more important than they seem.

A brand-new codebase and a language that's easy to refactor are best for learning. Try to include an experienced coach, and an experienced designer. It's best if everyone gets along.

You don't have to do any of these if you don't want to. (We provide alternatives.) But you'll have more success, and more fun, if you fix your environment rather than compromising your work.

as haiku

slippery, muddy--
where grass died, pepperbushes
provide fragrant blooms

Behind the Scenes

Truth or Clarity?

Poster

Download this poster!

Full Text

Is XP Right For Us?

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

As Martin Fowler said:1

1http://martinfowler.com/bliki/EnterpriseRails.html.

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

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

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

Prerequisite #1: Management Support

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

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

You will often need management's help to get the previous three items. In addition, the more management provides the following things, the better:

Team authority over the entire development process, including builds, database schema, and version control
Compensation and review practices that are compatible with team-based effort
Acceptance of new ways of demonstrating progress and showing results (see Reporting in Chapter 6)
Patience with lowered productivity while the team learns

If Management Isn't Supportive...

In order for management to support your adoption of XP, they need to believe in its benefits. Think about what the decision-makers care about. What does an organizational success mean to your management? What does a personal success mean? How will adopting XP help them achieve those successes? What are the risks of trying XP, how will you mitigate those risks, and what makes XP worth the risks? Talk in terms of your managers' idea of success, not your own success.

If you have a trusted manager you can turn to, ask for her help and advice. If not, talk to your mentor (see "Find a Mentor" in Chapter 2). Fearless Change: Patterns for Introducing New Ideas [Manns & Rising] is another good resource.

If management refuses your overtures, then XP probably isn't appropriate for your team. You may be able to demonstrate XP's value incrementally by adopting some standalone practices (see "Extremeties: Applying Bits and Pieces of XP," later in this chapter).

Prerequisite #2: Team Agreement

Just as important as management support is the team's agreement to use XP. If team members don't want to use XP, it's not likely to work. XP assumes good faith on the part of team members—there's no way to force the process on somebody who's resisting it.

If People Resist...

It's never a good idea to force someone to practice XP against his will. In the best case, he'll find some way to leave the team, quitting if necessary. In the worst case, he'll remain on the team and silently sabotage your efforts.

Reluctant skeptics are okay. If somebody says, "I don't want to practice XP, but I see that the rest of you do, so I'll give it a fair chance for a few months," that's fine. She may end up liking it. If not, after a few months have gone by, you'll have a better idea of what you can do to meet the whole team's needs.

One way to help people agree to try XP is to promise to revisit the decision on a specific date. (Allow two or three months if you can.) At that point, if the team doesn't want to continue using XP, stop.

If only one or two people refuse to use XP and they're interested in working on another project, let them transfer so the rest of the team can use XP. If no such project is available, or if a significant portion of the team is against using XP, don't use it.

Prerequisite #3: A Colocated Team

XP relies on fast, high-bandwidth communication for many of its practices. In order to achieve that communication, your team needs to sit together in the same room.

If Your Team Isn't Colocated...

Colocation makes a big difference in team effectiveness. Don't assume that your team can't sit together; be sure to include the possibility of bringing the team together is your first option.

With that said, it's okay if one or two noncentral team members are off-site some of the time. You'll be surprised, though, at how much more difficult it is to interact with them. (Actually, they're no more difficult to interact with than before; it's the rest of the team that's improved.) Talk with your mentor about how to best deal with the problem.

If a lot of people are off-site, if a central figure is often absent, or if your team is split across multiple locations, you need help beyond this book. You can use XP or another agile method with a distributed team, but it's a complicated problem that's outside of the scope of our discussion. Ask your mentor for help and see Sit Together in Chapter 6 for more ideas.

Prerequisite #4: On-Site Customers The on-site customers' decisions determine the value of the software.

On-site customers are critical to the success of an XP team. They, led by the product manager, determine which features the team will develop. In other words, their decisions determine the value of the software.

Of the on-site customers, the product manager is likely the most important. She makes the final determination of value. A good product manager will choose features that provide value to your organization. A poor product manager will dither time away on inconsequential features.

Domain experts, and possibly interaction designers, are also important. They take the place of an upfront requirements phase, sitting with the team to plan upcoming features and answering questions about what the software needs to do.

If Your Product Manager is Too Busy to Be On-Site...

If you have an experienced product manager who makes high-level decisions about features and priorities, but who isn't available to sit with the team full-time, you may be able to ask a business analyst or one of the other on-site customers to act as a proxy. The proxy's job is to act in the product manager's stead to make decisions about details while following the actual product manager's high-level decisions.

This can work well if your proxy has the authority to act in place of the product manager. If the proxy is unable to answer questions on his own and needs to confirm every decision with the real product manager, he will introduce too many delays for this book's approach to XP to work well.

If Your Product Manager is Inexperienced...

This may be okay as long as she has a more experienced colleague she turns to for advice.

If You Can't Get a Product Manager At All...

Although good product managers are in high demand, the absence of a product manager is a big danger sign. The right person for the job may not have the title of "product manager" (see Real Customer Involvement in Chapter 6), but XP requires that somebody with business expertise take responsibility for determining and prioritizing features.

Remind your organization of the cost of development (presumably, hundreds of thousands of dollars) and the value the software will bring to them (hopefully, millions of dollars). That value hinges on the participation of a good product manager. Is that really something they want to scrimp on?

If you can't find a product manager, someone from the development team can play the part. However, this may be a dangerous approach, because this person is unlikely to have the business expertise to deliver an organizational success. If you can't get a product manager, talk with your mentor about how to compensate.

If You Can't Get Other On-Site Customers...

Because XP doesn't have an up-front requirements phase, the work of figuring out requirements happens concurrently with software development. This compresses the overall schedule, but it means that at least one person—and usually several—needs to work on requirements full-time.

Unless you have a small team, this work is probably more than a product manager can handle alone. Typically, the product manager delegates the details to a set of domain experts. In applications that involve a sophisticated user interface, a interaction designer may be involved as well. This allows the product manager to focus on coordinating with stakeholders and resolving questions of value and priorities.

Some business analysts may be domain experts. Be careful of using business analysts that aren't already experts in the domain; although they can relay information from true experts, this process invariably introduces misunderstandings and delays.

As long as somebody is playing the on-site customer role, you can use XP. However, the less expertise your on-site customers have, the more risk there is to the value of your software.

Prerequisite #5: The Right Team Size

I wrote this book for teams as large as 20 people and as small as one person. For teams new to XP, however, I recommend four to six programmers and no more than 12 people on the team (see The XP Team in Chapter 3). I also recommend having an even number of programmers so that everyone can pair program (see Pair Programming in Chapter 5). If you have ongoing support needs, add one more programmer for a total of five or seven so the team can have a batman (see Iteration Planning in Chapter 8).

Teams with fewer than four programmers are less likely to have the intellectual diversity they need. They'll also have trouble using pair programming, an important support mechanism in XP. Large teams introduce coordination challenges. Although experienced teams will handle those challenges smoothly, a new XP team will struggle.

If You Don't Have Even Pairs...

The easiest solution is to add or drop one programmer so you have even pairs. If you can't do that, the XP practices are still appropriate for you, but try to find useful nonproduction code work for the programmer who isn't pairing. This will help the team consistently apply XP's technical practices and will improve code quality.

If Your Team is Larger than Seven Programmers...

The coordination challenges of a large team can make learning XP more difficult. Consider hiring an experienced XP coach to lead the team through the transition. You may also benefit from hiring another experienced XP programmer to assist the coach in mentoring the team.

If your team is larger than ten programmers, you need guidance that's outside of the scope of this book. Hire a coach with experience in scaling XP to large teams.

If Your Team is Smaller Than Four Programmers...

Most of the XP practices are still appropriate for you, but you probably won't be able to pair program much. In this situation, it's best if your team members are conscientious programmers who are passionate about producing high-quality code. That passion will help them apply the technical practices with discipline.

You may have trouble getting on-site customers to sit with you full-time. Instead, sit close to them so that you can get their attention when you need it.

If You Have Many Developers Working Solo...

Some organizations—particularly IT organizations—have a lot of small projects rather than one big project. They structure their work to assign one programmer to each project.

Although this approach has the advantage of connecting programmers directly with projects, it has several disadvantages. It's high risk: every project is the responsibility of one programmer, so that any programmer who leaves orphans a project. Her replacement may have to learn it from first principles.

Code quality can also be a challenge. Projects don't benefit from peer review, so the code is often idiosyncratic. Stovepipe systems, in which each programmer solves the same problem in different ways, appear. Junior programmers, lacking the guidance of their more senior peers, create convoluted, kludgey systems and have few opportunities to learn better approaches. Senior programmers, not realizing the inexperience of their more junior peers, create overly sophisticated code that others have trouble understanding.

You may be able to combine four to seven of these programmers into a single XP team that works on one project at a time, which allows it to complete projects more quickly (see Release Planning in Chapter 8). By working together, senior developers have the opportunity to mentor junior developers, and the team can eliminate stovepipe systems.

Combining your programmers into a single team has some drawbacks. The biggest is likely to be a perceived lack of responsiveness. Although projects will be finished more quickly, customers will no longer have a dedicated programmer to talk to about the status of their projects. The team will only work on one project at a time, so other customers may feel they are being ignored.

To resolve these problems, consider dedicating one programmer to deal with customer requests and minor changes (see Iteration Planning in Chapter 8). You'll also need an influential, unbiased business person to play the product manager role, addressing conflicts between customers and making prioritization decisions.

Prerequisite #6: Use All the Practices

You may be tempted to ignore or remove some practices, particularly the ones that make team members uncomfortable. Be careful of this. XP is designed to have very little waste. Nearly every practice directly contributes to the production of valuable software.

For example, pair programming supports collective code ownership, which is necessary for refactoring. Refactoring allows incremental design and architecture. Incremental design and architecture enables customer-driven planning and frequent releases, which are the key to XP's ability to increase value and deliver successful software.

XP doesn't require perfection—it's okay if you accidentally misapply a practice from time to time—but it rarely works well if you arbitrarily remove pieces.

If Practices Don't Fit...

You may feel that some XP practices aren't appropriate for your organization. That may be true, but it's possible you just feel uncomfortable or unfamiliar with a practice. Are you sure that practice won't work, or do you just not want to do it? XP will work much better for you if you give all of the practices a fair chance rather than picking and choosing the ones you like.

If you're sure a practice won't work, you need to replace it. For example, in order to achieve the benefits of collective code ownership without pair programming, you must provide another way for people to share knowledge about the codebase. (You'll also have to find ways to replace the other benefits of pairing.)

Replacing practices requires continuous refinement and an in-depth understanding of XP. Ask your mentor for help and consider hiring an experienced XP coach.

Recommendation #1: A Brand-New Codebase

Easily-changed code is vital to XP. If your code is cumbersome to change, you'll have difficulty with XP's technical practices, and that difficulty will spill over into XP's planning practices.

XP teams put a lot of effort into keeping their code clean and easy to change. If you have a brand-new codebase, this is easy to do. If you have to work with existing code, you can still practice XP, but it will be more difficult. Even well-maintained code is unlikely to have the simple design and suite of automated unit tests that XP requires (and produces). New XP teams often experience an epiphany between the second and fourth months. "This is the best code I've ever worked with!" they say, and start to see the power of XP.

To understand and appreciate XP's technical practices fully, you need to experience the practices meshing together to give you complete confidence in your code, tests, and build. You need to feel the delight of making big improvements with small changes. You're unlikely to have that experience when working with existing code. If you can, save preexisting code for experienced XP teams.

If You Have Preexisting Code...

You can dig your way out of this hole. See "Applying XP to an Existing Project," later in this chapter.

Recommendation #2: Strong Design Skills

Simple, easily-changed design is XP's core enabler. This means at least one person on the team—preferably a natural leader—needs to have strong design skills.

It's hard to tell if somebody has strong design skills unless you have strong design skills yourself. One clue to look for is an understanding and appreciation of domain-driven design. It requires a crucial shift in thinking—from imperative procedural design to declarative object-oriented design—that programmers with poor design skills can have difficulty grasping.

If No One Has Strong Design Skills...

You'll probably do as well with XP as you would be with any method—perhaps more, because XP includes specific technology practices and advice. However, that doesn't mean you'll be successful. Take it slow and steady, and seek out as much experienced help as you can get.

Meanwhile, start learning! [Evans]' Domain-Driven Design is a good place to start, as is [Fowler 2002a]'s Patterns of Enterprise Application Architecture. Consider taking a course or hiring somebody to join the team as a mentor. Be careful, though—strong design skills, while essential, are surprisingly rare. Ask someone with good design skills to help you vet your choice.

Recommendation #3: A Language That's Easy to Refactor

XP relies on refactoring to continuously improve existing designs, so any language that makes refactoring difficult will make XP difficult. Of the currently popular languages, object-oriented and dynamic languages with garbage collection are the easiest to refactor. C and C++, for example, are more difficult to refactor.

If Your Language Is Hard To Refactor...

You can still use XP, but be sure to include someone on your team who has experience with refactoring in your language, if you can.

Recommendation #4: An Experienced Programmer-Coach

Some people are natural leaders. They're decisive, but appreciate others' views; competent, but respectful of others' abilities. Team members respect and trust them. You can recognize a leader by her influence—regardless of her title, people turn to a leader for advice.

Leadership is independent of title or position. You can identify leaders by their followers, not by their desire to give orders. To identify the real leaders on your team, look for the people that team members want to follow.

XP relies on self-organizing teams. Such a team doesn't have a predefined hierarchy; instead, the team decides for itself who is in charge of what. These roles are usually informal. In fact, in a mature XP team, there is no one leader. Team members seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved.

When your team first forms, though, it won't work together so easily. Somebody will need to help the team remember to follow the XP practices consistently and rigorously. This is particularly important for programmers, who have the most difficult practices to learn.

In other words, your team needs a coach. The best coaches are natural leaders—people who remind others to do the right thing by virtue of who they are rather than the orders they give. Your coach also needs to be an experienced programmer so she can help the team with XP's technical practices.

If You Have No Obvious Coach...

Explain the situation to the team and ask them to choose a coach by consensus. In other words, ask them to pick one person that they can all agree would be a good coach.

In consensus decisions, everyone has a veto. A quick way to perform a consensus vote is to ask everyone to hold their thumbs out. Thumbs up means "I agree". Thumbs sideways means "I'll go with the team's decision." Thumbs down means "I disagree and want to explain why."

If you can't pick a coach by consensus, your team may be too fractured to use XP. If there's someone you can hire that the team would trust, that may help. Be sure to tell whoever you hire that you weren't able to reach consensus on this issue—an experienced XP coach will see it as a danger sign and should speak to team members before accepting.

If Your Leaders are Inexperienced...

Good leaders aren't always experienced developers, but a good coach should look for subtle cues that indicate upcoming problems, which does require experience. An experienced developer is your best coach.

If your leaders are inexperienced, you may want to try pair coaching. Pick one person who's a good leader and one person who has a lot of experience. Make sure they get along well. Ask the two coaches to work together to help the team remember to practice XP consistently and rigorously.

If You're Assigned a Poor Coach...

Your organization may assign somebody to be coach who isn't a good leader. In this case, if the assigned coach recognizes the problem, pair coaching may work for you.

If the assigned coach doesn't recognize the problem and he's damaging the team's ability to function, discuss the situation with your mentor or a manager you trust. This is a delicate situation that requires context-specific advice.

Recommendation #5: A Friendly and Cohesive Team

XP requires that everybody work together to meet team goals. There's no provision for someone to work in isolation, so it's best if team members enjoy working together.

If Your Team Doesn't Get Along...

XP requires people to work together. Combined with the pressure of weekly deliveries, this can help team members learn to trust and respect each other. However, it's possible for a team to implode from the pressure. Try including a team member who is level-headed and has a calming influence.

If team members won't even attempt to work together, don't use XP. If there's just one person whose behavior encourages other people's bad behavior, you might be able to solve the problem by moving him to a different team.

Comments

Categories: Blogs

The Art of Agile Development: Customer Tests

Fri, 08/20/2010 - 10:00

20 Aug 2010 James Shore/Agile-Book

New Information

Although I still fully embrace using the Describe, Demonstrate, Develop process described for this practice, I've found that using tools such as Fit to automate those examples results in unacceptable maintenance burdens. The value is in the collaborative Describe, Demonstrate, Develop process, not the automated tests. I recommend ignoring the final section of this practice, "Automating the Examples." Everything else is still correct.

I describe the reasons for this change of heart in The Problems With Acceptance Testing. In Alternatives to Acceptance Testing, I explain what to do instead.

Full Text

Customer Tests

Audience: Whole Team

We implement tricky domain concepts correctly.

Ally: Ubiquitous Language

Customers have specialized expertise, or domain knowledge, that programmers don't have. Some areas of the application—what programmers call domain rules—require this expertise. You need to make sure that the programmers understand the domain rules well enough to code them properly in the application. Customer tests help customers communicate their expertise.

Ally: Ten-Minute Build

Don't worry; this isn't as complicated as it sounds. Customer tests are really just examples. Your programmers turn them into automated tests, which they then use to check that they've implemented the domain rules correctly. Once the tests are passing, the programmers will include them in their ten-minute build, which will inform the programmers if they ever do anything to break the tests.

To create customer tests, follow the Describe, Demonstrate, Develop process outlined in the next section. Use this process during the iteration in which you develop the corresponding stories.

Describe Customer tests are for communication.

At the beginning of the iteration, look at your stories and decide whether there are any aspects that programmers might misunderstand. You don't need to provide examples for everything. Customer tests are for communication, not for proving that the software works. (See No Bugs in Chapter 7).

For example, if one of your stories is "Allow invoice deleting", you don't need to explain how invoices are deleted. Programmers understand what it means to delete something. However, you might need examples that show when it's okay to delete an invoice, especially if there are complicated rules to ensure that invoices aren't deleted inappropriately.

If you're not sure what the programmers might misunderstand, ask. Be careful, though; when business experts and programmers first sit down to create customer unit tests, both groups are often surprised by the extent of existing misunderstandings.

Once you've identified potential misunderstandings, gather the team at a whiteboard and summarize the story in question. Briefly describe how the story should work and the rules you're going to provide examples for. It's okay to take questions, but don't get stuck on this step.

For example, if you decided to discuss invoice deletion, you might say:

Customer: One of the stories in this iteration is to add support for deleting invoices. In addition to the screen mockups we've given you, we felt some customer tests would be appropriate. Deleting invoices isn't as simple as it appears because we have to maintain an audit trail.

There are a bunch of rules around this issue. I'll get into the details in a moment, but the basic rule is that it's okay to delete invoices that haven't been sent to customers because presumably that kind of invoice was a mistake. Once an invoice has been sent to a customer, it can only be deleted by a manager. Even then, we have to save a copy for auditing purposes.

Programmer: When an invoice hasn't been sent and gets deleted, is it audited?

Customer: No—in that case, it's just deleted. I'll provide some examples in a moment.

Demonstrate

After a brief discussion of the rules, provide concrete examples that illustrate the scenario. Tables are often the most natural way to describe this information, but you don't need to worry about formatting. Just get the examples on the whiteboard.

Customer (continued): As an example, this invoice hasn't been sent to customers, so an Account Rep can delete it.

Sent User Okay to delete N Account Rep Y

In fact, anybody can delete it—CSR's, managers, and admins.

Sent User Okay to delete N CSR Y N Manager Y N Admin Y

But once it's sent, only managers and admins can delete it, and even then it's audited.

Sent User Okay to delete Y Account Rep N Y CSR N Y Manager Audited Y Admin Audited

Also, it's not a simple case of whether something has been "sent" or not. "Sent" actually means one of several conditions. If you've done anything that could have resulted in a customer seeing the invoice, we consider it "sent". Now only a manager or admin can delete it.

Sent User Okay to delete Printed Account Rep N Exported Account Rep N Posted to web Account Rep N Emailed Account Rep N

As you provide examples, be completely specific. It's tempting to create generic examples, such as "this invoice hasn't been sent to customers, so anybody can delete it", but those get confusing quickly and programmers can't automate them. Provide specifics. "This invoice hasn't been sent to customers, so an account rep can delete it." This will require you to create more examples—that's a good thing.

Your discussion probably won't be as smooth and clean as this example. As you discuss business rules, you'll jump back and forth between describing the rules and demonstrating them with examples. You'll probably discover special cases that you hadn't considered. In some cases, you might even discover whole new categories of rules that you need customer tests for.

One particularly effective way to work is to elaborate on a theme. Start by discussing the most basic case and providing a few examples. Next, describe a special case or additional detail and provide a few more examples. Continue in this way, working from simplest to most complicated, until you have described all aspects of the rule.

You don't need to show all possible examples. Remember, the purpose here is to communicate, not to exhaustively test the application. You only need enough examples to show the differences in the rules. A handful of examples per case is usually enough, and sometimes just one or two is sufficient.

Develop

When you've covered enough ground, document your discussion so the programmers can start working on implementing your rules. This is also a good time to evaluate whether the examples are in a format that works well for automated testing. If not, discuss alternatives with the programmers.

Programmer: Okay, I think we understand what's going on here. We'd like to change your third set of examples, though—the ones where you say "Y" for Sent. Our invoices don't have a "Sent" property. We'll calculate that from the other properties you mentioned. Is it okay if we use "Emailed" instead?

Customer: Yeah, that's fine. Anything that sends it works for that example.

Don't formalize your examples too soon. While you're brainstorming, it's often easiest to work on the whiteboard. Wait until you've worked out all the examples around a particular business rule (or part of a business rule) before formalizing it. This will help you focus on the business rule rather than formatting details.

In some cases, you may discover that you have more examples and rules to discuss than you realized. The act of creating specific examples often reveals scenarios you hadn't considered. Testers are particularly good at finding these. If you have a lot of issues to discuss, consider letting some or all of the programmers get started on the examples you have while you figure out the rest of the details.

Don't use customer tests as a substitute for test-driven development.

Ally: Test-Driven Development

Programmers, once you have some examples, you can start implementing the code using normal test-driven development. Don't use the customers' tests as a substitute for writing your own tests. Although it's possible to drive your development with customer tests—in fact, this can feel quite natural and productive—the tests don't provide the fine-grained support that TDD does. Over time, you'll discover holes in your implementation and regression suite. Instead, pick a business rule, implement it with TDD, then confirm that the associated customer tests pass.

Focus on Business Rules

One of the most common mistakes in creating customer tests is describing what happens in the user interface rather than providing examples of business rules. For example, to show that an account rep must not delete a mailed invoice, you might make the mistake of writing this:

Log in as an account rep
Create new invoice
Enter data
Save invoice
Email invoice to customer
Check if invoice can be deleted (should be "no")

What happened to the core idea? It's too hard to see. Compare that to the previous approach:

When an invoice has been emailed, an account rep may not delete it... or, as you might draw it on the whiteboard:

Sent User Okay to delete Emailed Account Rep N

Good examples focus on the essence of your rules. Rather than imagining how those rules might work in the application, just think about what the rules are. If you weren't creating an application at all, how would you describe those rules to a colleague? Talk about things rather than actions. Sometimes it helps to think in terms of a template: "When (scenario X), then (scenario Y)."

It takes a bit of practice to think this way, but the results are worth it. The tests become more compact, easier to maintain, and (when implemented correctly) faster to run.

Ask Customers to Lead Remember the "Customer" in "Customer Tests".

Team members, watch out for a common pitfall in customer testing: no customers! Some teams have programmers and testers do all the work of customer testing, and some teams don't involve their customer at all. In others, a customer is present only as a mute observer. Don't forget the "customer" in "customer tests." The purpose of these activities to bring the customers' knowledge and perspective to the team's work. If programmers or testers take the reins, you've lost that benefit and missed the point.

In some cases, customers may not be willing to take the lead. Programmers and testers may be able to solve this problem by asking the customers for their help. When programmers need domain expertise, they can ask customers to join the team as they discuss examples. One particularly effective technique is to ask for an explanation of a business rule, pretend to be confused, then hand a customer the whiteboard marker and ask him to draw an example on the board.

If customers won't participate in customer testing at all, this may indicate a problem with your relationship with the customers. Ask your mentor (see "Find a Mentor" in Chapter 2) to help you troubleshoot the situation.

Testers' Role

Testers play an important support role in customer testing. Although the customers should lead the effort, they benefit from testers' technical expertise and ability to imagine diverse scenarios. While customers should generate the initial examples, testers should suggest scenarios that customers don't think of.

On the other hand, testers should be careful not to try to cover every possible scenario. The goal of the exercise is to help the team understand the customers' perspective, not to exhaustively test the application.

Automating the Examples

Programmers may use any tool they like to turn the customers' examples into automated tests. Ward Cunningham's Fit (Framework for Integrated Test)1, is specifically designed for this purpose. It allows you to use HTML to mix descriptions and tables, just as in my invoice auditing example, then runs the tables through programmer-created fixtures to execute the tests.

1Available free at http://fit.c2.com/.

See http://fit.c2.com/ or [Mugridge & Cunningham] for details about using Fit. It's available in several languages, including Java, .NET, Python, Perl, and C++.

You may be interested in FitNesse at http://fitnesse.org/, a variant of Fit. FitNesse is a complete IDE for Fit that uses a Wiki for editing and running tests. (Fit is a command-line tool and works with anything that produces tables in HTML.)

Ally: Exploratory Testing

Fit is a great tool for customer tests because it allows customers to review, run, and even expand on their own tests. Although programmers have to write the fixtures, customers can easily add to or modify existing tables to check an idea. Testers can also modify the tests as an aid to exploratory testing. Because the tests are written in HTML, they can use any HTML editor to modify the tests, including Microsoft Word.

Programmers, don't make Fit too complicated. It's a deceptively simple tool. Your fixtures should work like unit tests, focusing on just a few domain objects. For example, the invoice auditing example would use a custom ColumnFixture. Each column in the table corresponds to a variable or method in the fixture. The code is almost trivial (see Example 9-1).

Example 9-1. Example fixture (C#)

  public class InvoiceAuditingFixture : ColumnFixture
  {
      public InvoiceStatus Sent;
      public UserRole User;

      public Permission OkayToDelete() {
          InvoiceAuditer auditer = new InvoiceAuditer(User, InvoiceStatus)
          return auditer.DeletePermission;
      }
  }

Ally: Ubiquitous Language

Using Fit in this way requires a ubiquitous language and good design. A dedicated domain layer with Whole Value objects2 works best. Without it, you may have to write end-to-end tests, with all the challenges that entails. If you have trouble using Fit, talk to your mentor about whether your design needs work.

2See Domain-Driven Design [Evans] for a discussion of domain layers and http://c2.com/ppr/checks.html#1 [Cunningham] for information about Whole Value.

I often see programmers try to make a complete library of generic fixtures so that no one need write another fixture. That misses the point of Fit, which is to segregate customer tests from programmer implementation. If you make generic fixtures, the implementation details will have to go into the tests, which will make them too complicated and obscure the underlying examples.

Most tests can be expressed with a simple ColumnFixture or RowFixture. Questions When do programmers run the customer tests?

Ally: Ten-Minute Build

Once the tests are passing, make them a standard part of your ten-minute build. Like programmers' tests, you should fix them immediately if they ever break.

Should we expand the customer tests when we think of a new scenario?

Ally: Slack

Absolutely! Often, the tests will continue to pass. That's good news; leave the new scenario in place to act as documentation for future readers. If the new test doesn't pass, talk with the programmers about whether they can fix it with iteration slack or whether you need a new story.

What about acceptance testing (also called functional testing)?

Ally: No Bugs

Automated acceptance tests tend to be brittle and slow. I've replaced acceptance tests with customer reviews (see "Customer Reviews" later in this chapter) and a variety of other techniques (see "A Little Lie" in Chapter 3).

Results

Ally: Ubiquitous Language

When you use customer tests well, you reduce the number of mistakes in your domain logic. You discuss domain rules in concrete, unambiguous terms and often discover special cases that you hadn't considered. The examples influence the design of the code and help promote a ubiquitous language. When written well, the customer tests run quickly and require no more maintenance than unit tests do.

Contraindications

Ally: Test-Driven Development

Don't use customer tests as a substitute for test-driven development. Customer tests are a tool to help communicate challenging business rules, not a comprehensive automated testing tool. In particular, Fit doesn't work well as a test scripting tool—it doesn't have variables, loops, or subroutines. (Some people have attempted to add these things to Fit, but it's not pretty.) Real programming tools, such as xUnit or Watir, are better for test scripting.

Allies: Whole Team; Sit Together

In addition, customer tests require domain experts. The real value of the process is the conversation that explores and exposes the customers' business requirements and domain knowledge. If your customers are unavailable, those conversations won't happen.

Finally, because Fit tests are written in HTML, Fit carries more of a maintenance burden than xUnit frameworks do. Automated refactorings won't extend to your Fit tests. To keep your maintenance costs down, avoiding creating customer tests for every business rule. Focus on the tests that will help improve programmer understanding, and avoid further maintenance costs by refactoring your customer tests regularly. Similar stories will have similar tests: consolidate your tests whenever you have the opportunity.

Alternatives

Some teams have testers, not customers, write customer tests. Although this introduces another barrier between the customers' knowledge and the programmers' code, I have seen it succeed. It may be your best choice when customers aren't readily available.

Customer tests don't have to use Fit or FitNesse. Theoretically, you can write them in any testing tool, including xUnit, although I haven't seen anybody do this.

Agile Friday: "Customer Tests" Now Online

Fri, 08/20/2010 - 10:00

20 Aug 2010 James Shore/Blog

Controversy! After writing the Customer Tests section of The Art of Agile Development, I had a change of heart. I used to be a major advocate for customer testing--what people are now calling "Acceptance Test-Driven Development," or ATDD. In fact, I was the project coordinator for Ward Cunningham's Fit, the first major customer testing tool. But I no longer use or recommend it.

Why not? I explain the details in my Problems With Acceptance Testing blog entry, but the short-short version is that automated customer tests just don't work well over the long term. In the short term they're great. In the long-term, the tests become a major maintenance burden, and the tools tend to get in the way of customer collaboration rather than enhance it.

Luckily, I'm not a complete idiot. (Or Shane isn't. Hmm.) What we wrote in the book is still accurate, even though we wrote it before my change of heart. Shane and I actually highlight the problems in the "Contraindications" subsection. If I could do it over again, though, I'd call this practice "Customer Examples" rather than "Customer Tests." I'd focus on communication even more. I'd come up with some better examples. And I'd leave out the "Automating the Examples" subsection. But what we have in the book, other than the automation subsection, is still good advice.

Next week, I'm planning to post Is XP Right For Us? from Chapter 3. All of the practices we recommend so confidently in the rest of the book rely on an important set of assumptions that are described in that section. I figured it would be useful to put those assumptions online now that so much of the rest of the book is up. If you'd prefer something else, make your case in the comments, as usual.

See you next week!

Comments

Categories: Blogs

Agile Friday: "Stories" Now Online

Fri, 08/06/2010 - 10:00

06 Aug 2010 James Shore/Blog

I've uploaded Stories, which is this week's excerpt from The Art of Agile Development. Due to time constraints, I haven't incorporated the copyedits yet. If it seems a bit rough, that's why. Thanks once again to Sarah Schneider at O'Reilly for copyediting our book and making a million tiny improvements. You don't notice them until they're gone, which tells you what a good job Sarah did.

I'm going to be at Agile 2010 next week, presenting an awesome session with Arlo Belshee titled "Bloody Stupid Johnson Teaches Agile." It's a parody of all things Agile, and we're having tons of fun with it. If you're going to be at the conference, I hope you'll attend and help heckle. (We'll need hecklers.)

The poll for next week's excerpt will be cut short thanks to my trip, so get your votes in early. Here are your choices, from the Developing chapter:

Comments

Categories: Blogs

The Art of Agile Development: Stories

Fri, 08/06/2010 - 10:00

06 Aug 2010 James Shore/Agile-Book

Next: Estimating
Previous: Slack
Up: Chapter 8: Planning

Stories

Audience: Whole Team

We plan our work in small, customer-centric pieces.

Stories are not requirements.

Stories may be the most misunderstood entity in all of XP. They're not requirements. They're not use cases. They're not even narratives. They're much simpler than that.

Ally: Release Planning

Stories are for planning. They're simple, one-or-two line descriptions of work the team should produce. Alistair Cockburn calls them "promissory notes for future conversation"1. Everything that stakeholders want the team to produce should have a story:

1http://c2.com/cgi/wiki?UserStory, accessed 30 May 2007.

"Warehouse inventory report"
"Full-screen demo option for job fair"
"TPS report for upcoming investor dog-and-pony show"
"Customizable corporate branding on user login screen"

Some people find that using a template helps them write good stories. For example, [Cohn] recommends using the template "As a (role) I want to (goal) so that (reason)".

Ally: Incremental Requirements

This isn't enough detail for the team to implement and release working software, nor is that the intent of stories. A story is a placeholder for a detailed discussion about requirements. Customers are responsible for having the requirements details available when the rest of the team needs them.

Although stories are short, they still have two important characteristics.

Stories represent customer value and are written in the customers' terminology. (The best stories are actually written by customers.) They describe an end-result that the customer values, not implementation details.
Stories have clear completion criteria. Customers can describe an objective test that would allow programmers to tell when they've successfully implemented the story.

The following examples are not stories:

"Automate integration build" does not represent customer value.
"Deploy to staging server outside of the firewall" describes implementation details rather than an end-result, and it doesn't use customer terminology. "Provide demo that customer review board can use" would be better.
"Improve performance" has no clear completion criteria. Similarly, "Make it fast enough for my boss to be happy" lacks objective completion criteria. "Searches complete within one second" is better.

Story Cards

Write stories on index cards.

I prefer 3x5-inch cards because they fit into my pocket.

This isn't the result of some strange Ludditian urge on the part of XP's creators; it's a deliberate choice based on the strengths of the medium. You see, physical cards have one feature that no conglomeration of pixels has: they're tactile. You can pick them up and move them around. This gives them power.

Ally: Release Planning

During release planning, customers and stakeholders gather around a big table to select stories for the next release. It's a difficult process of balancing competing desires. Index cards help prevent these disputes by visually showing priorities, making the scope of the work more clear, and directing conflicts towards the plan rather than personalities.

Ally: Informative Workspace

Story cards also form an essential part of an informative workspace. After the planning meeting, move the cards to the release planning board—a big, six-foot whiteboard, placed prominently in the team's open workspace (see Figure). You can post hundreds of cards and still see them all clearly. For each iteration, place the story cards to finish during the iteration on the iteration planning board—another big whiteboard; see Figure—and move them around to indicate your status and progress. Both of these boards are clearly visible throughout the team room and constantly broadcast information to the team.

Use index cards to be more responsive to stakeholder suggestions.

Index cards also help you be responsive to stakeholders. When you talk with a stakeholder and she has a suggestion, invite her to write it down on a blank index card. I always carry cards with me for precisely this purpose. Afterwards, take the stakeholder and her card to the product manager. They can walk over to the release planning board and discuss the story's place in the overall vision. Again, physical cards focus the discussion on relative priorities rather than contentious "approved / disapproved" decisions.

Ally: Estimating

If the product manager and stakeholder decide to add the story to the release plan, they can take it to the programmers right away. A brief discussion allows the programmers to estimate the story. Developers write their estimate—and possibly a few notes—on the card, and then the stakeholder and product manager place the card into the release plan.

Index cards are simpler and more effective than computerized tools.

Physical index cards enable these ways of working in a very easy and natural way that's surprisingly difficult to replicate with computerized tools. Although you can use software, index cards just work better: they're easier to set up and manipulate, make it easier to see trends and the big picture, and allow you to change your process with no configuration or programming.

Most people are skeptical about the value of index cards at first, so if you feel that way, you're not alone. The best way to evaluate the value of physical story cards is to try them for a few months, then decide whether to keep them.

Customer-Centricity

Ally: The Planning Game

Stories need to be customer-centric. Write them from the on-site customers' point of view and make sure that they provide something that customers care about. On-site customers are in charge of priorities in the planning game, so if a story has no customer value, your customers won't—and shouldn't—include it in the plan.

A good way to ensure that your stories are customer-centric is to ask your customers to write the stories themselves.

One practical result of customer-centric stories is that you won't have stories for technical issues. There should be no "Create a build script" story, for example—customers wouldn't know how to prioritize it. Although programmers can tell customers where the technical stories belong in the plan, that disrupts the balance of power over the scope of the project and can leave customers feeling disenfranchised.

Instead, include any technical considerations in the estimate for each story. If a story requires that the programmers create or update a build script, for example, include that cost when estimating for that story.

Ally: Incremental Design And Architecture

Including technical costs in stories, rather than having dedicated technical stories, requires incremental design and architecture.

Customer-centric stories aren't necessarily always valuable to the end-user, but they should always be valuable to the on-site customers. For example, a story to produce a trade-show demo doesn't help end-users, but it helps the customers sell the product.

Splitting and Combining Stories

Stories can start at any size, but it is difficult to estimate stories that are too large or too small. Split large stories; combine small ones.

Select story sizes such that you complete four to ten each iteration.

The right size for a story depends on your velocity. You should be able to complete four to ten stories in each iteration. Split and combine stories to reach this goal. For example, a team with a velocity of ten days per iteration might split stories with estimates of more than two days, and combine stories that are less than half a day.

Combining stories is easy. Take several similar stories, staple their cards together, and write your new estimate on the front.

Splitting stories is more difficult, because it tempts you away from vertical stripes and releasable stories. It's easiest to just create a new story for each step in the previous story. Unfortunately, this approach leads to story clumps. Instead, consider the essence of the story. Peel away all of the other issues and write them as new stories. [Cohn] has an excellent chapter on how to do this in his book Agile Estimating and Planning. He summarizes various options for splitting stories:

Split large stories along the boundaries of the data supported by the story.
Split large stories based on the operations that are performed within the story.
Split large stories into separate CRUD [Create, Read, Update, Delete] operations.
Consider removing cross-cutting concerns (such as security, logging, error handling, and so on) and creating two versions of the story: one with and one without support for the cross-cutting concern.
Consider splitting a large story by separating the functional and nonfunctional [performance, stability, scalability, and so forth] aspects into separate stories.
Separate a large story into smaller stories if the smaller stories have different priorities.

Special Stories

Most stories will add new capabilities to your software, but any action that requires the team's time but is not a part of normal work needs a story.

Documentation Stories

Ally: Documentation

XP teams need very little documentation to do their work (see Documentation), but you may need the team to produce documentation for other reasons. Create documentation stories just like any other: make them customer-centric and make sure you can identify specific completion criteria. An example of a documentation story is "Produce user manual".

"Non-Functional" Stories

Ally: Performance Optimization

Performance, scalability, and stability—so-called non-functional requirements—should be scheduled with stories too. Be sure that these stories have precise completion criteria. See Performance Optimization for more.

Bug Stories

Allies: No Bugs; "Done Done"

Ideally, your team will fix bugs as soon as they find them, before declaring a story as "done done". Nobody's perfect, though, and you will miss some bugs. Schedule these bugs with story cards: "Fix multiple-user editing bug". Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

Bug stories can be difficult to estimate. Often, the biggest timesink in debugging is figuring out what's wrong, and you usually can't estimate how long that will take. Instead, provide a time-boxed estimate. "We'll spend up to a day investigating this bug. If we haven't fixed it by then, we'll schedule another story."

Spike Stories

Ally: Spike Solutions

Sometimes programmers won't be able to estimate a story because they don't know enough about the technology required to implement the story. In this case, create a story to research that technology. An example of a research story is "Figure out how to estimate 'Send HTML' story". Programmers will often use a spike solution (see Spike Solutions) to research the technology, so these sorts of stories are often called spike stories.

Word these stories in terms of the goal, not the research that needs to be done. When programmers work on a research story, they only need to do enough work to make their estimate for the real story. They shouldn't try to figure out all of the details or solve the entire problem.

Programmers can usually estimate how long it will take to research a technology even if they don't know the technology in question. If they can't even estimate how long the research will take, timebox the story as you do with bug stories. I find that a day is plenty of time for most spike stories, and half a day is sufficient for most.

Estimating

Other than spike stories, you normally don't need to schedule time for the programmers to estimate stories—you can just ask them for an estimate at any time. It's part of the overhead of the iteration, as are support requests and other unscheduled interruptions. If your programmers feel that estimating is too much of an interruption, try putting new story cards in a pile for the programmers to estimate when it's convenient.

Sometimes you'll have a large number of new stories to estimate. In this case, it might be worth creating a story card for estimating those stories.

Meetings

Like estimating, most meetings are part of the normal overhead of the iteration. If you have an unusual time commitment, such as training or an day-long off-site, you can reserve time for it with a story.

Architecture, Design, Refactoring, and Technical Infrastructure

Ally: Incremental Design And Architecture

Don't create stories for technical details. Technical tasks are part of the cost of implementing stories and should be part of the estimates. Use incremental design and architecture to break large technical requirements into small pieces that you can implement incrementally.

Questions Are index cards really more effective than computerized tools? What about reporting?

See our discussion of reporting (Reporting) for more information.

What about backups? Won't the cards get lost?

If you exercise reasonable care, you're unlikely to lose cards. The only time I've seen a team lose their cards was when they created them and then left them in an ignored pile somewhere on their boss's desk for six months.

That said, there's always the possibility of fire or other disaster. If the risk of losing cards is too great for you, consider taking a digital photo of the release planning board every week or so. An eight megapixel camera has sufficient resolution to capture a six-foot whiteboard and all of the detail on the cards.

Why do you recommend sizing stories so that we can complete four to ten stories per iteration?

If you only have a few stories in an iteration, it's harder to see that you're making progress, which increases the risk that you won't see problems in time to correct them. In addition, if something goes wrong and you can't finish a story, it will represent a large percentage of your work. Too many stories, on the other hand, increases your planning and estimating burden. Each story becomes smaller, making it harder to see the big picture.

An average of six stories per iteration leads to a three-month release plan (the maximum I recommend) consisting of 78 stories. That's a nice number. It gives you flexibility in planning without overwhelming you with details.

Our customers understand programming. Can we create programmer-centric technical stories?

It's much more difficult to create customer-centric stories than programmer-centric stories, so it's tempting to find excuses for avoiding them. "Our customers don't mind if we have programmer-centric stories" is one such excuse. Try to avoid it.

Even if your customers really do have the ability to prioritize programmer-centric stories, customer-centric stories lead to better plans. Remember, your goal is to create stories that allow you to release the software at any time. Programmer-centric stories usually don't have that property.

If your customers are programmers—if you're writing software for programmers, such as a library or framework—then your stories should use a programmer-centric language (see Ubiquitous Language). Even so, they should reflect your customers' perspective. Create stories about your customers' needs, not your plans to fulfill their needs.

How can we encourage stakeholders to use stories for requesting features?

When a stakeholder asks you for a feature, take out an index card and invite him to write it down so it can be scheduled. For electronic requests, a customer should follow up, either by speaking to the requester in person or creating the story card himself.

If stakeholders refuse to use stories, the product manager can manage this relationship by providing stakeholders with what they want to see and translating stakeholders wishes into stories for the team.

Results

When you use stories well, the on-site customers understand all of the work that they approve and schedule. You work on small, manageable, and independent pieces and can deliver complete features frequently. The project always represents the best possible value to the customer at any point in time.

Contraindications

Stories are no replacement for requirements. You need another way of getting details, whether through expert customers on-site (the XP way) or a requirements document (the traditional way).

Ally: Incremental Design And Architecture

Be very cautious of using customer-centric stories without also using most of the XP development practices. Customer-centric stories depend on the ability to implement infrastructure incrementally with incremental design and architecture. Without this ability, you're likely to incur greater technical debt.

Ally: Sit Together

Physical index cards are only appropriate if the team sits together, or at least has a common area in which they congregate. Experienced distributed teams often keep physical index cards at the main site and copy the cards into the electronic system. This is an administrative headache, but for these teams, the benefits of physical cards make the added work worthwhile.

Some organizations are skittish about using informal planning tools. If important members of your organization require a formal Gantt chart, you may need to provide it. Your project manager can help you make this decision. As with a distributed team, you may find it valuable to use physical cards as well, then duplicate the information into the tool.

Alternatives

For teams that don't use stories, the main distinction between stories and the line items in most plans is that stories are customer-centric. If you can't use customer-centric stories for some reason, customers cannot participate effectively in the planning game. This will eliminate one of its primary benefits: the ability to create better plans by blending information from both customers and programmers. Unfortunately, no alternative practice will help.

Another distinctive feature of stories is the use of index cards. Physical cards offer many benefits over electronic tools, but you can still use an electronic tool if necessary. Some teams track their stories using spreadsheets and others use dedicated agile planning tools. None of these approaches, however, provide the benefits of physical index cards.

The Art of Agile Development: Ten-Minute Build

Fri, 07/30/2010 - 10:00

30 Jul 2010 James Shore/Agile-Book

in 99 words

Build, test, and deploy your entire product at any time with the push of a button.

Your build should be comprehensive but not complex. Make it compile source code, run tests, configure registry settings, initialize database schemas, set up web servers, launch processes, build installers, and deploy. Your IDE won't do all this, so learn to use a dedicated build tool. Make sure your build works when disconnected from the network, too.

Builds should be fast. If not, look at your tests. End-to-end integration tests are the typical culprit. Replace them with faster, more maintainable unit tests.

as haiku

--> Commentary

Living in the Punch Card Era

Full Text

Ten-Minute Build

Audience: Programmers

We eliminate build and configuration hassles.

Here's an ideal to strive for. Imagine that you've just hired a new programmer. On the programmer's first day, you walk him over to the shiny new computer you just added to your open workspace.

"We've found that keeping everything in version control and having a really great automated build makes us a lot faster," you say. "Here, I'll show you. This computer is new, so it doesn't have any of our stuff on it yet."

You sit down together. "Okay, go ahead and check out the source tree." You walk him through the process and the source tree starts downloading. "This will take a while because we have all of our build tools and libraries in version control, too," you say. "Don't worry—like any good version control system, it brings down changes, so it's only slow the first time. We keep tools and libraries in version control because it allows us to update them easily. Come on, let me show you around the office while it downloads."

After giving him the tour, you come back. "Good, it's finished," you say. "Now, watch this—this is my favorite part. Go to the root of the source tree and type build."

The new programmer complies, then watches as build information flies by. "It's not just building the source code," you explain. "We have a complex application that requires a web server, multiple web services, and several databases. In the past, when we hired a new programmer, he would spend his first couple of weeks just configuring his workstation. Test environments were even worse. We used to idle the whole team for days while we wrestled with problems in the test environment. Even when the environment worked, we all had to share one environment and we couldn't run tests at the same time.

"All that has changed. We've automated all of our setup. Anybody can build and run all of the tests on their own machine, any time they want. I could even disconnect from the network right now and it would keep building. The build script is doing everything: it's configuring a local web server, initializing a local database... everything.

"Ah! It's almost done. It's built the app and configured the services. Now it's running the tests. This part used to be really slow, but we've made it much faster lately by improving our unit tests so we could get rid of our end-to-end tests."

Suddenly, everything stops. The cursor blinks quietly. At the bottom of the console is a message: BUILD SUCCESSFUL.

"That's it," you say proudly. "Everything works. I have so much confidence in our build and tests that I could take this and install it on our production servers today. In fact, we could do that right now, if we wanted to, just by giving our build a different command.

"You're going to enjoy working here." You give the new programmer a friendly smile. "It used to be hell getting even the simplest things done. Now, it's like butter. Everything just works."

Automate Your Build

What if you could build and test your entire product—or create a deployment package—at any time, just by pushing a button? How much easier would that make your life?

Producing a build is often a frustrating and lengthy experience. This frustration can spill over to the rest of your work. "Can we release the software?" "With a few days of work." "Does the software work?" "My piece does, but I can't build everything." "Is the demo ready?" "We ran into a problem with the build—tell everyone to come back in an hour."

Automating your build is one of the easiest ways to improve morale and increase productivity.

Sadly, build automation is easy to overlook in the rush to finish features. If you don't have an automated build, start working on one now. It's one of the easiest things you can do to make your life better.

How to Automate

There are plenty of useful build tools available, depending on your platform and choice of language. If you're using Java, take a look at Ant. In .NET, NAnt and MSBuild are popular. Make is the old standby for C and C++. Perl, Python, and Ruby each have their preferred build tools as well.

Your build should be comprehensive but not complex. In addition to compiling your source code and running tests, it should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention. Once you get the basics working, add the ability to create a production release, either by creating an install file or actually deploying to servers.

Construct your build so that it provides a single, unambiguous result: SUCCESS or FAILURE. You will run the build dozens of times per day. Manual checks are slow, error-prone, and—after the umpteenth time—seriously annoying.

You should be able to build even when disconnected from the network.

A key component of a successful automated build is the local build. A local build will allow you to build and test at any time without worrying about other people's activities. You'll do this every few minutes in XP, so independence is important. It will also make your builds run faster.

Be cautious of IDEs and other tools that promise to manage your build automatically. Their capability often begins and ends with compiling source code. Instead, take control of your build script. Take the time to understand exactly how and why it works and when to change it. Rather than starting with a pre-made template, you might be better off creating a completely new script. You'll learn more, and you'll be able to eliminate the complexity a generic script adds.

The details are up to you. In my build scripts, I prefer to have all auto-generated content go into a single directory called build/. The output of each major step (such as compiling source code, running tests, collating files into a release, or building a release package) goes into a separate directory under build/. This structure allows me to inspect the results of the build process and—if anything goes wrong—wipe the slate clean and start over.

When to Automate

At the start of the project, in the very first iteration, set up a bare-bones build system. The goal of this first iteration is to produce the simplest possible product that exercises your entire system. That includes delivering a working—if minimal—product to stakeholders.

Use the build script to configure the integration machine. Don't configure it manually.

Because the product is so small and simple at this stage, creating a high-quality automated build is easy. Don't try to cover all of the possible build scenarios you need in the future. Just make sure that you can build, test, and deploy this one simple product—even if it does little more than "Hello, world!" At this stage, deployment might be as simple as creating a .zip file.

Ally: Continuous Integration

Once you have the seed of your build script, it's easy to improve. Every iteration, as you add features that require more out of your build, improve your script. Use your build script every time you integrate. To make sure it stays up-to-date, never configure the integration machine manually. If you find that something needs configuration, modify the build script to configure it for you.

Automating Legacy Projects

If you want to add a build script to an existing system, I have good news and bad news. The good news is that creating a comprehensive build script is one of the easiest ways to improve your life. The bad news is that you probably have a bunch of technical debt to pay off, so it won't happen overnight.

As with any agile plan, the best approach is to work in small stages that provide value as soon as possible. If you have a particularly complex system with lots of components, work on one component at a time, starting with the one that's most error-prone or frustrating to build manually.

Once you've picked the right component to automate, start by getting it to compile. That's usually an easy step, and it allows you to make progress right away.

Next, add the ability to run unit tests and make sure they pass. You probably compile and run unit tests in your IDE already, so this may not seem like a big improvement. Stick with it; making your build script able to prove itself is an important step. You won't have to check the results manually any more.

Your next step depends on what's causing you the most grief. What is the most annoying thing about your current build process? What configuration issue springs up to waste a few hours every week? Automate that. Repeat with the next-biggest annoyance until you have automated everything. Once you've finished this, congratulations! You've eliminated all of your build annoyances. You're ahead of most teams: you have a good build script.

Now it's time to make a great build script. Take a look at how you deploy. Do you create a release package such as an installer, or do you deploy directly to the production servers? Either way, start automating the biggest annoyances in your deployment process, one at a time. As before, repeat with the next-biggest annoyance until you run out of nits to pick.

This won't happen overnight, but try to make progress every week. If you can solve one annoyance every week, no matter how small, you'll see noticeable improvement within a month. As you work on other things, try not to add new debt. Include all new work in the build script from the beginning.

Ten Minutes or Less

A great build script puts your team way ahead of most software teams. After you get over the rush of being able to build the whole system any time you want, you'll probably notice something new: the build is slow.

With continuous integration, you integrate every few hours. Each integration involves two builds: one on your machine and one on the integration machine. You need to wait for both builds to finish before continuing on because you can never let the build break in XP. If the build breaks, you have to roll back your changes.

A ten-minute build leads to a twenty-minute integration cycle. That's a pretty long delay. I prefer a ten or fifteen-minute integration cycle. That's about the right amount of time to stretch my legs, get some coffee, and talk over our work with my pairing partner.

The easiest way to keep the build under five minutes (with a ten-minute maximum) is to keep the build times down from the beginning. One team I worked with started to look for ways to speed up the build whenever it exceeded 100 seconds.

Many new XP teams make the mistake of letting their build get too long. If you're in that boat, don't worry. You can fix long build times in the same agile way you fix all technical debt: piece by piece, focusing on making useful progress at each step.

Slow tests are the most common cause of slow builds.

For most teams, their tests are the source of a slow build. Usually it's because their tests aren't focused enough. Look for common problems: are you writing end-to-end tests when you should be writing unit tests and integration tests? Do your unit tests talk to a database, network, or file system?

Ally: Test-Driven Development

You should be able to run about 100 unit tests per second. Unit tests should comprise the majority of your tests. A fraction (less than ten percent) should be integration tests, which check that two components synchronize properly. When the rest of your tests provide good coverage, only a handful—if any—need to be end-to-end tests. See Test-Driven Development in Chapter 9 for more information.

Although tests are the most common cause of slow builds, if compilation speed becomes a problem, consider optimizing code layout or using a compilation cache or incremental compilation. You could also use a distributed compilation system or take the best machine available for use as the build master. Don't forget to take advantage of the dependency evaluation features of your build tool: you don't need to rebuild things that haven't changed.

In the worst-case scenario, you may need to split your build into a "fast" build that you run frequently and a "slow" build that an integration server runs when you check in (see Continuous Integration later in this chapter). Be careful—this approach leads to more build failures than a single, fast build. Keep working on making your build faster.

Questions Who's responsible for maintaining the build script?

Ally: Collective Code Ownership

All of the programmers are responsible for maintaining the script. As the codebase evolves, the build script should evolve with it.

At first, one person will probably be more knowledgeable about the script than others. When you need to update the script, pair with this person and learn all you can.

The build script is the center of your project automation universe. The more you know about how to automate your builds, the easier your life will become and the faster you'll be able to get work done.

We have a configuration management (CM) department that's responsible for maintaining our builds. We aren't allowed to modify the script ourselves. What do we do?

You need to be able to update your scripts continuously to meet your specific needs. It's unlikely that anybody can be more responsive to your needs than you are. If the CM department is a bottleneck, ask your project manager for help. He may be able to give you control over the scripts.

Alternatively, you might be able to use a two-stage build in which you run your own scripts privately before handing control over to the CM department.

How do we find time to improve our build?

Ally: Slack

Improving your build directly improves your productivity and quality of life. It's important enough to include in every iteration as part of your everyday work. The best way to do this is to include enough slack in your iteration for taking care of technical debt such as slow builds. If a particular story will require changes to the build script, include that time in your story estimate.

Should we really keep all of our tools and libraries in version control?

Yes, as much as possible. See Version Control earlier in this chapter for details.

Does the build have to be under ten minutes? We're at eleven.

Ten minutes is a good rule of thumb. Your build is too long when pairs move on to other tasks before the integration cycle completes.

We use an IDE with an integrated build system. How can we automate our build process?

Many IDEs use an underlying build script that you can control. If not, you may be better off using a different IDE. Your other alternative is to have a separate command line-based build system, such as Ant, NAnt, or make. You risk duplicating information about dependencies, but sometimes that cost is worthwhile.

We have different target and development environments. How do we make this build work?

If possible, use a cross compiler. If that doesn't work, consider using a cross-platform build tool. The benefits of testing the build on your development platform outweigh the initial work in creating a portable system.

How can we build our entire product when we rely on third-party software and hardware?

Even if your product relies on yet-to-be-built custom hardware or unavailable third-party systems, you still need to build and test your part of the product. If you don't, you'll discover a ton of integration and bug-fixing work when the system becomes available.

A common solution for this scenario is to build a simulator for the missing system, which allows you to build integration tests. When the missing system becomes available, the integration tests help you determine if the assumptions you built into the simulator were correct.

Missing components add risk to your project, so try to get your hands on a test system as soon as possible.

How often should we build from scratch?

At least once per iteration. Building from scratch is often much slower than an incremental build, so it depends on how fast the build is and how good your build system is. If you don't trust your build system, build from scratch more often. You can set up a smoke-testing system that builds the project from scratch on every check-in.

My preference is to reduce build times so that incremental builds are unnecessary, or to fix the bugs in the build system so I trust the incremental builds. Even so, I prefer to build from scratch before delivering to customers.

Results

With a good automated build, you can build a release any time you want. When somebody new joins the team, or when you need to wipe a workstation and start fresh, it's a simple matter of downloading the latest code from the repository and running the build.

When your build is fast and well-automated, you build and test the whole system more frequently. You catch bugs earlier and, as a result, spend less time debugging. You integrate your software frequently without relying on complex background build systems, which reduces integration problems.

Contraindications

Every project should have a good automated build. Even if you have a system that's difficult to build, you can start chipping away at the problem today.

Some projects are too large for the ten-minute rule to be effective. Before you assume that this is true for your project, take a close look at your build procedures. You can often reduce the build time much more than you realize.

Alternatives

If the project truly is too large to build in ten minutes, it's probably under development by multiple teams or sub-teams. Consider splitting the project into independent pieces that you can build and test separately.

If you can't build your system in less than ten minutes (yet), establish a maximum acceptable threshhold and stick to it. Drawing this line helps identify a point beyond which you will not allow more technical debt to accumulate. Like a sink full of dishes two hours before a dinner party, the time limit is a good impetus to do some cleaning.

Comments

Categories: Blogs

Agile Friday: "Ten-Minute Build" Now Online

Fri, 07/30/2010 - 10:00

30 Jul 2010 James Shore/Blog

This week's excerpt from The Art of Agile Development is Ten-Minute Build.

These days, my favorite build tool is Rake. I like to create multiple batch files or shell scripts for running Rake: dev, for building and testing on the local machine; repo, for manipulating the version control repository; and deploy, for shipping iteration and production releases. Each script gets its own Rake file, and then I take advantage of Rake's Ruby underpinnings to put code common to the various rakefiles in shared Ruby classes.

Next week's excerpt: something from the Planning chapter. Voting is back to normal this week, so please speak up for your choice in the comments. Here are your choices:

Comments

Categories: Blogs