• Next: Vision
• Previous: Documentation
• 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.

Planning

Today I talked to a friend who wanted to know how I organized software projects. His team has grown rapidly, and their attempts to create and manage detailed plans are spiraling out of control. "It just doesn't scale," he sighed.

The larger your project becomes, the harder it is to plan everything in advance. The more chaotic your environment, the more likely it is that your plans will be thrown off by some unexpected event. Yet in this chaos lies opportunity.

Rather than try to plan for every eventuality, embrace the possibilities that change brings you. This attitude is very different from facing change with clenched jaws and white knuckles. In this state of mind, we welcome surprise. We marvel at all of the power we have to identify and take advantage of new opportunities. The open horizon stretches before us. We know in which direction we need to travel, and we have the flexibility in our plan to choose the best way to get there. We'll know it when we find it.

This approach may sound like it's out of control. It would be, except for eight practices that allow you to control the chaos of endless possibility.

• Vision reveals where the project is going and why it's going there.

• Release Planning provides a roadmap for reaching your destination.

• The Planning Game combines the expertise of the whole team to create achievable plans.

• Risk Management allows the team to make and meet long-term commitments.

• Iteration Planning provides structure to the team's daily activities.

• Slack allows the team to reliably deliver results every iteration.

• Stories form the line items in the team's plan.

• Estimating enables the team to predict how long their work will take.

"Planning" Mini-Etude

The purpose of this étude is to discuss the effect of change on value. If you're new to agile development, you may use it to better understand the purpose of your project and how each story adds value. If you're an experienced agile practitioner, review Chapter 14 and use this étude to help you adapt your plans.

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 three different colors of index cards, an empty table or whiteboard, and writing implements.

Step 1. Start by forming pairs. Try for heterogenous pairs.

Step 2. (Timebox this step to five minutes.) Within your pair, choose an unimplemented story and discuss why it's valuable to the customer. Write the primary reason on an index card.

Step 3. (Timebox this step to five minutes.) Within your pair, brainstorm ideas that would provide even more value, whether by changing the existing story or creating a new story. Write one idea on an index card of a different color.

Step 4. (Timebox this step to five minutes.) Still within in your pair. Devise an experiment that would prove whether your new idea would work in practice—without actually trying the idea itself. What can you do to test the concept behind your idea? Write the test on an index card of a third color.

Step 5. (Timebox this step to fifteen minutes.) Return to the group. Choose three pairs. Give each pair five minutes to lead a discussion of their findings. Post the resulting cards prominently for as long as you perform this étude.

Discussion questions may include:

• What types of value are there in the cards?

• What would be hard to do? What would be easy?

• How well does your work reflect the potential value of the project?

• Which concrete experiments should you conduct in the next iteration?

• Next: Vision
• Previous: Documentation
• Up: Table of Contents