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.

Arranging work around projects is a significant impediment to the creation of a responsive organisation. Hopefully this simple illustration shows how focusing on projects generates waste and delay – and the good news, there is an alternative. 

Clarification: Following some feedback I suggest you read this in the context of any project where value can be delivered incrementally - typically IT projects. (5th Dec)

Project-centric thinking allocates ‘resources’ to the project.  A team-centric approach takes the work to the team.

Project-centric thinking first creates the somewhat arbitrary artefact called a ‘Project’

It then attaches a number of key elements like; a budget, project manager, requirements and shares of different ‘resources’

Projects artificially create a large batch - where highly valuable features are made unnecessarily dependent, and therefore delayed, by lower value features.

When you include the other projects, the picture becomes complicated.

This complexity appears to need process to bring a sense of order and so we introduced:

• Process and gates to manage the budgeting and requirements gathering.
• Project managers to allocate resources, parcel-up pieces of work to different people and then chase them up, creating summaries and reports for stakeholders.
• Governance and steering groups reassure the organisation with a sense of control.

However each of these interventions generates waste.

A Catch 22, where both the complexity and the attempts to deal with the complexity, introduce waste through task switching, delays and non-value-adding activities.

A note on waste: I am using the lean definition of waste i.e. any activities undertaken by an organisation that consume resources but do not add value. Where value is defined by the user.

In a picture as complex as this we begin to focus inwardly on the process rather than on the user and the flow of value.

Please don’t read this as a dig at Project Managers. These activities (not the role) are systemic and have emerged through an understandable, but ultimately misguided attempt, to manage and plan our way out of complexity.

So, what does the alternative look like..

Keep the teams stable, with all the human benefits that gives us, and take the work to the team.

Stable cross-functional, co-located teams develop trust and effective ways of working.

They bring other benefits too:

• Better solutions – created from multiple perspectives
• Less stress as team can focus on their work and not be distracted
• A sense of common purpose and endeavour can raise moral, less solitary working.
• Organisational resilience as skills are spread between team members
• New arrivals can get up to speed faster and blended into an existing team. Important in organisations with increasing rates of churn
• Key-man risk can be mitigated with no isolated developers.
• Quality improves through peer review and join responsibility for code quality.

A way-of-working based on Agile principles and practices brings a simpler, calmer picture of how value flows.

A portfolio backlog is created that includes all the work to be done. Not forgetting non-functional work and those smaller nuggets of functionality with a potentially high ROI and user benefit.

Portfolio backlogs help move towards a more continuous flow of smaller batches of work.  This improves the predictability that the business craves.

Work is taken to the team.

The work might be 'accompanied' by a Product Owner who is clear about the opportunity, knows the domain and is best placed to maximise the return from the investment that is about to be made .

A single parcel of work is taken to the team.

This could be a Release lasting a few months although preferably a smaller MVP or shippable increment.  The smaller the better.

Bigger pieces of work can be given to more than one team and split down into backlogs for each team.

Note: work in the portfolio backlog is not made up of projects but of releases of projects, each of which can be shipped to live. Giving us earlier value, less risk and more predictability.

This simpler, calmer picture of work being taken to the team requires fewer Project Management non-value-adding activities, like resource planning and delegation and instead focus on value-adding work.

Governance can add value by guiding and validating work.

Further reading

If you want to explore this further then there is plenty more on the  #noprojects tag on Twitter

Alan Kelly has been talking about this for a while. http://www.allankelly.net/static/presentations/Oredev2016/Oredev-BeyondNoProjects.pdf

and InfoQ has a good article  https://www.infoq.com/articles/noprojects1-projects-flawed

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.

The delivery pipeline is an idea which resonates with our clients. The simplicity of the metaphor and the truths that it reveals make it a compelling message to share with others in the organisation.

The pipeline helps to visualise two key Lean principles; seeing the end-to-end value stream and ‘optimising the whole’ http://bit.ly/ImpLean It illustrates the emerging emphasis on Continuous delivery’ http://bit.ly/CDAgile

The overall organisational aim is to balance the pipeline, as any constrictions generate waste.

The pipeline helps with the key challenge of getting senior stakeholders to prioritise and budget the money, and time, to balance the pipeline end-to-end.

Instinctively, because developers create functionality then, if we want more functionality, we must need more developers. Whilst jarringly simplistic, this is a perspective held by too many senior stakeholders.

