Archive for April, 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.
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
When agile is working at scale, with multiple teams, there is usually a need to see progress through the work at different “zoom-levels”.
Most familiar is the story zoom-level: How are the stories progressing? Are they blocked? Why? How is the iteration progressing? Team boards, and team level hacks, help us to see these things change, and to understand how to improve.
At a higher zoom-level, the visibility needed is: How are multiple teams progressing through the larger pieces of work (we’ll call them features) which the stories are part of. So what we need to see is: When are they likely to finish this feature? What’s at risk? What’s blocking the team? Does the team need help?
This level of information is often represented on a program wall, which is a bit like a “zoomed-out” version of a team wall, showing the backlog of features to be delivered, cycle time across the whole program, and so on.
Here’s an example of a program wall. Each team is represented by a horizontal row and the columns are the iterations in which the teams expect each feature to finish.
The detail of how these features are tracking is found on the individual teams walls. But one team found a way to clearly summarise their progress on this wall too. They decided to stick burnups onto the front of each feature card. (A burnup is one of the most eloquent of board hacks as it provides a single view of scope and velocity, as both change).
You can see it a little better below:
So now, when you’re standing at the feature wall you can see the burnup for that feature, right on the front of the feature card without having to go and find the team wall. In this example, the feature is in the Iteration 12 column, but the burnup tells me it’s more likely to finish in the 14th iteration unless something changes – I smell risk! You can get a very rich sense of what’s going on, at a glance.
Spotted: Telstra Contact Solutions
This team wanted to track cycle time, and chose to do this by simply putting a dot on each card every day at standup. This way, you can count the dots on each card in the “done” pile at the end of the iteration (or any time), and understand average cycle time per card, or by point-size.
Cycle time for the story below is 6 days.
But this team took it a step further, colour-coding the dots by number of days in each process step. So, the card below spent 2 days in the backlog (green dots), then 3 days in build (red), and 2 days in test (black).
“Some of the cards had dots going all around the edge of the card!” says Gina. And sometimes the stories bounced back and forth between build and test (you would see this as alternating runs of red and black). Great fodder for retro.
Spotted: Telstra Contact Solutions, CCRI