Why all the boards for your lean and agile teams should be visible all the time

A simple answer would be: spatial memory.

A slightly longer answer could be: spatial memory and confirmation bias.

(Oh, and by the way: They should be visible all the time only for the people who need to see the information on them)

But let's put that into context. Why are spatial memory and confirmation bias important for the way we use boards in Agile teams?

As many people have pointed out in the past Agile doesn't fix any problems, it just makes them visible, so that it is easier to do something about them. One of the tools agile teams started to use early on to facilitate this is visualization. A team, working towards a goal, visualizes the information they need to know about. This can be all kind of information –which might be a topic for another blog-post–, but one of the most prominent visualization techniques is the taskboard. Taskboards are especially helpful for knowledge workers because the very nature of our work makes it impossible to directly perceive the status of the work – let alone knowing how much work is currently in progress. The Kanban method went so far as to have the notion of ‘making invisible work visible’ at its very heart, albeit many so-called Kanban-boards are merely task-boards.

To really make use of this visualization we need to leverage spatial memory and counter confirmation bias.

Why spatial memory?

If the great benefit of (Task-)boards is, that they make work tangible and agile only makes problems visible, then it is important, that we help our brain to make use of this information. With a visible board, it is plausible that the amount of information displayed is still manageable. With electronic boards on the other hand: not so much.

Physical work (what David Allen –of getting-things-done fame– calls "cranking widgets") takes up a defined amount of space and most of the time also a defined location. So, for example, when working on some home-made stuff, during sanding it is easy to remember that “the blocks on the left side of the table still need work, and those in the upper row need some special treatment because they felt ’strange’.“ In this case, ‘left-hand side’ would be associated with unfinished and ‘top row’ with special treatment needed.

Likewise, if we have a number of boards physically placed throughout the workspace, location gets mapped to meaning. After a while, we just ’know’ that we have to look at the board on the wall behind Jenny to see the current status of Portfolio initiatives. Or at the board in the hallway to see the state of affairs with regard to the committed user-related features.

One could argue that having electronic boards for the same information works almost the same, because with electronic boards we just ‘know’ that we have to go to «boards»->«companywide»->«MyDepartment»->«Initiatives» to find the portfolio information and we have to go to «boards»->«MyDepartment»->«Stories» to see the committed user-related features. But this draws on a different kind of memory, which is accessed a lot slower. And takes more energy to activate. At least that's one of the learnings I took away from Sharon Bowman’s “Training from the Back of the Room”.

Even our figures of speech are quite informative here. Getting a ‘picture or the situation’ or having the ‘big picture’ are good examples of this.

And glancing at the walls just takes somewhere between a fraction of a second and a couple of seconds, depending on how much information you want to absorb. It even happens without conscious effort. Just walking by the feature-board in the hallway and the portfolio-board behind Jenny's desk gives you a certain amount of situational awareness - whether you want it or not.

What about confirmation bias?

Unfortunately, even though one of the original ideas behind Agile approaches was to make problems visible most humans are influenced by confirmation bias. We tend to look for helpful clues to help us to confirm whether a course of action is feasible. In earlier times that was helpful – and it even is helpful today as Jeffry Levine explains convincingly on quora. We wouldn’t be able to act in the world if we didn’t apply filters to the huge amount of information that comes at us all the time. And re-thinking topics we already thought about would –most of the time– be a waste of the rare resource mental power.

One of the implications of this is that we –in general– don’t go out there and look for things that are not as expected. We probably won’t open the portfolio board every day to check whether the portfolio item that our current feature relates to just got flagged ‘canceled.’ And neither is it likely that all portfolio managers look at the detail boards all the time. But, in my personal experience, they develop quite a keen eye for an agglomeration of blockers on features if they pass that wall several times a day.

To help people tackle problems and issues they care about it does help to make this information visible. Especially in those cases where nobody would actively look for the unwelcome information.

It's called visual management for a reason

Even if Agile and the Kanban method have both somewhat evolved from their roots in Lean, the whole board idea is based on visual control and the enormous lever for self-management it provides.

So, if you use boards, make sure the important ones are visible all the time to the right people.

till next time
  Michael Mahlberg

How to find the cards

When teams turn towards kanban as a process control method I often see people standing in front of the board asking “Where the #*$+%+ is the card with task #12345?“

Is that a problem of physical boards?

One could easily argue that this is because it is much harder to find a card on a board than it is by using an electronic search engine.
And I guess that is true.
But that is not the problem here. In my opinion the real problem here is that the board is not yet used as a tool but only as a reporting system.

If you use the board as a tool you never have to search a card

If you use the board as a tool to drive your work it is hard to image a situation where it would be necessary to really search a card. Since you would be working on one, and only one topic at a time you would know exactly where the card you’re working on right now is. And when it’s finished you would move it to the respective «done» column and select a new card on the board according to the station you're working on and the prioritized cards on the board.
In most cases that card would be the topmost card in the «done» sub-column upstream from the one you're going to work in. And once you select this card as your new item to work on, you would move it in the «doing» column of your selected station (e.g. development).
Since this is the card you are working on (perhaps together with somebody else, but in your responsibility) that card won't move on it's own. So you know exactly where it is. So once you're finished with it you would move it to the respective «done» column... (see above)
Rinse and repeat.
No need to search for a card.
Unless you let your work be driven by another system – then of course the question arises “which is the leading system?”

