As I’ve mentioned earlier most of the time it is a good idea to start visualization with a physical board. And very often it is a good idea to stick with that. For all the reasons that make it worthwhile to start with it.
One of the biggest advantages of a physical board is the one thing that command and control organizations perceive as it’s biggest drawback: A physical board knows nothing about the process.
The fact that the physical board knows nothing about the process forces the people who use it, to actually know about their working agreements. And to negotiate them. And to make them explicit in some way. Well, at least if the want to remember the gist of their long discussion from Friday afternoon on Wednesday morning.
As my esteemed colleague Simon Kühn put it all those years back: The intelligence is in front of the board.
But we’re all working remote now
Now, that we‘re not in a shared office space anymore, real physical boards are hard to do, aren’t they? Well – yes and no. If you look at the important advantages of physical boards, they are easy to replicate with today’s electronic white board solutions.
Whether you use use google drawings, miro, or conceptboard –to name just the ones I’m familiar with– is mostly a question of taste and, more importantly, legal and company policy considerations.
Using a simple collaborative whiteboard enables people to have most of the advantages they can have from physical board, while retaining the advantages of remote work.
What are the big advantages of a physical board?
A physical board can easily be changed by everyone. Just pick up a marker and draw something on it. The same is true for electronic whiteboards. In both cases it is a good idea to also have a talk with your colleagues to make sure they are okay with the additional (or removed) thing you did to the board.
One could say “individuals and interaction over workflows (process) embedded somewhere in a ticket system (tool)” – just to reiterate the first value pair from the Manifesto for Agile Software Development as an argument for “physical” boards.
Physical boards have extremely quick iterations. Trying out whether a new policy makes sense takes just a pen, a sticky note, a quick discussion and a couple of days (sometimes only hours) to see if it works. Conversely, with ticket systems even proposing a change to the admins often takes weeks and needs a predefined concept and sign-off. Not exactly agile. But with electronic whiteboards you can do just the same things you would do on a physical board. Which is why they provide tremendously quick feedback loops.
And as Boyd’s law of iteration says: speed of iteration beats quality of iteration.
If you decide to add a new status on a physical board or add new meta-information on a ticket, you don’t have to migrate all the old tickets. And you don’t have to coordinate that meta-information with the names of the meta-information of all other projects in the organization. Another huge an advantage of physical boards over ticket systems. And you can achieve the exact same independence with electronic white boards.
But where do the details go?
When I have these discussion in real life, I usually get a couple of questions about the details. Let’s look at two of them.
Q: On a physical board I used to write my acceptance-criteria on the back of the card. I can’t do that with an electronic whiteboard.
A: True, but then again you can put a link on the card on the electronic whiteboard and that can point to almost any place you like. For example a wiki-page that contains that additional information.
Q: But if I use a dedicated bug tracker (the origin of Jira) or any other ticket system I have all those nifty fields for details.
A: But do you need them on the card? Wouldn‘t they better be put on a documentation page?
My general advise here: put only meta-data on the card and all the other information in appropriate systems like a wiki. This also gives you the opportunity to put the information where it belongs in the long run, instead of putting it on the perishable ticket. On the page related to the ticket you can just link to or include that central information.
But what about metrics?
One of the things that gets lost with the ”physical” board is the automated transcription of relevant data for statistics. And I have to admit that this is a real disadvantage. With an electronic whiteboard you could either write a little plugin that tracks the movement of the cards or do a very strict separation of concerns and use different tools for different topics.
A word of caution – writing that little tool for the electronic whiteboard might not be that easy, after all. And even if you were going to do that eventually, it would be a good idea to start by collecting the metrics manually.
Either way: if you start with the metrics that you really need now and create your own tools for those –based on spreadsheets or databases, after all you’re in the software development business— you have a huge advantage over the metrics provided out of the box by many tools: you actually know, what the data means.
And some of the most important metrics are actually easy to evaluate and some of them even easier to capture.
Just give electronic whiteboards a try – if you adhere to the same ideas and first principles that guide your usage of a physical whiteboard you should reap almost all of the same benefits and get a couple of helpful things like links on the cards and enough space for dozens of people to stand in front of the board on top.
till next time
Michael Mahlberg
No comments:
Post a Comment