The journey from “Sure” to “No” to “Not now”

Recently I was invited to a meeting where the discussion was how to implement Kanban within the team. During the course of the conversation I said, “… we need to start saying “No” more often…” A colleague smiled, “Coming from you, that’s quite a change”

I consider customers to be the greatest assets an organization can have and have always said “Sure” to requests. I try to exceed expectations and I tend to encourage people I work with to do the same. However, as I began working with the Kanban, frequently, I find myself asking questions like, “Are we sure this feature is value add? What benefits have you identified? How would you quantify the investment? etc.” We all have very limited resources and people time. So I probe deeper to understand if the undertaking provides significant benefit. This approach also helps the customer reiterate the feature benefit. A side benefit is that this helps limit work-in-progress at the program and portfolio level.

Assuming a 3 person team working 40 hours/week, the capacity of the pipe is only 6,240 hours at 100% utilization. However, scaling back to a more reasonable 60% utilization, the capacity of the pipe is only 3,744 hours; i.e. I have only 3,744 hours to work with. And I need to ensure that every bit of the 3,744 hours is used effectively. (Definition of effectiveness: Do the right thing. In contrast efficiency is: doing things right).

Ever since I started taking the Kanban approach, I thought I was saying “NO”. But when you pause to think about it, is it really a NO? I don’t say that we won’t do it? All I am saying is that we are not going to drop everything right now for this new feature. Our team has (enter count here) items on the go now and the backlog size has (enter count here) items. We won’t stop working on the things we have on the go now but as soon as we finish at least one feature we are working on, we’ll take the next that’s on your priority list. As long as we have not started working on a feature, you are free to change the priorities of the features in the backlog. And by the way, our cycle time for the current work-in-progress feature is 10 days. We will be able to start work on the next priority feature in 10 days. So, in essence, I am just saying “Not now”. I am just following one of the three tenets of the Kanban: “Start new work only after you finish existing work”

With such a low cycle time, it has never been a problem to get the customer to agree on this approach. We have a problem when we take a long time to deliver features. For example, if you follow the big design upfront approach, it will probably be a long time before the customer gets to see anything your team has developed. Having long cycle times provides the customer an opportunity to change the scope. Shorter cycle times enable you to deliver features faster than the customer’s ability to change their minds. I absolutely love the service Amazon provides – a physical book would be at my doorstep within 3 days of placing the order. The order would be processed and shipped within 24 hours. With the Kindle books they now have taken away even that one day opportunity for me to change my mind. It’s almost instantaneous. Cycle time is in hours instead of days.

So in summary, before you take on more work look at how full your plate is. If taking on more work will increase your cycle time, don’t be afraid to say “Not now”.

What are your experiences in limiting work-in-progress as you transition into the Kanban way?

Leave a Reply

Your email address will not be published. Required fields are marked *