The thought that you wouldn’t use Agile in a project where requirements were defined upfront was also an oddity to me – why wouldn’t you mitigate risk and get feedback as you deliver despite thinking that you got your requirements 100% right? At one stage of my life I was a Business Analyst. I wrote the best business and system requirements. My documents, in my mind at the time, were epic odes to the perfection of thinking. I learnt very quickly that defined requirements never changing was a farce. I was human and my mind had unintended errors and gaps. 

Some would dispute that Kanban is more a Lean method than an Agile one, however I have considered it one element of a wider suite a methods, practices and techniques. This suite used to be known as an “Agile umbrella” but it is now referred to as “New Ways of Working”. It combines Lean thinking, Lean Startup thinking, Design thinking, Agile thinking, Software craftsmanship thinking and much more. 

With such a broad toolkit now at the disposal of organisations we should be solving problems everywhere. But we aren’t. We aren’t consistent, nor predictable in the outcomes of our transformations. Our perfect designs and methods are failing on implementation or their stickiness is not strong enough to handle a significant c-suite change. Maybe we are suffering from the same problem that we had when we thought we could do requirements upfront – that we think we know all the answers when really we are doing it totally wrong.

I had for a while thought that the potential solution lay in experimentation – testing and learning the processes that work for a culture. Part of me is still attached to this thought, especially as I have seen it work more often than not. After all, complexity theory says that in a complex system that ‘probe-sense-respond’ is the best approach. But what if complexity theory is wrong too?

I love Agile. I love what it does to individuals and teams and the difference it can make to them. It is just a lot harder at scale to get it working. There are schools of thought that the best approach is to descale your organisation. I’m not against this as a tactic, but to me it is an overly simplistic answer to a complex problem.

Yes there is tonnes of literature about setting yourself up for success on what you need to do when kicking off an Agile transformation, I probably have a blog or three on this already, but lately I have been thinking that in some organisations we shouldn’t be trying to do Agile transformations. I know, this is very heretical.

I’m not proposing that we give up. I now have a different hypothesis – fix the more critical issues in the organisation before trying to kick off an Agile transformation. What critical issues you may ask? If you have any of the following issues I believe you should try to fix the root cause of these before trying any form of transformation (Agile, New Ways of Working, or something else).

The ‘restructure every three months’ organisation

If your organisation restructures at least every six months (and I know of a number in Australia that restructure its people at least three times a year) then I don’t feel like an Agile Transformation is going to be successful in this environment. 

Agile requires stable teams to create productivity. Every time you restructure you:

1. Create uncertainty. This uncertainty dramatically reduces individual productivity.
2. Force teams to go through Tuckman’s model, again decreasing productivity.
3. Force work to be re-distributed to teams, creating a hold on flow.
4. Confuse stakeholders who work with teams on where work is at and who to engage/work with, also dramatically impacting flow.

The science of impact on productivity for points 1 and 2 are well understood, but I believe there has been little done to demonstrate the significance to productivity of points 3 and 4. 

I would argue that you should test and learn to what extent your restructures are successful in removing problems. If your organisation restructures more than three times in a year I don’t think there is enough stability to be able to test and learn from. 

Also, all too commonly organisations restructure to solve one problem and inadvertently create new problems, hence creating the cycle of pain where another restructure is required. Any structural pattern will have trade-offs – most organisations don’t spend the time to understand the options, trade-offs and mitigating steps for each trade-off. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop restructuring more than once a year (twice ideally)
2. Learn your choices and trade-offs and implement appropriate mitigations
3. Test and learn using real data – how do you know your organisational productivity and how does your structure affect it?
4. Change manage the restructure better to mitigate productivity risks (most organisations say they do this, in my experience I have yet to see one of them do it well)
5. Performance manage out your people that aren’t performing. This means having a HR group that can actually deal with difficult conversations and managers who have skills to deal with system thinking around performance (assuming Deming’s Law that 85% of issues are the system and not the person). Why did I add this one? Most organisations use re-structures as a means to remove poor performers (mostly due to labor laws) rather than doing the hard yards to remove them through the formal HR process. If organisations did proper systems and performance management a lot less restructures would be required. You could also argue that better recruitment processes would reduce poor performance issues downstream. 

The ‘implement change without change management’ organisation

If you are in an organisation that rolls out change poorly then trying to roll out an Agile Transformation is going to be impossible without good change support. Poor change management includes:

