Task boards

You are currently browsing articles tagged Task boards.

Status tags revisited

Status tags are my preferred approach to visually attaching state metadata to work items.

In plain english, what this means is that if you have a task, represented for example by a standard size Post-it, you would add a physical tag, represented by a smaller colored Post-it, to indicate it has some particular status, such as “Blocked” or “Delegated” or “Bug” or “Please Test”. This creates visibility and awareness and enables the right people to react to that new status fast.

A visual alternative to tagging is creating special columns or specially designated areas in your taskboard that fulfill the same purpose.

While this is valid, and many people do it, I much prefer tagging to that approach. Taskboard real estate is expensive. If you start creating special areas or columns for each status a piece of work can have, you might quickly fill your Taskboard with empty zones. Furthermore, changing the structure of your taskboard is cumbersome. This might limit the number of status areas you create. Too many areas and columns make people think about waterfall processes, even if they are not meant to be used. For example, look at the picture of the following kanban board:

While it looks good because it was done with care, there is much wasted space in those columns and boxes. And let’s take a closer look at those separate areas at the right. In this example we see a “Back to business” box. What if this status is very temporary? In that case, you are probably better off tagging it. Creating the box has allowed work to accumulate there, unchecked. Are all those post-its supposed to be going back to the main board? Someone is going to be spending some serious time moving post-its back and forth…

Another example: let’s assume a task that involves coding but is functionally testeable is being developed. During the same day the following happens:

  • A developer starts and finishes it
  • Someone else tests it and finds a bug
  • The original developer fixes the bug
  • The task is re-tested and this time declared “done”.

This is a typical scenario in Agile teams. If you have separate columns for “In development”, “To validate”, “Defect found”, you are going to spend the whole day moving the task around columns. People might lose track of where the task went (well, not really – but it does require more effort to locate it). I prefer the much simpler solution of leaving the task in place and rotating status tags on top of it. Another advantage: if it would go through this code-test-bug-fix cycle many times, you can place status tags on top of others, creating a “traceability” effect. With columns, you can’t do that.

Tagging is very flexible. There is no limit to the number of tags you can create. Some teams create temporary tags for special occasions. In the example above, the tag “checked” was created specifically for the occasion. This can be done quickly and easily by the team by their own initiative. Almost no work is required and suddenly your visual management process includes a new status.

I think the elegance, flexibility and visual appeal of using colored tags for indicating task status cannot be denied. Even in a software tool, it looks good, as the example below shows.

For physical taskboards, my preferred tags are Post-it 653 which come in many different colors. They are the 1.5″x 2″ small ones.

Important detail: if you just stick this small post-it onto a bigger one, it will not stick, it will fall off almost instantly. That’s why I use a small piece of Scotch Magic tape with each status tag. See the first picture in this post for a detail.

Build a taskboard in 10 steps

In this tutorial I will explain how to build a physical taskboard out of electrical tape step by step, for those of you who -like me- were not born with a gift for bricolage. I admit up front to this post not being my most intellectual piece of work ever, but I’m hopeful more than one of you out there will find it at least marginally useful.

I will demonstrate using a 120 x 90 cm whiteboard, the smallest format that will support a small team board. Magnetic whiteboards make great task boards because the surface is so versatile: you can write on it, you can stick magnets, post-its stick and unstick very cleanly, so does Scotch Magic tape, and -most important for this case- so does electrical tape, which is what we will be using to make the lines. That means that if you make a mistake, you can just unstick and re-stick the tape, though it will never be as easy as the first time around. The downside, of course, is that they are expensive and/or not always available for hijacking in your office. That’s why I advocate building boards wherever you can: I have built boards on the back of closets, directly on walls, and even on windows (looks cool at first, but later it’s very distracting – your attention always ends up going to what’s outside).

What you will need:

  • 1 ruler
  • 1 roll of electrical tape
  • 1 whiteboard marker
  • 1 pair of scissors

Note: if you don’t have a whiteboard, electrical tape might ruin your surface (for example it might peel off low quality wall paint). A good alternative is thin blue painter’s masking tape.

