Visual management and the everlasting tasks

Arseni Mourzenko
Founder and lead developer
October 14, 2015
Tags: short 50 management 33 agile 10 workspace 1 communication 27

Near­ly a year ago, I de­scribed how I im­ple­ment­ed vi­su­al man­age­ment in my com­pa­ny. My us­age of vi­su­al man­age­ment re­mained rough­ly the same, but over time, I dis­cov­ered one as­pect I wasn't think­ing of when I wrote the orig­i­nal ar­ti­cle: the tasks which re­main for­ev­er.

In Roadmaps, goals, morale, be­liefs and mo­ti­va­tion, I ex­plained that in or­der to be suc­cess­ful, a pro­ject needs a goal and a small list of tasks—the tasks to per­form in im­me­di­ate fu­ture. I ex­plained this through a term of roadmap which is very de­tailed around the cur­rent lo­ca­tion and very loose far away from it.

Vi­su­al man­age­ment pro­vid­ed all I need to have this vi­sion of im­me­di­ate fu­ture: by hav­ing the list of pre­cise tasks to per­form in the next few days, I could al­ways de­ter­mine what to do next. The prob­lem is that some of the tasks just won't go. They would re­main, here, in front of me, for­ev­er, and the more they spent on the board, the more an­noy­ing they be­came.

What are those tasks? I iden­ti­fied three types:

The pres­ence of those tasks on the board high­lights a con­cept I al­ready men­tioned in the orig­i­nal ar­ti­cle:

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. [...]

A task board, 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.

If the board is con­sid­ered as a snap­shot of the im­me­di­ate fu­ture, then re­mov­ing the tasks I don't want to do makes sense. They just don't be­long there. Their place is in the bug track­ing sys­tem, and only there.

On the oth­er hand, tasks re­lat­ed to the pro­jects which are cur­rent­ly sus­pend­ed still have their place on a board. But every pro­ject should have its own sep­a­rate board in or­der to re­flect clear­ly the sta­tus of a pro­ject in iso­la­tion from oth­ers.

This, how­ev­er, cre­ates an ad­di­tion­al is­sue. How do you get a bug track­ing sys­tem in sync with the board? En­ter­ing the same in­for­ma­tion by hand is out of ques­tion: even a high­ly mo­ti­vat­ed team won't do that. As­sign­ing to pro­ject man­ag­er (or any oth­er per­son) the task of syn­chro­niz­ing the in­for­ma­tion from the board to the bug track­ing sys­tem sounds wrong too: such bor­ing job won't be done cor­rect­ly.

This makes me think that the ide­al case would be a dig­i­tal board (six or eight 32-inch tac­tile mon­i­tors would do the trick). Sur­pris­ing­ly, I've nev­er seen this im­ple­ment­ed, and none of the bug track­ing sys­tems I know makes it pos­si­ble to do this.