Any similarity between this guy and my desk is
purely… frightening. I
hope these things don’t start moving on their own!
Using information visualization to manage agile projects
You are currently browsing the archive for the Visual management category.
Any similarity between this guy and my desk is
purely… frightening. I
hope these things don’t start moving on their own!
Here are some examples of Kanban boards I built for a friend. I was not coaching these teams, so I did not have any say on the process. My job was simply to build a board that would reflect their current process, using my Visual Management guidelines.
These boards are for a corporate unit that acts as a sort of “enterprise proxy product owner”. They receive business demands from multiple business units, they analyze and classify them, and make a proposal to the customer. They also make recommendations such as build or buy. If the proposal is approved, they send it to development and follow it up into production.
For my first attempt, I was told that there was a special state that had to be highlighted: the “GO/NO GO” state, where a proposal is waiting to be either approved or rejected. So I built this board with a red swimlane to hold kanban cards in that state:
I was very happy with this solution from the visual point of view. Unfortunately they realized that it did not reflect their process accurately so I was asked to tear it down and start over again.
For the next iteration, They identified
four states where something vaguely resembling single-piece-flow should theoretically occur. The four states are “quotation” (yellow) , “study” (blue), “contract” (green) and “execute” (red). The colors are the background color I chose as
a title for the swimlane to visually distinguish it. For each state, there are three sub-states that are not always the same. This is what a finished board looked like:
Note that I used different colored tape to indicate internal columns from state-boundary columns. In the first board I had used gray tape, which I like more than the blue tape in this picture because it connotes better the idea of sub-columns.
These boards were accepted and populated with kanban cards. Each card is a Super Sticky Post-It, representing a customer demand as it flows from being submitted by the business to being deployed into production. Note how immediately upon populating the board the bottlenecks became visible. This board represent the initial state this team was in when they decided to visualize their workflow.
They also put some sections out of the swimlanes for special things. For example jobs that get cancelled or sent back to the business. Those are the boxes you see on the side.
Here is a closeup of the main part of the board.
A good way to know if
your team is using their taskboard to really manage their work is to look at their daily standup meeting.
Does it look like this:
or like this?
A team that is using visual management to manage their work will always do their daily standup against the board. During the daily standup you update your team members on your work. Both work finished the day before and work still in progress should be clearly indicated on the board. It only makes sense to go over the board as you talk. This is both easier for you and easier for team members. It also helps to visually place what you are talking about in context.
If you are using the DONE tag, nametags, status tags and the three columns; then there is a very simple guideline to make sure you don’t forget to talk about anything important every day: do the daily standup
against the board, and make sure all tasks in the middle column (“in progress”) are talked about.
Putting team member pictures on the team taskboard is another good idea. This is particularly useful for large organizations that have many teams and lots of people.
We also use team pictures to do literal “team building” exercises. Every now and then you might want to reshuffle and reorganize the teams. You can take all pictures into a meeting room with a clean whiteboard and brainstorm how new teams would look like. This is a highly visual way of “seeing” and “building” a large team that has to be divided in sub-teams.
pictures below you can see such an exercise with a team of 35 people. We did this when going from component teams to feature teams. In this case, people were pre-divided into groups (based on specialization, domain knowledge, etc). People from each group were not supposed to end up in the same team (this was a way of ensuring cross-functionality and cross-pollination). Asides from that restriction, people were free to self-organize and choose the team they wanted to be in. Based on the number of people, we wanted to create 4 sub-teams. I set up the board like this:
The result after the exercise was finished:
Using pictures allows you to “see” how the teams will look like. Moving the pictures around is very easy and allows you to visualize different team configurations. The visual effect is very strong here.
I go through the effort of making high quality team pictures because they look good and last forever.
I take a decent picture of the person, crop it to a 750×750 pixel square, and insert their picture into a Photoshop template I made (available on request) with the logo of the company and the name of the person. Then I print it in glossy photo paper and plastify it (you can fit 12 pictures per A4 sheet). I cut the pictures out and finally I stick a piece of thin magnet to the back. The result is really good and sturdy, hard to explain in writing but the pictures look great, are solid and stick well to whiteboards. Many people ask for them as a souvenir when they leave the team!
Some people joke that they look like mugshots, and they’re right . But they don’t have to, you can take a nice picture with a blurry background too, if you have the required photographic skills and equipment (a reflex camera and a zoom or fast lens). There’s an example of my friend Katie with a blurry office background in the “Elements of Taskboard Design” page.
I got this idea from the table tennis world. Specifically, from TTC Rooigem in Gent
(where I live). First I did it for my ping pong club and then when I saw the result I thought “Hey, this would look great on my Scrumboards!”. Sure enough, it was an immediate hit… once people got past the embarassment of having their picture taken!
“Unplanned items and legacy issues” is the top row on my scrumboards. Instead of a story, it is a placeholder for:
suddenly have to do and we can’t plan (meaning we cannot put into the backlog as a story). A typical example is reinstalling a PC after a hard drive crash. You might spend all day at this, and you are obviously not going to wait until the next sprint to fix your PC.
Why do I put this on top? For unplanned items it’s rather obvious: this is for things you are doing anyways, and are not part of any story. Most teams simply don’t visualize this type of work, but I like all work to be visible, even if it doesn’t add value. Otherwise the day is gone and “nothing” was done. This way at least everybody knows what you are doing.
Regarding legacy issues, a general best practice is to fix bugs before writing new code, and implement all feedback from the Sprint Demo before starting with new stories. If you follow those guidelines, legacy issues should have priority over new work. (If for any reason it doesn’t, then put it either in the backlog or in the parking lot).
In both cases, we are assuming the work is relatively small. That means tasks, not stories. At most a couple of days of work. For example, during the Sprint demo, the customer might make a small observation that takes one or two hours to fix. A small change request if you want. How are you
going to manage this work? Are you going to create a new story for this? Too much overhead… just put up a task (a post-it) in Legacy Issues, get it done with and forget about it. But be careful with this and always use common sense. If it is story-size work, there is really no excuse not to plan it, it is the PO’s responsibility to tell the customer it will go in the backlog and the best he can ask for is top priority for the next sprint.
Visual management is not just about having visual elements, how you use them is equally important. A bad process can render a good idea useless. And some trivial ideas, with a good process behind them, can produce interesting results.
The DONE status tag is a process related idea. It is a creative way to visualize flow, give teams a moment to celebrate their achievements, and to ensure team alignment and communication; all on a daily basis.
The concept is simple. During the day, team members work on tasks that are in the “In progress” column of the task board. When they finish a task, instead of immediately moving it to the “Finished” column, they slap a DONE tag on it. And
there it stays for the rest of the day, broadcasting to the world that the team has finished some work. This is the flow part: at a glance, at the end of the day you can “see flow” by scanning the boards for DONE tags. The more blue, the more flow. Managers and Product Owners like this.
The celebration part comes during the daily standup. Here, the team gets to move all their DONE tags to the Finished column, creating a small daily moment of pride. Naturally it
should be the person who finished the task who talks about it and moves it.
What about alignment and communication? By moving all DONE tasks at the daily standup, you basically ensure that everybody in the team is aware of what is getting finished and by whom. This is actually how the idea came up. Team members were moving tasks to Finished during the day, and then at the daily standup they would forget to talk about stuff. With lots of tasks in the Finished column, it was getting difficult to remember which ones were new from the day before. And if you have One Day Tasks, believe me, this is going to happen, especially with the most prolific developers who get a lot of stuff done. The idea was to come up with a foolproof process that would guarantee people would talk about everything they finished the day before without requiring a special effort on their part. This worked, and people liked it.
So the general guideline for using the DONE tag is:
Another curious thing I discovered is that sometimes team members forget to talk about something they finished the day before, even if it is in the “In progress” column and has a DONE tag on it. But in this case it is easy to detect: if after the daily standup there are still DONE tags remaining, either they forgot to talk about it, or it was done by a team member that is absent that day (in that case, unless he went on holidays, teams normally wait for him to come back so as to not steal his achievement).
The truth: no special reason. I just randomly chose a nice looking color. But then I found out that blue represents “good” in japanese, so -being these tags a Lean idea- this actually gave it some meaning. (For the curious: I learned this through a lengthy debate with Kohsuke Kawaguchi, the author of the Hudson CI engine. Hudson displays a blue screen instead of a green screen when the build is OK.) Blue also has very good contrast with yellow, making it easy to visualize finished tasks from afar, as you can see in the above picture. But there is no special reason for blue, and I have seen that some teams prefer using green for DONE.
I tried out for the first time my session proposal for Agile 2009, thanks to my friends at iLean who invited me to give their free monthly iLearn session in Kontich (near Antwerp). In this workshop participants are divided into teams and challenged to come up with the “ultimate taskboard” for the newly appointed CEO of their company. After a first iteration where
basic boards are built, the work is criticized by the CEO and then it’s back to the drawing board as more requirements are added.
Asides from the basic “who’s doing what”, teams are expected to come up with creative, visual ways of showing daily project issues such as “a team member’s hard drive crashed and he spent all day reinstalling his PC” or “a team member is sick”.
Thanks to all the people who participated! Workshop pictures follow.
The purpose of nametags is to be able to quickly and easily see who’s working on what. I love nametags. I haven’t been able to come up with a simpler, more practical and more flexible way of achieving this level of transparency and visualization.
I like nametags because:
Usability is very important when designing your visual elements and processes. It is important to distinguish between nice and usable. Both are good, but usable is more important. Let’s examine a couple of other ideas for achieving the same goal, and see how they fare against nametags.
Idea 1: Scribble the name or initial of whoever is working on the task, on the task itself.
This is the “default” method that many teams use. I don’t like this idea at all. It’s neither nice nor usable. It looks bad, is not very readable, and in practice it is never maintained. What happens if you get blocked? Do you cross your name out? And what if another person starts working on the task, with or without you? Do you add his name? What do you do with your name? And what do you write, your full name or your initials? Initials are not very readable.
Idea 2: Small round magnets that have a picture of each team member (this also applies to magnets with initials, or any other physical artifact that represents a team member)
This is a typically nice idea. It probably looks great and it’s kind of funny. You would see people’s head all over the board. Wacko! I like this idea, and one day I will try it out. Although I suspect that looking at a picture of someone’s head is not as simple as reading a name. (You still have the pictures of team members on the board in case you want to see who the person is. But I haven’t talked about that yet). Obviously team members know who everyone is, but for people outside of the team, this is not the case. So using pictures to indicate who is working on what might actually makes the board less readable to people outside the team. Gotta be careful with that. And if you are using initials or color coded magnets or little cute pokémons, it’s even less readable. Too many mental connections to make to see who’s doing what.
But the main reason I haven’t tried these picture-magnets is practical. It takes time and money to build little magnets with team member pictures on them. And how many do you make? What’s the maximum number of tasks people will be working on in parallel? You would be surprised. No matter how much you encourage people to not parallelize, all kind of stuff happens in reality, and you need to have a flexible process or people will not follow it. People start stuff and get blocked, or have to wait, or the task needs to be worked on by two people, or suddenly you realize three different tasks defined during sprint planning are actually the same and should be done as one so you check them out at the same time. Magnets, magnets, magnets. You’re probably not going to have enough.
How to build the nametags: these are actually Post-It “Notes Markers” (product code 670/5) with a little bit of Magic Scotch tape at the end (because they’re not Super Sticky – just like status tags). They cost next to nothing and
you get 100 of each color. They are 15 x 50 mm.
You can also cut nametags yourself out of colored paper, but why would anyone go through the trouble. I would only do that in
countries where you cannot find these post-its.
“Less is more”. You heard this before, right?
This applies particularly to visual management. It is very easy to generate noise by creating visual elements that are not strictly necessary. When designing our information radiators, we should always be careful not to create waste. And any visual element that doesn’t add value is waste.
Of course, sometimes it’s not that easy to figure it out. For example: suppose you run out of yellow Post-it’s, and you see some green Post-it’s lying around. Should you use them, or is this waste?
By using another color, you are creating “something”. There used to be one color, now there are two. People will look at the board and wonder: “What does green stand for? What’s the difference between green and yellow?”. And
there is none, you were simply out of yellow. So in this situation, using green is waste. You are also killing off your possibilities of giving green a specific meaning in the future, which you might will need.
But on to status tags and the three columns, the main topic of this post. It’s time to design your taskboard, and you have to decide the most basic of things: how many colums do I make,
and what do I call them?
If you are doing Scrum, and you agreed with One Day Tasks, you will probably be tracking the flow of tasks (not stories) across your board.
What’s the simplest solution that will work?
A unit of work can have three basic states: “Not Started”, “In Progress”, and “Finished”. Most taskboards that have more than three columns are breaking up “In Progress” into intermediate, sequential phases. Typical example: “To Validate”.
There are many reasons why I would try to avoid using additional columns. It promotes specialization and local optimization. It creates two processes and a buffer where there could be a cell and single piece flow. It’s waterfallish.
But the most important reason -from the visual management perspective- is that it creates extra visual elements (more columns). It also uses more taskboard real estate, which can be scarce. All this is waste.
A good way to eliminate the need for extra columns is to use status tags. For example, instead of adding a “To Validate” column, we can solve the same problem with a PLEASE TEST status tag that you stick on the task. Practically any sub-state of “In Progress” can be represented by these status tags; which are smaller, less intrusive and more flexible visual elements than columns. They are also color-coded which makes them even more powerful from the visual perspective.
So unless you’re into Kanban and you really know what you’re doing, I highly recommend you stick to the basic 3 columns. (And we’ll discuss Kanban another day, because I think status tags and the 3 columns might also be applicable there. For example, you can limit work in progress by limiting the number of available status tags.)
The Post-it’s I use for status tags are product number 653, 51 x 38 mm in size. I use two different color sets, that gives you around 6 total usable colors (there is some overlap between sets). I also put a very small piece of Scotch Magic tape on the top, because they are not Super Sticky.
The status tags I use will be discussed individually in separate posts.
day tasks are tasks that take -in theory- up to one day to complete by one person, or by a pair of people in the case of pair programming. Creating tasks of one day maximum size gives two benefits to the team. The first is that under normal conditions it creates visible daily flow. Meaning that if nothing goes wrong, one task will be finished (on average) per team member per day. So if a team has 8 members, theoretically they should finish 8 tasks per day. But in Agile teams, people work in pairs a lot, either pair programming, or a coder/analyst-tester pair, so in practice it should be around half of that that gets finished. And effectively, my experience is that in healthy 8-member teams, you should expect to see around 4 DONE tags per day.
Without one day tasks, you will end up with a story with only one or two Post-its, where nothing ever moves and during the daily Scrum a team member says “I’m still working on this… yep… still some work to do, still working on it.”
The other advantage of having one-day tasks is that it is great way to see if the team has really analyzed the story or not. Sprint planning blues? Having one day tasks forces the team to think about what they really have to do to finish that story, to a good level of granularity that is later on easy to follow up. The big effort is not in writing the Post-its, it’s in thinking what has to be
done in those 1-day chunks.