Do Agile Well

This article presents an idea. One I had from tens of thousands of hours of working with Kanban/Scrum boards and hundreds (possibly thousands) of hours of teaching and coaching others how to do the same. My idea of "Well boards" works for me and the boards I use for my day to day work. Hopefully they will be of use to you.

Agile itself does not particularly value processes or tools. However over it's 20 year lifecycle it has become synonymous with many tools probably none more so than the work visualisation boards typically called a Kanban board or Scrum board like the one shown below.

The beauty of these boards are their simplicity and flexibility. Originally designed to visualise work in a physical way using just a few cards (often Post-Its) and a wall they have morphed into a plethora of software tools all using broadly similar design as the original physical boards. (Note: I highly recommend Dominica DeGrandis' book "Making Work Visible" about using boards. It is excellent.)

Visual Information Confusion

This current design is flawed, however. One issue is that any user educated in a Western writing style is inclined to look to the top left to start reading. This is not the right place to start. In my experience, teams that read a board from the top left have an unsurprising tendency to start lots of new work without finishing the work in progress. Any team that does this during a standup often complains of standups taking ages - sometime hours. The correct place to start is just before the Done column. This focuses attention on what is nearly done so that the team "stop starting and start finishing".

A second issue is the orders of PBIs on a board. Even really simple boards like in Figure 1 above haver very odd ordering. The Done column has no particular order. The In Progress column has no particular order. The Backlog is (usually) highly-ordered from most important at the top to least important at the bottom. This gives a curious flow if PBIs across the board - the "happy path" is that they first flow vertically in the backlog column, before flowing horizontally across other columns to Done.

A third issue is where "Won't Do" (and similar) work should go. On physical boards, this was easily solvable - this PBIs went into the bin or as my friend Donal once taught me, onto the floor. on software versions of the boards it is most common to put these items into the "Done" column. This has the advantage that it allows drag and drop of virtual tickets but has the disadvantage that it can be difficult to see which PBIs were really done and which were cancelled, rejected, abandoned or no longer relevant.

Figure 2 uses a slightly more advanced board to illustrate the issues better. This board uses four classes of service: Expedite, Fixed Date, Standard and Intangible to set set a priority on work. I also use my personal preferred "vanilla" columns of Backlog, Ready, Waiting/Blocked, In Progress, and Done that I like as a starter with new teams. On this board, the most important PBI is almost certainly the Expedited, In Progress issue that is four fifths of the way along the top row. The next most important is confusing - it could be the PBI seen by reading the Expedite column from right to left or it could be the one seen by reading the in progress column from top to bottom. The Done and Won't Do resolutions are combined so it's not easy to see what has truly been recently completed.

Many past authors and speakers refer to how work "flows". In fact the much maligned predecessor to Agile was named after the most beautiful of natural flow artefacts - Waterfall. This misunderstands work. From physics we know that work occurs when a force moves an object against the field - a complicated way of saying that there is no such thing as a free lunch. Work never, ever wants to "flow", and if it ever did, it would be backwards.

The current design is flawed and based on a flawed model.

Introducing a "Well board"

At home beside me on my wall (and also on my wardrobe door) I like to visualise my work. My work flows consistently from bottom to top. The items I recently completed are at the top, and the ones I probably will never have a chance to do but I've not yet completely given up hope on are at the bottom. The items that are most important are on the left hand side of the board and the further from the left, the lower the importance. This means that the top left of the work not yet done is the most urgent and important item to do and everything descends from this. As positive work is applied the Post-It moves upwards from "To Do" to "Ready" to "In Progress" to "Done". If something negative occurs the Post-it moves downwards, from "In Progress" to "Waiting / Blocked" and potentially from there to "Ready" or potentially all the way back to "To Do" in really bad cases.

Figure 3 uses the same PBIs as figure 2 but in a Well configuration but with the standard swimlanes (now vertical) and my personal preferences for vanilla statuses. Perhaps the first thing to notice is that there are only actually 7 items that have been recently Done by the team. The two other PBIs that appeared to be Done in Figure 2 were actually rejected as Won't Do and are now at the bottom of the board. Now the most important issues is easier to determine - it is at the top left of the active PBIs. The next most important issue is easily determined to be the other In Progress issues. This follows the classic "F" shape used by designers to maximise attention to the top and left of a page. The columns below emphasise getting started work finished and the order of work is consistent and logical across the entire board.

Unlike current board designs soft versions of Well boards shouldn't need to automatically remove all items in a Done column after a period of time. Instead both the Done and the Won't Do could be scrollable to give a simple visual guide of what was done (or not done) and when. Also this vertical design could be more mobile friendly than current board designs.

Why "Well"?

Water management has always been important to human culture and collaboration. Many of the great engineering works have been to manage access to clean fresh drinking water and to remove dangerous sewage from where it could kill. From building irrigation systems on the Nile, the Euphrates and the Yellow River to Joseph Bazalgette's early forays into statistical quality control to manage pollution of the Thames in London water matters. The reason Jack and Jill went up a hill to get a pail of water was people have known that water taken from the water table under the top of a hill is cleaner and safer than some polluted with runoff at the bottom. Waterfalls promise free energy but in reality are beautiful and sometimes dangerous but not often very useful. A simple elegant and effective mechanism using work to get things done might be better. If you have to visualise your work, do it Well.