Posts Tagged Focus
A common or garden Agile board is good for a view of the iteration you’re in, and perhaps a little further out. But what about when you need to see even further? Agile teams often face the problem of “boiling priorities”. Priority changing on big pieces of work daily. You start to work on them, and then you hear they have been de-prioritised. It’s hard to know what you should be working on. The team can churn through a lot of brain cycles thinking about pieces of work which may or may not eventuate. This can be stressful.
Sometimes we need to be vaguely aware of pieces of work which are “out there” in the future, whilst still keeping our focus squarely on what we know is coming next. Different roles in the team, too, have different time horizons they need to care about. For Project Managers, or Business Analysts who need to organise and run inception activity, it’s good practice to keep an eye on what’s coming down the pipe. For developers, it’s often: “Meh. Just tell me what I need to do next.”
Daniel Aragao showed us a great way to deal with frothing priorities – the release radar.
Here he has trained his radar across the portfolio:
– each concentric circle represents time (12,9,6,3,1 and .5 month). Items far out on the radar are distant in time, items nearer the centre are closer in time
– each slice is a project, identified by a post-it on the outer rim
– resources working on the project are also on the outer rim – these will be avatars in the future
– each post-it represents a task, module, something that is big enough to be picked up by the radar
– post-its will be colour-coded to show the size of each task. T-Shirt sizes (S-green,M-yellow,L-orange,XL-red)
– IT, Ops and Business get together every 2 weeks to update the Radar and discuss associated risks
On our team, we took the idea and adapted it to our needs. Our radar simply tracks pieces of work as they orbit our world, and then come in to land.
The purpose was to be able to provide steady priorities to the team (they only need to look at the innermost ring), to help our BA structure her work with stakeholders on preparing epics, and to get a view of the whole pipeline if we needed it. We keep it on the back of the iteration board, and a subset of the team meet once a fortnight to update it. It tells us what we need to actively think about, and what we can ignore.
The quadrants relate to stakeholders.
Spotted: Daniel Aragao of Thoughtworks shared this idea.
Teams get their best work done when they can concentrate and focus on the task at hand. Switching back and forth between different tasks interrupts your train of thought and it can take a long while to get back on that train. Tom DeMarco recognised this more than a decade ago when he wrote “Peopleware“.
But of course sometimes interruptions are unavoidable. When we say we value conversations as the highest-bandwidth channel of communication teams can use, we are inviting interruption. Or someone from another team has a technical question. Or sometimes a production issue comes up that needs immediate attention, or a developer is the only person who can help unblock someone else’s work.
So how can we minimise these interruptions? The team chose a ‘fireman’. Someone whose job it is to extinguish any of these fires as soon as they happen. Team members take turns to be the fireman, and the fireman for the day is clearly shown on the team board so that everyone knows who they can tap on the shoulder to help them. As well as keeping the rest of the team focused on their work, it means the people with the questions don’t feel guilty about interrupting someone.
Spotted: LPOS development team