Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Patterns for getting to a lower WIP level in a system

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

The Freeze, No New Work, Limit Later, and some Mashups...

Some of us have the luxury of designing processes for greenfield systems meaning there is no history/legacy to deal with.

Typically though, we are dealing with Brownfield/Legacy systems – This usually means there is some work in the system already, there are outstanding commitments, and some existing queues between steps in our processes.

I’m working with several clients that decided to start using a Kanban system to manage their work, and believe Limited Work in Process is key to improving their performance.

But a challenge most of them share is how to deal with is something along the lines of:

  • We already have a commitment to deliver V10 with 20 features by end of October.
  • Our testing department is backlogged – its still dealing with the previous release V9 while development is already working on those 20 features for V10.
  • V10 is critical to the business.

We then discuss various ways to get from here to there.

The Freeze

Essentially prioritize all work. Anything that is in process but above the WIP limit, goes to the freezer – a new temporary lane/area where work is put on freeze until there is room for it.

The immediate effect would be an acceleration of all work inside the WIP limit, and significant risk to the commitment made about the frozen work. Yes, you say that the original commitment took all the work into account so why is there a risk just due to changes in parallelism? Well, because we focus on the higher priority work, the reality is that we might spend more effort on it, to deliver it with reasonable quality (not necessarily an attribute of previous releases…), we might spend more time investing in Versatility in order to sustain a lower more focused work in process limit. So, it would be prudent to negotiate the commitment level on a couple of lower priority features from the release… and give the business a heads up this might happen.

This is one of the fastest ways to achieve a new inventory/WIP level in the system. If we are looking to show quick results and are able to negotiate a temporary change in service levels with the business, this can be a great approach.

This strategy is elaborated in depth in the Theory of Constraints body of knowledge.

No New Work

This is a more evolutionary version – don’t freeze current work, but deny new work until we reach the desired work in process levels. This means anyone finishing work on something will look at how he can help someone else, instead of starting something new. There will still be effects on the release commitment, but milder ones.

The price we pay here is that it will take more time to reach the new inventory/WIP level. It’s easier to negotiate with the business, but the results will show more slowly…

Visualize now, Limit Later

This is even a more evolutionary version. You start with Kanban principle #1 – Visualize work. You don’t put any WIP limits for now. You see how work looks like, you try to manage WIP, but don’t limit it. Perhaps when negotiating commitments to the next release V11 you take into account a period of cleaning the system/queues and the implications of lowering the WIP, and at that point you go into a Freeze/No New Work period, with a bit more confidence in how this will look like, based on a few weeks/months of visualizing your work.

This clearly is the risk-averse approach. Just be careful of running out of improvement energies and forgetting that just Visualizing Work is not enough…

Differentiated Service

A tweak on all of the approaches above can be to treat different work types differently. This is what we call Classes of Service in Kanban.

For example, Normal work above the WIP limit will be frozen. Fixed date work will hopefully be inside the WIP limit and be allowed to finish. New Fixed date work can be allowed to start, with the condition that a Normal work will be frozen in exchange for introducing it. If all work currently in the system is Fixed Date, we can decide whether to allow the new Fixed date to start (should be a comfort zone for most organizations 😉 or to have a serious discussion with the business on the risks it introduces and how we want to address them.

We can also say we visualize all work, but limit specific types of work.

Feedback

What do you think about those approaches?

Which of the above did you find useful in real life?

Do you have other strategies for starting up in the real world?

Subscribe for Email Updates:

Categories:

Tags:

Lean Agile Leadership
SAFe DevOps
Agile Testing Practices
Agile Techniques
Agile Development
chatgpt
Agility
Lean Agile Basics
Keith Sawyer
Agile for Embedded Systems
Jira admin
Reading List
Implementing SAFe
Sprint Planning
Agile Delivery
Agile Project
ARTs
Spotify
ART Success
Agile Games and Exercises
Kaizen
Lean-Agile Budgeting
Agile Basics
PI Planning
Frameworks
AI
Agile Exercises
Lean and Agile Principles and Practices
Kanban Basics
speed @ scale
Engineering Practices
Agile Mindset
Agile Marketing
Agile Community
Lean Software Development
System Team
Kanban Kickstart Example
Lean Budgeting
Nexus and Kanban
Perfection Game
SA
Continuous Deployment
Enterprise DevOps
Elastic Leadership
Legacy Enterprise
Professional Scrum Master
Atlassian
Agile Release Management
Continuous Integration
Jira Cloud
Continuous Planning
lean agile change management
Webinar
Acceptance Test-Driven Development
Agile Program
Scrum Primer
AI Artificial Intelligence
Coaching Agile Teams
Value Streams
Agile and DevOps Journey
Process Improvement
ScrumMaster Tales
Large Scale Scrum
Business Agility
BDD
Kanban Game
Tips
Professional Scrum with Kanban
Kanban
Effective Agile Retrospectives
An Appreciative Retrospective
agileisrael
Games and Exercises
Nexus Integration Team
IT Operations
Daily Scrum
Agile Israel
Sprint Iteration
transformation
QA
Agile
Planning
Video
Scrum With Kanban
Agile Games
Nexus vs SAFe
A Kanban System for Software Engineering
Risk Management in Kanban
speed at scale
Lean-Agile Software Development
Scaled Agile Framework
GanttBan
SAFe
Product Ownership
Achieve Business Agility
ATDD vs. BDD
Portfolio for Jira
LPM
ALM Tools
AgileSparks
Accelerate Value Delivery At Scale
Development Value Streams
Implementation of Lean and Agile
What Is Kanban
Limiting Work in Progress
Manage Budget Creation
Rapid RTC
Certified SAFe
Kaizen Workshop
Retrospectives
Operational Value Stream
Software Development
Hybrid Work
Agile Release Planning
Amdocs
Team Flow
Nexus
System Integration Environments
Applying Agile Methodology
ROI
Atlaassian
TDD
Introduction to ATDD
Product Management
RSA
Entrepreneurial Operating System®
Covid19
LAB
Lean Agile Management
Risk Management on Agile Projects
Systems Thinking
Releases Using Lean
Scrum Master
Test Driven Development
Agile Outsourcing
Agile Risk Management
Managing Risk on Agile Projects
Agile Israel Events
Agile Contracts Best Practices
EOS®
Principles of Lean-Agile Leadership
Scrum.org
Code
The Agile Coach
Agile Product Development
Tools
Professional Scrum Product Owner
Managing Projects
SPC
DevOps
Program Increment
Nexus and SAFe
Jira
Software Development Estimation
Risk-aware Product Development
Slides
Lean Startup
Change Management
Kanban 101
Agile in the Enterprise
Built-In Quality
Lean Risk Management
Lean Agile
Scrum Master Role
Agile Project Management
Artificial Intelligence
Scrum
POPM
Scrum Guide
NIT
Agile Product Ownership
Lean and Agile Techniques
Scrum Values
WIP
Story Slicing
Continuous Delivery
Agile India
Introduction to Test Driven Development
RTE
Certification
User stories
Legacy Code
Agile Assembly Architecture
ATDD
Presentation
SAFe Release Planning
Lean Agile Organization
LeSS
Continuous Improvement
Advanced Roadmaps
Sprint Retrospectives
Scrum and XP
Pomodoro Technique
Quality Assurance
RTE Role
System Archetypes
PI Objectives
Self-organization
Iterative Incremental Development
Jira Plans
Release Train Engineer
predictability
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart