Posts Tagged Team
Feature Burnup Charts are on the Cards
Posted by nthorpe in Telstra Contact Solutions on April 17, 2013
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
Shower Curtain Aids Transparency
Posted by nthorpe in Bankwest, Perth, In the Agilista's Backpack on March 5, 2013
No, it’s not for planning your iteration in the shower. Sorry.
Sometimes, you just can’t get to the walls. Maybe the building police won’t let you put anything on the walls. Maybe there just isn’t the space, or your team isn’t located adjacent to a wall. Portable whiteboards, which are the usual guerilla weapon of choice in this situation, can block lines of sight and available light. And sometimes they get the building police excited, too.
One team decided to take matters into their own hands and create their own Shower Scene. The cards fit into little pockets designed into the shower curtain. Note the little suckers at the top which allow you to stick it up on any smooth surface.
Just one supplier for this product (shop around, people, and let us know where the bargains are!).
Spotted: Bankwest, Perth
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.
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
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