Originally posted as Kanban boards: physical or virtual? on Where Technology Meets Teamwork - Thoughts on TFS, Lean, Agile, Kanban, Scrum and other collaborative technologies and techniques
Physical vs. virtual kanban board: which is best? What are the options? How do you choose?
Recently I posed the question to the Northwest Cadence team: which type of Kanban board do you prefer? I’m in the middle of a huge process engagement with a global corporation, and Kanban boards are a key tool we’re using with their teams. I started out with a clear preference for physical boards, but as some teams have pushed back, or just plain ignored me and self-organized around virtual ones, I’ve gotten a broader perspective.
Spoiler alert: my preference hasn’t changed, but I have a better appreciation of the tradeoffs. I don’t tell teams what to do (here nor anyplace else), but as a result of this analysis I’ve taken greater initiative and have asked several of them nicely to consider the advantages of a physical board. (In so doing, I uncovered dissent within the teams, and developers who were championing physical boards before I asked!)
In researching this post, I looked around the consultosphere for a complete overview and didn’t find one, so I am taking the liberty of presenting my version here. I have limited experience with independent online boards (see: preference for physical ones), but I looked up a few and they’re included here superficially. I have a fair amount of experience with TFS, which is the version my client’s teams are proposing to use, so it’s included here with a bit greater detail.
Have I overlooked your favorite virtual board? By all means, clue me in in the comments!
TL;DR
Pros of physical boards
Flexible, easy to make incremental process change
Can display definitions of done per column and elsewhere
Can display system-level WIP (aggregate across all columns)
Can support blocked flags in any column/state
Can support sub-states
Can support split/parallel states
Can easily indicate multiple team members working on one backlog item
Can easily limit a team member’s WIP (e.g., to 1) by limiting number of avatars per person
Tells a story from a distance/in aggregate
Unavoidable; information is always available without the team having to intentionally open it
Visible (and unavoidable) beyond the immediate team
Go viral, generating enthusiasm and buy-in throughout the organization
Fun; team can own the board and play with it (fun avatars and other art, beer column, etc.)
Can easily hold the daily standup at the board (if collocated)
Team members appreciate the physicality of moving a sticky across the board
Moving stickies focuses the team on the right things in the daily standup
Pros of virtual boards
Provide equal access to distributed team members
Can enforce WIP and workflow rules
Can calculate cycle time and other metrics
Can populate CFD and other reports
Can track history of items
Pros of TFS (2012.2+) boards
Linked to check-ins, traceable
Linked to test cases, builds, documentation, other artifacts
Can drill into backlog items for more detail
Easy to decompose backlog items into tasks and visualize both on separate boards
Easy to aggregate backlog items into epics/features and visualize both on separate boards
Easy to aggregate items from multiple teams onto a project board
Team-level customizable columns allow flexibility while mapping to consistent enterprise workflow states
Touch support out-of-box
ALM Ranger Tiago Pascoal has written a killer TFS plug-in with a host of amazing board-enhancing features that my teams love. I’m nervous about recommending it as a complete solution, because it’s unofficial and unsupported; there’s no guarantee it’ll work in future TFS versions. But it’s well worth checking out.
The issues
A slightly deeper dive into some of the bulleted claims above.
Flexibility and placement
I’ve heard it said that physical boards are less flexible and harder to tear down to change. I don’t think that has to be the case.
Magic Whiteboard won BBC Two’s Dragon’s Den, and no wonder: it’s brilliant. It’s 20m of whiteboard surface, on a roll, for £33. It static-sticks to hard flat surfaces. You can make a Kanban board of any size on any wall (or window, and it comes in clear), flow stickies across, and modify columns easily, with no hardware and no damage. In one of my clients’ offices, we were able to route their Kanban board around a wall-mounted clock on their only available wall, without losing the clock!
In the Northwest Cadence Kirkland office, we used layers of magnetic paint, chalkboard paint, and washable chalk to make an amazing Kanban wall. The size and location of the wall were fixed, of course, but the layout of the board could be changed at any time to accommodate any process. Stickies and avatars were laminated, erasable/rewritable, and mounted on magnets.
In open-plan offices I’ve used rolling whiteboards, which have the added advantages that they’re two-sided, and you can roll them into conference rooms for meetings. Clarus Mobile Xpress portable glass boards are gorgeous and functional. Quartet Motion, Wilson, MOI, and others have simple rolling whiteboard divider panels that work and look great.
Features
Tagging independent of state
Items can become blocked in any state. You want to remember the item’s state and count it against your WIP limit for the state it’s in.
On some electronic boards, you can customize the color of individual stickies, which works just fine for this. In TFS, you can’t set the color or any flag (even in templates that have a Blocked field), so the only way to visualize blockedness is to create separate column(s) for it. Most unpleasant.
LeanKit, AgileZen, Silver Catalyst, and others also support custom tags and/or icons so you can make other facts visible about your items. TFS has tags, but they don’t show on the board.
Sub-states, split/parallel states, swimlanes
LeanKit handles complex board designs, second only to dry-erase as far as I’m concerned. (Steven Borg‘s fancy circular Kanban boards are still going to require a wall and some markers.)
Avatars
Some electronic boards use image avatars. Their uncreative sales demos show these as photos of the team members, but obviously you’d want to use something more fun than that. 
My hands-down favorites are custom South Park avatars and custom Lego minifig avatars.
Touch screen
I haven’t seen one in action yet, but I think these might almost be good enough. I would still miss the total ownership, fun avatars, and the impromptu doodling, but I think team members would love moving stickies on a touch screen even more than they love moving physical stickies, which focuses them on keeping work moving, and that’s a big win.
TFS still has some limitations in terms of configurability of lanes, but LeanKit Kanban has both advanced configurability and touch screen support.
I saw a blog suggest that touch screens are a good solution if you have “limited wall space” for multiple teams. Don’t do this. If teams have to fight for airtime on the big screen, you’ve thrown away the key benefit of the wall-mounted board: it’s a passive, unavoidable information radiator that engages teams (and bystanders) without anyone having to dig to find it. There’s a big temptation to justify the expense of the screen by repurposing it for other organizational data, too.
Distributed teams
This is a tough one for me. As you’ll read below, my preference for physical boards is all about what they do for teams, that virtual boards just don’t. And yet, with a distributed team you end up having great benefits for the ones who are collocated with the board, while the distributed minority of the team are pretty much screwed: many of the “pros” aren’t available remotely. Pointing a webcam at the board, taking a smartphone photo of the board, or synchronizing to a shared virtual tool, are clunky and poor substitutes for having the board in-person.
Here’s why I don’t consider this a deal breaker, quite:
The disadvantages of physical Kanban boards for distributed teams are closely tied to the disadvantages of having distributed teams in the first place. Agile methodologies teach us that teams should be collocated, and one of the original Twelve Principles for Agile Software states that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Kanban boards are meant to supplement in-person interaction, not replace it. Don’t blame the board.
Even when one team member is screwed, the benefits for the collocated portion of the team can sometimes be so great that they make up for the extra effort needed to keep the distributed folks in the loop. If your team are unwilling to do this, that’s another problem to not blame the board for.
Yeah, it’s a stretch. When teams don’t have any control over whether they’re collocated or distributed, no, it isn’t fair to blame them for the difficulties distribution can cause them. When I find this at a client, I leave the distributed teams alone and attack the issue two ways: I turn up the charm and try to persuade any collocated teams to use physical boards, and then with senior leadership I point to those teams’ success (along with the agile principles and a wealth of other supporting information) to get the organization to value and build collocated teams.
Bad reasons
I hear some #facepalm-inducing arguments against boards in general, especially physical ones.
Sync: the best and worst of both worlds
My client’s teams are typical engineers: they’re allergic to the faintest perception of redundant effort, like having to sync information from a physical board into a virtual tracking tool. Ever. I’m continually surprised by the virulence of their reaction when I suggest that:
it takes < five minutes a day, and
team members can update their own items in both places as they complete them, and/or
the team can rotate the update responsibility among all members.
To me, it’s a no-brainer: the benefits of a physical board are well worth this paltry extra effort.
(If syncing the board and the tracker takes any longer than five minutes, it means you’re tracking way too many things on either your cards or your tracking tool or both. I’d confidently bet you a fresh kürtős kalács that nobody’s even using all that data. If your process is too heavyweight, don’t blame the board.)
In the spirit of my typical engineers, who delight in finding complicated tool solutions for simple people problems, I fully disclose the existence of Agile Cards for JIRA, which purports to allow you to snap a photo of your physical Kanban board, e.g., with a Smartphone, and promises to parse the photo and update your JIRA tracking automagically for you. I do not have experience with this plug-in, so I have no idea whether it even works, but my typical-engineer heart (yes, I still have one) finds the cool factor highly appealing…
Feeling the pains
One of my mostly-collocated teams put up a physical board, after weeks of cajoling, but abandoned it after just one-and-a-half iterations of use. The team reported that having a Kanban board was great, they loved having the information easily accessible to all team members and found it extremely valuable to know the project’s status at any moment at a literal glance.
“Really? Why’d you stop using it, then?”
“A physical Kanban board is just too much overhead to maintain. I mean, when the business interrupts us in the middle of the sprint and tells us to drop all the work we have in process, and start over with a huge amount of brand-new work, the effort to tear down the entire board and rebuild it with all brand new stickies is totally unreasonable!”
“…”
Any Kanban board, physical or virtual, is just a messenger. The whole point of visualizing work as step one in a Kanban adoption is to identify bottlenecks and pains, so the team can work toward solving them. When the Kanban board exposes a team pain, if your solution is to get rid of the board so you don’t have to face the pain anymore, you are Doing It Wrong. Don’t shoot the board!
Engagement
To me, the Kanban board has one purpose above all others: to bring the team together. Technical folks have a habit of valuing individual (perceived) efficiency over fluffy crap like team spirit and morale and trust, which I think is why a physical board can be an uphill fight and is also why I keep fighting it.
I’ve seen physical Kanban boards transform teams. They improve communication, foster a spirit of ownership over the work, and create active engagement in daily stand-ups (which were previously dull and seen as a chore). I’ve seen physical Kanban boards transform organizations. They go viral and inspire non-delivery departments within organizations: I’ve been invited (begged!) to teach agile principles to HR, finance, and receptionists.
I’ve seen a lot of virtual board adoptions and a virtual board is just another tool. Even when the team likes it, there’s no transformation. There’s no energy. It’s a fine tool but nothing more.
How do you get buy-in from senior leadership in a large organization for the changes needed to transition to agile? If your CEO’s executive assistant is able to show her real-time status updates of major work using a physical Kanban board, and when asked where that idea came from can answer, “oh, it’s a technique I learned from your agile software development teams, it comes from Lean,” um, how far does that get you? Or the CFO finds that productivity and traceability in accounting have noticeably increased and they’ve got your physical boards to thank for it?
At one of the locations of one of my clients, their CEO was in town for an office visit, and he stopped to take a look at the physical Kanban board for a high-profile project. Several of the team members engaged him directly in conversation about the board, which represented a level of access they didn’t normally get at all, and as a direct result of pains he saw on their board, the team was able to get senior management support for key solutions they needed!
You won’t get that kind of organizational participation by burying your process on the corporate network in some tool.
Conclusion
Get a board. I prefer physical, but if that’s a blocker for your team, then by all means get a virtual one. Visualizing the work any way you can is better than not. And then, engage the team around whatever you’ve chosen. Don’t fight with your board; focus on the work it represents and the problems you can solve now that you’ve exposed them.
What did you choose, and how did it go?
Northwest Cadence can help you implement a modern application life-cycle. Call rick.flath@nwcadence.com today to help you get there more easily...