Work Item Tracking, to See or Not to See?

Work Item Tracking, to See or Not to See? This is always an interesting debate. The lists are much longer but for simplicity I’ve surfaced a few salient points. So which is best? Physical or virtual? For me physical boards win hands down, but there are occasionally good reasons for a careful blend.

Benefits of a physical board

First there are the get it on the wall types who:

  1. Like visibility of what everyone’s doing, or ‘airing your dirty laundry’ as a CFO once constructively said to me (he also declined my offer to walk the boards, but that’s another story).
  2. Want a simple, visual indicator alerting them to bad smells in the dev pipeline, or process improvement opportunities (ignoring the kanban for flow, or kanban for show debate).
  3. Like something physical to relate to when discussing work items, at standup or otherwise. Standup meetings are more ‘real’ near a physical board.

Benefits of a tracking tool

Then there are the pro work item tracking tool types who:

  1. Like to interrogate the data to obtain various project metrics, and force the responsibility of accurate accounting on the team members (ew).
  2. Have a need to collaborate across many sites or roll up complex programme reporting – one source of the truth.
  3. Like things to be ‘fully documented’ in systems, or at least have the perception that things are fully documented, so that they can go back there to see what and how later.

Pulling project metrics from the data

Personally I don’t believe that getting the team to be accountable for the data is best use of their time, they need to worry about building stuff. More often than not there is a painful moment when the board needs to be reconciled with the tool, that’s usually an activity not performed by the offenders. So why bother, if you need the metrics, take ownership of them and be sure you are all over them, don’t let precious performance data hide away in systems and be at the mercy of people who are better focussed elsewhere.

Collaboration across multiple sites / one version of the truth

This is possibly the best argument for a tool. However I still prefer running things from the wall. There are ways to achieve this;

Take a photo of the board (at least daily) and make sure it’s accessible by all team members and ideally, post a link on a wiki/intranet site is great as it means the Product Owners can also get involved if they’re remote.
Point a hi-res video stream at the wall and share that, it’s amazing how much activity goes on at the board if you time-lapse record this.
Mirror the board across sites and use a ‘card-buddy’ to ensure things are moved in all locations. Not pretty, but it can work.
Of course, the optimum solution is co-location, but that isn’t always practical. Work items should always be visible, if you can get wall space, use it, even if you still need to use a tool in parallel. Complex programmes with multiple initiatives feeding into the same CFD can also be achieved just as simply using excel, I don’t really see this being a huge issue.

The documentation benefit

This is usually a fail, as no systems in my experience are fully documented to the point where the product and subsequent increments are recorded in totality. User stories are transient things and don’t add much value retrospectively. Things are too disjointed. Having been recently exposed to BDD, my preference will always be living documentation, but you don’t always have that option.

Auditors like tracking tools as they provide a window into delivery metrics and releases. That’s fine, that level of detail needs to live somewhere, so use the tool to generate IDs and close the items once you’ve implemented them / put them live. This way you can satisfy the need to deliver, and the need to be audited. Auditors like to see conformance to process, and are usually lenient of an emerging or evolving methodology as long as you’re open about it, imposing a horrible process on your team is completely unnecessary.

The important things for me are delivering products, and the checks and balances to see when or if it’s all going wrong. A physical board is one of the best tools for that, the metrics are easily generated either way.

[An earlier version of the post appeared on Rich’s blog.]