till next time
  Michael Mahlberg

Breaking down the task-board

Have you ever experienced that dull task breakdown session, where you started with a couple of concepts (lets say street and phone and country) and ended up with a list of three or four tasks that somehow re-occured several times?

In this case perhaps:

• modify database schema to accommodate street
• modify ui to display street
• modify validators to validate street
• modify database schema to accommodate phone
• modify ui to display phone
• modify validators to validate phone
• modify database schema to accommodate country
• modify ui to display country
• modify validators to validate country

In these cases it might help to think differently about your work – perhaps those repeating categories are in faction stations that each of the concepts to be implemented have to go through.

Some people would model this as three different stations

• Database
• UI
• Validation

If you put them on the board as separate columns each item could be reduced to it's concepts core and just ‘flow’ through the system.

Database	UI	Validation	done
street
			phone
		country

So, perhaps it’s time to rethink task boards, put in some of the ideas from lean and kanban and add a couple of columns.

(of course not with the exact names from above ;-)

Disclaimer:
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

till next time
  Michael Mahlberg

Boards: Paper vs. Digital – when, how and why

There are all kinds of boards around – Scrum Boards, Task Boards, Personal Kanban Boards, Story Boards, Portfolio Boards, Kanban Boards etc. – and all of them can come in different flavors. Two of the most distinctive flavors are “physical“ and “digital” and the difference is huge!

Even though the names differ, all the boards are in some way descendants of the kanban boards used in manufacturing, notably at Toyota.

(Of course there is a huge difference between kanban systems in manufacturing and virtual Kanban systems, therefor in Kanban the kanban is not the kanban, but that is another story)

Why use a board at all?

The first rule of Kanban is not ”You do not talk about it”.
Instead it is “Make it visible” or, to quote the correct words “Visualize the workflow” – and that is what a board is good at. In my early days with agile we called all kinds of boards “information radiators.” That term also referred to burndown charts, and burnup charts, and earned value visualizations, and defect maps, etc. – whatever was helpful, but never all of them at the same time.
The point is: information should be radiated. Made visible to everyone. And it should be the relevant information at the point where it is relevant.

Communicate!

Okay, so that is one part of it. But is there anything else, besides visibility?
Yes there is – such boards can also be a great way to communicate!
When they are located at places where everyone on the team notices when somebody else updates the board a lot of information is conveyed implicitly. Not to mention that the boards can serve as a culmination point for standup meetings and as a tangible way to discuss the current state of flow.

Create bite size chunks

Even if there are no WIP-Limits on the board, as long as they are physical there also is a physical limit on what can be put on the board. Just realizing – for example – that you can't put any more cards in “quality assurance” without calling some brick-layers to remodel the rooms can persuade teams to shift their work-focus.

Model your process

In Kanban for knowledge workers (the one with the capital K) the board also is a physical representation of the actual process – including process policies like WIP-Limits or cadences and such.

Electronic boards make change harder

Huh?
Seriously?
No, of course not – at least as long as you're the administrator of that electronic board. And you don't have too many reports that rely on the boards layout. And nobody shares basic definitions like stations (a.k.a. columns or status-values) or classes of service. And you have a way to remove stations that are not empty. And you can easily inform everybody about the new process policies that go with the new board layout.
As long as all of these preconditions are met, electronic boards don’t make change harder. But as soon as you introduce central administration, create elaborate dependencies, share basic assets etc. change becomes a lot harder.
After all agile software development was meant to be adaptable and one of the most important parts is that there are retrospectives (or operations-reviews). But what good are those retrospectives if it is not possible to easily (!) adjust the process accordingly?
Where is the empowerment of the team if some tool-administrator hast to edit status values, so that the so-called self-organizing team can get their new buffer column (or something like that) on the board?

Electronic boards reduce visibility

There used to be a saying "DOORS - where requirements go to die!". Lately DOORS in this quip has been replaced by the names of more modern tools, but still there is a bit of truth in that saying.
Requirements that are stacking up in a tool (usually) don't make you feel uncomfortable. Unlike walls, tools have almost no limitations and the difference between, lets say, 350 and 850 un-reviewed requirements is quite easy to miss.

It’s about learning!

One of the great effects that can be experienced by going through the pain of really modeling the actual work we do is that we learn a lot about our processes. And adjusting the visualization over and over again is what reflects this learning. We might start with a five station (column) board and end up with a five station board. But if our board really reflects the learning it will probably have experienced times with a lot more columns in between.

(Try to) always start physical

And since everyone can break the rules on a physical board (hang a card sideways to indicate an improvised class of service, write a new rule, suggest a new cadence etc.) which is immediately visible to everybody who comes along to interact with the board, physical boards facilitate the willingness to experiment. And there is a much smaller risk to break anything (which is just not the same with electronic boards) which also contributes to a more relaxed stance to experimentation.

So – there are some good reasons to use an electronic board and even if you do use a physical board you still have to find a way to process the data electronically. But the power of a physical board, especially due to its limitations should never be underestimated.

Until next time
  Michael Mahlberg