Visual management and the everlasting tasks

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:

• Some are the tasks I don't want to do. They are low pri­or­i­ty stuff which is there be­cause I don't want to throw it out, but I don't want to do it ei­ther, be­cause it's too bor­ing. Those tasks some­times move to the col­umn of the tasks to do dur­ing the week, but in­evitably go back to the col­umn with the tasks which should be done lat­er.

  I be­lieve that I shouldn't re­move those tasks: if I do, I won't re­call those low pri­or­i­ty tasks; if they are there, I might, one day, do them. On the oth­er hand, they would ob­vi­ous­ly be elim­i­nat­ed in a con­text of any triage. But in a bug track­ing sys­tem, triage means se­lect­ing tick­ets which will be part of the next re­lease, and the post­poned tick­ets; in my case, there are no post­poned tick­ets.

• Oth­ers are the tasks which con­cern a pro­ject I'm not work­ing on right now. For in­stance, tasks re­lat­ed to the sys­tem used by this blog are all in this cat­e­go­ry: while I need to re­call the changes I need to do to this blog, I don't ex­pect to work on the pro­ject in the next few months.

  Not only those tasks shouldn't be re­moved, but they can't even be fil­tered through triage: those are all the im­me­di­ate tasks with­in a scope of their re­spec­tive pro­jects. The fact that I don't work on a giv­en pro­ject for months is ir­rel­e­vant here: the tasks have the same sta­tus and im­por­tance as any oth­er task I work on right now. Sim­i­lar­ly, a task of a team can be as im­por­tant as a task of an­oth­er team, but be re­leased one month lat­er, be­cause the first team was on va­ca­tion.

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.