Visual management and the everlasting tasks
Nearly a year ago, I described how I implemented visual management in my company. My usage of visual management remained roughly the same, but over time, I discovered one aspect I wasn't thinking of when I wrote the original article: the tasks which remain forever.
In Roadmaps, goals, morale, beliefs and motivation, I explained that in order to be successful, a project needs a goal and a small list of tasks—the tasks to perform in immediate future. I explained this through a term of roadmap which is very detailed around the current location and very loose far away from it.
Visual management provided all I need to have this vision of immediate future: by having the list of precise tasks to perform in the next few days, I could always determine what to do next. The problem is that some of the tasks just won't go. They would remain, here, in front of me, forever, and the more they spent on the board, the more annoying they became.
What are those tasks? I identified three types:
Some are the tasks I don't want to do. They are low priority stuff which is there because I don't want to throw it out, but I don't want to do it either, because it's too boring. Those tasks sometimes move to the column of the tasks to do during the week, but inevitably go back to the column with the tasks which should be done later.
I believe that I shouldn't remove those tasks: if I do, I won't recall those low priority tasks; if they are there, I might, one day, do them. On the other hand, they would obviously be eliminated in a context of any triage. But in a bug tracking system, triage means selecting tickets which will be part of the next release, and the postponed tickets; in my case, there are no postponed tickets.
Others are the tasks which concern a project I'm not working on right now. For instance, tasks related to the system used by this blog are all in this category: while I need to recall the changes I need to do to this blog, I don't expect to work on the project in the next few months.
Not only those tasks shouldn't be removed, but they can't even be filtered through triage: those are all the immediate tasks within a scope of their respective projects. The fact that I don't work on a given project for months is irrelevant here: the tasks have the same status and importance as any other task I work on right now. Similarly, a task of a team can be as important as a task of another team, but be released one month later, because the first team was on vacation.
The presence of those tasks on the board highlights a concept I already mentioned in the original article:
The first thing is that a task board doesn't replace a fully-featured bug tracking system, and I imagine that it was never designed to do it. Those are just different tools for different needs.
A bug tracking system tracks bugs over time. [...]
A task board, on the other hand, pursues the goal of showing in a clear way the status of the project—right now, obviously, but also for the next weeks. They can't show precisely what the team will be doing in a week or two, but it doesn't matter. The only thing that matters is that everyone knows what is the next task to do, as well as the overall direction.
If the board is considered as a snapshot of the immediate future, then removing the tasks I don't want to do makes sense. They just don't belong there. Their place is in the bug tracking system, and only there.
On the other hand, tasks related to the projects which are currently suspended still have their place on a board. But every project should have its own separate board in order to reflect clearly the status of a project in isolation from others.
This, however, creates an additional issue. How do you get a bug tracking system in sync with the board? Entering the same information by hand is out of question: even a highly motivated team won't do that. Assigning to project manager (or any other person) the task of synchronizing the information from the board to the bug tracking system sounds wrong too: such boring job won't be done correctly.
This makes me think that the ideal case would be a digital board (six or eight 32-inch tactile monitors would do the trick). Surprisingly, I've never seen this implemented, and none of the bug tracking systems I know makes it possible to do this.