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.