Step 1: This is how our whiteboard looks before starting. If you did not buy a new board, make sure it is clean of any old whiteboard marker ink, old pieces of scotch tape, etc.

Step 2: Make two small marks at 25 cm from the left side of the board, one should be around 5 cm from the top, the other almost at the bottom.

Step 3: Press the tip of the tape with your thumb on the top mark.

Step 4: Carefully extend the tape out and downwards, without touching the board, making sure you do not pull too hard on the tape. Electrical tape is elastic, and if you pull, you will stretch it and stick it in a stretched state. Later on it will contract to its original length, unsticking and curling upwards, ruining all your great effort. (It took me several cases of shouting “Who sabotaged my taskboard!” in vain to figure this out)

Step 5: With the tape still only touching the board at the point pressed by your thumb, carefully bring down the roll of tape onto the bottom point.The full roll should be resting on the bottom dot. The tape will now be touching the board but only lightly.

Step 6: Carefully pass your thumb upwards over the entire tape, which should stick cleanly and nicely to the board.

Step 7: Cut the tape at the bottom and voilá, you should have a perfect line.

Step 8: Repeat 3 more times, each line 25 cm from the one before it. You should now have 4 vertical lines.

Step 9: The horizontal lines should be placed in a similar way. First put the bottom line on the bottom of the board. Then measure upwards at distances of 15 cm. You should be able to place 6 lines.

Step 10: Add any additional sections you wish in a similar fashion. Then add little signs for the columns, status tags, nametags, team pictures, and you are ready to start scrumming!

For the electrical tape, I recommend 3M Temflex 1500. This tape is cheap and high quality and in Belgium can be purchased at the Brico for less than 1 euro the roll. Look for these packages of 10 rolls if you are going to build multiple boards for different teams: you get all kinds of colors.

This is my recount of my session at Agile 2009 Chicago. It was titled “Visual Management for Agile Teams” and was part of the Manifesting Agility stage.

VMW Agile 2009

The session went well, around 36 people came and left 27 session reviews. Many people found value in the practical, down-to-earth approach of the workshop, leaving comments such as “excellent hands-on demo”, “extremely applicable information”, “finally something hands-on practical” and “very helpful”. Review averages were: Met expectations 4.4/5; Would recommend 4.3/5; Presentation skills 4.1/5; Command of topic 4.6/5; Matched description 4.4/5 and Overall 4.4/5.

I changed the format and structure of the session a little bit. First I gave a short presentation to introduce the topic. I was nervous and it showed… I’ll do better next time. We quickly moved on to starting the workshop itself. Each team was given a bag of office supplies and a blank taskboard. They set themselves up around a table.

XQA_9475

The format of the workshop is simple: teams have to build taskboards, following some guidelines such as “the boards must show who is working on what”. The first round gave teams 20 minutes to figure out what they were going to do and how to implement it. Here is the red team getting busy:

VMW 1

The blue team had a good idea: they did a rapid prototype on a paper on the wall, and only after that started building their taskboard.

Visual Management Workshop at Agile 2009

More taskboard building:

XQA_9456

After a first round of taskboard building, people spread out to review other team’s boards.

XQA_9479

Some stayed behind to present and defend their boards…

XQA_9467

Finally, we did another round of taskboard improvement with new requirements, and another review session. To close, I presented my own version of the taskboard that I had built the night before in the hotel room.

XQA_9508

Results

These are the final taskboards of all four participating teams, with comments.  Click through to see a larger version of each taskboard. My comments are meant to show how each team approached a certain problem, the idea is to point out to the reader the different ideas that emerged.

Blue team

XQA_9557

  • They found and put up some team pictures. They used them to assign a color to each member and used colors as nametags. The only problem with this is that with a larger team you will run out of colors.
  • They created an “URGENT” swimlane for expedited work. It is clearly distinguishable with a different color tape and a header. It is at the bottom, but they said during the workshop that if they would have had more time, they would have refactored their taskboard and put it at the top. Very good solution.
  • They used red stars to indicate all impediments. I’m not so sure I would use this, as stars connote something good to me. But you can certainly see impediments clearly.
  • They re-wrote their story cards in big blue post-it’s; other teams simply stuck up the printed stories.
  • They put columns for “QA” and “Done Today”.  In the QA column there is a single small yellow post-it that says “BUG”. No idea where the bug is though.
  • Each story has tasks of a different color. There does not seem to be any significance to this other than visually pointing out that tasks belong to different stories.

