Posts Tagged Release Planning
Dependency mapping
Posted by fe in Telstra Contact Solutions on April 20, 2013
An Agile world without dependencies would be a wonderful place. Each piece of work could be executed independently of any other, in any order. In a perfect world it all works out just like this. 😛
But much as we would like it to be, it’s not always like that. Dependencies are real. For example: hardware might be required to provide the value the end-customer wants. And until it’s in place – either for development, or testing, or production – you just can’t create that value. Dependencies are especially common in large, distributed pieces of work where one team will depend on the work of another. Ignore them at your peril.
The board below is one of those situations. A large program of work spread across multiple teams, with dependencies between teams. Caleche Watson, the project manager on this team has mapped out the dependency using a piece of string, so its clear where it lies.
A piece of string shows the dependency between two pieces of work.
Teams which depend on each other need to talk a lot to keep in sync and ensure the best outcome overall. This piece of string makes obvious a conversation that needs to happen at their regular joint stand up. As Caleche said:
“At the end of the piece of string is a conversation”.
Spotted: Telstra Contact Solutions
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.
Get on the Release Bus – you know you want to
Posted by fe in Lonely Planet SPP Dev Team on June 4, 2011
The LPOS team's release bus starts to fill.
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
If it’s a Release Bus, where does it stop?
Posted by fe in lonelyplanet.com on May 18, 2011
The LP website team's release bus map.
Team Says: “We were sick of the confusion about which apps to deploy each release. Our release manager knew the site backwards but as soon as he wasn’t around it all fell apart”.
The website is a large, complicated beast with many apps to be deployed behind the scenes to provide a single experience for the user. A few times we forgot to release an app with the result that we broke something on the site. Also we needed everyone on the team to be aware of which parts of the system were going to change with each release.
The fix? Since we already had a release bus, we made a bus route map. Every app which runs the site is listed there, and a sticker gets placed over each app that the ‘bus’ needs to stop at during the release. It’s a great visual that provides a checklist to use during the release, and also helps non-technical types understand how complex our website is.
Spotted: lonelyplanet.com website development team
Countdown to a Milestone
Posted by nthorpe in Lonely Planet SPP Dev Team on May 3, 2011
The LPOS Team track progress toward a big milestone.
Team says: “The days are decreasing at exactly one per day, but the feature cards definitely aren’t!”
We’ve seen agile burn-down charts many times. But here’s a different approach. This team runs a lean/kanban board, and they don’t estimate in points, so they decided not to use the traditional burn-down chart. Sometimes, there are immovable deadlines and in this case an author was going on the road to research a destination. Tickets were booked long ago and there was no possibility of delaying the release.
As the release date approached the team simply kept track of the number of feature cards versus the number of days left. This was a nice simple metric which stared them in the face every day, and gave urgency to the task of ruthlessly cutting scope to meet the date. The days always decrease of course, but the card count can increase as additional stories are uncovered. Sometimes product owners can be reluctant to cut scope, but this made it painfully obvious that it was necessary in order to meet the release date. When the number of remaining cards fell below the number of remaining days the back of the beast was finally broken.
Spotted: LPOS Team
Agile Board Hacks 