The power of Visualization used in my current project

Posted by Marcus Hammarberg on January 21, 2011
Stats

I’ve been involved and coached a project with several teams during the last year. The project aims to convert a big (and important) core business system from VB6 to the .NET platform.

It’s quite a big project with about 25-40 member (depending on which phase it’s in) and so we have several different teams working in parallel during the whole project. But it’s not until lately we’ve created an board to show the status for the whole project. Mainly due to high load in other areas of work, I have to admit.

This post will be a long one. But with lot of pictures so I hope you wont be boredWinking smile

I’ve been involved and coached a project with several teams during the last year. The project aims to convert a big (and important) core business system from VB6 to the .NET platform.

It’s quite a big project with about 25-40 member (depending on which phase it’s in) and so we have several different teams working in parallel during the whole project. But it’s not until lately we’ve created an board to show the status for the whole project. Mainly due to high load in other areas of work, I have to admit.

This post will be a long one. But with lot of pictures so I hope you wont be boredWinking smile

Project status board

In order to easily and effortless communicate the status of the complete project we have created a board on the project level that captures the status for each team. This is our first try to do this:

project status board

Note that we’ve started quite simple to only show the status, problems and work in progress for each team. Later on you probably want to be able to track resources to spot queues and bottlenecks building up easier.

Here are some details on some of the visualizations we’ve used

Status per team

status per team

Each team are communicating their status by the use of three visualizations:

  • A traffic light (Red, Green, Yellow) that answers the question; “Do we think that we will make our deadline?”
  • To the far left they also show the number of items left in their respective backlog.
  • For each team there’s also noted their deadlines and other important dates to work against.
  • Finally on the right of the board there’s a section for any problems.

So with this there’s several ways to quickly get the status of the project. The easiest is just to scan the traffic lights which gives you an feel for how we’re doing.

Other project level information visualized

We’ve also put up some other stuff to help people to understand the board and our project.

An easy example of that is the key or legend that show how the traffic light are to be interpret:

legend for the board

Here you can see the project overall time schedule, the organization of the project and other projects at the company that are dependent on us (and deadlines for them):

project information

We also have all the tools needed to add or change stuff nearby:

tools

Different teams, different backlogs, different methods

One really challenging part of when taking in a project with several teams like this is that different teams work on different thing, in different speed and with different methods.

This is manifested in “funny” (?) in the section showing the backlog where the rows for each team right now says:

  • Team 1 – 18/24 backlog items left
  • Team 2 – 97/97 items left + 1/1 for an other little thing that doesn’t fit into their normal work (?)
  • Team 3 – 6/8 items left. Each item takes about 4-8 weeks to complete though.
  • Team 4 – 250 / 270 items to complete.
  • Team 5 – No known backlog. This is a maintenance team that gets work through a mailbox. About 15 work items passed through their lane on the board each day.

So, as you probably can understand each team have chosen different approaches. We have two Scrum project that uses sprints and well defined backlogs for the sprint and for the whole “sub-project” (a.k.a. product backlog for the team). Here are their boards:

scrum team 1 scrumboard

scrum team 2 scrumboard

Phases for cross cutting concerns conversions

And we have a development team that converts a big VB6 client GUI to .NET. They work in phases for about 1-2 month each. There is no easy way to visualize their work since they are tackling crosscutting concerns through the complete system. For example:

  • create and implement a new data access strategy through the whole system
  • remove all the Visual Basic 6 references that still is left in the converted code.

The complete backlog is just a couple of items. But they have to be done through a complete system. Here is the backlog (as it looks now):

dev team backlog

So instead we listed all the forms from VB6 (270 forms!) and estimated them in S, M, L and XL. We could the create an excel sheet that shows our progress as we go through all the code in each phase. Here’s an example of the excel sheet from a late stage in the current phase:

dev team status

With this in place we could even show how “badly” we estimated in the outset. But I’ve already written about that.

Test a phase oriented development team

To test this we have aimed to write automated test using SpecFlow and White (see this (and yes this is NOT BDD but it’s a great way to get business readable automated test scripts)). Their challenge was that the code they are testing (from the GUI Dev team) changes. A lot. And often. So we HAD to automate the test. Also no-one tester are full time in the project. They all have other tasks as well.

So the backlog is simply a list of all the features of the system (here’s a part):

test team backlog

And the board is a Kanban board using many visualizations:

test team kanbanboard

Note the exit criteria at the bottom that sets the expectations or definition of done for each stage. They have also proven to be a great support for people to remember what to do next.

Conclusion

With this post I wanted to show some of the way we have used different visualizations in our project. I’ve learned a lot by it and especially the power of just putting up stuff on the wall. If you can’t see your work probably no-one else will either.



Published by Marcus Hammarberg on Last updated