To recap, the Ball Flow Game is based on the Ball Point Game, with the following rules:

• Participants play as a whole team
• Balls must have air time between people
• No passing to a direct neighbour
• The start person must be the end person

The aim is to complete 20 balls (as opposed to complete as many in 2 minutes). Thanks to Rally colleague Eric Willeke I now add some fun context as well. I tell the team that they are producing magic balls. Magic is added to a ball only when everyone has touched it. If two people touch a ball at the same time, the magic is dispersed. Further, magnetic fields mean that passing a ball to a direct neighbour also stops magic being added. The start/end person is the customer wanting magic to be added to the balls. Its silly, but it adds an extra element of fun, and reinforces that the rules are constraints in the context that can’t be changed.

I use a spreadsheet to help automatically capture data about the performance of the team. (Download the template). It works using four macros, which are assigned to buttons and hot-keys:

• Begin (Ctl-B). Begins a round by starting a timer.
• In (Ctl-I). Captures the time a ball is added into the system.
• Out (Ctl-O). Captures the time a ball come out of the system.
• End (Ctl-E). Ends a round by calculating the metrics.

Once the metrics are calculated, three charts on the worksheet will populate themselves.

• Lead Time. The time each ball took to work its way through the team (assuming balls enter and exit in the same order). The dotted line is the average.
• Throughput. The number of balls the team completes every 10 seconds
• Cumulative Flow Diagram. The number of balls either not started, in progress or done every 10 seconds

Upper and Lower Control Limits can also be calculated and displayed for Lead Time. They are currently commented out in the macro code because I found that they weren’t necessary for the core learning objectives. You may also need to tweak some of the macro functions for different versions of Excel (I use Windows Excel 2010). The template has worksheets for 5 rounds. For additional sheets, simply one of the existing rounds.

One of the things I’ve noticed is how the dynamics of the conversations are different from when I run the traditional Ball Point Game with teams. In particular, the team I was working with today really understood the idea of scientific management and made very small, quick and focussed changes each round as experiments, hypothesising on how the metrics would change. With the Ball Point Game I find teams want to debate in depth all the options in their attempts to get an improvement.

Note that as I said in a post of Balanced Software Development, “scientific management is still relevant for knowledge work, when the workers are the scientists.”

Here are the results. (Apparently we started with only 19 balls due to a facilitator error!)

Round 1

In this round, the customer ‘pushed’ balls into the system when he could. You can see the lead time increase as the WIP increases in the CFD, up to a point when a natural system limit is reached. Towards the end the customer stops adding more balls to let the system flush itself out a bit, which shows as the step in the CFD at about 60 seconds, the drop in lead time, and the spike in throughput. The final two balls went through when the system was virtually empty. Notice the short lead times again!

Round 2

In this round the team decided to limit the WIP to 6 – one per person. However, interestingly (to me at least) they decided to batch them, by getting all 6 through before they started the next 6. Lead time is much more stable this time. The spike is because the customer forgot to receive the last ball of the 1st batch before starting the 2nd batch, so it got stuck! Throughput is wildly variable though because nothing comes out for a while, and then all 6 come at once. You can see the batching in the ‘steps’ in the CFD.

Round 3

In this round the team wanted to experiment with an low extreme WIP limit of 1. Lead time is significantly better, but throughput is low because there is too much slack in the system now. Notice the smooth flow in the CDF. The patches where WIP drops to zero are because the customer’s process between receiving a ball out, and adding a ball in, added a noticeable delay.

Round 4

In this round the team increased the limit to 3, but continued to process those 3 in batches. Lead time remains the same, but with improved throughput. The CFD still shows signs of the batching with the customer delay between batches, but is much steeper due to the improved throughput.

Round 5

Finally, the team decided to remove the batches and solve the customer’s delay issue by re-organising themselves. This time the customer added 3 balls into the system, and then only added another when one came out. Lead time is slightly increased, probably due to the fact that there were always 3 balls in process which added some complexity. Throughput is improved again though, and the CFD is looking very smooth.