1. Change plans that are never implemented
2. Change plans that don’t target the right groups
3. Non existent change plans
4. Insufficient change plans (for example an email or two is done but nothing to embed a real capability change)
5. Lack of focus on behavioural value differences. Immunity to change talks about behaviours that are hard to shift because of unconscious needs. This requires a individual or a persona based approach to change management rather than a whole collective approach.
6. Rolling out a change that has been ill-considered or not piloted

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Look at the capabilities and process by which you do change management and get real data from people (not managers) within your organisation as to how successful previous change initiatives have been
2. When you find that they haven’t been as successful as you have previously thought, find out why. Do some root cause analysis and fix these problems
3. Check to ensure that your change management processes can handle an incremental approach to delivery

The ‘waiting for the next CEO’ organisation

I haven’t seen this pattern often, but it tends to be in extremely bureaucratic organisations or in government organisations that have a fixed date of leadership tenure. In this type of organisation the CEO has had challenges in their leadership style. This includes:

1. They do not create a safe space; failures are not tolerated
2. They make outlandish promises to shareholders on what can be delivered and when, without ever checking with the people who will do the work if it is achievable. They often do this under the guise of creating a “strong vision” or “stretch targets”
3. They don’t connect with their organisation beyond their direct reports

The impact of this is an organisation full of apathy and disconnectedness. People within the organisation don’t want to invest their time in the vision or any changes driven top down. Consequently they do the minimum they must do to fly under the radar resulting in the organisation staying in a holding pattern whilst they wait for the CEO to be exited.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Have strong conversations at the C-Suite layer or even the Board about how the CEO is performing and how their behaviours impact the productivity of the whole organisation, how it sets an example for the leaders underneath them.
2. Think about having an ‘Undercover boss’ mechanism to get real feedback on problems and insights of people deep in the organisation.

The ‘new shiny’ organisation

Are you in an organisation that has trouble focusing? ‘New shiny’ organisations tend to act like a cat chasing after a laser light – everything else gets zoned out. The biggest issues with this type of organisation tends to be:

1. That once something is kicked off there is little focus on delivery or execution of the work
2. Which results in lower benefits realisation, lower value to customers and a delivery system filled with waste
3. And whilst the ‘shiny’ might be Agile, something new will come along and you will end up having an implementation that no longer has any focus or intent to follow through on
4. Then there are the real problems of the organisation that are never really prioritised as the new shiny keeps everyone’s attention.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop starting and start finishing. Learn how to create focus through to value realisation before kicking off something new. 
2. Have a mechanism for being able to understand what the core problems/impediments are in delivery, ranked by waste and track very frequently the steps being made to resolve them. In essence, focus on delivery optimisation.

The ‘we don’t have time to be smarter’ organisation

Are you in an organisation that is so busy that there is no time to work smarter? People are always in meetings. They have meetings on top of meetings. They have lots of people doing the same thing. Each area solves their own problems, but the same problems exist all throughout the organisation. 

Fundamentally this is an organisation that has no slack (teams loaded 100%) and a fixed mindset. To be fair, there will naturally be individuals who in the organisation still have a growth mindset, but the organisation isn’t culturally setup to encourage continuous improvement and to encourage learning.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop behaviours like cutting project costs or time frames. I see this all too often – executives think a project costs too much, slashes the budget or time and forces the team(s) to deliver under this pressure and think they have saved the company millions. Every time I see the project ends up costing the original figure and time, but because teams were forced to think they had less time they cut corners, reduced quality and introduced technical debt. It is a false economy. Work ends up being costing more over time due to the operational maintainability of the solution.
2. Introduce slack time into the system – load teams up to only 80%. Slack allows the system of work to handle unplanned exceptions and gives people space to think critically about the what, why and how of their actions before starting them. It also gives people space to look more broadly to other people and other organisations for solutions to problems.

The ‘we’ve tried it six times before’ organisation

Some organisations have already tried Agile many times over and failed. They have this really strong belief that ‘this time it will be different’ which may be true, but all too often, little is done to retrospect on why previous attempts have failed.

If you are in one of these organisations, before implementing your next Agile transformation you should:

1. Do a root cause analysis on where implementations have gone wrong (it could have been one of the previous types of organisational patterns that has caused this)
2. Share with the C-Suite and the board these findings
3. Get buy-in with this group on how this implementation is going to be different and how it is going to address those root cause issues
4. Test and learn whether it does address the issues before rolling anything out.