Red Team

XQA_9556

  • They put their project backlog on the leftmost column. From there, they can “pull” stories into the Sprint backlog. When an urgent story came in, they placed it on top.
  • They have a column “WIP Blocked” and next to it “WIP”. Another column is called “Done today”.
  • They have a calendar that shows at what moment during the week they have Planning, Retrospective and Release. This allows me to see that they do 1-week iterations.
  • They used different colored post-its to indicate different types of specialist work. This is a very good idea (where it makes sense). In the bottom right hand corner is the color legend.
  • They did not use the red electrical tape to make their swimlanes, instead opting to go for a blue masking tape. This makes it harder to identify them as the red team.

Yellow team

XQA_9559

  • I like how this team kept their board “clean”, in comparison with other teams. Also, they put the most effort into making sure their swimlanes were tidy.
  • They have only 3 columns, yellow post-its and few elements, keeping the board clean and uncluttered. It is much more relaxing to look at.
  • They used red stars as nametags. Each star has the name of a team member written on it.
  • They used small green post-its as “DONE” tags. They put their DONE tasks on the Complete column, so during the daily standup all they will do is remove the green tag I assume.
  • They move finished stories to the 3rd column together with all the tags. For some reason, they finished the least priority story first. They seem to be working on everything at the same time.
  • Pink post-its indicate a special situation is happening with that task.

Green team

XQA_9558

  • The first thing you notice is that this team opted for no horizontal swimlanes. This makes the board lighter and cleaner, but might cause confusion as to where tasks belong. To compensate, they gave each story different colored tasks as we saw the Blue team did before. This is an interesting design alternative to consider.
  • Another original idea is the use of Post-it flags as status indicators with a clear legend on the lower right hand corner. Some examples include “defect found”, “retest”, “urgent” and “blocked”. This is the first time I see it and I want to say that it is an interesting idea. The Post-it flags are unobtrusive and easy to detach. I will add Post-it flags to the Elements of Taskboard Design page.
  • They also have the Product backlog on the left-hand column and pull stories into their WIP backlog like the Red team.

Xavier’s board

XQA_9442

For completeness, here is my board. The only new thing if you follow my blog is that I decided to use pink post-its instead of yellow post-its for normal tasks, simply for effect. But I didn’t find any value in it and actually the pink color is too noisy. So I will definitively stick to yellow (there are economic reasons for using yellow for tasks too – yellow super stickies are cheaper)

Conclusions

I want to thank all participants for coming to my session. I think the session was a success, and each team left me with new ideas and lessons learned.

  • From the Blue Team, I learned I can create a priority swimlane which is visually clear.
  • From the Red Team, I learned to use colors to indicate the nature of work. This could be used to visually identify the need for more specialists for example.
  • From the Yellow Team, I learned the value of keeping it simple and clean. Overloading your board with elements and colors creates visual saturation and is tiresome to the sight.
  • From the Green Team, I learned to use Post-it flags as status tags. They are small, elegant and unobtrusive.

I also wish to thank the following friends who helped me out: Mark Levison for all the advice before and during the conference, Karl Scotland for helping me during the session and for motivating me, Dan Mezick, stage producer, who came to visit during the session and seemed to really care about the quality of his stage; Tobias Mayer for always supporting me; and above all my sweetheart Joke Vandemaele without whom I would not be able to do any of this.

Thanks to you all!

PS: If you missed this session and would like to attend, I will be doing a short version of it at the Agile Eastern European Conference in Kiev next week. Registration for the conference is still open!

agileee_banner_speaker_205x130_thumb

It will also be presented at Agiles 2009 in Florianópolis and at XP Days Benelux 2009. See you there!