As you can see, the team made significant improvements over the five rounds by making small changes informed by the data they had about their flow and capability.

People don’t buy WHAT you do, they buy WHY you do it. Simon Sinek says that this is the fundamental reasoning behind what he refers to as the Golden Circle, which he describes as a natural law occurring in many forms, in the same way as the Golden Ratio. He cites example of the Golden Circle including Martin Luther King, who said “I have a dream” not “I have a plan” and the Wright brothers, who succeeded first with manned flight despite having less money, education, connections and publicity as competitors. The Golden Circle suggests that we should start with WHY, before determining HOW, and finally WHAT, rather than starting with WHAT.

Starting an Agile transformation with WHY involves knowing why you want to use an Agile approach, and the goals you are aiming for, rather than becoming Agile just because it seems popular or a good idea. Therefore, begin by defining your WHY, deciding where you want to go and creating a vision of the future that you hope Agile will help create. Then Agile will be a means to an end, rather than an end in itself. Your WHY is your destination, and Agile can help with HOW you get there, and guide WHAT you do to get there.

WHY

A WHY is what motivates people to take action. It is a purpose, a cause or a belief. It is a reason to care and want to get out of bed in the morning. A WHY is not to make money. Money is a necessary precondition for business, in the same way that breathing is a necessary precondition to living although our purpose in life is not to breathe. Making money may also be a desirable result, but it is not a WHY.

WHY is the equivalent of the System Thinking premise of purpose. Complex Systems have a purpose which influences behaviour, the product of the system’s elements and interactions. Dave Snowden uses the Magic Roundabout in Swindon as an example of a complex system whose purpose is to enable a high throughput of cars with a low accident rate. Reports show that it achieves this purpose, despite also being generally regarded as one of the scariest roundabouts in existence. By starting with WHY, the roundabouts designers created an effective, safe and resilient WHAT. Starting with WHAT leads to the less scary but more common design.

WHY is always going to be context specific, but one simple generalisation would be that it is to satisfy customer demand. Demand analysis can help understanding of what work adds value, and helps us towards our WHY, and what work doesn’t add value. John Seddon describes failure demand is work that results from not doing something right, or not doing something at all. That is not to suggest that we should strive for perfection and be right first time with up front analysis and design. Value can still be added in small, incremental and iterative steps. Think of it like a ticket machine at your local deli. When a customer first takes a ticket then the request can be considered value demand. Subsequent tickets for the exactly same request can be considered failure demand. However, further tickets could be for similar, related requests because the customer comes back for more of the same, as opposed to exactly the same.

Simon Sinek argues that our brain is wired to start with WHY. Our first brain, the Limbic System is what deals with emotions, unconscious thought, instinct, and governs our behaviour. Our thinking brain, the Cerebral Cortex, is what deals with rationality, conscious thought, intellect, and governs our language. Thus, our natural behaviour is to make decisions emotionally, unconsciously, and instinctively. We then justify those decisions rationally, consciously and intellectually with facts. I have just bought a new car (well, new for me) and spent a not insignificant amount of money in a totally impulsive purchase. I had no intention of buying a car when I entered the garage, but fell in love with the car and ended up talking myself into deciding it was an opportunity I would regret if I missed it. Similarly, both times I have bought a house, which is both an important decision and major investment, the decision was because the house “felt right”. The size, condition, location, price etc. came second.

How

HOW describes the way that a WHY will be realised. It can be thought of as a set of guiding principles that help map a WHY to a WHAT. A HOW can also be a specific outcome that is to be accomplished without detailing the activity and output required to complete it. Additionally, HOWs are often ways of differentiating approaches and describing them in comparison to competitors.

One way of describing HOW an Agile approach enables a WHY is with the metaphor of a Recipe for Success. David Anderson popularised this idea with the following recipe:

• Focus on Quality
• Reduce WIP
• Balance Capacity against Demand
• Prioritise

