In a series of articles I discuss the importance of visualisation of work using an Agile Board for effective software development. I contend that while most teams attempt this to some extent, relatively few think about it much or do it particularly well. This article considers a possible reason for this state of affairs: the influence of the underlying methodologies used by such teams.

Scrum is unquestionably the dominant organisational methodology in software development today. Probably second in influence is Kanban, a system whose roots are in hardware manufacturing, and whose principal advocate in the world of software is David Anderson, author of the seminal book on the topic. What is the place of visualisation in each of these methodologies, and how does that relate to what we see in the workplace?

We’ll start with Kanban. The very word itself denotes a visual card, originally used to control inventory in a manufacturing production line:

In Anderson’s porting of Kanban into the realm of software, he states its major principles as follows:

1. Visualize¹ the workflow
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively (using models & the scientific method)

In other words the First Commandment Of Kanban, just as the meaning of the word itself, tell you that visualisation is at the heart of the methodology. Since a ‘workflow’ is precisely the series of steps that any piece of work goes through from conception to finish, you are not even doing Kanban if you haven’t structured your world around an Agile Board (also known, not surprisingly, as a Kanban Board). You would therefore expect practitioners of this philosophy to have thought considerably about how best to create and use such boards, and to be somewhat refined and advanced in their practice of it.

But what about the dominant methodology, Scrum? A search through The Scrum Guide 2016 contains not one mention of the words ‘visualize’, ‘workflow’, or ‘board’, so the contrast with Kanban is immediately clear.

Below are some excerpts from the Guide that could be implemented via something like an Agile Board, but they could be implemented in other ways, even ones that are not visual at all.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog

[In] the Sprint Review… the Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

Monitoring Progress Toward a Goal: At any point in time, the total work remaining to reach a goal can be summed…  This information is made transparent to all stakeholders.

At any point of time in a Sprint….the Development Team tracks [the] total work remaining…[to] manage its progress.

More promising is the language used to describe two Scrum ‘artifacts’, the Product and Sprint Backlogs:

The Product Owner [ensures] that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. [It] is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint

This is more like it! But before we get too excited, remember that a Backlog is really just an ordered list, and lists are hardly rich visual experiences. This isn’t quite a direct command to use something like an Agile Board.

And finally there is this:

Significant aspects of the process must be visible to those responsible for the outcome.

This is the most promising allusion, but no more is said in the Guide – the very next sentence goes on to talk about agreeing terminology and a definition of done, which (while definitely important) are clearly nothing to do with visualisation.

In summary, there’s nothing in the Scrum Guide that stops you using an Agile Board, but there’s also nothing that requires or particularly promotes it, and so you might expect that teams following this programme may try some form of work visualisation, but might not have developed it particularly far – which is exactly the situation commonly found in most software development teams. Thus there is a plausible cause-effect relationship between the low prominence given to visualisation techniques in the dominant methodology, and the somewhat half-hearted attempts at a fully-functioning Agile Board that we see in many real software teams.

No article comparing Kanban and Scrum would be complete without mentioning the best short guide to the two; Henrik Kniberg’s masterful free booklet, Kanban and Scrum – Making the Most of Both is a must-read for anyone interested in the topic, chock full of insights and wisdom, and highly recommended.

[1] a constant nightmare for Brits writing on this subject is having to switch between UK and dominant US spellings of key words