Visual management

I dis­cov­ered Vi­su­al man­age­ment blog in 2013. Al­though I al­ready heard about Kent Beck's Big Vis­i­ble Chart, I've nev­er ac­tu­al­ly seen vi­su­al man­age­ment in prac­tice be­fore. For me, tick­ets went straight to Fog­Bugz or TFS and re­mained there, im­ma­te­r­i­al and elu­sive.

The idea of mov­ing the tick­ets from the cold nowhere of vir­tu­al­i­ty to the real world of ob­jects was ap­peal­ing, so I jumped on the oc­ca­sion when start­ing the Next Great Thing—my one-man Con­tin­u­ous In­te­gra­tion en­vi­ron­ment pro­ject.

My us­age was slight­ly dif­fer­ent from the one de­scribed in Vi­su­al man­age­ment blog. I'll ex­plain how and why I made some changes, and what do I think about the idea of mov­ing from Fog­Bugz/TFS to a real-world board.

“I'm dif­fer­ent”

At first, I want­ed to stick to the pre­cise way de­scribed in Vi­su­al man­age­ment blog. “Don't rein­vent the wheel”—I was telling my­self: oth­er peo­ple spent a lot of time think­ing about this stuff and ex­plain­ing it. But at the same time, I un­der­stood that my sit­u­a­tion was dif­fer­ent from their.

The first dif­fer­ence is that I'm work­ing alone. Vi­su­al man­age­ment is a way to rep­re­sent N-di­men­sion­al data us­ing po­si­tion, col­ors and shapes, and the ma­jor prob­lem is that there are too many di­men­sions:

• This task is in progress, and that one is fin­ished.
• That task is as­signed to Jeff, while this one should be han­dled by Cindy.
• Those two tasks are ex­treme­ly im­por­tant, be­cause they can be block­ing in a near fu­ture.
• This task is re­lat­ed to in­ter­ac­tion de­sign and has noth­ing to do with pro­gram­ming.
• etc.

In my case, I was lucky: be­ing the only mem­ber of the team, I had one di­men­sion less: all tasks were nec­es­sar­i­ly as­signed to me. On the oth­er hand, I could be work­ing on sev­er­al pro­jects at the same time, and us­ing mul­ti­ple boards was not an op­tion.

I fi­nal­ly de­cid­ed to han­dle three di­men­sions:

• The type of task. Types are mu­tu­al­ly ex­clu­sive: while it's some­times not ob­vi­ous to pick a type for a task, it's not that im­por­tant, af­ter all.

  1. De­vel­op­ment: this en­com­pass­es ar­chi­tec­ture, de­sign, test­ing and im­ple­men­ta­tion, i.e. any­thing with­in a scope of white­board and IDE.
  2. De­sign: this deals with tasks re­lat­ed to in­ter­ac­tion de­sign, graph­ics, com­mu­ni­ca­tion, etc.
  3. In­fra­struc­ture: here, the fo­cus is on the en­vi­ron­ment. If I have to de­ploy a VM, cre­ate a back­up, con­fig­ure an ap­pli­ca­tion, etc., this is it.
  4. Non-pro­gram­ming re­lat­ed tasks (of­ten ad­min­is­tra­tive stuff). Hard­ware-re­lat­ed is­sues (like a failed HDD) are here too.
  5. Pre-pro­duc­tion, pro­duc­tion and post-pro­duc­tion: deals with my movie-re­lat­ed pro­jects as well as still pho­tog­ra­phy.

