The Kanban Pocket Guide: Chapter 5 - Improving a Workflow to Optimize for Flow

In the Kanban Guide, we purposefully gave preference to the word "optimizing" over the word "maximizing". This is because to "maximize" value is a very dangerous sentiment. Its fairly straightforward to maximize value over the short term. Just burn your people out, make decisions where you favour long term risk for short term gain (instead of short term risk for long term gain), ignore costs, etc. The trick is how do you position yourself to deliver value to your customers year in and year out. For example, Toyota has been doing this Lean thing for over 80 years and my guess is they would tell you they are not done yet.

Optimizing also acknowledges that you are operating within certain constraints. By trying to Trying to maximize one means that you may minimize the others. Optimization implies finding the right balance across all organizational constraints. I believe the Kanban Guide says it best:

"Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done:

* An effective workflow is one that delivers what customers want when they want it.
* An efficient workflow allocates available economic resources as optimally as possible to deliver value.
* A predictable workflow means being able to accurately forecast value delivery within an acceptable degree of uncertainty.

The strategy of Kanban is to get members to ask the right questions sooner as part of a continuous improvement effort in pursuit of these goals. Only by finding a sustainable balance among these three elements can value optimization be achieved."

You will note from the above statement that at the heart of optimization is this notion of continual improvement--which is the purpose of our discussion here.

Options for Improvement

The third practice of Kanban is to improve a workflow. Any element of your Definition of Workflow (DoW) is a candidate for experimental improvement. I say "experiment" because not all process changes will work. If the experiment makes things better, great. If it makes things worse, go back to what you were doing before. The point is to try.

Work Items

Updates to Work Items could range anywhere from what types to track, to what information is tracked on the work item, to how the work item is sized. For example let's say User Stories are one type of work item that you track on your Kanban board. Maybe an improvement is (as mentioned in Chapter 3) to put in place a policy that a given story can only have 1 or 2 acceptance criteria. Maybe you want to introduce color to segment the different types of work items. Maybe you want to eliminate the assignee field from your work items (assignee is probably not good information to be tracking anyway). Maybe you want to stop estimating work items in points (easily the best thing you can do to a work item). Whatever the case, the point is you have plenty of options when it comes to experiments with work items in your workflow. Which brings us too...

Workflow

Equally you should experiment with different aspects of the workflow itself. Maybe it is adding or removing columns, maybe it is renaming columns, maybe it is removing swimlanes (better) or adding swimlanes (worse). Maybe you want to start to visualize steps upstream and downstream of your started and endpoints to get a more end-to-end view of your process (more on this in just a bit). The thing is, if you are using a virtual Kanban tool, adjusting your workflow is one place where you may be handcuffed. I've made no secret of my love affair with physical boards, but I understand that in our increasingly remote/distributed world physical boards may not be practical (not impossible, but not practical either). The advantage of a physical board is that you are only limited by your imagination in terms of how you want to visualize your workflow. With an electronic tool you are now locked into whatever functionality the tool supports. This is not fatal, however. I once worked with a team that used an electronic tool that did not natively support WIP controls. That didn't stop them as they put Post-It Notes with numbers on them to signify the WIP limits at the top of the monitor that broadcast the board in the team room. Which brings us to...

WIP Controls

In 2016, Steve Reid, Prateek Singh, and Daniel Vacanti published a case study from Ultimate Software detailing our success with Kanban up to that time^1^. In that case study we explored in some detail some of our efforts with a group known as the "Aces Team":

"After taking note of the Scatterplot, the team began to dive into the reasons why stories were taking so long to complete. What they discovered was that most long-lived stories were sitting in the "Ready for QA" column for extended periods of time. That was a problem because 'Ready for QA' is a queuing column where stories just sit and are not actively worked on. These "waiting" columns are the low hanging fruit of process improvement and so it was "Ready for QA" that the team decided to attack first by putting a WIP limit of 5 on that column. This decision meant that developers could not pull in new work if there were 5 or more things waiting for QA. They would instead have to go help with the testing of the product. This implication was discussed and accepted by the team as the appropriate behavior to ensure the flow of work."

What is not mentioned in this case study is the Aces continually reviewed and adjusted the WIP Limit on their "Ready for QA" column and ultimately (pun intended) got it down to two. You can read from the case study that they had evidence that this change worked because what they saw was a commensurate decrease in Cycle Time and increase in Throughput through their process.