The ‘we have five consultancies in here’ organisation

I am not saying that consultants are the problem – just that lots of different consultant groups who are unaligned is a really big problem. Consultancies, much like coaches, can help to give you perspective that you don’t ordinarily have, they can provide expertise and global knowledge and help drive a greater focus towards value. But if their perspectives differ then you are going to be creating deep factions of power in the organisation that are working against each other. Often they also don’t have visibility of what each other is doing. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Think about consolidating/reducing the number of consultant groups
2. Create visibility about what what each group is focusing on, or ensure that the work is fully mutually exclusive
3. Determine if there is a lack of alignment between groups and hold workshops between invested parties (ie the people who are working with the consultancies) to reach alignment.

The ‘we have managers (not leaders) everywhere’ organisation

You may have picked up through some of the suggestions above that a few key techniques are being consistently utilised. Agile requires a different type of manager, a leader who can help to change the culture of an organisation, who can think critically of ‘the way that we do it now’ versus the possibility of the future of the organisation. A key enabler to Agile that you should consider prior to kicking off an Agile Transformation is a Leadership Transformation. A Leadership Transformation should: 

• Focus on lean wastes and flow analysis, systems thinking, and root cause analysis capabilities across the organisation
• Focus on the difference between management styles (Taylorism, Theory X vs Y, Management 3.0) and what works in the organisation now versus what is needed for the organisation going forward (which does depend on a really clear vision for the organisation)
• Educate managers on options on how to structure it’s people and what the impact that structure has on communication and flow
• Educate managers on options of governance and finance and what the impact that these options have on flow, engagement, and values
• Provide managers incentives to focus on new behaviours (though be careful as extrinsic motivation can backfire)

This leadership transformation creates the internal pull for an Agile transformation, but importantly puts leadership on the journey sooner so that they can be more effective in supporting an Agile transformation through the right behaviours. 

A final note

Agile Transformations are tremendously hard. Don’t make it harder by setting them up for failure before they have even started. 

Arya Stark – Stick bad ideas with the pointy end

This is a PO take on Arya’s statement “Stick em’ with the pointy end” referring to her high prowess and knowledge on how to wield her sword ‘needle’.

The Product Owner rule here is to stop starting work if it doesn’t hit the mark from a analytics and validated learnings perspective. We’ve all seen the HIPPO (HIghest Paid Person’s Opinion) effect in action – work that we know shouldn’t go ahead that seems to be fast-tracked. The best Product Owners are ones that are unafraid to terminate work when it is a bad idea, knowing the risks that it may have to their job but holding steadfast regardless.

Ygritte – You  know nothing without validating your hypotheses

Whilst Jon Snow arguably knew nothing according to Ygritte, so too do teams and Product Owners if they blindly go building capabilities without validating problem-market and problem-solution fit assumptions.

Lean Startup gave us a huge shift in the mindset of software development when it began to re-wire our thinking to stop considering everything a requirement and to start to test and learn on our riskiest assumptions.

Great Product Owners not only test and learn on their riskiest assumptions around problem-market and problem-solution fit, but they are critically aware of the different types of cognitive bias and actively struggle against their better-self in order to ensure that the best possible solution goes to market.

Jon Snow – Benefits are coming

It might as well be winter with how much money is spent building work that doesn’t result in the expected benefits. Although most people have heard the of the 2002 Standish Chaos report that cites 64% of features are rarely or never used, this has yet to be considered statistically valid. Again the biggest challenge to how products deliver benefits has come from the Lean Startup community by focusing on a lifecycle that deeply embeds into its core a process of Build-Measure-Learn with critical decision points at the “Learn” stage to pivot (changing problem goals), persevere (continuing on same path, changing solution options) or perish (stop the work altogether).

There is still too much “throw it over the wall and it’s done” mentality in the industry. Leading organisations are deeply embedding this learning cycle into their development approaches and moving away from heavy batch to more flow based lifecycles. Whilst the Scaled Agile Framework (SAFe) is continuing to grow momentum, it is lost on many that implement it, that applied poorly, it creates massive three month batching.

Think about what this means from a test and learn perspective – you release something to market and begin to gather analytics and data. At the same time you start your next Program Increment meeting and create a firm commitment for the next three months of work. Let’s say that after three weeks you get enough data to validate what you just released and with great concern it just isn’t resulting in the outcome expected. You have an assumption about what you need to pivot, but it will require two weeks of work. What do you do?

