We use timeouts and a couple of different retrospectives to
drive improvement. Stop-the-line events like Pomodoro timeouts and
Pomodoro retrospectives happen spontaneously within the team to
solve problems immediately and produce small continual
improvements. We also use a monthly retrospective for the product
stream to reflect on how it's working and conceive bigger, more
strategic improvements.
Pomodoro timeout
One of our norms is that anyone can call a timeout. The team calls
timeouts frequently, usually more than 1 a day; they seldom last 25
minutes and if they need longer they just run another Pomodoro.
People huddle in the bullpen, sometimes around a whiteboard, to
discuss something within the remit of the team and collectively
decide what to do. Whether the purpose is to discuss a technical
issue and define a set of spikes to prove the way forward, explore
options to get around an obstacle, or investigate a process issue,
the timeout often creates opportunities to make improvements.
On-demand Pomodoro retrospective
When something extraordinary happens the team runs a Pomodoro
retrospective in 25 minutes, as soon as possible after the event,
to find the root cause and agree 1 specific and clearly defined
action that can be taken immediately to prevent it reoccurring. We
like to use the 5-whys technique but we also use other activities
(within the format - brainstorming, affinity mapping, dot voting,
decide what to do) depending on what had happened. The
retrospective is always done standing up to keep people focused and
energetic. Most of the time the retrospective concentrates on
events that the team could have controlled or avoided. However,
sometimes it investigates problems in the
product stream that were outside
the team but nevertheless impacted them, in which case appropriate
people from the stream also participate.
Monthly retrospective
Once a month the facilitator runs a structured retrospective for
the
product stream (that involves
setting the stage, gathering data, generating insights, and
deciding what to do, close). Everyone in the team attends,
including the technical mentor, as does the business sponsor,
product owner, team leaders from the business users plus a handful
of their staff, and other people from the various business
disciplines within the stream. The purpose of this retrospective is
to step back and look at the big picture, including any external
factors that have affected the stream, and identify any trends. We
challenge how we currently work and try to get beyond the obvious
to discover transforming ideas that would make the product stream
more effective.
Thursday, 22 October 2009
Timeouts and retrospectives
Posted by Simon Baker - Permalink
2 Comments
Two really good bits of advice! Just one question: when someone calls a timeout, did you wait until all the pairs end their pomodoros or you interrupt (and "break the pomodoro") them?
Thanks!
Good question! It's up to the pair that want to call the timeout. If they wait, they could be waiting a long time since the Pomodori aren't synchronized across the pairs. They're aware of the cost of the timeout (in terms of interrupting Pomodori and flow time), so they weigh up the importance of the timeout against the cost of interruption.
Most of the time, the timeout is called and the Pomodori are terminated. After all, a Pomodoro is just a means to focus, while the reason for the timeout is usually critical for the team and requires a consensus decision.