Digital vs Physical Kanban Walls: Making the most of both

Originally published in Agile Today volume 13.

Following my visual management talk at Agile Australia 2016, there were a number of questions from the audience around using digital Kanban walls instead of physical walls. In this article, I will explore the benefits of each and offer some tips for getting the best out of both worlds.

I recommend starting out using a physical wall for the maximum visceral, emotional and cultural impact. Physical walls provide a meeting place for formal and informal conversations, and subtle but continuous opportunities for collaboration. Team members and leaders in the organisation can see the current situation and any problems immediately and continuously, without any effort getting access to a tool.

Physical walls have unlimited flexibility of design and of what can be visualised and thus represent an opportunity for expression of team culture. Physical walls can be funny and creative in a way that no digital tool can currently match. There is also a whole world of visual management beyond what current digital tools can support: achievement posters, dotting, blocker clusters, team policies, schedules, roadmaps and pairing stairs to name a few. In reviewing Jimmy’s book 96 Visualisation Examples,[¹] I counted 70 examples that I don’t think are possible with current digital tools.

As soon as I point out the advantages of physical walls, the following questions arise: “What about remote workers?”, “Won’t a tool make all the measurement and reporting easier?” and “What about sensitive information?” Teams of engineers in particular, typically express a general sense that using a digital tool might be a better and more comfortable choice for them.

Indeed, digital work management tools have many advantages. In addition to being able to access the tool from any location, digital tools allow attaching and searching related documents and also directly link to code changes in software. Digital tools can also automatically produce reports and charts without manual data entry. In regulated environments the audit trail and change management provided by a digital tool can be essential. So what should we do?

I believe the best approach is to use both physical and electronic tools in parallel, regardless of incremental costs of double handling, in order to get the benefits of both. I believe physical and digital walls provide fundamentally different benefits (see Table 1) and I believe the choice between them is a false dichotomy: we almost never have to choose only one.

At first this idea may seem like it would waste time, effort and accuracy. Many people point out the inefficiency of double handling the work items in both places. Underlying this thought is usually the idea that efficiency is critically important. I suggest that the small extra cost of using both systems is far less than the value of having both approaches available.

So how do we minimise the cost of running both physical and digital walls in parallel? Here are 5 tips for getting the best of both:

  1. For teams of engineers that can’t get past the idea of double handling work, consider an always on touch screen as a potential compromise. At a number of the teams I worked with used a particularly large touch screen with a digital wall and we found it worked reasonably well for daily meetings. Some limitations we experienced included a lack of flexibility of wall design and a fairly limited amount of information displayed on each ticket. We noticed the lower resolution and much smaller displayable size compared to our physical walls.
  2. If you want the benefits of the physical wall but need to provide access to a few remote team members, try taking a photo each day of the physical wall and uploading it to an intranet or wiki page. This approach can be extended with a webcam pointed at the wall at all times and there are new telepresence robots that are an excellent option to achieve this.
  3. Consider how often you will update each wall. In one team that wanted automated auditing and reporting, they used a tool for all planning and tracking of work items, but only updated the tool at iteration boundaries: during the iteration they used a physical team wall, and updated the tool at the end of the iteration. We can extend this idea to experiment with separate, distinct lifecycles for the physical and electronic systems and this can reduce or eliminate much of the double handling of items.
  4. To reduce confusion, try nominating one system as the “source of truth”. For example, teams can update the physical wall during the day, and sync the electronic tool as needed, perhaps only once per day. To make this even easier, some teams have a laptop or tablet located next to the team wall for just this purpose: quickly updating the electronic system just before or after a daily meeting at the wall.
  5. A highly distributed team may be spread out across many locations. For these kind of teams I suggest each location has a local physical wall to get the day to day benefits of visualisation, focus and collaboration, with the electronic tool being the primary system of record. This even works for locations that have only one team member. For example, if one team member works from home, having a personal kanban board[²] for the solo team member provides all the focus advantages to that person at minimal overhead. I’ve had solo workers report a reduction in distractions by simply having the current tasks physically visualised near their workstation.

If we are open to experimentation, there are many ways to reduce or eliminate costs associated with having physical and digital kanban walls. Next time you are tempted to choose one over the other, stop and think if you can experiment with having both to truly get the best of both worlds.

Table 1: Benefits of Physical and Digital Kanban Walls

Physical Digital
Meeting place Remote access
Information radiator, visibility Attachments, detail and links
Visceral, emotional and cultural impact Search and Audit
Flexibility, creativity, fun Automated Tracking and Reporting


Works Cited

