Blitz Planning Re-imagined

Blitz Planning is a technique developed by Alistair Cockburn which builds upon and extends the familiar (from XP) planning game and described in detail in his book Crystal Clear. This workshop presents an updated version which borrows from the concept of the Kickstarter campaign to reflect current thinking around hypothesis-driven product development.

Blitz Planning is a fast moving highly collaborative activity which supports the development of the first three-month planning horizon for any technology project. The outcomes of a Blitz planning session can be used to inform activities such as story writing or story mapping, but the technique differs in both process and outcomes in several significant ways. Key among these are the breadth of the tasks included. In a Blitz planning session, tasks are written at a much higher level and include both technical and non-technical items such as the need to develop training or marketing materials, the need to identify and provision infrastructure. There are opportunities to identify any long lead or lag times or dependencies on a particular individual, or group. Because technical and business stakeholders work together, it is possible to rapidly identify project dependencies and bottlenecks and expose any potential hidden surprises in the project. A key benefit of this technique is the resultant shared understanding of what is actually involved in delivering the project. It gives business representatives the opportunity to ensure that the expected business value of the project is clearly understood as well as providing technical representatives with the opportunity to make sure that any technical constraints or challenges are properly socialised.

Blitz planning can be conducted towards the end of an inception or project kick-off workshop and provides technical and business stakeholders with sufficient information to make crucial decisions as early as possible in a project. A successful outcome from this technique may equally be a plan to conduct an experiment or even a decision not to proceed with a project in its envisioned form due to the identification of constraints.

While originally developed with technology projects in mind, this technique can be used to kick off many different project types.

 
1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This workshop is very practical where most of the learning comes from working through the sample activity.

Initially, there will be a round of introductions - and we will cover session ground rules, explain the idea of a parking lot for questions, or other things that come up, as well as the use of an AhHa poster. An icebreaker exercise then follows.

Key Activities

  1. Technique Introduction - The presenters will provide the participants with information about the method its use cases and potential benefits.
  2. They will then lead a discussion of the sample scenario; the group will make some decisions about it and identify some of the decisions individual teams will need to make
  3. Form teams and start the exercise (we use a process which aims to form teams with a balance between technical and non-technical people)
  4. Break for morning/afternoon tea
  5. Complete the exercise and move to questions and discussion

Detail about the exercise;
Part 1.
Participants are asked to work together to identify all the tasks that would need to be completed to deliver the sample project to the market.
Teams are then coached through the process of developing a high-level plan, identifying any potential dependencies, bottlenecks or risks finally coming up with an elapsed time estimate for the project.

The presenters then lead a discussion to determine the potential pitfalls of the initial approach and suggest some antidotes to these.

Part 2.

While the Kickstarter approach frames the exercise, it is not about developing a Kickstarter product. The three stage Kickstarter approach is analogous to the delivery of a Walking Skeleton, and MVP and Version 1 of a given product and is a useful generic framework. The technique is useful for any product or service delivery project.

Release one; Walking Skeleton reflects the development of the initial product hypothesis; participants identify the essential tasks they would need to complete to prove the technical feasibility of their idea. This release represents an initial experiment. Release two; the MVP extends the investigation, asking participants to consider how they will test the level of demand for the product or service. Finally, Release three tests the hypothesis that the product can deliver value to customers.

The presenters then lead a discussion of the lessons learned and key take-home points arising from the exercise. These include the ideas underlying hypothesis-driven product development. The development of the overall plan represents a very low-cost initial experiment, and provides answers to such questions as; is this idea even viable? How will we test demand? What is the earliest point at which value can be delivered? Each subsequent release in the plan provides an opportunity to prove or to disprove the viability of the product idea.

Learning Outcome

Participants will learn a technique which supports the following

How to identify and estimate the first three releases of your project
What your iteration zero tasks should be
What the project walking skeleton will look like
When can we obtain the earliest possible feedback
The earliest point at which business value (revenue or savings) can be delivered
How to spot hidden dependencies on people, technology or equipment
Which activities have long lead times
How collaboration can lead to better outcomes between between business and technology stakeholders

Target Audience

Anyone who is involved in the planning and delivery of projects

Prerequisite

Specific technical knowledge is not required. The content is relevant to anyone involved in leading, planning or facilitating a project, the technique is best used when both technical and business stakeholders are present, for example during an inception or kick-off workshop.

schedule Submitted 4 months ago

Comments Subscribe to Comments

comment Comment on this Proposal