Sunday, January 26, 2014

Why agile teams should not use an electronic task board

I often hear people expressing interest in moving to an electronic task board. This always concerns me. I see so many benefits in physical boards and only a few benefits in electronic boards. Until recently I had struggled to explain to people why they should go for physical over electronic. 

Now with thanks to Allan Kelly (who presented at Agile Tour London), I can articulate why it is so important to stick with a physical board. 

Teams should work collaboratively to create and design their own physical task board; because this creates significant buy-in to actually using the board on a regular basis. The act of deciding how the board will look / operate is much more interactive when done physically. This creates a stronger sense of ownership for the board and hence increased buy in.

As an aside; if you are working in a distributed way, go ahead move to an electronic task board. For me this is where electronic task boards shine. However if you are working in a co-located team (and I hope you are), you should go for a simple physical task board. 

The diversity that can be achieved via a physical board continues to astound me. To gain some appreciate for this please head over to Agile Board Hacks.

Other reasons to stick with physical boards are that it is often very difficult to use these powerful annotations on an electronic task board:

  1. Pairing estimates. E.g. ‘Extract user details from the request (8h x 2)’, meaning two people will pair on this task, spending 8 hours each for a total estimate of 16 hours.
  2. Action plus Review on one card. E.g. ‘Extract user details from the request (18 + 3)’, meaning 1 person will spend 18 hours developing the functionality, and then there will be 3 hours for someone else to review it and the first person to correct any issues.
Example physical task board



5 comments:

  1. > As an aside; if you are working in a distributed way, go ahead move to an electronic
    > task board. For me this is where electronic task boards shine. However if you are
    > working in a co-located team (and I hope you are), you should go for a simple
    > physical task board.

    I had a very strong bias _for_ co-located teams until I read about GitHub's workplace[1].

    I'm still biased but part of me now thinks remote teams can work.

    (Even more surprising is how teams with unpredictable membership can work, and even force you to increase quality because it won't work without quality)

    My current team was originally using a specific JIRA workflow decreed by management. It was OK at the start, but management decided to keep adding more heavyweight processes (mandatory fields, new transitions, new issue types, etc) without cleaning up existing processes (fields existing on issues that don't make sense anymore, etc).

    I suggested that our team move to a physical board for tasks (keep JIRA for stories) and we haven't looked back. That is, until management decided we should be co-located with other teams in another country. Not a bad idea, but the execution is we don't all go at the same time. We are being forced to become a team with remote members for a few months until everyone can move. There are some really nice tools available, more lightweight than JIRA and more conducive to remote collaboration which I'm investigating now.

    [1] http://www.fastcolabs.com/3020181/open-company/inside-githubs-super-lean-management-strategy-and-how-it-drives-innovation

    ReplyDelete
  2. GitHub and high code quality are very useful for distributed teams. I am glad that you got success out of your physical task board. Perhaps you can move back to a physical task board once your team is fully co-located. Good luck during this transition phase.

    ReplyDelete
  3. I agree with your assertion that explaining why a physical board is so much better is very difficult. I've found that only experience can create the knowledge. Few people seem to grasp the nature of the problem in the abstract. Look to the father of UX design Donald Norman (affordances) for the root reasons. My article on the missing-affordances attempted to explain this http://agilecomplexificationinverter.blogspot.com/2012/07/missing-affordances.html alast I believe it failed. Again, experience works better than telling in this case.

    My article tries to quantify the aspects of a great board: http://agilecomplexificationinverter.blogspot.com/2013/11/elements-of-effective-scrum-task-board.html

    ReplyDelete
  4. I see what you mean. For me it is the experience of having ideas to improve the board; yet the electronic system prohibits me from making those changes, that steers me to the physic.

    ReplyDelete
  5. Right. The tanagable board is instantly mutatable

    ReplyDelete