[1] J. Janlén, Toolbox for the Agile Coach, 96 Visualization Examples: how great teams visualize their work, Crisp Publishing, 2015.
[2] J. Benson, “Personal Kanban 101,” Modus Cooperandi, [Online]. Available: [Accessed 2016].

To explore these ideas in more depth, you can register for Ben’s upcoming Visual Management Masterclass

Got a Kanban Wall? Try my free online self-assessment

Has your team started visualising work? Are you adopting Kanban? Are you wondering what’s next?

Try my online self-assessment survey to review what techniques you are currently doing and find next steps for improvement.  The survey is useful as a baseline for measuring your depth of Kanban adoption over time and also as a checklist of ideas for techniques to try. I recommend my clients conduct the survey one month after doing my visual management training, and then every 3-6 months after that.

The survey looks at three areas: Clarity of the the work (position of the work, performance measures and identification of problems), Controls (over team capacity and commitments to stakeholders) and Collaboration (feedback mechanisms and team collaboration practices). 

I will send all participants a report on insights into the state of Kanban across the survey once there are enough responses. Don’t miss out!  

Sign up below for access to the Visual Management Online Self Assessment Survey

Name *
Interested in

Was 2016 overwhelming? You are not alone: how to make it better in 2017

Are you or your team members stressed? Overworked? If the holidays feel like taking a breath from a crazy workload then you are not alone.

Many of the teams I see are doing too much. Often 10 simultaneous ongoing projects per person! It's not right and you can take practical steps to make it better.

If you are too busy to fix any underlying issues then a good place to start is adopting very basic visual management techniques to get out of the chaos: get clarity around the current work, what is being worked on, by who, and in what sequence.

Once you have a good handle on current problems and performance then it becomes much easier to put in the essential controls around team capacity and commitments to customers.

In a half-day class I teach practical techniques to get this clarity and control over work. I have just announced limited dates for public classes in Melbourne and Sydney.

If you know someone who could do with the gift of clarity over the chaos, please pass on these links to limited early bird tickets:

Visual Management Masterclass Melbourne - 19 January

Visual Mangement Masterclass Sydney - 22nd February

I'm also available in the new year to work with your team providing onsite coaching and deep dive training.

Happy holidays and all the best for 2017!

PS. I have a collection of visual management materials available free to subscribers.




What I learned at the Kanban Leadership Retreat

I arrived in Bali yesterday for the Kanban Leadership Retreat. Check out the welcome we got at dinner:

It’s great to be away from the cold of Melbourne and the resort here is amazing. I love this format for a conference, and over lunch today we are visiting a volcano!

We did our open space planning last night and the topics that were interesting to me included:
- Kanban Failures
- Visualising Decisions (from our own Daniel Ploeg)
- Forecasting and Monte Carlo simulation
- Kanban by stealth: evolving from other methods
- Evolving beyond NPS using Fitness for Purpose scores
- Demo of Russel Healy’s new Obeya software (of GetKanban game fame)
- Latest Risk Management theory in ESP
- Kanban outside IT (from me and Daniel)

I’ll update this blog post with summaries of the sessions I attend... stay tuned.

Kanban failure

I liked the idea that the only real failure is the  inability to evolve or improve.


  • Focus on high utilisation
  • Inability to say no to demand (push)
  • Lack of trust in staff, theory X thinking
  • Fear

Possible causes

  • Management thinking
  • nfluence of education
  • Lack of leadership training
  • Lack of courage


This was a mind bending session on maths and statistics and how they relate to making forecasts. My favourite part was the idea of "Turbulence": the variation of your variation.

This allows you to spot regime changes and tells us when the data set in not suitable (not stable) for making predictions. It also shows ideal places to split the data to account for changes.

I also liked the classification of different lead time distributions using the type of Weibull distribution (k number) with a k less that 1 mapping to long tail, Operations and help desk type environments.  

Today I'm speaking at Scrum Australia: my slides, an assessment tool and more

I'm some combination of excited and nervous to be talking at Scrum Australia today! I'm talking about extending scrum adoption with Visual Management.  See my notes from other talks below.

If you'd like the materials mentioned in the talk, sign-up to my updates list below, and I'll send you a link to my subscriber-only materials, this includes:

  • My mini-book: Visual Management Mastery
  • Slides from my talks
  • A visual management self-assessment tool
  • A discount for my upcoming public class:  Visual Management Masterclass

Some notes from the conference

