Developing great products is hard. Using dual-track Agile dramatically improves the likelihood of success. But getting products off the ground requires some up-front thinking. Rackspace uses a number of tools to design and build the right product, not just build the product right. This presentation offers four of those tools.
3. Insights & Learnings
• At the end of this session you will know:
– How to think about designing the right thing
– How to use four new tools for flawless execution
• To make the future real
• Use framework spell out success
• Sequence dependencies for success
• Manage commitments effectively
Rackspace 3
12. What is it …………….
Why is it important
…
How does it work
…...
Product Box
A “game” to visualize the product
A fun way to make the future real
Design thinking & doing activity
12
13. What is it …………….
Why is it important
…
How does it work
…...
Desired Outcome
A powerful thinking framework
Forces clarification of success
Answers seven key questions
1. Who wants it?
2. What’s wanted?
3. What does it get them - that’s even more important?
4. How will they know when they have it?
5. What stops them from having it?
6. What problems could having it cause?
7. What must they do to achieve their desired outcome?
13
14. What is it …………….
Why is it important
…
How does it work
…...
Backplan
Highlights key dependencies
Clarifies the real path to success
Reverse chronological mapping
14
15. What is it …………….
Why is it important
…
How does it work
…...
Request and Agreements
A protocol for crafting agreements
Managing commitments is key
Each party follows the “rules”
1. Make well-formed requests
2. Respond to requests
3. Keep commitments
4. Renegotiate if necessary
Rackspace 15
16. What is it …………….
Why is it important
…
How does it work
…...
Request and Agreements
A powerful thinking framework
Forces clarification of success
Answers seven key questions
Rackspace 16
17. Learning More
• Product Management
– Inspired – Marty Cagen
– Start-up Owner’s Manual by Steve Blanc
• Dual-track Agile – svpg.com
• Serious Games and Product Box
– innovationgames.com
– Game Storming by Dave Gray
• Desired outcome framework
– NLP: The Essential Guide by Tom Hoobyar
• Backplanning
– Signature Series: Habit 2 - Begin with the End in Mind by Stephen Covey
• Requests and agreements
– Smart Work by Lucy Freedman
Rackspace 17
In my previous post, I wrote about alternatives to numbering sprints. In this post I want to deal with a very special number that some teams use in numbering their sprints--zero. The concept of a "sprint zero" has become popular with some teams and so it is important to consider whether or not this is a good idea. First, let's agree on the basic premise of "sprint zero." Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero. One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product? I find that many of these things that can be used to argue for the need for a sprint zero are really best thought of as things that happen in what I call the project before the project . Before a development project begins, there is often a project to decide if there should be a development project. Before a company begins a major new initiative, someone has to think about whether that initiative should be undertaken at all. Making that decision can be viewed as a project. Since Scrum works well as a general purpose project management framework, it can be used to manage the work of this project-before-the-project. During this project-before-the-project, the early team members (perhaps just a future product owner) can work toward creating an initial product backlog, finding or hiring team members, setting up the technical environment, and so on. I find it helpful to think of this work as a project of its own because it is not hard to imagine this work taking longer than one sprint, the special sprint zero. What does a team using a sprint zero call their second sprint if they need one to do whatever work they've used to justify the special type of sprint? Is it sprint 0.5? A couple of cautions are necessary at this point: Keep any "project before the project" as lightweight as possible. Most development projects do not need a project before they begin. Remain true to the principles of Scrum. A team participating in a project before the project will not be able to have anything potentially shippable. That's fine. But understand why having something potentially shippable is a central tenet of Scrum and apply that in a honest way to the project before the project. I'll write more about this last topic--staying true to the principles of Scrum on a project-before-the-project--in my next post next week.