Recognize Project-Startup Traps

As a leader, you have direct control over avoiding these traps:

• The team starts with Iteration Zero to define the project.
• The organization wants detailed planning for the entire project before it starts.

As the team starts the project, be aware of these traps and avoid them.

Trap: Iteration Zero

Some teams learned or thought they needed an entire iteration of planning or architecture or estimation for the entire project. I’ve actually seen teams fall into “Iteration Minus One,” “Iteration Minus Two,” “Iteration Minus Three,” and so on.

For example, one team had trouble starting because it had always defined the architecture at the beginning. The team was faced with a new product and management wanted an estimate. The team spent Iteration Zero developing an architecture, and Iteration Minus One developing an estimate. That changed the architecture so the team spent Iteration Minus Two redoing the original architecture. The team was ready to estimate again.

A manager familiar with agile approaches stopped by and asked to see the team’s walking skeleton. When she realized the team had been planning and estimating, she asked it to create one specific feature for her to see the next day.

The team did and was surprised by three things: it needed to change the architecture again, it could complete a feature in one day, and the estimates it had prepared had no relationship to reality.

The manager helped the team realize it had fallen into Big Design Up Front and a phased approach to the project. The team continued to work on one feature at a time at the start of the project to see what the team could deliver and to have some idea of the accuracy of the team’s estimate.

Instead, consider these possibilities:

• Spend up to half a day creating a list of experiments so the team knows where to explore.

• Determine the hardware or other resources the team requires and start that effort. Ask the team if it can start on anything without those resources.

• If the team wants to use iterations and has no idea how to estimate together, consider a one-week timebox so the team can learn to work together. Use that week to define several small stories and see how the team jells.

• If the team has no stories ready, consider a one-day workshop to generate stories small enough that the team can work on them and the product owner can generate more stories.

Ask yourself the “how little” question applied to starting: How little can we do as a team to get ready so we start delivering value?

Trap: Your Organization Wants Detailed Project Plans

In waterfall (and some other kinds of projects), organizations try to optimize everyone’s “efficiency.” (See ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​.) To organize the project and to utilize everyone, “efficient” projects need detailed plans: communication plans and often Gantt charts.

You don’t need those plans when you use agile approaches. When organizations use agile and lean thinking, the project has a fully formed cross-functional, collaborative team able to deliver value on a regular basis. That team doesn’t need a communication plan.

The team might have to provide status in some way to others in the organization. I have suggestions for that in Chapter 14, ​Report Your Project State​. However, you don’t need many other plans.

The team doesn’t need Gantt charts. Gantts mean nothing to an agile team. What people need to see is the initial product roadmap and the rolling-wave deliverables as the team completes the work. See Chapter 6, ​Teams Deliver Features​.

If your organization wants detailed project plans, ask about the value it receives for these deliverables. Instead of writing plans, show demos of the product. If your organization wants detailed plans for milestones, show the product roadmap.

If managers in your organization send you mixed messages, such as “Give us all the old measures and work in an agile way,” you have major impediments to a successful agile transformation. Consider how you will help people see the new measurements that provide value. You might have to meet people where they are. See Chapter 16, ​How Managers Help Agile Teams​, for ideas.