However, adding more developers or teams, immediately leads to an imbalance in the capacity of each section. More development teams develop more code, which we then try to force through the lower environments – where it sits, wastefully, in queues or trying to muscle its way past other projects waiting for a limited slot in a integration test environment.

In addition to the waste, the quality plummets due to the stress of trying to get work through this constriction. A situation that is often made worse when these downstream environments are shared with other projects / programmes.

Similar constraints usually exist upstream of the developers. The Product Owner role is new to most businesses and the level of on-going work they need to do is often underestimated. Beyond the responsibility for preparing stories every sprint, collaborating with the team on a daily basis, POs need to actively engage with stakeholders and users.

The diagram below illustrates the actual capacity of the pipeline, which can be quite an attention grabber. It’s troubling for senior stakeholders to realise they are paying for all that under-utilised development capacity.

Steps to a balanced pipeline

Step 1: Communicate the need of optimising the system end-to-end

Use the pipeline diagram to communicate the essence of the challenge. These issues are difficult for even IT people to see and understand, even though they live with the stress of these systemic shortcomings on a daily basis. Create a sense of urgency by providing estimates of how much this waste is costing, both in money and in delayed value to customers.

Step 2: Prioritise and target specific interventions at the points where they will have most impact

• Investment in the environments, automated testing and deployment tools to ensure frequent/continuous movement of software through the environments to live
• Improve the quality and frequency of collaboration across traditional organisational boundaries, e.g. between developers, service introduction, support and infrastructure.
• Improve ways of working upstream between Product Owners, stakeholders and the teams. A clear vision with stable portfolio backlog is more likely to create a steady flow of high priority work into the development teams.
• The teams themselves can improve quality and throughput by adopting Agile/XP technical practices and working more closely with both the product owners and the ‘downstream’ teams.

Step 3: Visualise the waste with a value stream map

Visualisation and quantifying of the waste is key to building a sense of urgency for change and then targeting interventions at the most wasteful sections of the pipeline.

Value stream mapping is the simplest and most effective way to identify where the biggest queues and worst bottlenecks are in the system. The best resources on value stream maps are Mary Poppendieck’s books, including Implementing Lean Software Development’ http://bit.ly/ImpLean

Real-time visualisation of queues is best done with Kanban techniques, which can highlight emerging issues in the system.

Step 4: Get senior stakeholder support and the budget and time

The level of investment needed in environments and tools are often new to a business, which may not be clear on the sizeable returns available. These returns are often in the form of reduced waste, which many senior stakeholders can’t see or evaluate – even though they can sense waste all around.

A senior director estimated that 50% of their software development expense was wasted. How have we ended up accepting, or not able to deal with, this level of waste?

A smoother flowing pipeline also reduces cycle time, meaning that profit-generating functionality is deployed sooner.

Whilst getting the budget is difficult enough, ensuring the work actually gets done, month after month, is even harder, given the prevailing culture in many businesses.

Businesses and managers are rewarded for delivering value to customers. Few businesses reward managers for improving the capability of their system to deliver value.

It’s common to recognise the sacrifice in fixing problems – rather than rewarding those who prevented the problems in the first place.

The ‘non-functional’ work needed to improve system capability is difficult to value and prioritise in any company-wide backlog of work. Those that understand the potential benefits of a balanced pipeline need to articulate that value and be prepared to be held accountable for delivering the promised benefits.

This cultural bias, towards delivery and not improving the means to deliver, continually sabotages attempts to balance the pipeline.

Step 5: Expect resistance and be in it for the long haul

The value stream maps highlight that many constrictions occur at existing boundaries within the organisation. The delay, hand-offs, lack of visibility and accountability at those boundaries are the biggest challenge to creating a balanced pipe.

These changes to what people do, how they work with others, changes to accountability and their daily work will generate resistance.

Specific action is the best way to ignite the change. People on both sides of the boundary typically suffer from its existence and are often keen to improve the situation.

And… it’s not just the pipeline… but the shape of what you put down it..

In addition to working on the pipe itself – the throughput will be significantly improved by looking at the material going through it. This is the subject of a follow-up blog, where we’ll look at batch size, variance and work-in-progress as key variables.

In the meantime, Mary Poppendieck already has some good insights on this at http://bit.ly/LeanPipe

Tweet.