Scrum of Scrums detailIn Scrum, the “Scrum of Scrums” is a way to ensure alignment and coordination across different teams, or among different sub-teams of a large Team.

How big is the Team?

A Team is a group of people collaborating towards a common goal. Sometimes it’s not that easy to pick your goal, and thus figure out who the Team is, or who it should be. On one hand, small teams are good. Small is simple, small is beautiful.  So maybe you should pick a small goal, and make a small Team.

On the other hand, you should try to look at the system as a whole. This could mean anything: a project, a department, the whole company… What is the ultimate system, but the Organization itself? Your whole company is the Team, from the Systems Thinking perspective. Especially for small companies. So maybe you should think of a large Team.

Most likely, we need to strike a balance between these two dichotomic approaches.

I have found my comfort zone with a simple, practical definition: One Team, One Backlog.

Splitting it up

Banana SplitLet’s assume you found your definition of Team, and you have more than ten people in it.  Since the ideal team size is 5 to 9, you probably want to split them up. But you don’t want to lose the concept of  one Team. The recommended approach is to break them up into sub-teams. I will discuss some ideas for creating these sub-teams and for visualizing their work, while trying to keep and respect the spirit and vision of the one (big) Team.

Feature teams

Using the same logic regarding why it is interesting for team members to be as cross-functional as possible, the best strategy for making sub-teams is to create cross-functional feature teams, as opposed to ‘component’ teams or -god forbid- teams that specialize in a certain technology or skill (like  ‘QA team’ or ‘.Net team’).

Feature teams are teams that work on features, i.e. stories. Pieces of business value. They are value-driven teams, whereas other sub-team splitting strategies (component, skill, etc) create function-driven teams that invariably fail to deliver business value and create local optimizations and waste.

You create your feature teams by spreading out the knowledge, skills and experience equally. The goal is that any team can do any story in the backlog.  You should stress that the “real” Team is the big one. Sub-teams are just created for communication and coordination purposes. In my opinion, they should not develop too strong a team identity. For example, I would not measure sub-team velocity, and I would make sure people rotate from sub-team to sub-team a lot.

You can then work with a single, large backlog and distribute stories in round-robin fashion.

Colored teams

I like to give sub-teams a color for a name. E.g “Red team”, “Blue team”, etc.  Colors are very visual and we will be able to use this to our advantage. For example I use electric tape of the same color to create their taskboard, which gives them an immediate strong visual identity (see picture below). Another reason colors are good is that they are non-hierarchical, and people don’t attach themselves that much to a color.

colored_boards_small

The Black team

In large projects, particularly in transitioning organizations, there are always some people left floating around that are not doing any actual work at team/trenches level.  I put them in the Black team. This is a pseudo-management team that mostly combines the responsibilities of Product Owner and Scrum Master (in the same team, not the same person!) and any other role that you either want to share across teams or that you simply can’t get rid of.

Typical examples of people who we have put in the Black team include:

  • all the ex-Project Managers, who now had to remove impediments full-time (they also had a lot of administrative work to do: fake Gantt charts, fill in timesheets, useless reports, etc)
  • the Agile Coach
  • the Product Owner(s)
  • an Architect from Architecture (we later convinced him to move into the trenches with the real teams)
  • a QA Team Lead who didn’t want to test (we later got rid of him, once the testers he used to C&C were doing agile testing)
  • a Release Coordinator, whose job was to beg to Infrastructure to deploy our app into production (this was a full time job)
  • etc.

As you can see these were mostly roles that existed because we were doing Scrum within a traditional large organization. In any case, the idea is to group all these people into one “team” so as to not leave any loose ends. Ideally they will jell and work cooperatively, otherwise at least you can visualize their work by putting up a taskboard for them. For example on this picture below, most tasks are either impediments or things that have to be delegated to people outside of the Team. The horizontal lines are not stories but simply priority slots, i.e. High Priority, Medium and Low. If I would have known at the time, I would have put WIP limits, because nothing was ever getting done here. :D

Scrum Black Team

The Scrum of Scrums

