Visual management

Arseni Mourzenko
Founder and lead developer
163
articles
December 16, 2014
Tags: featured 8 management 33 agile 10 productivity 34 communication 25 workplace 7 backlog 2

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.

Showing a few post-its on the board

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:

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:

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.

The full view of the right side of the board containing tasks to do during the current iteration

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:

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 14th, 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.