You can wait to the next Program Increment, which is another two and a half months away, and then deliver a change in another three months (just over a five month pivot – yikes!). You could pull something out of the Program Increment, thus breaking the expectation that was set, further delaying the scoped benefits. If you were smart you would have built in some slack into the Program Increment to allow for pivots on released work.

In the field, I have rarely seen either of these decisions occur. Leaders don’t generally allow any slack in a Program Increment and instead tend to drive for the whole increment to be filled up, and then sadly what happens next is they push to have the teams deliver both, breaking their sustainability with a promise of “we won’t let this happen again”, which it inevitably always does.

Whilst you could argue that these leaders haven’t been coached effectively and are misunderstanding the core Agile manifesto value around adaptation for Agile (responding to change over following a plan), it doesn’t deminish the fact that SAFe as it tends to be implemented results in massive batching which in turn reduces the time to benefits and pivoting for benefits optimisation.

Great Product Owners know this and will be empowered to push back against the organisation’s leaders to ensure benefits optimisation. To do this, again the Product Owner will likely need great courage to fend their decision against leaders within the organisation.

Littlefinger – Backlogs aren’t a pit, backlogs are a ladder

For a while I considered using the Petyr Baelish quote “Fight every battle everywhere, always, in your mind. Everyone is your enemy, everyone is your friend. Every possible series of events is happening all at once” twisting it into a quote about stakeholders, customers and predictability of needs, but in the end I used the more known quote, “Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. And some, are given a chance to climb. They refuse, they cling to the realm, or the gods, or love. Illusions. Only the ladder is real. The climb is all there is.”

Backlogs are real. The climbing through them to deliver is (almost) all there is. Importantly a backlog shouldn’t be a pit. Product Owners tend to acknowledge all requests from stakeholders and politely put them into the backlog. These get prioritised down at the bottom of the backlog and languish for all of eternity. Great Product Owners will look at not just the important and prioritised work in the backlog as part of backlog refinement, but will also actively remove aged items within it, work that will never get done because it is deemed as too low in priority or value.

Product Owners will also appreciate where they are in the Explore-Expand-Extract stage of their product development and their backlog’s content will be reflective of the stage.

Tyrion – A Lannister always prioritises by value

Need I say more? The answer should be yes. A good Product Owner will prioritise by value, a great product owner will prioritise by value with an understanding of cost, alignment to strategy, market and competitive trends. Value can take many forms – customer value, business value, risk reduction or meeting industry obligations. Balancing value with cost of delay and job size will mean Product Owners can realise benefits sooner. A weighted shortest job first algorithm with relative estimation can be utilised to compare work in the backlog in order to ensure that the highest valuable work is prioritised higher.

Daenerys – I’m not just going to tell the story, I’m going to live the story

Daenerys Targaryen may be the breaker of chains with a goal to break the wheel, but as a Product Owner she epitomises the role of a story teller. Product Owners are passionate about the problem they are trying to solve. They want to get to the heart of it and do this best by engaging directly with customers and deeply knowing the data, insights and pain points about both customers and the business. Ideally the team would be attending the customer testing, but if they don’t then the Product Owner really has to be the voice for the customer, to put help the team to put themselves into the customer’s shoes and deeply understand their needs.

This is where Lean UX and Design Thinking intersect with Agile in order to build the right thing.

More Product Owners in Game of Thrones?

Do you have a good quote conversion from a Game of Thrones character to a Product Owner? If so post in the comments below.

• We build in powerpoint or prezi these gorgeous training decks and train up people new to Agile
• We outsource our training to groups who do the same as the above
• We build intranets, wikis or documents worth of content on “how to do <insert Agile activity here>”
• We teach the “Shu” rulebook without constantly re-enforcing the need to progress to “Ha”
• We have embed games to re-enforce and experience learnings from training sessions
• We mentor through SODOTO (See One, Do One, Teach One), but often never get to the TO bit

We talk a lot about innovation and radicalizing the business and yet some of the training techniques we still use are from 1990s. How many Scrum Masters open up this content and use it? How many Scrum Masters experiment and adapt how they work? How transparent, engaging and interactive is this content? Playing games and implementing SODOTO is a great start to interactivity and real-time knowledge sharing, but can we do more?

