As a comment on “How much do you let a new team self organize?” IanJ asked
Why are 59-Minute Scrums cool and what are they good for?
The 59 Minute Scrum has been a popular training exercise for years in the Scrum community. The team gets a problem to solve, and goes through a “simulated” sprint to solve the problem. You get to experience real Scrum in a safe environment.
Fifty-nine minute sprints are an excellent learning tool because so much happens in such a short time. Everything that goes wrong in a real sprint can happen in a 59-minute sprint. They are great for problem solving!
In my classes, I usually simulate a 3-day sprint, using 5 minutes for each half of the Sprint Planning and the Sprint Review, 12 minutes for each day, and 4 minutes for each daily scrum. If you add it up, it comes to 59 minutes. Each Scrum Team has a Scrum Master, a Development Team and a Task Board. Depending on the context, there may be one Product Owner for all the teams in the room, or each team gets it’s own PO. Note the 59 minutes does not include the Retrospective, which I handle separately in my courses. I usually don’t too much about the length of the Sprint Review either.
I have found that if a team does three of these over three days, by the end of third iteration, they are really good at the basics of Scrum and ready to do it “in real life.”
What is the difference between this being a Scrum simulation and a real-life “micro Sprint”? Well not much, except for the importance of the results you are producing. If you plan to throw away the results, it’s a simulation. If plan to use them, it’s a micro-sprint.
What would be an example of using micro-sprints? One area is to address organizational impediments. Imagine you have assembled in one room not just the Development Team, but also their management, important stakeholders, the operations group and other interested parties for the product. Ask them, “What are the biggest impediments to success of our project?” Have them write them on stickies and post them on the wall. Like in a retrospective, have their owners present them. The others can ask clarifying questions.
Finally you do some sort of dot-voting to identify the top issues. Exactly how you do this depends on many things, most importantly the number of people in the room. One way is to each table create a short list of two or three items, merge the lists to get about 10 to 15 items, then have everyone dot vote the this short list to prioritize the problems.
Now you are ready to use Scrum 59’s to tackle your challenges. What could you do to solve the issues identified? Form teams around the top priority cards, usually one team per card and one team per table (did I mention, island seating with about 6 to 8 people per group?) Whoever wrote the top priority cards becomes Product Owner for those cards.
Iterate once or twice to come up with possible solutions for those impediments.
I have seen awesome results with this approach! Usually the people who are most surprised are the managers in the room, because they have never seen their staff working so creatively and with such energy. And the teams come up with good ideas that the managers never would have thought of. Oh, and they get really good at the mechanics of Scrum and ready to take on the challenges of their project using Scrum to help them.
Prepare to be amazed! And don’t forget you can start implementing those solutions right away!