A really great talk by Steve Denning

  • Agile is a mindset: without the mindset, there is no benefit
  • Genuine agile is delighting the customer
  • Huge change: the priority needs to shift completely from shareholder value to customer value
  • Customer is missing from the org chart
  • Motivation is: change or die
  • Agile can be fragile: one manager can destroy 10 years of progress in 10 minutes
  • No time to loose: 7 years for Microsoft to move towards genuine agile
  • Requires strong leadership at all levels that are obsessed with customer value in order to fight the entrenched mindset

10 workplace challenges and the urgent need for effective Visual Management

Again and again I see teams that are busy, stressed, suffering from low motivation and are generally underperforming against their potential. 

Here are the top 10 challenges I see for these teams, and some thoughts on how effective Visual Management can help us meet these challenges.

#1: Too busy to improve

Most teams now have more work to do (demand) than people to do it (capacity), this has become normal. It is no longer enough to work harder or longer hours to keep up.  The pressure to be busy 110% of the time, doing “real work” means teams are too busy to invest in self improvement or process optimisation. Learning suffers. Overall levels of service, both speed and quality suffer.  Visual Management provides techniques for managing demand and capacity to free up space for improving service.

#2: Everything takes too long

Overburdened teams are often working on multiple projects simultaneously and sacrificing vast amounts of productivity to multi-tasking costs. The more simultaneous projects the team takes on the longer each project takes to deliver, often leading to a snowball effect. Unhappy stakeholders pile on more pressure to deliver and make the situation worse. Visual Management can provide a mechanism to better understand, communicate and manage down the number of simultaneous projects with stakeholders.      

#3: Unhappy staff

Busy teams are often those with the worst levels of happiness and engagement.  Staff become either checked-out or burnt-out and often see no end in sight. They often have a poor handle on how their individual contribution relates to overall goals and are usually completely disconnected from a sense of purpose and disconnected from the customer.  In contrast, highly visual workplaces often have energetic and highly engaged teams.   

#4: Lack of autonomy, accountability and pride in work

Without a clear and simple mechanism to self-manage work, teams who are under significant pressure will usually revert to a command-and-control style management approach, leading to a lack of autonomy and accountability. Staff will be reduced to order takers, and in the worst cases check their mind at the door waiting for instruction from above. Low autonomy leads to a lack of pride in work and motivation suffers. Low motivation means low productivity.  Effective visual management allows teams to self-manage their work and to take ownership of end-to-end workflows, even in high pressure environments.

#5: Poor transparency and slow access to critical information

Information is power, and in some environments information is hidden and known only to a select few.  In many environments critical work information, e.g current priorities, performance against purpose, stakeholder agreements, who is working on what, and what needs to be done next are often hidden away in electronic tools or in people’s heads. At best they are slow to access, at worst the information is not available in any accessible way. Well managed visual workplaces provide instant and easy access to the most important information, constantly updated and always at hand.  

#6: Lack of collaboration  

In an individually managed workplace it is easy for teams to focus on just their piece of the puzzle and it can seem unnecessary to have an understanding of what others are working on or how their work contributes to the overall delivery of value to the customer.  Opportunities are lost to help colleagues, to reduce hand-offs, to reduce rework and reduce cross-function and cross-team waste. Visual management can encourage shared understanding and create opportunities for collaboration and improvement.

#7: Work is getting thrown over the fence

Highly siloed organisations often have departments throwing work over the fence via email or documents often leading to distrust, rework and significant delays to customer service. The best visualisations bring staff together across departments and start to break down the silos while creating opportunities for longer term system of work improvements.  

#8: Working on the wrong things

Without clear prioritisation policies and good visibility of incoming demand it is very common for teams to be working on the wrong things, working on lower value work when there is higher value work not getting done. Visualising demand as a queue can provide a mechanism for rich discussions around priority and allow difficult trade-offs to be made clear to both team members and stakeholders.        

#9: Lack of motivation to change 

Larger organisations have often established was of working over decades, and there can be very little motivation to adopt new practices, learn new techniques or to improve in general. One of the subtlest yet important impacts of visual management is emotional: physical and tactile change in the workplace can kick-start cultural and process improvement even in previously established and static environments.

#10: Conflict is personal

When work is owned by individuals or when the projects are represented by staff there can be a tendency to confuse criticism of the work for criticism of the person. Conflict can become personal and avoided at all costs. Useful feedback about the work can be lost or feedback can be taken personally instead of part of an ongoing improvement of products or services.  Visualising work can externalise the focus of feedback, literally putting on the wall to be discussed separate from the staff involved in the work.

Effective Visual Management is a critical skill

I provide training and coaching for leaders and teams in advanced Visual Management techniques. I’m pleased to offer my half-day master class for agile leaders at Agile Australia this year. The class covers the key principles and practical techniques to master Visual Management. Get in touch if your organisation would be interested in running a private version of this training with your team. 

