Posts Tagged Agile
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.
I’ve talked about cards that are never going to get prioritised and should end up in the Dead Card Cemetery. But what about small cards that are important enough to keep in the backlog, but that keep getting deprioritised behind other things in the backlog? I’m talking about the really tiny ones, often bugs, no more than half an hour’s worth of work. Maybe you could try an opportunity bucket.
A purist might say that if a card is important enough to be worked on then it will be prioritised into the backlog. But actually, there are always things that have too little value on their own to be prioritised. The team I currently work with created a ‘bucket’ of these at the bottom of their board. Cards get plucked from the bucket if it’s late in the day and not worth picking up a bigger card from the main backlog, or if they’re doing some work in that part of the code anyway and can fix something from the opportunity bucket while they’re in there. It’s proved to be a great way to knock off tiny cards that would otherwise have languished in the backlog.
Spotted: LPOS development team
“We wanted a way to notice recurring patterns in glitches.”
This team gets through an enormous amount of work which requires many hand-offs with other departments. When there’s a glitch in a part of the process, the team member adds a little red sticker to a card, often with an accompanying note about why there was a glitch. If a story accumulates a few of these, we can see it’s in trouble. Also, the little stickers are an excellent reminder for retro, where we have a chance to talk about how to address any larger issues that might be driving them, or even use “5 whys” to delve into the root cause of glitches.
Spotted: Lonely Planet
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
Sometimes it feels like the agile community knows the cost of everything, and the value of nothing. We have clever ways to measure velocity and to estimate the size (and therefore cost) of pieces of work, and we like to obsess over these. But when do we ever quantify the value which will be delivered by a piece of work? Relative value is taken into account when a product owner prioritises higher value stories in the backlog, and some methodologies do take a shot at quantifying business value nowadays, but I don’t see much evidence of teams trying to quantify the value of a piece of work either before, or after it is delivered.
Deming says “Plan, Do, Check, Act“. But most of the time it just feels like “Plan, Do, Plan Do, Plan Do”.
I salute this team which puts the revenue at stake right on the card for everyone to see. If this is job is blocked for a day – is it a big deal, or not? Look at the revenue at stake. It’s a big deal.
Team says: “A cool way to visualise the output of each iteration.”
The idea behind this hack is to give a visual representation of the cards signed off in each sprint.
The card colours represent bugs, features, BAU support and tech stories. By arranging them on a spare wall according to colour groupings it’s easy to see how many cards and of what type have been signed off each sprint. For example, feature cards, defects, and tech cards. And you can see how this changes over time.
It’s also immediately apparent whether the main activity has been skewed towards one area. It takes it’s name from it’s similarity to the display of a graphic equaliser.
Just by walking past, it’s easy to learn a lot about this team’s work:
So.. what this board is telling me is …
… this team pumped out a lot of features in a short time then faced down some serious technical debt and some outstanding defects.
Here’s another card equaliser, this time from the Lonely Planet web site team.
Spotted: lonelyplanet.com website and mobile development teams.
Here’s another variant, from a different source. Might be useful if you don’t have a lot of space:
Katie says: “There’s something really satisfying about spiking the completed cards at the end of each iteration”.
Here’s another take on what to do with the cards once the iteration is complete – stick them on a custom-made giant spike and top it off with a unicorn!
It’s important for a team to recognise the progress that they’ve made over a series of iterations. Watching the cards rise higher and higher up the spike is satisfying and a visual indicator of how much work the team has done.
Spotted: lonelyplanet.com website development team
Nick says: “The first time we did this, it helped us to get our release success rate up. It was a long road, but this was one thing which helped.”
We were working on a sprawling web site made up of 22 separate applications which may or may not need to change for a particular release. The release would bring work by 2 to 4 teams to production. As we moved to biweekly releases, we needed a way to see exactly how our preparations for release were going. Is regression testing complete? Did we pass load testing?
So we decided on what our criteria were for a release to be good-to-go, and made each criterion a traffic light which could be red or green. This included a “stop the line” light which developers could turn to red at any time if they felt the release was too risky.
Each day, from three days out til release, we would stand around the release readiness traffic lights after morning standups were over and discuss the status of each light (“is that really green?”), and agree on actions to get to green.
Spotted: lonelyplanet.com website development team
Cycle time is the time that elapsed from the beginning to the end of a process. In lean practice, this metric takes the place of velocity as a way of understanding how fast we’re moving.
This team are tracking cycle time from the moment a card comes into play until it is done. The grid shows the average time for a story to transit the board, by type and size of card, and the size of sample. So, for example, a 3 point story takes this team an average of 5 days to complete, with bugs taking slightly less: 4.5 days. This figure is an average over 26 cards.
Teams often use old-school office date stamps to stamp today’s date on a card when they pick it up to work on, and again when it’s done. Later on, someone can simply subtract one date from the other. Alternatively, if the team is working in iterations, team members can simply write the day number of the iteration on the card.
Here is a slightly more hi-fi version:
Spotted: Aconex Extensions Team
Team says: “That bus is getting full. Looks like it might be an Indian bus“.
Ok. You have achieved continuous delivery. You can now release your features whenever you like. But how do you know when it’s time for a release? You want to keep the value flowing out to your customers. How do you track which cards are going in the release?
One way is to use a release bus.
All the stories that will go out with the release are moved onto the bus as they are signed off. There are limited seats on the bus – when the seats are all full then it’s time for a release. There’s no reason to wait until all the seats are full though, a release should still happen whenever it’s required. On the other hand, a release bus that has run out of seats is a sure sign that there are getting to be too many stories in the release and that it might be a good idea to release in order to minimise complexity and risk.
Spotted: LPOS Team