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.