• The sta­tus. Here, Vi­su­al man­age­ment blog uses an ap­proach that I per­son­al­ly find not par­tic­u­lar­ly straight­for­ward. It slices the sta­tus into two: first, the task can be not start­ed, in progress or fin­ished; sec­ond, the task can be “please test”, “bug”, etc. Since I don't see the ben­e­fit of such sep­a­ra­tion, I used the same ap­proach for all sta­tus­es, which are non-mu­tu­al­ly ex­clu­sive.

  1. Done: the task is fin­ished. It's kept here un­til the ret­ro­spec­tive, but it is ac­tu­al­ly fin­ished, which also means test­ed. This is also why I don't un­der­stand the “please test” tag in Vi­su­al man­age­ment blog: if the task is untest­ed, it's not done. If the task is not done, why would some­one flag it “please test”, and not oth­er tasks which are not done yet?

  2. Cur­rent: that is, I'm work­ing on this task. In an ide­al world and if I were a ro­bot, I would have only one task la­belled as cur­rent and not-yet-done. Since I'm not a ro­bot but an un­or­ga­nized hu­man be­ing who switch­es from task to task all the time, there are usu­al­ly one to four cur­rent tasks. Four is re­al­ly bad; I ad­mit it and do my best to im­prove my­self.

  3. Crit­i­cal: this is for the tasks which are block­ing and/or should be done ASAP. If I no­tice that au­to­mat­ed back­ups of SVN repos­i­to­ries are down, this is damn crit­i­cal.

  4. WTF: this tag in­di­cates that some­thing got com­plete­ly wrong with the task. Ei­ther I failed on man­age­ment lev­el (like I'm on this sim­ple 30-min­utes task for the last five days) or tech­ni­cal­ly (like the thing is com­plete­ly out of con­trol and I have no idea how to do the task). It's like a cry for help, but to my­self.

• The pro­ject, since I work on mul­ti­ple pro­jects at a time, and I only have space for one board. The at­tri­bu­tion is mu­tu­al­ly-ex­clu­sive.

• The it­er­a­tion switch.

  1. Some tasks are ex­pect­ed to be done dur­ing the cur­rent it­er­a­tion.

  2. Oth­er tasks will wait in a sort of back­log.

This means that I have to rep­re­sent four di­men­sions: two with mu­tu­al­ly-ex­clu­sive val­ues, one with non-mu­tu­al­ly-ex­clu­sive val­ues and one with a mu­tu­al­ly-ex­clu­sive boolean. That should be easy.

• First, I de­cid­ed to use col­ors of post-its to show their type. De­vel­op­ment-re­lat­ed post-its are light yel­low. De­sign ones are blue. In­fra­struc­ture ones are or­ange. Non-pro­gram­ming ones are yel­low. Dif­fer­ent types of green are used for pre-pro­duc­tion, pro­duc­tion and post-pro­duc­tion.

• Then, log­i­cal­ly, small post-its dec­o­rate large ones in or­der to tag them. Tag­ging is ac­tu­al­ly the only way to rep­re­sent non-mu­tu­al­ly ex­clu­sive cri­te­ria here, and small tags seem to be a good vi­su­al rep­re­sen­ta­tion of tags. Dif­fer­ent col­ors rep­re­sent dif­fer­ent sta­tus­es, giv­en that the sta­tus is also in­di­cat­ed in all let­ters to en­sure re­dun­dan­cy with the col­ors. Ac­tu­al­ly, “crit­i­cal” and “WTF” share the same col­or, since they share the same na­ture.

• Pro­jects are marked with small dots in the top right cor­ner. Mi­nor pro­jects don't have a dot, but a hand-writ­ten name.

• Fi­nal­ly, for the it­er­a­tion switch, I used the po­si­tion of the post-its. On the right side of the board (where I can see the tasks with­out mov­ing my chair) there are tasks to do dur­ing the cur­rent it­er­a­tion. On the left side, there is a back­log.

^{The full view of the right side of the board con­tain­ing tasks to do dur­ing the cur­rent it­er­a­tion. Sim­i­lar tasks, not shown here, are on the left side, wait­ing for fu­ture it­er­a­tions.}

Mis­takes I've done

One of my mis­takes was the in­ten­tion to han­dle de­pen­den­cies—an old habit from bug track­ing sys­tems. Task boards are a weak rep­re­sen­ta­tion of de­pen­den­cies, and I'm pret­ty sure that hav­ing tasks which de­pend on oth­er tasks is not very ag­ile.

As a re­sult, man­ag­ing de­pen­den­cies was a night­mare. I couldn't move a post-it with­out mov­ing the de­pen­dants and the de­pen­dees, which re­sult­ed in a very rigid board. More­over, that's not that im­por­tant, af­ter all. De­pen­den­cies are es­sen­tial when tasks are as­signed to team mem­bers, there­fore PERT is es­sen­tial in Wa­ter­fall. On the oth­er hand, in Ag­ile, mem­bers of a small team know ex­act­ly what's hap­pen­ing with the pro­ject and com­mit to the tasks they en­joy, which also means that they grasp the pos­si­ble de­pen­den­cies with ease.

An­oth­er mis­take was to use one board for all pro­jects. While it some­how works in my par­tic­u­lar case, even in my case, I clear­ly see the dif­fi­cul­ty it pre­sents to not be­ing able to iden­ti­fy with ease the tasks for a sin­gle pro­ject.

Al­though I'll prob­a­bly con­tin­ue to use one board for every­thing, I would imag­ine that this would be a mis­take to do the same in a team.

Con­clu­sions

I've now used task boards for more than six months. In the past, I've used:

• Fog­Bugz: my pre­ferred bug track­ing sys­tem,
• TFS: good enough but more un­friend­ly,
• Jira: I haven't used it too much but have in im­pres­sion that it is very ca­pa­ble and well-done sys­tem,
• Red­mine: the Ph­pBB of bug track­ing sys­tems, made with no user ex­pe­ri­ence in mind,
• Two in-house bug track­ing sys­tems.

There­fore, I imag­ine that I'm in a po­si­tion to com­pare bug track­ing sys­tems to the vi­su­al man­age­ment ap­proach.

The first thing is that a task board doesn't re­place a ful­ly-fea­tured bug track­ing sys­tem, and I imag­ine that it was nev­er de­signed to do it. Those are just dif­fer­ent tools for dif­fer­ent needs.

A bug track­ing sys­tem tracks bugs over time. It doesn't do a great job of show­ing the sta­tus of the pro­ject right now, but it does an ex­cel­lent job (when done cor­rect­ly) when it comes to re­mem­ber­ing that this pre­cise bug was al­ready filed on Feb­ru­ary 14^th, closed the next day by Mike, then con­firmed as solved by test­ing team, and then re­opened, two months lat­er when we had our new ju­nior pro­gram­mer gone mad and cre­at­ing dozens of re­gres­sions all over the code base. Post-its are volatile, and make such trace­abil­i­ty im­pos­si­ble. Some­one may re­mem­ber that there was a re­lat­ed task ap­prox­i­mate­ly three weeks ago (or was it two?), but then, good luck for get­ting the de­tails.

Task boards, on the oth­er hand, pur­sues the goal of show­ing in a clear way the sta­tus of the pro­ject—right now, ob­vi­ous­ly, but also for the next weeks. They can't show pre­cise­ly what the team will be do­ing in a week or two, but it doesn't mat­ter. The only thing that mat­ters is that every­one knows what is the next task to do, as well as the over­all di­rec­tion. This is ex­act­ly what I've ex­plained in Roadmaps, goals, morale, be­liefs and mo­ti­va­tion ar­ti­cle, and I be­lieve that vi­su­al man­age­ment ap­proach makes an ex­cel­lent job of show­ing ex­act­ly every­thing that is need­ed to be shown, and only that. Bug track­ing sys­tems do not, and may some­times have a neg­a­tive ef­fect on the morale of the team.

In my opin­ion, a task board is a great tool in Ag­ile en­vi­ron­ment. For a small team, it gives an op­por­tu­ni­ty to be up to date on what's go­ing on and to keep mo­ti­va­tion high through prop­er in­for­ma­tion cast. Since know­ing what to do and re­main mo­ti­vat­ed is two top pri­or­i­ty things in pro­ject man­age­ment, I think that not us­ing a task board is a big mis­take.

How­ev­er, the tool has its lim­i­ta­tions that are worth tak­ing in con­sid­er­a­tion when choos­ing to use vi­su­al man­age­ment:

1. It ap­plies only to a team where all mem­bers work in the same part of the build­ing. You have four de­vel­op­ers in Ore­gon and two oth­ers in Tel Aviv? Don't use a task board, it's not for you. You have four de­vel­op­ers at the sec­ond floor of your build­ing, and three oth­ers at the fifth floor? The task board is not for you.

   The con­di­tion sine qua non for us­ing the task board is to make it pos­si­ble for any mem­ber of the team to reach the board with­in thir­ty sec­onds in or­der to add a post-it, add a tag to a post-it, move a post-it or sim­ply read one. Not giv­ing this op­por­tu­ni­ty to at least one mem­ber will re­sult in a con­stant­ly ob­so­lete board which is not used by every­one. You def­i­nite­ly don't want that.

2. It re­quires ef­fort from every team mem­ber to main­tain the board. I had to work with peo­ple who are re­luc­tant to open a bug track­ing sys­tem even af­ter they re­ceive an e-mail telling that there is a tick­et as­signed to them, or peo­ple who are just don't want to write a tick­et cor­rect­ly. There is no hope that they will en­joy us­ing a task board.

   An im­por­tant part of the board is the over­all or­ga­ni­za­tion—an as­pect which is high­light­ed a lot in Vi­su­al man­age­ment blog. If you can't make your team or­ga­nized, the board will suf­fer.

   More im­por­tant­ly, the board re­quires con­stant ef­fort: an ob­so­lete board is use­less, prob­a­bly even harm­ful.

3. It is based on hand writ­ing. It may be strange that I men­tion this, but this as­pect is crit­i­cal. If one or sev­er­al of team mem­bers are un­able to write cor­rect­ly and in­tel­li­gi­bly, ei­ther they won't use the board (which leads to the same prob­lems as with a re­mote team dis­cussed above).

To con­clude, if you work with/in a col­lo­cat­ed team of high­ly mo­ti­vat­ed and com­mit­ted in­di­vid­u­als, vi­su­al man­age­ment's task board is an ex­cel­lent tool which can great­ly im­prove the morale and the per­for­mance of the team while free­ing the team from a bur­den of work­ing with a bug track­ing sys­tem. But be­ware of cas­es where this tool wouldn't be ide­al and could make more harm than good.

Also, re­mem­ber that a task board is not a sub­sti­tute for a bug track­ing sys­tem. Al­though it may be for the team mem­bers, some­times pro­ject man­ag­er (or an­oth­er spe­cif­ic per­son) will have to en­sure the link be­tween the task board used by the team and the bug track­ing sys­tem used by the cus­tomer.