Posts Tagged Lean
Follow the dots: the simplest way to track cycle time
Posted by nthorpe in Telstra Contact Solutions CCRI Team on April 4, 2013
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
What we said vs. what we did
Posted by fe in Lonely Planet, Lonely Planet SPP Dev Team on April 14, 2012
Are the stories that are talked about in planning always the ones that actually get played during a sprint? In an ideal world they are, but seldom does a sprint run according to the ideal.
This team was getting a lot of work done, but still seemed to have cards left over at the end of a sprint. Were the cards taking longer than expected? Were additional cards being added? No one could quite be sure.
One of the team members came up with a solution. After the team had agreed the stories that would be played for the upcoming sprint, he took a photo of the cards. This provided a visual record of what the team had agreed would be done.
It was stuck up next to the backlog and as cards were completed they were ticked off on the photo. At the end of the sprint it was easy to see what had got done, or not, out of the planned cards, and which new cards had been added into the sprint.
This is a great example of a team member taking matters into their own hands and using their own visual language (photographs) to come up with a fresh take on planning.
Spotted: SPP development team
Retro Heat Map
Posted by fe in Lonely Planet SPP Dev Team, LP Content Desk on April 14, 2012
Retrospectives are the place for everyone to have their say on what’s working and what isn’t. But does everyone have their say? Who’s talking? Who’s not?
Sometimes it’s hard to tell who speaks and who gets drowned out. To get to the bottom of this, one of our team began mapping who spoke during the retro, almost as a doodle. It’s a simple idea which has been evolved by other members of the team as they had a go at it. The latest incarnation of the heat map shows who is interacting with who. The secret sauce here is empowerment. This mapping process started because Dan felt empowered to just do it, and each subsequent team member who evolved the map felt empowered to adapt and improve it.
When you can easily see who’s interacting and who’s not, you can see where the whole team is missing out on important contributions from some members, and we can ask why.
The Naughty Corner
Posted by fe in Lonely Planet on April 14, 2012
At Lonely Planet, it’s not just software development teams that use big visual indicators. In this hack, the guidebook commissioning team wanted to be very clear just what they were working on at any given time.
Here you can see what’s in pre-planning, currently being contracted, which books authors are researching and writing now, what’s in editing, at the printer and has just hit the shops. Also visible at a glance is what is blocked right now – there’s a special naughty corner for books that can’t be researched due to civil unrest. No authors in Libya right now!
I particularly like the little magnetic book covers that they use – visual language everyone involved in publishing can understand, and much more durable than paper and blue tack.
Thanks to Dave Carroll for this hack.
Spotted: LP Commissioning Editors
Who knows what?
Posted by fe in Lonely Planet, LP Content Desk, Telstra Contact Solutions on April 14, 2012
A self-serve training plan.
The team that I work with runs a complex process involving many steps that require specialized knowledge for each step. Their aim is to have everyone skilled up on all the steps, and avoid single points of failure. It was pretty hard for team members to know who knew what, and we needed to be sure when Christmas holidays came along that the few people left knew enough to keep the process rolling.
They came up with a visual to solve this. This grid lists all the steps in the process across the top, and all the members of the team down the side. A half circle means that person has learned the task, two half circles means that they know it well enough to teach someone else. And the little avatars across the top next to each step show who the expert is for that step – and therefore the best person to go to with questions.
As well as being a self-serve training plan – it’s easy to see what each person does and doesn’t know and therefore make sure they learn new steps – it also highlights areas of risk. In this picture we can see that the last step, with only one person knowing how to do it, shows up a pretty big risk if that person is away.
Below, you can see this “self serve university” at a massive scale. This time it covers more than 100 niche skills, and 80 people. The principle is the same: people can mark each skill with either “I know this skill”, “I want this skill” or “I can teach this skill”.
Spotted: SPP Content Desk, Telstra Contact Solutions
Making Sense of Tech Debt, Fast
Posted by nthorpe in If we tell you we'll have to kill you on April 10, 2012
Fabio Pereira uses this method to help teams quickly prioritise tech debt. In this example, the team held a Tech Debt retro where they brainstormed all the technical debt they thought they had accrued since the start of the project.
“Technical Debt” is postponed work created when a team takes some technical shortcuts in order to get a solution out fast. These shortcuts create a “debt which must be paid back later. It’s often hard to know where to start on addressing this “debt”.
The team then classified the debt on two axes this way:
“The relative effort that the team would have to spend in order to pay this debt.“
“Pain is the direct impact on productivity that this debt causes. (interest)”
This made it easy for them to decide what to tackle first. “Lets start on the high value work which takes the least effort”!
Fabio says: “One interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.”
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.
When opportunity knocks…
Posted by fe in Lonely Planet SPP Dev Team on August 26, 2011
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
Highlighting Process Glitches
Posted by nthorpe in Lonely Planet on August 17, 2011
“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
Who’s on fire?
Posted by fe in Lonely Planet SPP Dev Team on July 19, 2011
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