Patterns for getting to a lower WIP level in a system – 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 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.

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?

 

The Agile Lowest Common Denominator – Avoiding a slowdown due to the weakest link

One of the concerns often raised when people hear about kanban is that the weakest/slowest link will slow down the whole chain.

For example if testing is a bottleneck what will happen is that the whole chain will accommodate its pace.
Similarly in scrum a team that actually does realistic planning will commit to a goal that stretches the bottleneck leaving other resources some serious slack.

In both approaches this is indeed a valid concern.

The worst thing that can happen is if the bottleneck causes the rest of the links to adjust their pace, and worse than that their “pace memory”. I’ve been thinking about this for a while and am also asked about this quite frequently whenever I introduce kanban to Managers with some experience…

In an old but wise article about the “Four Roles of Agile Management” David Anderson refers to it as “The team can forget how to run fast – when there is a bottleneck/drum”. I recently had a twitter chat with David on the subject. David sees this problem as an optimization problem for high maturity organizations. Based on the discussions I’m having, I think the optimization might indeed by a high maturity tweak, but even the concern about this happening is a roadblock to accepting the concept of Kanban Limited WIP or Scrum Whole Team Commitment.

I think we need to have a better answer for this question as part of the kanban “sales pitch”. At least I need it…

So what do we say? Based on the discussion with David and some more thoughts some of them fueled by recently reading The Principles of Product Development Flow: Second Generation Lean Product Development, I would recommend the following.

Basically, what we want to do is solve a conflict. On one hand we don’t want to create inventory and increase the gap between faster stations and the bottleneck as we know that creates slow feedback, lower quality, and we will have to close the gap at some point. On the other hand we don’t want to slow down the other stations as we know its both lost capacity, as well as can lead to lower capabilities over time if they “forget how to run fast”.

How can we solve the conflict? By looking at the assumption that the other stations always work on flows that must involve the bottleneck. Can we break this assumption? YES we can…

There might be work types that don’t need to go thru the bottleneck. Not all work is created equal. For example, if Server guys are the bottleneck, choose work that is not as Server-Heavy. If Testing is the bottleneck, choose work that is not Testing-heavy, or even items that can be tested without the involvement of the testing bottleneck.

Now the purists will say that the priority always needs to be the business priority. But now we’re pulling and prioritizing work based on our capabilities. Yes we are. Prioritizing purely based on the business priority will lead to lower business outcome overall. Our aim is throughput of business value. We achieve that through the right mix of Business Priority and right exploitation of our resources.

Having said that, if we see that we keep skipping priorities due to our capabilities, its time to go to the next step. Create a work item / class of service that serves to realign the business needs and the factory/machine capabilities. For example, in the world of testing this can be test automation done by developers in case testing is a bottleneck. If Server are the bottleneck, we can define a backlog of items that reduce the workload on Server (e.g. Refactoring and returning Technical Debt), or cross-train UI people to gain Server capabilities.

There are more ways to do this, but the bottom line is to always have items in the backlog that the non-bottlenecks can pull and run as fast as they can on. Preferably some of them are aimed at helping balance the line, driven by a process of ongoing improvement.

Since I started talking about this with Management, I see much more traction for the various ways to limit WIP, whether Scrum Sprint Commitment or the more explicit Kanban WIP Limit. I think the idea of “Too much slack” is currently a truth the mainstream is simply not ready for. Beyond that, I think its not fair to ask people/teams to solve this conflict on their own. Help them by discussing the various ways to address the problem, by helping them create backlogs of improvement ideas they should pull in those situations, and by setting the right classes of service / work types that create the alternative routes around the bottlenecks. I think this IS a management role in an agile environment.

PS None of this is really new. The innovation is in setting up the right classes of service and the right risk profiling to effectively manage the line. Elements like choosing items with low cost of delay so they can be used to “Fill Slack” and not pulled as part of the normal priorities. And risk profiling so we re-route or skip the bottleneck on the items where the risk of doing that is minimal. Add to that measuring local cycle times (e.g. with tools like LeanKitKanban ) so each Capability can focus on its own performance as well as the overall cycle time, and you get quite an elaborate system. Sounds advanced? It is. I intend to cover this in Advanced Kanban Workshops we will be starting to run, since we know have quite a community of Kanban Practitioners around Israel. Hopefully we can extend that community to the region soon.


Lean/Agile Testing

I've been a bit quiet lately on the blog front (as well as twitter for those who are following)

Mainly I've been busy preparing an Agilesparks Agile Testing training with Ronen Bar Nahor. While a lot of work, it has been a great experience. We tried to take some of the Lean/Kanban work we've been focused on lately and apply it to the Testing domain. Those following my blog can see some of that thinking already. 

Applying concepts like Limited WIP to Defects, Hardening, DONE DONE, and how to instill collective test ownership make a lot of sense for Agile Testing in our view. 
It also helps that one of the teams that has progressed the most towards Agile Testing approach is a Scrumban team…

The first round is running next week, already sold out, and we are scheduled to run it publicly as well as internally several times in the upcoming months, all in Israel (for the moment…)

If you are interested to hear more about this, feel free to contact me or Agilesparks.

I hope in the upcoming days I'll return to blogging more regularly. My next area of focus is the synergy between Agile and Theory of Constraints. Keep tuned…

Want my elevator-pitch answer to what is Kanban for a Scrum rookie?

 

Our coaching team at agilesparks runs into this question a lot. 

Many of the teams we are working with are familiar with Scrum and using it. Other teams are just now going into Scrum. 
Since kanban is becoming a hot buzzword, we often get asked – so what is this kanban thing? How is it related to Scrum? 

We needed a good answer, that depends on the context, the amount of time you have to answer, and the maturity of the person/forum asking.

In this post, I will try to give the answer you give when someone finds you in an elevator, the last 2 minutes of a workshop, or on the way back from lunch, in short both you and him have a very short time to give an answer. 
Add to that that his knowledge is quite limited. 

Here goes:
"What you might have heard about kanban is that its scrum without sprints. 
I would say that Scrum is an agile approach where the container used to protect, focus and challenge the team is the time-boxed sprint. 
Kanban is another Agile approach! In Kanban the container used to protect, focus and challenge is limiting the amount of things we do in parallel – Limiting the Work in Progress. If you need to remember one thing – remember and lookup Limit the WIP"

If you are in a very high building, you can also add:
"Mixing the two can lead to beautiful results – called ScrumBan. Also one of the biggest differences is in how an Agile change usually looks like with Scrum/Kanban. Scrum is a revolutionary big change up front approach. Kanban is more of an evolutionary laser-focused approach where you find where to focus (using the WIP limit as the challenging force), do something there, continue to the next area to focus on. If you've heard of TOC, its quite similar in how it manages change. "

Now all of this is very simplistic, but probably concepts like Cycle Time, the Lean origins, and other Kanban goodies are too much for a rookie with very short attention span at the moment. 
The important thing is to grow an interest for what this WIP limit means and look it up.