The Elastic Leadership Book



        RSS Feed

Latest Entries


Step #2 – Use a big visible board with post it notes 

Most team leads really have no idea how many things their developers are doing at the same time.

There is a very simple tools that you can use starting today. Take a white board and place it in an area where your whole team can take a look at it. It's not supposed to be in a computer so don't try to use software for this.

It's supposed to be a big visible board.

Give it columns for pending tasks, tasks in progress, tasks done (waiting for approval) and tasks approved as done. In the case down below “Accepted” means that a customer has seen a demo of this functionality and said it’s OK.




Next, you can start out by placing post it notes or index cards with small tasks. you fill the left most side with tasks that you are planning for this week. This is not an “iteration”. it’s just the amount you think you can make in a week. Any tasks that don’t fit in this board belong on an excel document



Once you’ve done this, ask team members to put on the “in progress” column any tasks they are currently doing, or to add any cards which do not exist that represent work they are currently doing. Ask them to put names on cards they are working on, or, assign the in progress part in the groups by the team names:

what ends up happening in a lot of teams is something like this:


this board represents the fact that you have people working on multiple things at the same time. That’s not a great thing.

the good thing is that at least you’ve found out about this and can do something about it!

you an also use this board to show management just  how busy your team really is.

Try to have no more than one concurrent task for developers on your team, as a thumb rule.

« Don’t despair in the face of nitpickers | Main | The first five Whys »

Reader Comments (9)

Liked the new blog.. looking for more posts..

Concerning this post, I've been on teams adopting Agile for over a year at my company.. & for me I find using a physical Task wall is a bet messy.. You get lots of stuff running out of order let me state some:

- Most of the time, you end up with your back log scattered; unless ur maintaining a soft copy of course.. & even if you did sometimes you lose the mapping between both physical & electronic backlog..
- Maintaining a parallel electronic version of your backlog makes ur team a bit fussy about adapting one of them.. every team member have a preference you wind up with only one always updated (in case the whole team likes one option) or worse both ur physical & electronic backlog/task wall not fully updated..
- I'm now checking other electronic alternatives that are still visual but are "searchable" & "report-capable" at the same time compared to the physical task wall which lack such a luxury.. I've tried alternatives like "scrum for team system".. & currently trying Rally.. which is really promising..

Yet, I'm still using a physical task board coz unfortunately our PMs, are too lazy to check our electronic task wall though it give more updated, & thourough reports if we really focused on using it as our main..

September 5, 2009 | Unregistered CommenterShady M. Najib

that's exactly the problem with non physical things: people are much more inclined to use the simpler things, so that's exactly what you're seeing.
if you need to, you can always create a separate board just for the backlog.

September 5, 2009 | Registered CommenterRoy Osherove

How do you cope with having geographically separated teams use this?

September 6, 2009 | Unregistered CommenterRik Hemsley

This is a good and simple tool which you have mentioned. But I just do it in a bit different way. The first thing I do when I land in my office is to create a task list for the day. This task list includes:

1. Followup for the items for all the developers.
2. My own tasks to be completed
3. Any pending items from yesterday or in past
4. Any changes/releases to be deployed today
5. any meetings to attend and if I need to prepare any material for it
6. Any members on leave/going on leave to be communicated to whole of the team
and so on and so forth...
This helps me to be in sync with the tasks whole day and makes sure that I am not missing out on anything whether its small or big.
Hope this helps.
Aman Garg

September 6, 2009 | Unregistered CommenterAman Garg

In my opinion a physical task board is superior to an electronic one for one simple reason: visibility. Really, visibility is the first element in achieving ownership of your team, as Roy called it - if your managers see what you are working on, they are less anxious and more willing to give you slack. I can show anyone who asks just what is planned for my team, what is being worked on right now, and what is ready to demo.

Won't you rather discuss these points with your team on the daily stand up? It helps me when the team give their angle on what should be done today (according to what's on the board) - I'm a big believer in emergent work, and it gives me a good clue on whether I was able to communicate the focus of what we're working on to the team. Also, by managing this yourself you are losing visibility, which, for me, is key.

September 7, 2009 | Unregistered CommenterDoron

I've been working on an agile team since more than a year now. We use the scrum process. For backlog and other agile management, we use VersionOne software.

As far as manager's curosity is concerned, my manager uses dual monitor. On the other monitor he usually has the VersionOne backlog opened. (most of the time). Most developers have dual screens too. Even if they dont, they keep the versionOne window always opened. Daily scrum calls make it even better because everyone gets to update his/her status. Depending on the ScrumMaster, the person might not be able to get away without doing anything.

We have about 190+ items in the backlog all the time due to nature of the tasks and users. I dont think that could be maintained on a whiteboard. But overall, i think the Daily scrum meetings really eliminate the use of the whiteboard. It has following issues:

1. too physical setup dependent. What if there are rooms for each dev (i heard you have those in microsoft?). We have cubicles and most people dont really like moving around much (culture dependent).
2. Gets messy with larger backlogs and bigger teams.
3. Is hard to maintain. Our system notifies everyone relavent by email or RSS feeds whenever something changes.

Just my two cents,
Nice blog. I'm posting it on my blogs to read by the end of this week.


September 9, 2009 | Unregistered CommenterZaki
December 2, 2009 | Unregistered CommenterAndrew

Just wanted to say hello all. This is my first post.

I hope to learn alot here.

December 27, 2009 | Unregistered CommenterJizadebuiddeK


we too use Scrum in an nearshore development team. We use ScrumDesk, which is really very intuitive and makes everything mor visually, also for stake holders from other countries.

I agree with "[the white board] is not supposed to be in a computer", but sometimes you just really have to use a computer.


March 23, 2011 | Unregistered Commentermcanti

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>