Mind the Product 2013: Sprint Zero

1,993 views

Published on

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.

Published in: Design, Business, Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,993
On SlideShare
0
From Embeds
0
Number of Embeds
80
Actions
Shares
0
Downloads
37
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • 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.
  • Mind the Product 2013: Sprint Zero

    1. 1. Mind the Product London 2013 Sprint Zero 1
    2. 2. Mark Interrante SVP Products & Engineering •Deloitte •Hewlett Packard •HP Shopping •Yahoo Harry Max VP Experience Design •Silicon Graphics •Apple •Virtual Vineyards •Hewlett Packard •DreamWorks Animation •Executive Coach Our Perspectives @interrante @harrymax Rackspace 2
    3. 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
    4. 4. Discovery vs. Development Sprint Zero Rackspace 4
    5. 5. Building the thing right Building the right thing 5
    6. 6. Page 6 Rackspace 6
    7. 7. Get the Generic Experience Right Rackspace 7
    8. 8. Deliver on the Expected Experience Rackspace 8
    9. 9. Focus on the Augmented Experience Rackspace 9
    10. 10. Aim for the Potential Experience Rackspace 10
    11. 11. Desired Outcom e Requests & Agreements Back-plan Sprint Zero Tools ProductBox Rackspace 11
    12. 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. 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. 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. 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. 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. 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
    18. 18. THANK YOU @interrante @harrymax 18

    ×