Ok, let’s move on to the interesting part. Each sub-team has their scrumboard with the stories they have selected for the current Sprint, divided into tasks as usual. How do we visualize what is going on at Big Team level? How do we keep track of so much work? We need to change the level of granularity. In the Scrum of Scrums, you only visualize stories. You create the “Scrum of Scrums storyboard” where every story that is currently open is visualized, with the team that has it and the current status indicated. The picture below shows such a board at the beginning of a Sprint. Click on the picture for a larger version. Note: This is actually the same physical whiteboard as pictured above… you are just looking at the other side! The Scrum of Scrums side is pointing towards the hallway, so passer-bys can look at it.

Scrumboard Scrum of Scrums 1

There are only two columns: “Story” and “Status”. Story has a copy of the story card that is on the team board. Status is normally “not started, “in progress”,  “done” or “done-done” (a curious distinction between “we think we’re done” and “we’re sure we’re done”). This last done-done was indicated with a red star. Each story has a little magnet indicating which team is working on it, but we also experimented with other visual elements like creating status tags of the color of the team. In this example you see both at the same time: a Green Team story will have a green “in progress” tag, and also a green magnet.

The mechanics for the Scrum of Scrums are simple: after the daily Scrums, each team sends a rotating delegate to give a brief status report on each of their open stories to the other delegates and the Product Owner. The delegate is then responsible for updating the rest of his sub-team members on what’s going on at project level (something that never happens, but oh well). Of course sometimes a lot more people show up during the Scrum of Scrums. Anybody who is interested in knowing what’s going on at Big Team level goes.

Note: The black and blue tape indicate nothing in this case, we simply didn’t have enough tape of the same color, and our boss was a fan of Club Brugge (whose colors are black & blue), so we made it for him.

This is how the board might look like towards the end of the Sprint, on a good Sprint where lots of stuff got done. (Click for large version)

Scrumboard_Scrum_of_Scrums_2_small

Note how you can quickly visualize different types of problems.

  • Several top priority stories are not getting finished. In particular the #1 top priority story.
  • The yellow team seems to be in trouble. I see 3 yellow “in progress” and only red star with yellow magnet. Also comparing yellow to green, red and blue you can see the difference.

If you looked at the large version of the picture, you probably noticed those white horizontal lines that say for example “End of Sprint 9 Demo: 8/Sep”. This is a visual way of indicating what was the scope taken for Sprint 9. The point here is that this was a Team that was not delivering all they started, and was dragging along open stories. Some stories were blocked, others underestimated, some teams had sick people… for whatever the reason work wasn’t getting finished, and since it was not possible to limit WIP for political reasons, we just let the teams take more work, keeping existing stories open. But with this board at least the situation was kept clearly visible and the Product Owner knew perfectly well what was going on.

A last picture with some comments, in a style similar to my original “Scrum Board with Comments” picture:

Scrumboard Scrum of Scrums with comments

In Visual Management for Agile Teams, I discussed the importance of usability and good design when building our taskboards. Today I want to focus on how we write our tasks, and try to make a case for increased readability.

Readability

Readability is defined as “how easy it is to read something”. There are two meanings, as in “a readable handwriting” and “a readable book”. In this case we will focus on the first definition as it applies to answering the following question: how easy is it to read the tasks on our taskboard?

thick_black_marker_500

Readability will always be somewhat subjective: what could be perfectly readable for me, could be unintelligible for you. But let’s try to agree on a general readability acceptance criteria. I propose the following:

Tasks should be easily readable and understandable by a person with normal sight from a distance of around two meters.

Why two meters? Because it is a reasonable (maximum) distance from the board you can expect people to be standing at during the daily standup meeting, and when passing by.

In order to achieve this, we have to comply with two simple guidelines:

1) Small amount of text: tasks should have no more than 10 words, as a rule of thumb.

2) If handwritten, text should be written in big, bold, capital letters.

Avoid documenting

