Geeks With Blogs
Brendon Page Dev stuff

The physical task board has become very popular in software development recently. It is an extremely useful tool that helps a team communicate the reality of the work happening within the team. This is helpful to everyone involved, managers, stake holders and even individual team members. The more aware everyone is of what is going on, the shorter the feedback loop, the quicker and more accurately action can be taken, be it helping out a team member who is struggling with a task, solving an issue impeding a task or a decision on the direction of the project.

Accurate information fed into a short feedback loop is what enables a team and project to be agile. When a team commits to or does work that isn't on their board they are failing to communicate reality. This failure bleeds into any measurements derived from the task board and therefore any decisions based on those measurements. This can result in a multitude of problems such as missed deadlines, extra pressure on the team from management or even a project being terminated.

A task board typically contains the stories being worked on, tasks for those stories and bugs. What is not as common are miscellaneous tasks, tasks that aren't related to any feature or bug but still need to be done. These can be anything from upgrading the build server, to conducting code reviews. When these type of tasks aren't on the task board they happen out of the normal work flow, which means that they aren't planned for, they don't get discussed at stand ups and no one knows the status of them. One of many things happen because of this:

  1. They don't get done because things in the normal workflow are being done.
  2. They are done at the expense of things in the normal workflow.
  3. They are done but something in the normal workflow hides the time and effort spent on them, this results in that time and effort being lumped onto the thing in the normal workflow.

Those are just the ones I've noticed, I'm sure there are many more. One thing they all have in common is that they distort reality in some way. Number 1 makes it seem that the team is coping when in fact they aren't, at some point the things they've been neglecting will catch up. Number 2 makes it seem like the team isn't coping, is working slowly or is being lazy. Number 3 has all the lovely side effects of number 2 with the addition of distorting the size of tasks and stories.

This is a very difficult problem to spot because it poisons the information being radiated from the task board. If all work that a team does is put onto their board, miscellaneous work becomes part of the normal workflow, it is therefore discussed, tracked and measured. It becomes part of the short feedback loop instead of sabotaging it.

Something I've been trying out lately is a personal task board. I use it to keep track of everything I need to do, this includes the work on my team's board. Every time I get something on main board I make a copy of that item and then prioritized and place it appropriately on my board. This allows the rest of my team to see when I will get to that item. If there needs to be any conversation around the delivery of that item the outcome will be a lot healthier because of the extra context added by my personal board. A personal board is especially handy if it isn't practical to put all work on the main board.

In summary, keep your board real, if it doesn't reflect reality then expect unrealistic expectations and decisions.

Posted on Tuesday, December 10, 2013 9:01 AM kanban , software development , software development process , software process | Back to top

Comments on this post: Keep Your Board Real

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © brendonpage | Powered by: