If you aim to improve, inspect and adapt on a frequent basis in a highly unconstrained way, stick to a whiteboard (as large as possible) and stickies (and possibly scissors, tape, card, paper, pens – did I mention that many Agile coaches I’ve met have an addiction to stationary that stems back to their childhood :)). Your process will adapt to the project significantly faster with a manual board.

As an example, here’s the original board used on my current project (it’s now cleared down as we migrated to a better space) :

(Thanks to Andrzej for the rather disturbing portrait)

 The board was too small and constrained (much like many electronic tools) so we switched to something better. We reused the board layout and approach from a previous project (see 5S your Scrum board) as a kick-start but less than a week later we had already moved forward significantly from where we’d started. Our needs on this project were different enough that we had to adapt.

Here’s what the current board looks like this week:

(Thanks to Ellie for the donated parrot)

 The mass of stickies across the bottom of the board is where we cut scope for this sprint as the result of an over-commitment. This was spotted as soon as we migrated to this board and I started plotting additional information for the team around the edges.

Admittedly what we have here could potentially be implemented electronically as a board and a series of “widgets” but that needs development skills and time – this would slow down our speed of adapting.

In our example, adding avatars was a 15 minute job with scissors & tape, adding a capacity planning check took 2 minutes and adding new charts and graphs took 10 minutes. Better still – an unplanned adjustment – when we have a success story from our users, one of the team will bring the evidence along and tag it to the board in whatever format they wish.

There’s some further changes needed to our process this week. One of the horizontal streams of work is a (roughly) repetitive series of activities so we’re going to start tracking cycle time on these and moving to a Kanban model as we need to start setting expectations to our users for these areas. In parallel, the less predictable work will be continuing Scrum-style for the development team. We’ll be ensuring the board captures these stats for us to see every day.

As soon as you start using electronic tools, there’s an immediate speed barrier to the changes you want to make plus there’s often the constraint of a small screen (or investment in a large one), how to add related information in meaningful ways without underlying data model support, user experience, data entry and the ability for non-technical team members (my current team is 50% sales & marketing staff) to make changes.

Don’t get me wrong, when you have a globally distributed team, you’ll almost certainly need an electronic tool as a single point of truth but it’s just not tactile or flexible enough to support the level of interaction and adjustment that a constantly evolving project and process needs. Many companies adopting electronic tools push for standardisation to keep processes consistent, costs under control and sustain support for reporting aggregation. This really stifles making adjustments to the process to suit project and environment context.

I’m not entirely down on electronic tools. I’m actually quite a fan of Trello at the moment and use this for sharing our bigger picture with the spectrum of stakeholders we have around the business that cannot be co-located. At least it’s a tool aimed at users, (rather than many commercial electronic boards whose capabilities tend to target management reporting instead) however for now Trello is limited to swimlanes, a constrained card format and the need for a screen. It’s not quite tactile or ubiquitous enough. Extending it requires time, technical skills and screen real estate rather than simply a process gap and a creative team member.

In my time at a very large US corporation we did a great job with the constraints we had. We used giant smart boards with virtual card walls, high-spec videoconferencing and large TV screens. At the time it really was state-of-the-art  stuff but it still limited our visual management capabilities. We only ever really had a shared basic card wall (the reporting and metrics weren’t particularly visible to the teams). All the other peripheral information you can get from a great board during your standups wasn’t visible.

The teams actually developed and maintained physical boards in each location and ended up using the electronic tools as a synchronization point.

Whilst we could virtually move cards around on a giant touch-screen, changing information on the cards themselves required reverting to a keyboard, detaching from ongoing conversations and manually editing within the tracking tool. It worked but it really was a compromise.

Contrast this to our current board – if something needs adding or updating, the active conversation continues whilst a team member grabs a pen and starts writing. If our process changes, we update the board format the same day.

I just had a passing chat with my colleague David (another of our DevOps team) about electronic vs physical boards. He summed it up brilliantly; “I don’t know why… …but it’s just not the same”.

We also tailed off into the value of an entirely co-located team. A rarity for many these days but a real game-changer in the performance of your teams – I’ll cover this another day.

So in summary, even where you have distributed teams, work with a physical board for as long as possible to allow your processes to adapt and develop to the context and project around you. When you start using electronic tools you’ll find the pace of process improvement will significantly decrease.

If you’re hunting for more whiteboard examples, you may also want to take a look at “A Year of Whiteboard Evolution” and “5S Your Scrum Board”.