Tasks should have no more than 10 words because fitting more text into a 3×3 inch (76×76 mm) standard Post-It forces you to write too small, and we want to avoid that. But there is also another reason. You shouldn’t need to write a lot of text if you understood the nature of tasks and how to use them in your process. Tasks are meant to be pointers to the work that has to be done. Reminders. Not a full analysis or description of what has to be done. The goal of a task is to represent a unit of work. The details of the work should be in the person’s head, having been discovered and defined by having conversations with the other team members. We should avoid documenting tasks on the post-its as much as possible. We should also avoid using sticky notes as “documentation hand-offs” between team members.

The reason for using bold letters is to increase readability of the text. Bold is required because of the distance we want to read from, and the size of the font we want to write in. Writing 10 words on a standard post-it in ballpoint pen in a text size that fills the post-it would result in a font that is too lightweight and disproportioned. Most likely what will happen is that people will write the 10 words in a very small font, thus rendering it illegible from the required distance.

The reason for writing in all capital letters is that lots of people have bad handwriting, or write in cursive when not writing capital letters. This makes a task difficult to read even if it complies with the 10-word rule and is written in big bold letters. We are not trying to learn to decipher your doctor’s handwriting here, thank you. See above example in orange.

Readability creates transparency and trust

Readability of tasks is cornerstone to generating and sustaining the feeling of transparency and trust that taskboards have the potential to transmit. To achieve this, the taskboard has to invite to be read. Avoid the following readability anti-patterns:

  • Difficult to read handwriting
  • Small text
  • Text written in ballpoint pen or pencil
  • Text written with colored markers.
  • Text written with whiteboard marker or dried up markers.

Read it from your desk

If tasks are readable from two meters without effort, they might also be somewhat readable from a distance of up to 5 or 6 meters. If the taskboard is in the work area, chances are most desks will be located within this radius. This means that team members might be able to read the taskboard from their desk, something desirable. As an example, in the picture below, most desks are within reading distance of their taskboard.

XQA_0250

The thick black marker

A black permanent marker with a rounded tip is the only writing tool you will need. If you take care of it well (you close the lid carefully and don’t press too hard on the tip when you write) it will far outlive your project. They are also very cheap and it is not unreasonable to give one to each team member.

There are several brands in the market. I have tested many of them and my top recommendation is the Edding 3000 which I can get for around €1 a piece here in Belgium.

Edding3000_firstprize

Top contenders and good substitutes are the Sharpie classic and the Artline 70N.

sharpie_artline

What you are looking for in a quality permanent marker is:

  • rich, solid black ink
  • ink dries fast, doesn’t smear
  • doesn’t bleed on Post-it paper
  • lasts long
  • cap fits on the back (so you don’t lose it), and is easy to open and close

As an extra, the Edding 3000 and some other brands come in a mini-marker version which is ideal for the purse of the lady Product Owner or the pocket of the gentleman Scrum Master. :)

Daily Scrum against 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:

standup1

or like this?

standup2

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.

marc

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.

Team pictures

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.

team_pictures

Benefits of team pictures

  • Helps create team identity (together with a team name) “This is who we are. We are the Blue Team and these are our members.”
  • Helps you match faces to names when looking at the board, especially if you use nametags.
  • Eliminates all uncertainty regarding who is in what team. People get one picture and can only belong to one team.
  • Helps find people in large offices. “You have to talk to Susan from the green team. You can see her picture on their board”.
  • Changing teams, or going on loan to another team for a Sprint, is as easy as moving your picture and nametags from one board to another.
  • We turn around a picture to indicate that the person is not present today. This helps you not lose time looking for people that aren’t there.
  • We also put cell phone numbers of team members on the back of their picture. No more going crazy trying to find the number of Johnny!

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.

Visual Team Building exercise

In the 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:

dsc_0481

The result after the exercise was finished:

dsc_0492

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.

How I make the team pictures

I go through the effort of making high quality team pictures because they look good and last forever.

mugshotsI 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.

Footnotes & Credits

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!

The DONE tag

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 DONE tag

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:

  • You should only move tasks to the Finished column during the daily standup.
  • You should only move tasks that have the DONE tag on them and you did yourself.
  • Once you move them to the Finished column, remove the DONE tag.

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).

Can you quickly spot the finished tasks?

