Timeouts and retrospectives
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 timeoutOne 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 retrospectiveWhen 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 retrospectiveOnce 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.
Labels: pomodoro, retrospective, timeout
Links to this post
Focus On Intent!
I frequently use the term 'focus on intent', especially with respect to the writing of story cards and acceptance criteria. When I'm focused on intent:
- I understand, with absolute clarity, the goal my customer is trying to achieve and it's NOT expressed in terms of how I am going to get there.
- I have distilled the context of the situation by identifying the most significant or important contributing factors.
- My clarity of understanding allows me to convey meaning, describing these factors clearly with a high signal-to-noise ratio.
- My state of mind is determined and concentrated on a central point while I focus on achieving only one thing at a time without ambiguity on the outcome.
- I have identified a clear, unambiguous measurement that will tell me when I am done.
- I am conscious of the essence of design and so I maintain consistency at different levels of detail so that everything makes sense separately and in context of the whole.
For me, focusing on intent conceptually represents a cognitive state required to be effective. However, achieving this state of mind isn't easy, especially in a busy environment. Personally, I find the
Pomodoro technique useful in staying focused.
Labels: focus, intent, pomodoro
Links to this post
Pomodoro galore
Almost everything for us is now a
pomodoro. Some time ago we replaced the per-iteration planning game with on-demand planning
pomodoros and the end-of-iteration retrospective with a pomodoro retrospective.
Every
Wednesday, the first day of our
weekly iteration, we kick off with a 25-minute planning pomodoro to give us just enough stories to make a start. We've been experimenting with a modified
fishbowl format to stimulate the right level of technical discussion and keep energy levels surging. When the
board gets short of stories (and the team is in danger of stalling) we run another planning pomodoro to top up the 'waiting' column. We keep doing this until the
showcase on Tuesday but we're careful not to end with loads of stories still in progress.
Our estimation is simply: "Is this story less than 2 days?" and the team shows thumbs up or down. If it's not, the story is split there and then. A pre-planning pomodoro run in advance of Wednesday, looking ahead into the next iteration, helps to size stories appropriately and get the acceptance criteria on the back of the cards. Our velocity is the average-to-date, over all the iterations, of the number of cards that made it to done. This gives us a steadier velocity than summing the estimates of the stories that made it to done in that iteration. We're not really using the velocity for planning purposes though. We use it to calculate a per-story cost, in £, derived from what was delivered in the iteration and the overall capacity cost for the iteration. From this we can then calculate the cost of any inventory and outstanding technical debt. It's sobering to see these things in money terms. I'll blog separately about the simple profit-and-loss sheet we use based on lean accounting and the metrics we watch.
The pomodoro
retrospective is conducted standing up. This keeps things moving and keeps people focused. 25 minutes doesn't provide a lot of scope for variation of activities but we can easily cover our standard format: brainstorming - affinity mapping - dot voting - and agree one action that will improve things. I expect this will eventually get boring so I'm thinking of ways to do pomodoro 'lets improve this, here-and-now' sessions that are triggered by a problem just encountered. I guess these are similar to timeouts. Ultimately, the challenge I've set myself is to focus these continuous improvement pomodoros on making an improvement that is not borne out of (and therefore constrained by) solving a specific problem. They just focus on making an improvement to get better.
We're also experimenting with a new board layout that helps us integrate iterative collaboration with designers. There's some serious thinking to be done here and, to be honest, we could do with a fresh project to try it out on.
Labels: planning game, pomodoro, retrospective
Links to this post
Pomodoro-powered promiscuous pair-programming
At
Agile2008, Gus attended a
session about the
Pomodoro Technique by
Stefan Noteberg and has been using it since.
He's running a session on the technique internally at
Energized Work next week. Then we plan to experiment by combining it with
pair-programming to see if we can achieve even more effective pairing sessions and greater
promiscuity. I'm imagining a pairing session being multiples of 2 Pomodoros, lasting about an hour with a 5-minute break after each Pomodoro. Potentially we could then achieve swap pairs every hour.
I'm looking forward to seeing what the hurdles will be, e.g. synchronizing the Pomodoros while allowing for 15 or 30-minute breaks every 4 Pomodoros and fitting lunch in.
Labels: pairprogramming, pomodoro
Links to this post
