Archive for February, 2012
Release Radar helps you see through the fog
Posted by nthorpe in If we tell you we'll have to kill you on February 10, 2012
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.