Problem

One of the first complaints of going to Scrum is the huge amount of overhead. The effort and time it takes to plan, task, standup and retrospect seems like a whole bunch of waste, especially in teams had no defined process in the past.

This is usually an argument for going to larger iterations, where teams only have to perform these ceremonies every three or four weeks. If a team is only planning 12 times a year (4 week iterations), how can they get better at it? Each time they plan, the last time will have been too long ago to remember any of the mistakes made.

The ceremonies will continue to drag on and provide little value, adding to the argument of putting more space in between them. One hour iterations will take this to the oposite extreme. Teams will practice these ceremonies 4-6 times more often in one day than they normally do in a month. They will also have to stick to very strict timeboxes, so wasting of time during ceremonies will not be tolerable.

Another, seemingly unrelated, problem is that most teams and Product Owners have a really hard time wrapping their heads around the idea of minimum viable product and adding value in incremental releases.

Ingredients

 

• 1 team
• 1 product owner
• 1 scrum master
• A handful of customers. Joining you in person if possible.

 

Instructions

 

1. First, define a minimum set of features that the team can deliver in one hour. The features must add value at the end of the hour. They can not be dependent on future features to work.
2. Set and start a timer for 42 minutes
3. Have the planning session for 10 minutes. The Scrum Master should be very strict about maintaining a 10 minute timebox.
4. Have a quick standup. We like to use the Check In Protocol.
5. Set a seperate recurring timer for 6 minutes.
6. Every 6 minutes, fill in a box on the task card. (see Extreme Timeboxing)
7. 42 minutes in to the hour, deploy (if you haven’t already). You must ship within the first iteration and continue to ship every iteration after that.
8. Facilitate an 8 minute retrostpective. Since time is so limited, try to stick to a format that everyone can understand with minimal explanation. Start/Stop/Keep works well for this.
9. Take a 10 minute mandatory break. No programming allowed! It helps to move around a bit and physically leave the development space. Just make sure everyone is back on time, because you can’t afford to waste a minute.
10. Now that the product is live, the Product Owner should show it to as many people as he/she can. This is where the on-hand customers come in. Try to collect as much feedback as you can before the next planning meeting.

 
The schedule looks like this:

• 12:00 Planning / Tasking
• 12:10 Standup
• 12:12 Timebox 1
• 12:18 Timebox 2
• 12:24 Timebox 3
• 12:30 Timebox 4
• 12:36 Timebox 5
• 12:42 Retrospective
• 12:50 Break

 

What this does

 
By releasing every hour, the team starts to build a lot of confidence in their ability to ship. As they gain experience planning, tasking and retrospecting, they’ll start to find that they add value to the sprint that far exceeds the amount of time spent on them.

Product Owners will see the value of gaining early feedback, and how valuable it can be to have the flexibility to pivot. Every experiment the Product Owner runs, in the form of a User Story, has a maximum risk of losing 1 hour of development time. This invites trying some pretty out-there ideas.
 

Variations

 
Before starting a series of one hour iterations, have a 30 minute Agile Chartering session to come up with some team working agreements. Here are some examples from when this has been done in the past:

• Rotate pairs every hour
• Ok to checkout
• Hourly checkins
• Deploy every hour
• No stories greater than 1 hour