Recently I have had an awesome opportunity at Charter Hall innovate, experiment and enhance the experience of learning differently. Rather than build decks I have spent many hours building an interactive wall to people new to Agile. It is more an experience than a training session. It is one massive wall that flows a conversation about Agile quite naturally before the tour moves further into the working space.

The “basics” tour has the following elements:

1. The background of Agile
2. The Agile Values
3. The Agile Principles
4. The Agile Process
5. The Agile Roles
6. The Portfolio Wall
7. The Pipeline Activities Wall
8. One of the Project Walls

The principles behind the learning wall are quite simple:

• Create a natural flowing experience
• Introduce concepts with visual drawings to enable better retention
• Make the process introduction really simple, bare bones, but…
• Have the ability to drill through into detail without it overloading the audience. This would help when having more detailed role training.
• Make everything transparent, no content is hidden in a tool
• Break up content so that as things change it is a simple matter of changing one small picture

Now before I show you the pictures of what I have created I do want to highlight some intended future changes:

• Extend the values section to include the Scrum values and the company values
• Make pictures for the Agile Principles
• Add in Lean Principles
• Add in an “other section at the tail end”
• Maybe add in a visual around all the different Agile methods, edgy and support methods
• In addition to the wall I am also building a series of agenda cards – these are re-usable packs for Scrum Masters and coaches to use for workshops and key Agile activities (eg Iteration Planning, Retrospective, etc). These cards have some spares so that facilitators can adapt away from the standard set of agenda ideas. On the back of the cards are tips of the purpose of agenda activity and how it could be facilitated.
  What does this mean for a new facilitator? Well they have the clear activities they need to do with how to do it without having to open up a tool (which they don’t ever do), but most importantly this is real time – exactly when they need it. It also provides great clarity to everyone else in the room around what is happening and what still needs to happen when it is utilised as a backlog against a simple wall of “To Do”, “Doing” and “Done”.

Anyway, now for the pictures of the Learning Wall (it runs right to left due to the entrance point, but normally I would have preferred a left to right run). Taken from the right:

Taken from the left:

The Agile Values (some references taken from Rally’s awesome values picture):

The Agile Principles:

The Agile Process (note this is naturally a very specific organisational tailoring, I am by no means saying this is the one and only process for Agile). Specifically, this is the bare bones view. The number of iterations is just for an example.

And now the interactive version (note how the interaction points line up with the number of iterations).

With a detailed closeup on the iteration portion:

A high level overview of the Agile Roles. The three key Scrum Roles are here – Scrum Master, Product Owner and the Team. In addition I have added in our organisational specific governance roles which includes a high level organisational wide steering group, a Business Scrum and the PMO. Again I would like to highlight that some changes have been made to normal roles to suit the specific culture and needs of the organisation.

Detail on the Scrum Master role (interactive side showing):

Detailed view on the Product Owner role (bare bones side):

Detailed view on the Product Owner role (interactive side):

Detailed view on the Team role (bare bones side):

The Business Scrum role:

The Steering Group role:

The PMO role:

And that is the Agile Learning Wall! Please feel free to comment on any thoughts and suggestions to enhance the route of complete transparency and no tools that I am on.

I would like to thank both Nicki Doble and James Doust from Charter Hall who gave their support for my experimentation and for their willingness to expose to the world what we are doing.

I met recently with one of the worlds leading climatologists and asked deep questions regarding our future as a race. There is clear evidence that within one hundred years it will be on average ten degrees hotter across the globe. If you thought that I was wrong writing ten and not five then make no mistake – they are telling the media five degrees so that it doesn’t cause massive panic and so that they don’t appear to be fear mongering, but the real expected figure given current global politics and policy is ten degrees.

With ten degrees there would be widespread drought. Half of the planet would be inhabitable. Ground level railway systems would fail. Heat stroke related deaths would be significant. Imagine how we would live, how much we would have to seek travel out of the sun, how much extra energy we will be burning to make ourselves cooler. I have children and I want them to be able to have a future where they can enjoy being outside.

I want a world where the politicians listen up and start to address this problem. I want a world where the people within it get to have a voice beyond an election every few years. I want a less apathetic world.

Where I have seen Agile transformations highly successful is ironically when they have been driven from the top – a desire at the upper levels of organisations to create a new culture.

So I want a massive disruptive change, something to address this problem. But how?

I have some ideas, but I am keen to hear yours – do you think a disruptive change is needed? If so, what do you think can be done from it, different to what we are doing now?

