Chapter 6. Iteration 0: Preparing for the First Iteration

“People only see what they are prepared to see.”  —Ralph Waldo Emerson

“There are no secrets to success. It is the result of preparation, hard work, and learning from failure.”  —Colin Powell

Getting Ready for Iteration 1

A common cause of project failure is beginning without properly setting up for success. While Waterfall projects tended to spend too much effort on setting up, in Agile and Scrum projects many failures have occurred from not doing enough. Better is a middle ground—just enough to start up the project effectively so that it will develop and deliver incrementally, but not so much that we get overburdened before we even begin.

Start with the question, “What do the team and the organization each need to do to prepare for the first iteration?” That is, what is required so that we can begin building value in the first iteration?

This question is the basis for the rest of this chapter. To answer it, we need to consider four general areas, as shown in Table 6.1.

Table 6.1 Focus Areas for Iteration 0

The time required to complete Iteration 0 (also known as Sprint 0) will vary; it depends on the needs of the team and the product. Typically it takes one week for each three months of scheduled project-time. The team should time-box each week of Iteration 0 to ensure they don’t spend more time than necessary.

Set Up the Product

In order to drive software delivery from business value, the team needs a product champion who can clearly describe the vision of the undertaking and make it visible to the team. The product champion needs to be able to speak for the customer and the stakeholders. She answers the question, “Why are we here?” and establishes line of sight between the team and the business requirements.

For the team, line of sight ensures they understand the highest priority—for the day, the iteration, the release, and the product vision. Transparency and visual controls need to be established that create visibility of all work underway. Visual controls provide a powerful mechanism for keeping the development team tightly coupled to, and aware of, the product backlog—which the team should review regularly.

The Lean portfolio (described in chapter 4) can provide insight into what feature or features can be delivered for the most return on investment (guided by what business the organization is in). This portfolio and the release plan must be established, estimated, and made visible before any attempt is made to execute an iteration. This preliminary work is necessary because the time it would require to decompose and estimate a high-level plan and to establish enough stories ready to be broken down into tasks would overload the first iteration undertaken. In other words, we need to “prime the pump” of high-value work so that the team can focus on delivering business value and have the right amount of visibility into future work. The structure should support “responsible looks ahead,” but not so much that the team focuses too far into the future and risks doing unneeded analysis or building unneeded features.

Set Up the Team

Lean guidance dictates that limiting work to the team’s capacity is fundamental to efficient workflow. This environment is created by forming dedicated teams that pull work from a prioritized backlog and focus on completing it before starting new work. Iteration 0 is the time to form and locate the team(s) and assign roles well-established in Lean-Agile methods, including product champion and Scrum Master. Decide on the following:

• The logistics for both daily stand-up meetings and visual controls (product portfolio, road map, release plan, and iteration backlog)

• How to manage impediments

• How to ensure transparency (WIP, impediments, status)

Lean mandates that the team focus on quality and preventing waste, particularly delays. Additionally, the development process should help prevent the creation of technical debt.¹ It is recommended that the team transition to a test-first approach. If this transition is not underway, Iteration 0 should include a plan for the team to establish testing approaches at the unit, functional, system-acceptance, and user-acceptance levels. The agreed-upon strategies for driving all work under the context of testing should be documented, and incremental creation of a fully automated test suite, with visual controls in place to monitor progress, should be a clearly stated goal.

1. There are two types of technical debt. One is merely writing poor-quality code that makes future changes more difficult. The other results from not taking advantage of what you’ve recently learned about your system to improve its design.

At the story level, the team needs standards of work that specify the agreed-upon definition of “done.” This can be a simple document that describes the visible quality steps that the team must achieve prior to closing and demonstrating a story, including all updated compliance documentation, an updated design deliverable, code inspections, architecture review, and finally, product champion acceptance.

Set Up the Environment

In order to maximize the delivery of business value, the team needs to put in place as much of the technical setup as possible in Iteration 0. Install, configure, and validate all components of the development environment, including IDEs, version control, testing tools, and bug-tracking applications.

A common approach is to have the team test-drive these components by pulling in at least one build story in order to verify from end to end that business value can be delivered within the environment.

Set Up the Architecture

Other items that require attention and buy-in from the team in order to set standards of work include high-level identification of dependencies and risks, architecture goals, and documentation. These may require enterprise review and sign-off, and should be addressed during Iteration 0. How to do this is discussed in greater detail in chapter 13, The Role of Architecture in Lean-Agile Projects.

Iteration 0 Checklist

Use the checklist shown in Table 6.2 at the beginning of a project to ensure that all of the issues for Iteration 0 have been covered.

Table 6.2 Iteration 0 Checklist

Summary

This chapter describes Iteration 0 (also known as Sprint 0), the work required to set the stage for the team to start work on Iteration 1 and beyond. The length of Iteration 0 can vary depending on the needs of the team and the project. There are four primary focus areas: the product, the team, the environment, and the architecture. Time spent here sets up the team for early success.

After discussing each of these, the chapter concludes with a checklist for Iteration 0 activities.

Try This

These exercises are best done as a conversation with someone in your organization. After each exercise, ask each other if there are any actions either of you can take to improve your situation.

• Discuss a time when you did too much up-front preparation.

• How could you have avoided the excess preparation?

• What did this cost you besides your time?

• Discuss a time when you did not do enough up-front preparation.

• Can you tell the difference between doing too much and not enough preparation?

• What do you think is the minimal preparation required for virtually all projects?