• Next: "Done Done"
• Previous: Reporting
• Up: Table of Contents

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Releasing

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

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

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

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

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

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

• "Done Done" ensures that completed work is ready to release.

• No Bugs allows you to release your software without a separate testing phase.

• Version Control allows team members to work together without stepping on each others' toes.

• A Ten-Minute Build builds a tested release package in under ten minutes.

• Continuous Integration prevents a long, risky integration phase.

• Collective Code Ownership allows the team to solve problems no matter where they may lie.

• Post-hoc Documentation decreases the cost of documentation and increases its accuracy.

"Releasing" Mini-Etude

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

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

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

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

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

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

Figure. A sample card.

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

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

Consider these discussion questions:

• At which step does work pile up?

• Which results surprise you?

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

• Are there green cards with ideas you can adopt now?

Figure. A sample value stream map.

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

• Next: "Done Done"
• Previous: Reporting
• Up: Table of Contents