March 2009

You are currently browsing the monthly archive for March 2009.

Unplanned items and legacy issues

March 25, 2009 in Visual management by Xavier Quesada Allue | 1 comment

“Unplanned items and legacy issues” is the top row on my scrumboards. Instead of a story, it is a placeholder for:

  • Unplanned work: stuff that we 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.
  • Legacy issues: this is any bug or issue that belongs to stories already delivered and accepted, and should be fixed.

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.

legacy_unplanned

Tags: , , ,

The DONE tag

March 9, 2009 in Visual management by Xavier Quesada Allue | 5 comments

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.

Tags: , , ,

First Visual Management Workshop

March 2, 2009 in Visual management by Xavier Quesada Allue | 2 comments

Last Thursday 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.

Red team building their board

Red team building their board

Green team building their board

Green team building their board

Blue team presenting their board

Blue team presenting their board

The jury is out on this one...

The jury is out on this one…

Finished Red team board

Final Red team board

Final Green team board

Final Green team board

Final Blue team board

Final Blue team board (click for large version)

Nametags

March 1, 2009 in Visual management by Xavier Quesada Allue | 5 comments

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.

Nametags

I like nametags because:

  • Nametags are extremely self-explanatory.
  • Nametags are very readable if written nicely.
  • Nametags are small and unintrusive, but highly visible at the same time.
  • Nametags can be of different colors which adds some clarity without creating visual pollution.
  • Nametags are cheap and can be made in 10 seconds. And they last practically forever.
  • Nametags are flexible. Placing one is a snap. You can easily remove them. You can put one on top of another. You can bunch them together. They can overlap, hang out, or on the side of task and status Post-it’s.

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.

bad_nametags

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.

pokemon

Hello, I’m Alex! Check out my tasks!

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.

Materials

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

Tags: ,