Can you quickly spot the DONE tasks?

Why blue tags?

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.

Visual Management for Agile Teams

Introducing the Visual Management Blog, a space for the discussion of ideas and examples of Visual Management applied to Agile teams and project management.

What is Visual Management?

Visual Management is the practice of using information visualization techniques to manage work. A simple example is using sticky notes on a wall to manage a list of tasks, a better (and more complex) example is kanban. Many visual management ideas come from traditional Lean thinking and Toyota, but these techniques are also very popular within the Agile Software Development community.

Benefits of Visual Management

Visual management is generally regarded as a clear, simple and effective way to organize and present work . It can also be perceived as fun, since visual elements bring color and life into an otherwise boring office environment. Another benefit of visual management -often overlooked- is that it can positively influence the behavior and attitude of team members, managers and stakeholders. How? For example, by helping build transparency and trust.

Information Radiators and Visual Management

red lava lamp

“Information Radiator” is a popular term invented by Alistair Cockburn that is used to describe any artifact that conveys project information and is publicly displayed in the workspace or surroundings. Information radiators are very popular in the Agile world, and they are an essential component of visual management. Most Agile teams recognize the value of information radiators and implement them to some degree in their processes. The three most popular information radiators are Task Boards, Big Visible Charts (which includes burndowns and family) and Continuous Integration build health indicators (including lava lamps and stolen street lights). In this article I will focus on task boards, since I find them the most critical and least discussed information radiator.

Task Boards

The most important information radiator in visual management is the Task Board. (When doing Scrum, I sometimes call task boards Scrumboards). The task board has the mission of visually representing the work that is being done by the team. They are the most complex and versatile artifact: a physical task board is a “living” entity that has to be manually maintained.  I believe boards are being undervalued by most agile teams today. This might be because there has not been a lot of focus on their potential, or perhaps there are simply not many examples around on what makes a great task board. In any case, it’s time to take task boards to the next level. [1]

What makes a great Task Board?

A good task board should be carefully designed with readability and usability in mind, and the project methodology should actively rely on it. This implies that the use of the task board should be standardized and form part of the process. If task boards (and other information radiators) are not an integral part of the project methodology, maintaining them might be perceived as overhead or duplication of work. This results in boards not being updated and becoming out of sync with the work actually being done. An incomplete or stale task board is worthless. A task board is a living entity and should be kept healthy.

scrum task board

You have a great task board if…

  • Team members never complain about having to use it.
  • The daily standup happens against it.
  • Random people that pass by stop to look at it, expressing interest and curiosity.
  • Your boss has proudly shown it to his boss.
  • You see team members updating it regularly during the day.
  • It passes the hallway usability test: a person who has never seen it before can understand it quickly and without explanations.
  • You catch a senior manager walking the floor and looking at it.
  • It just looks great!

Visualizing waste

When designing the process to be used with the task board, two important factors should be taken into account: the first is how to visualize work that is not directly associated with the value-added activities being performed (i.e. in Scrum, tasks that do not belong to any story within the current sprint). Visualizing waste can sometimes be as important as visualizing value-added activities. So it is desirable to come up with a system that will visualize any work being performed. As an example on how to achieve this, I dedicate the top row of each board to “Unplanned items and legacy issues”, a placeholder for any task that does not belong to a current story. Bugs that come up (belonging to stories already delivered) go there, random tasks (e.g. “reinstall Windows”) too.

Work granularity

The second important factor is the level of granularity we will visualize. In my experience the ideal size of tasks is one day. (This is only a guideline and should be taken as such. As long as the average task size is around a day, you should be OK.) The goal is to see regular flow on a daily basis. Sometimes people don’t see the benefits of having 1-day tasks and go for much bigger lenghts. It seems difficult to achieve the benefits of visual management with work units of that size. The granularity is simply too big; not enough movement will be seen, not enough detail will be shown.

Aesthetics and Usability

