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

Monday, January 13, 2014

Scrum Roles and Responsibilities Game

I have recently posted my first game to, the Scrum Roles and Responsibilities game.

Scrum Roles and Responsibilities game at the end of the game

This is a game that I have used many, many in my Scrum training courses. I have found it is a great way to help trainees understand the differences between the Scrum roles and importantly what each role should be focusing on.

The physical interaction and discussion elements encourage everyone to participate and really helps to make the lessons learnt stick in the students brains. 

The format of that game can also be easily reused to teach other topics. Such as what is included in our different Definitions of Done (Release, Feature, User Story).