Agile Scrum / Project Boards

So, as some of you all may know I am a proponent of agile methodologies. I have posted about agile in the past: here and here and possibly here - what you'll notice about those posts is that they are not specifically about agile, but rather about practices that I find important to doing my job well. This post is specifically about an agile practice and in specific about scrum and the practice of keeping a 'scrum board'

Physicality is king

A scrum amounts to a time boxed iteration of work. In this time box we are fixing the time, the money available (in the form of people) and we are allowing to vacillate the total amount of work that this particular group of people can accomplish (the features they will develop). The team when they start understands how much work they can complete and they commit to doing that many features from a list of features supplied to them. Then the work can begin. This work is 'tracked' as to its done-ness in either electronic form or in physical form. This should come as no surprise to anyone - but I am a large proponent of the physical scrum board.

The scrum board is a physical board used during the iteration to track the work (as mentioned above). Each story/feature gets a card on the board and is placed in the "ready" column. The other columns may vary depending on the team, our team has a "ready", an "in progress", a "done", an "accepted" and an "impeded" column. The cards are placed in each of these states as the feature is being worked on, meets its doneness criteria and is eventually placed into the accepted column.

What is great about this is being able to see and touch the cards or stickies. Doing this provides each team member with a sense of accountability that is not there when you attempt to just talk about features and work you are doing in the 'theoretical' during your scrum stand-ups. Having a physical board provides something that doesn't seem to be there in software solutions either unless you happen to have LARGE touchscreens (think Version One, Rally Dev, etc.) that provide that tactile, walk over and move the 'card' from one column to another, feel.

For me there is also something internally satisfying about really seeing items move from ready, to in-progress to done - Right there on the board. Without it, despite peoples updates, I feel a little lost during the iteration.

Additional (unintentional) Benefits

An additional benefit to the physical board is that is can be a great information radiator - transparent to anyone who happens by... they can see what you are working on, what you plan to be working on and what is already complete just by looking at the board. If an individual needs clarification they can always ask, but the board being out on the floor for everyone to see provides an ave for communication (despite being passive) that didn't exist before. It may generate questions, comments, or just plain discussion. Think about this situation - you are working on a feature in your sprint that interacts with another persons feature set (i.e. more then one team developing at a time) they happen by your board and notice what your team is working on and ask about how its going to integrate with what they are working on. Possible disaster averted due to this simple upfront conversation. Simply AWESOME.

A team can also use the physical board to add additional sprint metrics (information radiation) increasing the transparency with which the team is operating.

I fought the creation of this physical board for our team for a good long time - seeing what it can do to help the team, I am sorry that I fought as long as I did. The physical board seems to be an invaluable tool for the team and the organization at large.

PS: This physical board can also play into a Kanban type pull scenario - but may not include the specific columns mentioned here.