You'll notice that hidden in this case study is a policy tweak that the Aces team put in place. Whenever the "Ready for QA" column became full, they had a policy that team members should go help out on another item in progress somewhere on the board. The policy was not to start something new, or not to go home, it was to go look for opportunities to pair or swarm. Which brings us to...

Policies

The most target-rich environment when it comes to improvement is most likely your process policies. You have policies that you may not even know are policies.

For example, how do you handle blockers? What does it even mean for something to be blocked? Should blockers count against the WIP Limit? What's the order in which you pull items through your process? What does it mean for something to be finished in a particular workflow stage? Should we pair by default? If you step back and think about it, you probably have dozens of policies--either implicit or explicit--that affect your ability to get work done everyday. One of the biggest levers you can pull to change your process is to change these policies.

Making a policy change will, by definition, change how your process performs. Which brings us to...

The Service Level Expectation

In the Aces example earlier, their process Cycle Time went from 33 days at the 85th percentile (before WIP controls) to 14 days at the 85th percentile (after WIP controls). If, when they started with Kanban, they set an SLE of 33 days or less at the 85th percentile, then certainly that SLE was no longer valid after weeks or months of improvement.

A common question I get is "how do I know when I should adjust my SLE?" As with almost everything flow, there is no straightforward answer. I can say this: a change in SLE is probably not warranted unless there has been some other change in the process (i.e., a change in one of the DoW elements discussed up until now). When you make a change--especially what might be considered a major change (e.g., change WIP limits, remove columns, change blocker policy, etc.)--what you typically need to do is empty the board of whatever items were in progress when you made the change and start tracking Cycle Time for new items that enter the process after the change. Most likely, if the change is big enough, when the change was made will be obvious on your Scatterplot and you can accordingly adjust the historical data that you use to calculate your SLE. If it is not so obvious on your Scatterplot, then, as a rule of thumb, once you have 10-ish "new" items that have completed after the change you should have a enough data to calculate a new SLE. Note that not all process changes will result in SLE changes. This is where the discretion of the team comes in. Use your understanding of context to decide whether an SLE change is appropriate or not.

One final thing about SLEs: you may be wondering what you do if you don't have enough historical data to calculate an SLE. While this is a very uncommon case (usually the problem is you have too much data), if you do find yourself in this situation, the answer is easy. Guess. Seriously, guess. Make a judgement about what an appropriate SLE might be and then (do you see a pattern here yet?) adjust the SLE once you have data.

One case where you might not have enough data to calculate an SLE might be if you have changed the started and end points of your process. Which brings us to...

Started and Finished Points

Let's say you've run through all the examples here and more and have run out of ideas of what process changes to make for improvement. For me, that is a pretty clear indication that it may be time to expand the boundaries of your Kanban system. Maybe you want to expand more upstream to cover the work that happens before items enter your process. Or maybe you want to expand more downstream to cover the work that happens after items leave your process. Either way, once you expand your boundaries you will almost always have all kinds of improvement questions to answer: are our WIP limits set properly? What policies do we have in place to handle upstream/downstream work? What should our new SLE be? By continually expanding your process boundaries outward, sooner or later you should get to that utopia known as true end-to-end business agility. I have yet to see that out in the wild, but I believe it exists (or at least it can).

By the way, for you skeptics out there who might say something like we do continuous deployment/delivery so there is no room for us to expand downstream, let me ask you this: once you have delivered to your customer, how are you validating that what you delivered is valuable? Let's even give you the benefit of the doubt and say that you are validating what is/isn't valuable, then how are you tracking what changes you are making based on that feedback? My point is, if you get creative enough, you will almost certainly think of opportunities to expand the scope of your overall workstream.

Conclusion

There is no way that we could enumerate in this book all of the possible ways you might improve your Kanban system. The best I can do is give you some examples of improvement and let you experiment on your own process from there.

Further, if you haven't made a meaningful change to your process in months, then you are not doing Kanban. The essence of professionalism is showing up to work every day in the belief that you can get better. We began this chapter talking about Toyota. Toyota sees improvement as a journey and not a destination. And so should you.

Running experiments on your process is all very well and good, but how do you know if those experiments made any difference? The missing--and final piece of our Kanban puzzle--is going to be a set of basic flow metrics that will give us additional insight into the health and performance of our process. Let's discuss those next.

Endnotes

1. Steve Reid, "Ultimate Kanban: Scaling Agile without Frameworks at Ultimate Software" https://www.infoq.com/articles/kanban-scaling-agile-ultimate/

Remember you can always download a PDF of The Kanban Pocket Guide here: https://prokanban.org/kpg/