Tag Archives: Transition

Patterns for getting to a lower WIP level in a system – The Freeze, No New Work, Limit Later, and some Mashups…

Estimated Reading Time: 3 minutes

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 are 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 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, 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 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…

Here is a short clip of how it looks like:

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.


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?


Why I think slack is highly important during an Agile/Kanban transition

Estimated Reading Time: 4 minutes

(Note, this post is about slack the concept not Slack the collaboration platform. Though Slack the platform is great as well. We use it at AgileSparks and love it, although it eats up some of our slack time…)

Actually, the title is wrong. I think slack is highly important during any change initiative where you expect continuous improvement of the process and practices. The importance of slack is not new. Not in manufacturing, and not in the Software Engineering world. One of my favorite books is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. Actually anything by Tom is a gem worth reading if you’re serious about managing Product Development organizations… But today I had an epiphany. One of the biggest challenges we face as consultants trying to challenge organizations to be more effective/agile/lean, is that the people simply don’t have enough slack. They don’t have enough time to meet with us. They don’t have enough time to meet and retrospect. They don’t have enough time to experiment. Experimentation takes time – you need to think about what to try, if you take a risk, there is a chance you will fail and lose time. Its very frustrating as a consultant/coach. You have so much to give, you see so many opportunities for improvement, you know that if the team will just sit in a room for an hour they will come up with ideas that can help. You know that if that Developer from the team has some slack time on his hands, he will think of a way to make that build run faster. That test automation suite easier to update.

My pledge to managers leading Agile/Kanban transitions
Please Please Please consider how to add slack to your system. Especially during a change initiative it will help you get the most out of it. People will be more engaged, you will get much more out of your efforts and budget. I pledge to try and convince my clients to do this…
Now that you’re convinced, lets discuss how to actually do it in practice. If you’re not convinced or think you have other ways to better drive this point, I’m all ears… and the post is open for comments…

To effectively use slack I think you need to do two main things:

  1. Account for slack in your resource planning.
  2. Have effective mechanisms to use the slack for the best possible purposes.

Accounting for slack in the plans This is quite straight-forward as soon as you convinced your stakeholders it is a worthwhile investment. Pointing them towards Google (20% time…), Atlassian (20% time and FedEx Day) and other companies using slack as a core part of their system, might help you. Technically, just reduce the resource capacity % in whatever method you are using to manage your projects/commitments. Another great way is to use the slack that is inherent to the plan/development process. What do I mean? For example – in a Kanban/TOC/Flow system the bottleneck doesn’t have any inherent slack. But upstream and downstream from it, if you work in Pull mode, you will find slack. This is because they can process faster than the bottleneck, so obviously there will be times they cannot process because they are bound by a WIP Limit (Or TOC Rope).Ā In Iteration-based Agile this slack takes the form of some free time on the last few days of the iteration if you’re not the tester. In both these scenarios when you have slack, you can either throw it at the bottleneck’s current work, or use it in other ways.

Effectively using the slack
Now that you have some slack time, what do you do with it?
One flow/continuous oriented approach is the Google 20%. People simply have the slack to work on other things in parallel to the ongoing core work.
Another approach is to setup special events, like Atlassian FedEx Day. These events are a time where the entire team/organization is focused on slack kind of work, and it is probably a good idea to use those especially when starting, to kickoff the mindset that slack is a good thing, and show some examples of what can be achieved.
What do you actually do on slack time?
One type of activity is pushing the product forward in some innovative small ways that are off-road from the main track of the project/release. You need to be careful here – messing around with the core behavior of the product is probably not a good idea without the blessing of the Product organization…
I would imagine the google engineers don’t mess around with the homepage too much. They introduce their innovations via Google Labs, plugins, etc. Some ideas make their way into the mainstream product, some become mainstream products (e.g. GMail)
I wanted to talk about a second kind of activity – the one that pushes the capability of the organization forward. Here, your aim is to identify areas where improving can have an effect on the bottom line performance of your organization, and then find ways to improve there.
I discussed before some scenarios like this, but to reiterate the important point – you want to use slack to help Exploit your current system Bottleneck. Now, as I said earlier, one way to simply throw the slack capacity at the current work of the bottleneck. This will help tactically, but will not improve the capacity of the Bottleneck in any long-term fashion. You should balance the tactic solution with finding ways to spend slack capacity on things that will really make the Bottleneck more efficient.
What this means is that a lot of times, the resources working to improve the capabilities of a function, don’t even belong to that function. This is why cross-functional teams and a holistic end-to-end view of the Value Stream is so important… without it you can improve things locally but have zero (or even negative) effect on the bottom line.