Similarly, my colleague Ken Clyne at Rally talks about the fundamentals of Agile as:

• Focus on customer value
• Deliver early and often
• Reduce batch size
• Pull quality forward
• Inspect and adapt
• Create a collaborative culture

These recipes are a guide to HOW to achieve Agility in order to achieve a WHY. However, they are not specific enough to describe WHAT to do.

A common explanation for WHY organisations want to become Agile is “Better, Faster, Cheaper”. These are at best HOWs, and not WHYs. In fact, I would suggest that cheaper isn’t even a HOW. To paraphrase John Seddon, focussing on cost will usually result in cost going up.

Another approach to describing HOW to become Agile is through a transformation strategy or roadmap. Options for which path to take include beginning slowly with a single, fully Agile pilot project from which to learn, diving in and moving all project to an Agile approach in one go for clarity of message, only beginning new projects or initiatives as Agile to avoid risking current work, or incrementally solve specific challenges with certain practices for a more evolutionary transition.

Working Agreements can also be considered as a description of HOW. Explicit policies for how work is done can be created by recognising how value is created, how that creation is visualised and made transparent, how the work in process is limited, what cadences are used for synchronisation and co-ordination, and how continuous learning and improvement happens.

My personal take on HOW to be Agile is in terms of flow, value, capability. Achieving flow involves eliminating delays and focussing on reducing the lead time from concept to consumption. Delivering value involves making sure that the right things are being worked on and the right problems are being solved rather than “doing the wrong things righter”. Building capability involves developing people and their skills working as teams aligned to the organisation strategy.

What

WHAT is done proves that a WHY really is believed. It consists of tangible ways with which a WHY is realised and provides clear data points that actions are according to a WHY.

Agile practices are WHAT teams do in order to enable them to realise their WHY. Further, practices can be associated with HOW agility is demonstrated, in terms of flow, value and capability. The following is one interpretation of some practices. I’m sure there are many others.

Flow

User Stories are a technique to break down functionality into small pieces of demonstrable functionality which can create single piece flow. Time-boxing and kanban-style limits are both ways of managing WIP and enabling a focus on finishing rather than starting to keep work flowing. Visualisation approaches help teams see all the work so that they can focus their energy in the right places to keep flow. Strong teamwork and collaboration minimises the need for queues and batches which cause delays. Test Driven Development, with its emphasis on automated unit testing and refactoring, keeps designs clean and quality high so that new work can progress quickly. Continuous integration and deployment help works flow right through to the customer without lengthy release processes causing delays.

Value

Product Backlogs, User Stories, Minimal Marketable Features and other value-focussed forms of requirements are intended to help teams ensure they are delivering maximum benefit. Similarly, the On-Site Customer, or Product Owner roles are intended to maximise collaboration with people who are determining and receiving the value. Iteration demos and reviews are a means of gaining early and continuous feedback and validation that the product is delivering the intended value. Frequent and continuous delivery means that the value can be realised as soon as possible. Acceptance Test Driven Development and Behaviour Driven Development provide techniques for delivering value through quality and clarity of functionality.

Capability

Dedicated, cross-functional, value focussed teams mean that learning and knowledge is kept, shared and built upon to develop capability. Various collaborative practices, such as Pair Programming, Collective Code Ownership, Group Design, Team Estimation and Planning Poker similarly share knowledge around a team. Regular demos and reviews provide a cadence with which feedback and learning can build product capability, while regular retrospectives provide a cadence with which feedback and learning can build team capability. Visualisation of work, and the way value is created, gives visibility of bottlenecks and constraints and other issues such that they can be resolved to improve capability. Slack ensures that teams have spare capacity to both address these issues, and spend time on other forms of capability development which will improve future productivity and performance.

Conclusion

When embarking on a change initiative using Agile approaches, always “Start with WHY”. Use the WHY as a True North with which to guide the Agile transformation and steer decisions on which Agile practices to use for what reasons. Understand HOW agility is going to help progress towards the WHY, and WHAT Agile practices will provide the means to get there.

A clear WHY, that people are motivated by, will make it more likely that they will want to use Agile. However, Thomas Edison said that “vision without execution is hallucination”, so don’t stop with WHY, but make sure that the Agile HOW is also well known and the Agile practices that form the WHAT are clearly understood to ensure that the goal is successfully reached.

One of the value statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.

People and process are two sides of the same coin, both equally important in understanding how to improve capability to deliver valuable software.

People

This side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wrote in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.

This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend creating cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed silos, will result in an improvement.

Process

This side of the coin is about taking a vision, which is developed into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality”. Taking this approach means that a product will maximise its value through being iteratively refined piece by piece in order to incrementally deliver functionality.

This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pieces. Thus, the process side suggests that continuously delivering small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.

People and Process

It is when we put these two sides together that we can achieve significant improvement. The iterative loops of learning about both the team and the product link into each other enable product value to rapidly flow through capability teams. This is the development nirvana we are trying to reach.

This model also gives some insight into why the “Waterfall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple work-flow described was inherently wrong, but because the work-flow has typically been implemented with specialist silos rather than capability teams, and with large rather than small batches. It is both these two sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development flow.

Here’s a couple of links (Kane Mar) (Declan Whelan) if you’re not familiar with the game. In a nutshell it involves a group working as a team to pass balls between themselves, constrained by some rules. The idea is to pass as many balls in a 2 minute time box. The team has to self organise and inspect and adapt in order to improve its velocity (throughput of balls).

For my variation I wanted to remove the time-box to emphasise flow more, and demonstrate a different way of understanding the capability of a system. In the game, the team are designing a system to meet the purpose of flowing balls quickly between themselves.

The changes I made were to ask the team to pass 20 balls as quickly as possible. I put a unique number (1 – 20) on each ball in case it was useful and also asked the team to time how long it took for each ball to pass through the system.  I took the data that was captured and entered it into a spreadsheet to create a control chart. We ran two rounds of the game twice, with the respective charts below.

Round 1

In Round 1, the team didn’t capture all the data, and some problems were had towards the end, but that the average time for each ball was 13 seconds. The system could also be said to be ‘in control’ as all the data points were with the control limits  which were calculated as AVERAGE +/- (3 * STDEV). The last measured ball was completed at 3 minutes and 35 seconds.

Round 2

In round 2, the team improved their data capture process and overall flow. The average time per ball dropped to 12 seconds and the variability also reduced. The Upper Control Limit dropped from 01:10 to 00:18. The last measured ball was completed at 2 minutes and 22 seconds.

What this demonstrates is that even with variability (which we don’t want to eliminate completely in software product development), by understanding the capability of the system over time, we are able to reliably communicate what might and might not be possible. For example, using the round 2 data, there is a 50% chance we’ll complete a ball in 12 seconds and a 99% chance we’ll complete a ball in 18 seconds.

We could also calculate and chart the throughput of balls completed over a cadence of 30 seconds to similarly understand the capability from that perspective also. For Round 2 those throughputs would have been 3, 4, 4, 5, 4.

There are a few areas I’d change next time I try this.

1. The measurement took a long time and was clearly the significant bottleneck. I made measurement part of the system to add some additional complexity, but in hindsight it was probably too much. Most of the improvements were in measuring the system rather than the performance of the system.
2. I allowed more time than I probably should have for improvement discussions. With the time-boxed version its easier to start the clock for a round and that usually that kicks the team into action. Similarly, when the measurement fell apart we stopped and restarted a couple of times. I wouldn’t do that next time, although by removing measurement from the system, it might be less of a problem.
3. It took time to enter the data into the spreadsheet. I need to find a better way! The spreadsheet can be found here. It’s very simplistic. Please let me know if you use it and improve it!

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

• Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
• Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
• Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

• Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
• Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
• Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
• Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
• Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

Overview

The basic aim of the simulation is to solve maths problems. This idea was inspired by Simon Bennett and Mark Summers session The Incentive Trap which also uses maths as the problem domain. The solving of equations introduces variability into the exercise using some simple knowledge work which is hopefully more interesting and engaging than rolling dice.

The maths problems flow through the following value stream:

• Options
• Analysis
• Solve
• Check
• Accepts
• Done

The following roles are involved in the value stream:

• Analyst
• Solver
• Checker
• Accepter
• Manager

The following scenarios are used to experiment with the flow:

• Phase Driven
• Time Boxed
• Flow Based

Stages

Options

Each scenario starts with a portfolio of possible problems to solve, in the following format:

In this example  we have an option to create an equation with 3 operands and a solution of 25.

Analysis

When an option is selected, it is transformed into an equation during analysis. Rather than expecting participants to come up with their own equations, which could result in trivial equations, a lookup is provided.  The equations in the lookup are in a different order to those in the portfolio so some effort is required!

Solve

The equations are then solved independently i.e. the solution is not available

Check

In order to check that the Solve stage produces a correct result, the equation is solved independently again.

Accept

Finally the two independent solutions are compared, along with the actual equation, to ensure it has been solved correctly

Done

When the correct equation has been independently solved correctly twice, then the problem can be considered Done.

Roles

Analyst

The analyst selects the options from the portfolio, matches them against the available equations, and writes them onto index cards. Each index card should contain the option ID and the equation as follows:

Solver

The solver takes each index card with an equation on it, and solves it. Any intermediate calculations should be written on a separate sheet, and calculators should not be used (although someone who did use a calculator at SPA didn’t seem to gain any advantage!) The answer is to be written on the back of the back of the index card, to the left side, and covered with a small post-it so that is hidden and can’t be copied.

Checker

The checker also takes each index card with an equation on it, and solves it. Again, any intermediate calculations should be written on a separate sheet, and calculators should not be used. this time, the answer is to be written on the back of the back of the index card, to the right side, and again covered with a small post-it so that is hidden.

Accepter

The accepter takes the index card and confirms whether the ID and equation match correctly, and that the two answers are both the same and correct. The they are, the the problem is Done, otherwise they reject it. Each scenario will handle rejection differently.

Manager

The managers job is to keep time, ensure the process is being followed and capture metrics. Every 30 seconds they should count how many of the maths problems are in each stage of the value stream and record it on a worksheet. It is these numbers which can be fed into a spreadsheet to generate a Cumulative Flow Diagram to visualise the flow.

Scenarios

Each scenario is 5 minutes each.

Phase Driven

For a phase driven approach, the team should initially plan how many of the set of options they think that they can complete in the 5 minutes available. Then all the selected options are worked on phase by phase. Thus they are all analysed, then all handed over to be solved, then all handed over to be checked, and finally all handed over to be accepted. Any rejected work can only be moved back to the beginning once everything else has been accepted as Done.

Time Boxed

For the time boxed approach, the team should plan how many of the set of options they think that they can complete in the 1st of the 5 minutes. Those options are then worked on by the team individually. Specialism still applies, but once a problem has been analysed, it can move to be solved, check and analysed without waiting for the whole batch. At the end of the 1 minute time-box, the team should stop, review and re-plan the next minute, deciding how many problems to work on next. This is repeated until the 5 minutes are up i.e. there are 5 x 1 minutes time boxes. Any rejected work can be passed back immediately.

Flow Based

For the flow based approach, the team should pick 1 problem at a time to solve. As with the time boxed scenario, specialism still applies, so once a problem has been analysed, it can move to be solved, check and analysed. However, there should only be one problem in each stage of the value stream at a time, thus creating a pull system. Any rejected work can be passed back immediately (which may result in the WIP limits being broken), or the accepter can pull in the appropriate role to resolve the issue.

Results

The metrics from the managers worksheets can be fed into an excel spreadsheet (included in the download package) to generate CFD diagrams. Here are 3 from one of the teams at SPA.

Phase Driven

Time Boxed

Flow Based

Variations

There are a number of variations I’d like to try.

• One of the things I’ve noticed is that the maths problems may be just a little bit too difficult for some teams, and the take too long sometimes to get any really useful results. One option would be to extend the time for each scenario to 10 minutes to allow more time. I wonder whether this could make it less snappy though.
• The time-boxed scenario never really plays out how I envisaged it. This is partly down to the short time frames. Stopping, reviewing and replanning every minute doesn’t seem right – especially when you can only manage 1 problem in a minute! What i was trying to show was the small-batching nature a time-box can have. One way round this is to explicitly create the batches in a similar way to the Penny Game.
• Some people don’t like the mental exercise involved in the maths! Katherine Kirk described a variation to me where the teams used a “Pictionary” workflow instead. Options –> Describing –> Drawing –> Guessing –> Checking –> Done
• Its quite likely that the Flow scenario comes out “best” because its the last one. It would be interesting to run the scenarios in different orders to see what impact that had. Especially if there are 3 or more teams so that each team can start with a different scenario. This would possibly be more complicated to run, but with enough facilitation could be done.

Feel free to download the pack, which contains:

• Handouts – PDFs of the options, analysis and accepter worksheets for each scenario
• Spreadsheets – one with all the details used to create the worksheets, and one to be used to create the CFDs
• Powerpoint – slides with simple instructions for running the experiment

All I ask is that you let me know how you got on, and what variations you come up with. Here are the SPA results and LWS results.

4 Week Time-box Schedule

Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.

2 Week Time-box Schedule

Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.

One Piece Flow

If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.

Cumulative Flow Diagrams

One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.

1. Map the Value Stream
2. Visualise the Value Stream
3. Limit the Work in Progress
4. Establish a Cadence

During subsequent discussions on the aspect of Continuous Improvement in a Kanban System, I decided that there was a missing fifth primary practice:

1. Reduce the Kanban Tokens

I originally named this practice “Eliminate Kanban”, but was persuaded that this was probably overly sensational, and as a result potentially confusing or misleading. Its intent is that once a Kanban System is in place, the team should be constantly looking to improve it by creating an environment where the work flows naturally. There is a quote that I believe comes from Rother and Shook which says “flow where you can, pull where you must”. By striving to reduce the number of kanban tokens in the system, a team will move towards an environment where they are more self organising and the work can flow. This can be achieved by either lowering the WIP limits or by collapsing the number of distinct stages.

A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.

A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.

A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.

By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.

A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.

Mihalyi Czikszentmihalyi describes the state of Flow as having a balance between ability, and the skills required for a piece of work. If some work requires more skill than a person has ability, then they are in a state of Anxiety. If a person has more ability than the skills required for a some work then they are in a state of Boredom. Applying this to Process Improvement, we want to move teams up the Flow Zone so that skills required and ability increase equally.

Increasing Skills and Ability equally at the same time is unlikely, so in practice there are two routes to move up the Flow Zone. The first is what I am dubbing “Anxiety Driven Process Improvement”. Move a team into a state of Anxiety such that they need to improve their skills to cope. I assert that this is the approach that makes time-box based method so effective. Time-boxing forces teams into a place where they need to improve their skills in order to deliver working software every few weeks. Many teams push back, and a common approach to this is to make the time-box shorter to emphasis the point! The other route is to do “Boredom Driven Process Improvement”.  Highlight to the teams where they need to improve their ability, and allow and support them in doing so such that they are able to taken on work requiring more skill. I further assert that this is the approach that kanban systems take. Visualising queues and work in progress in order expose the bottleneck where the ability needs improving.

This might sound like I am suggesting the time-boxing and kanban are mutually exclusive approaches. That isn’t the case – I have already said that! Instead, I just find it an interesting angle to look at a different dynamic between two approaches.