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
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 week, 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 week, helps to size stories appropriately and get the acceptance criteria on the back of the cards. We calculate a per-story cost, in £, from the total number of cards that are released in that week and the overall capacity cost for that week. 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
Reflecting at the Fun Day
We said there was a
whole lotta fun to be had at our end of project retrospective fun day and that's exactly what we had - fun! And the various retrospective activities interspersed throughout the day produced a lots useful information and ideas. I plan to blog about these separately because we'll be running some experiments based on our ideas to simplify and improve the way we work as a team. In the meantime, here's some photos from the day:
Labels: fun, retrospective
Links to this post
A whole lotta fun to be had
We're going to have a fun day on Friday to celebrate the success of our most recent client work.
We'll start the day at
My Old Dutch Pancake House for brunch and a retrospective. As we do every week, we'll be seeking some small
actions to drive our continuous improvement. In the afternoon we'll hit the
Bloomsbury Bowling to shoot some pool and do some ten pin bowling while engaging in a 'beerstorm', i.e. brainstorming fuelled by beer. I'm keen to stimulate some transformative ideas that could take us to a whole new place. I have no preconceived notions and I'm excited to see what the team comes up with.
It's both productive and revealing to do things like retrospectives and brainstorming in a social setting filled with jokes and laughs,
nom and drinkies. People relax, drop their guard, are less defensive and generally more open to things. And, importantly, our friendship helps avoid anything said being taken as offensive.
Labels: fun, kaikaku, kaizen, retrospective
Links to this post
Actions from retrospectives
A retrospective is pretty pointless if you don't come out of it with an action, which you then take in the next iteration.
An action should be small, specific and clearly defined on a card; can be taken immediately; starts something new and good, rather than stops something bad.
Labels: retrospective
Links to this post
What makes an effective pairing session?
Jeff Home works with
Dan Nye through their company,
Coedit. They're 2 of the best Web developers I've worked with and they're an important part of what's become the Energized Crew. Jeff and Dan are working with us in a team at one of our larger clients.
Jeff sent me this write-up on their last retrospective, which focused on what makes an effective pairing session:
We broke into groups of 3 or 4 and made our posters to present back to the team. This mind-map poster (one of the teams had created it as their poster) was used as the base to include other team suggestions, leading to a team-accepted definition of what makes an effective pairing session.
All the teams shared a very close vision and all the presentations were very similar. Obviously there was a very clear understanding within the team of what makes an effective pairing session. This retrospective served to show our new starters what we expect of one another as well as remind us all of what is expected of us when we are pairing with one another.
Here's
another write-up of a similar retrospective run with a different team.
Labels: pair-programming, retrospective
Links to this post
A 'Nut it out' Norm
Via
Diana Larsen.
I really like the idea of having a
team norm in place to help deal with interpersonal conflict.
The norm would require the people involved in the conflict, as part of their membership of the team, to work together (with the help of a facilitator; aka Scrum Master) to find the root cause of their conflict. Basically get in a room and work it out before the conflict gets bigger and pulls the whole team down. The people involved are required to bring their analysis and agreement to the next retrospective and report it to the team so that everyone learns from the experience.
Labels: agile2008, conflict resolution, retrospective, team norms
Links to this post