I hope you can join me at my workshop and don’t forget the early bird pricing for all workshops ends April 20.



Is Atlassian's "ShipIt day" a potential culture hack for introducing feature teams?

In my last post I wrote about Large Scale Scrum (LeSS) and how feature teams were a key element of the framework for me. 

One of the concerns that was raised in comments was how will team members react, in particular will the reduced emphasis on specialisation challenge team members sense of identity? Will the change be too fast or too disruptive?

When I think of companies that are successfully using many feature teams and have great culture I think of Atlassian and REA, and one of their most visible practices is their regular ShipIt Day aka Hack Day.   

My experience participating in Hack Day at REA has stuck with me, and when a client asked recently how to introduce feature teams, I suggested they start with a ShipIt Day. All going well, this could be followed by a pilot of one or two feature teams before any wider adoption.

The thinking behind using a ShipIt Day to ease the way to feature teams was that it would be a chance to try out out feature teams for a day in a safe context, and to give them a chance at running a team self-selection event. It would give teams a try at self-organising across disciplines at the same time.  I also suggested that allowing team members to volunteer to work in a team instead of being assigned to the team by a manger would build more buy-in for similar team structures in the future.

If you like this idea, here are some resources for running a ship-it-day:

All going well, the next stage would be using a self selection event to create a pilot feature team around a high value product area and using an urgent cross-component feature as the motivation for trying out the new team structure. 

Resources for running a self-selection event:

I'd be interested to hear your thoughts on ship-it-days and moving to feature teams. If you would like to have a chat with me you can book a catchup online here




An initial problem with Large Scale Scrum (LeSS)

I've noticed a bit of a problem with Scrum: it's comes across as hopelessly idealistic and simplistic for many people hearing about it for the first time. If you work in an organisation of any complexity or size you will have felt this gut reaction to hearing a Scrum expert explain the framework: it seems to ignore the reality of the current organisational complexity, existing roles and management thinking.

I was in Sydney last week attending the Certified LeSS Practitioner training by the wonderful Bas Vodde. 

At the training I found LeSS triggered an even worse gut reaction: as a direct application of Scrum at organisational scale LeSS seemed too simplistic to address the challenges across multiple teams, systems and functions. The challenges seem much more difficult at organisational scale compared to adopting Scrum at a team level.

I'm happy to say that after 3 days of stories, exercises, insights and some hilarious videos from Bas, I feel I got past this initial "it's too simple" gut reaction and gained a new perspective on Scrum and some new ways to think about agility at organisational scale. Here is one of the best bits from the training:

Actually creating real feature teams.  Feature teams done properly are for me the central idea for organisational agility in LeSS. This includes the restructuring into fully cross-functional feature teams that work across components in the architecture and implementing the related changes to reporting lines, job descriptions and engineering practices. 

One of my favourite parts of the training was how Bas positioned feature teams as a way of forcing organisational agility through continuous learning. He suggested we welcome the problems that specialisation brings. Forming feature teams allows us to deliberately set up a conflict between specialisation and prioritisation. You could also see this as a conflict between efficiency and agility.

If a Scrum team's purpose is to always work on implementing the highest value customer features then there is often going to be a significant imbalance between skills and features. The current specialisations and systems knowledge available in a given team will often not be suitable to implement the selected highest value customer feature.

Bas suggested we exploit this imbalance by challenging teams to learn new systems, skills and domain knowledge and to use this imbalance to force this learning. On the other hand, when there is an available team that already has the skills to implement a feature we should take maximum advantage of the skills in that team by implementing that feature in the best team possible. 

This idea of treating team members as expert learners, not as expert specialists was repeated throughout the training and was a challenging idea with many ramifications.

"I used to be a BA, but now I'm a team member"

Many of us had fears about the willingness of staff to be proactive learners and their willingness to work outside their specialisation. One helpful topic was a review of McGregor's Theory X and Theory Y management beliefs, and a reminder that these beliefs can be diabolically self-reinforcing: if you believe staff need a clearly defined job role to be effective this will create narrow work behaviours in staff. Bas pointed out shifting management beliefs takes lots of time, and probably lots of beer.

There were a lot of other gems coming out of the LeSS training, and I'll save these for a future post: scaling the Product Owner role, the feature team adoption map, differences from SAFe and new perspectives on team level Scrum. 

If you are interested in scaling your agile adoption outside a single team feel free to get in touch, I'm happy to give an overview of LeSS or discuss how LeSS might be useful in your context.