Firstly, this is an odd sort of post for what I normally write. It is more a brain dump of a concept or idea I have and not necessarily a well formed one.

The audience was for Dave Snowden or anyone else who considers themselves a Cynefin or complexity thinking specialist.

I openly profess I am not. I am trying to learn and so some of the concepts I have within may be wrong. Please forgive me if I haven’t gotten a concept right. I am here to learn, be challenged/corrected and think differently.

These ideas and thoughts were generated from trying to extend the boundaries of a new movement called “Visual Management”.

Coffee and Cynefin

Coffee at home

When we make a coffee at home it is a very easy affair. We choose the coffee type from the store (probably your hardest decision), add it to a cup, add sugar if you desire, add boiling water, stir, add milk if desired and Bob is your Uncle.

In terms of complexity of the task it is Simple. The outcome is predictable. The process requires no domain specialisation. In likelihood the home “barista” is also the customer. The quality is…. less than desirable. I know that quality is in the eye of the beholder, but having been privy to some of the worlds top coffee makers and blends and I can say, in my experience, that a Nespresso machine coffee pales to a good barista produced cafe coffee.

Cafe coffee

When we go to a cafe for a coffee the domain expert, the barista, should be able to do a better job of producing a coffee from the commercial quality machines than the average person.

In terms of the complexity of the task it is Complicated. The outcome is still predictable. The process now requires domain specialisation. The barista is no longer the customer. The quality is dependent on the experience of the barista, the process they use, the quality and freshness of the coffee  itself, the roasting process applied, the milk and lastly the quality of the tools (machine, grinder, milk jug).

World Barista Championships

Last year my husband was Australia’s 5th top Barista (I am very proud of him). His passion and energy for a good cup of coffee has enabled me to learn a lot about the coffee industry. In order to be a rated barista in both Australia and the world there are competitions that are run each year. These competitions are very arduous and time consuming. This year’s barista champion for Australia spent three months, full time, training for the competition event. In essence, he was sponsored, ie paid for three months, to do nothing but ensure that he was ready for a fifteen minute performance. Judges go through a similarly arduous process. Technical, taste and presentation standards exist and are assessed against.

Baristas at this level are highly passionate, highly educated and use the best tools and equipment that money can buy. To be on top of their game they conduct a lot of experiments. For their twelve coffees in fifteen minutes they would make hundreds of bases, cappuccinos, and try dozens of experiments for their signature drink. Dozens of blends would be tested and a variety of roasting conditions tested. Baristas have to work closely with roasters because, in essence, their coffee is also showcasing the roaster’s ability too. The roaster’s domain experience can greatly affect the barista’s outcome.

All in all, a barista, when they start their journey, would certainly not be able to predict the type of the coffee, the roasting elements, the milk to be used and their signature drink. In terms of complexity of the task it is Complex. The outcome is not predictable. The process requires several domain specialists. Experts are now the customer. The quality is high and graded within clear and defined guidelines.

How does this relate to Visual Management?

When we make a coffee at home there is no value in visually managing this work. Simple work will happen with such predictability and ease that the effort to do visual management would be considered an overhead or waste.

When a coffee is made at a cafe there is some value in visually managing this work – value for both the customer and producer. Complicated work has the simplest of visual management techniques applied – the flow is usually limited to “To do”, “Doing” and “Done”. The variability of items inside of the flow is constrained to a subset of possible conditions,that is, a barista is not going to make you a smoothie or sandwich.

When a coffee is produced for the world barista championships the process to deliver that coffee would benefit from a more complicated visual management system. Complex work has complicated visual management techniques applied – the flow may additionally have a “Wait” column. The variability of items inside the flow are no longer constrained to a subset of possible conditions. Work may now become easily blocked. Work may now have dependencies and relationships to other work items. Work may now need specialization outside of the barista’s capabilities – ie other domain experts are likely required. All of these things can be visually managed. You don’t have to have a visual management zone for doing the world barista championships, but speaking from experience it certainly does help.

Conclusion

For coffee making (and maybe more?):

• There is a relationship between the complexity category and quality
• There is a relationship between the complexity category and process specialised relationships required to produce the work value or outcomes
• There is a relationship between the complexity category and variability of work items within the flow
• There is a relationship between the complexity category and the predictability of the end outcome (known)
• The visual management techniques applied sit one category of complexity below the actual work within the system