Agile Zone is brought to you in partnership with:

James is a consultant, author, and speaker. He brings a rare combination of business savvy, deep technical understanding, and an engaging presentation style to his work, putting him in demand around the world. James is a prominent figure in the Agile community: he is an inaugural recipient of the prestigious Gordon Pask Award for Contributions to Agile Practice and one of the first ten people to sign the newly-released Agile Manifesto in 2001. James keeps a blog at jamesshore.com and is co-author of The Art of Agile Development. James is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. View Full User Profile

The Art of Agile Development: Releasing

03.12.2010
| 1410 views |
  • submit to reddit

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden (O'Reilly 2007). Copyright © 2008 James Shore and chromatic. All rights reserved.

Releasing

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

1The Agile Manifesto

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 six practices that give you leverage to turn your big release push into a ten-minute tap.

"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,2 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?



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

 

References
Published at DZone with permission of James Shore, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)