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

Human beings, like all primates, are primarily visual animals. We depend on our eyes far more than our ears or noses to apprehend and understand the world around us.

This means that, to a pretty good first approximation, we are aware of, think about, and respond to (or, in other words, ‘manage’) what we can see, and ignore what we can’t. Since it’s best to work with, not against, the grain of millions of years of evolution if you want to get stuff done, the Prime Directive of effective management is to make your work visual.

By representing your work visually in a unified way across all the group(s) of people involved in that work – those who request it, do it, check it, manage it, pay for it and benefit from it – then all these people will have a verifiably similar understanding of that work: what’s been done, its current status, what’s coming in the near/middle/far future, what milestones have been achieved thus far and what the problems exist. Without such a common understanding of the world and its challenges, these multiple people are not a team in any real sense of the word, and are correspondingly unlikely to make systematic progress together.

It is thus no exaggeration to say that the common understanding of work, that can only be achieved by making work visual, is how you build effective teams, and teams are what allow you to make progress and deliver what the organisation needs. It really is that important. In my experience very few teams have ever given their work visualisation much thought, and as a result not that many do it well, leading to poor coordination and massive waste.

To summarise: in complex fields such as professional software development, if you want to act like a team and manage your work effectively to make any progress, and do not want to risk wasting all your money and time, you must find good ways to make your work visual.

So what kind of visualisation are we talking about? The relevant characteristic of software development is that work passes through a series of discrete steps, moving through many hands as it does so, both between teams, and within teams (the typical sub-teams in software development being: Dev, Test & Product). While this flow of work has some loops and eddies in practice (ie parts of it are iterative), there is still a clear direction of travel, broadly: idea generation and selection – fleshing out – coding – checking – sending live (= done).

Such step-wise work with multiple handovers is best visualised on a two-dimensional grid, where the vertical columns represent the steps that the work flows through, from left to right (or right to left if everyone’s native language is Arabic or Hebrew), and the individual chunks of work are represented by cards or tickets that sit in the columns. Such a board goes under many names, perhaps the most common being Agile Board or Kanban Board. Although the latter is probably the most accurate term, the principle of visualisation is broader than any one methodology, so I will use ‘Agile Board’ by preference.

As always, lousy implementation will ruin even the very best of ideas, so such an Agile Board needs to be set up, maintained and used well, and I will write a series of articles on this topic.

In conclusion; proper work visualisation using Agile Boards is the arguably single most important component of efficient management of software development. Only by leveraging our most important sense, vision, can you effectively create common understanding and a sense of teamwork in complex organisations. Most software teams try to implement it to some extent (especially if they are more influenced by Kanban than Scrum), but few think about it deeply and many attempted implementations are deeply flawed, which goes a long way to explaining the wasted money and poor outcomes of much professional software development.

As an industry, we need to do this better.