Skip to main content

Tackle your organization impediments with 59 minute sprints!

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!

Comments

IanJ said…
Thanks for the response..
joseph said…
Good idea for training scrum. Makes team member see how things will go

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …