Limiting WIP (work in progress) is another of those wonderfully simple Agile principles that many of us still struggle to implement and possibly understand the significance.

It’s fundamental to Lean/Kanban, and yet explaining it through Little’s Law is dull and abstract.. so here is my attempt to make it engaging and shareable.

It's clearly something we should be trying to reduce.

Lead time is a great empirical feedback loop:

• Easy to measure - when did we start and when did we finish on a piece of work
• Represents a system-level behaviours
• Is 'impossible' to game or cheat
• Easy to see trends over time. Are we becoming more or less responsive?

So…. what is the best way to reduce lead time (cycle time)?

Little’s law

This maths is robust and applies across all kinds of systems, from the queue at your coffee shop to the progress of a feature through your team.

https://en.wikipedia.org/wiki/Little%27s_law

It’s easier to visualise this as

If you want to half the lead time

– you only have two options

– and one is much quicker and cheaper than the other

This is probably our default response and it does work. However, it will take a lot of time and cost.

This is much quicker and cheaper to implement.

It is also the reason why Kanban obsesses about it - if you are not reducing your WIP to the optimum level, then you're not doing Kanban

You can do either or both

..but the quickest, cheapest way to intervene at a system level and improve customer perceptions, responsiveness and innovation - is to reduce WIP

Tweet.

Agile can be seen as an interplay between its two overarching goals of building the right thing and doing it properly. Although 'Interplay' is putting it positively, as they often compete for resources and spend much of the time far from a harmonious balance

The dominance of Scrum in the Agile landscape has perhaps had us focused too much on the left hand side of the picture. We’re slowly correcting this to appreciate the importance of the counterbalancing right.

Of course the more technically-aware have been working hard on this for many years. However, it’s still quite shocking just how few organisations have really grasped how important, and difficult, it is to build the thing right.

Such an imbalance is probably the fastest way to accumulate technical that we have yet invented.  

Helping stakeholders understand this picture enables them to appreciate the true Agile picture and the consequent levels of investment in skills, people and tools that are needed.

Luckily Agile has some very good and established patterns to ensure we can achieve this balanced state.  

Yin and Yang speaks of complimentary and interdependent forces in a dynamic system, just like those we try to work with in software development

Build the right thing..

Is achieved through a number of established Agile principles and practices. 

Get close to users and understand their real requirements

• The Product Owner role in Scrum, and its equivalents in other Agile approaches – clearly identify the person with domain knowledge who we can hold accountable for ‘what’ is built.
• Well established ways to deeply understand requirements e.g. User stories, Specification by Example or Feature Driven Development
• These both enable us to hear the ‘user’s voice’ amongst the complex hubbub of development
• Early, frequent validation of our deliverables keeps us aligned to expectations
• More telemetry and metrics of how the solution is actually used help to validate the solution provides us with the final feedback loop

Build better solutions through closer collaboration and on-going emergence

• Daily collaboration within the team and between the team and PO or users encourage emergent solutions, informed by multiple perspectives.
• We have found ways to unleash the creativity of intelligent people and tapped into the collective, focused purpose the team.

Don’t begin to develop software that is not properly understood or may become blocked

• Definition of Ready (for development) ensures we don’t start to work on requirements that we don’t understand or are too big or ambiguous.

Align overall development capacity to changing organisational priorities

• Portfolio Backlogs act to align development capacity with the organisation’s evolving priorities in a single place, transparently.

And.. the Agile Manifesto says

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”.
• “Business people and developers must work together daily throughout the project. “
• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Build the thing right

Summarises the technical rigour that many organisations appear either unaware of – or find too difficult to try.

Prevent bugs or find them quickly when cheaper to fix

• Test Driven Development, Continuous Integration help to prevent defects – or find them rapidly
• Cloud-like technologies mean we can finally afford to do performance testing earlier in the process

Keep focus on the code quality

• Peer review of code, clear coding standards and pair programming help to move good practices around a team and establish accountability amongst peers for the work they are doing. This is much better than trying to ‘police’ the quality by an architect or other external role
• Code quality tools like SonarQube track key trends, like complexity or maintainability, over time. Alerting us to any negative drift in the trends of complexity and maintainability.
  • If I were using outsourced teams, this would be an easy, transparent and fair way to hold them accountable for the quality of their work - and yet so few companies do this.
• Refactoring and principles of ‘internal open source’ also help to maintain the focus on code quality.

Make the solution resilient and adaptable

• It is certain that the solution will evolve over time. Well documented code, wrapped-up in automated testing is a fundamental pre-condition to that process of evolution.

Focus on finishing high quality work

• The team’s ‘Definition of Done’ and Scrum’s emphasis on shippable quality every sprint helps to embed quality in the team’s daily work.
• Slicing work up into small chunks means we get more of into the done column more frequently

Building it right, through to live

• The ability to reliably deploy the solution into live is a key part of building it right.
• The automation of testing, build, environment-creation, configuration and deployment are relatively new though already indispensable set of disciplines and capabilities.
  • All brilliantly summarised in Jez Humble’s book ‘Continuous Delivery’

And.. the Agile Manifesto says;

• “Continuous attention to technical excellence and good design enhances agility. “
• “Simplicity - the art of maximizing the amount of work not done - is essential. “
• “The best architectures, requirements, and designs emerge from self-organizing teams”.

The simplest illustration of the benefits of focus must be this one – clearly illustrating that if we focus on _and finish_ one feature (or project) at a time then all 3 features are delivered quicker.

Agile emphasises delivering value sooner – in order to generate revenue, create lessons and validate assumptions.

1. In the ‘current situation’ all three features are started as soon as they are requested – but none are finished until near the end.
2. Focusing on one at a time means that A and B are delivered value sooner in the second example
3. However, many studies (e.g. in Tom DeMarco and Tim Lister’s book ‘PeopleWare’) show that there is a real cost in switching between tasks.
   Therefore, assuming a saving of only 10% – we see that all three features are delivered significantly sooner. This is not just a marginal gain, it could translate into weeks of additional sales.

As well as the benefit of earlier value and lessons – don’t underestimate the energising effect on a team that delivering A, and knowing it’s in the hands of users, can bring. Focus increases the ‘realness’ of the work and sense of achievement and recognition that the team.

Focus also means more collaboration within the team, which can only bring a better solution – creatively built from multiple perspectives.

The intuitive assumption is that the sooner we start something the sooner we finish it…

… the real challenge is how to adjust the behaviour that’s driven by this assumption, which often recurs at every level of the organisation.

Tweet.