Most task boards are set up without giving too much thought to aesthetics and usability.  They are hastily made, using available materials and without putting much attention to detail. As an example, in many boards columns are hand drawn with whiteboard marker, and tasks written in ballpoint pen or pencil on whatever material is available (large post-it, small post-it, index card, etc). There are no guidelines regarding the use of colors or materials, and no defined process for using the board. All this makes for very low readability and poor usability in general. If you are standing two meters from such a board, it looks sloppy and is rather illegible. With some effort, we can clearly do better than that!

blue_detail

I would like to emphasize the value of task board design and usability, and of implementing a standardized process regarding how to use it (which implies using standardized materials). This has really been a key success factor for me, helping me smoothly introduce Scrum to new teams that were at the Shu level.

I will be publishing illustrated examples of the task board best practices I have gathered over time in the series Elements of  taskboard design.

Results of applying Visual Management

In my experience, quality information radiators can become central to an Agile software development process for co-located teams. Most daily activities revolve around the task board. The burndown and backlog show project status at a glance. Build health is clearly displayed. In many cases good task boards result in teams not needing a bug tracking system anymore. Managers are at ease. Product owners claim to be able to sniff trouble coming up immediately, by visualizing trends on the boards. And the most important result: increased transparency and trust created among all parties.

Effect on team members

The main effect I observe among team members is increased accountability. High visibility and clear guidelines ensure team members cannot hide work (or non-work) from each other. This tends to expose things, but it is done with ground rules that people find quite reasonable. Thus accountability is achieved in a smooth way. This builds transparency among team members, which in turn builds trust.

This is also a good way for team members to learn to define and select their own work instead of having work assigned to them. Many transitioning teams struggle with this step, especially since it might imply a loss of perceived authority by the former manager or team lead.

Behavioral changes in Management

Project management and the Product Owner might perceive a decrease in risk: all work being clearly visible, there is less chance of issues going undetected and of people slacking off, and it is easy to keep track of progress.

Another benefit for people in positions of responsibility is that they can obtain the peace of mind sensation they would theoretically get from “micromanaging” a team, without any of the drawbacks.  They know that at any moment, if they would want to, they can go and see exactly what everybody is doing and the status of every work item, to any desired level of detail, with zero overhead and without causing any discomfort to anyone. The goal here is that managers, whenever they feel that need for control tickling them, will go to the task board instead of to the team members. This is especially good for enabling teams transitioning to Agile to self-manage.

Appendix: Lean / Kanban development and Visual Management

Visual management is an important part of Lean. As I mentioned in the introductory paragraph, there are several examples within the Lean literature on using visual tools in production or factory settings. These ideas also extend to Lean Product Development [2], but there are not that many examples or pictures out there.  The Kanban development movement -which is a relatively frontier area at the moment-  explicitly takes a visual approach to managing work, and everything I have seen features strong visual management aspects. But, understandably, most of the focus of Kanban at this point is being put on describing the more important Lean aspects of the methodology such as cycle time, single piece flow, limiting to capacity, etc. and not on usability or design of the boards themselves. I hope this article will help introduce some ideas on task board best practices to the Lean/Kanban movement, since they already have a strong bias towards visual management.

kanban board

Footnotes

[1] Researching this article, I found a very good post specifically focused on task boards, but it is mostly introductory and surveyal: Tom Perry’s Task Boards: telling a compelling story . There is also a great article out there that comes from a Lean practitioner and is very similar in spirit to what I wrote here (including what I consider a very nice -albeit simple- board): Visual Management and Self-Reliance by Peter Abilla. BTW, this guy also interviewed Mary Poppendieck! Coincidence?

Some other articles touching the subject:

  • Lisa Owens wrote a short article on the Scrum Alliance website with a promising title but unfortunately not that much content and no pictures: Attractive task boards.
  • Maarten Volders, who was part of my first Scrum team and helped develop some of the tecniques used in my task boards, complains about his current employer’s “task boards gone wrong” but apparently couldn’t get any pictures of them.

[2] Morgan/Liker in “The Toyota Product Development System” dedicate a paragraph (page 262) to Visual Management when describing the obeya room, saying “Visual management is key to effective communication[…]”. Mary and Tom also talk about the importance of the “Visual Workplace” in one of their books.