Hey delivery team, customer, project manager… what do you value? What I value has evolved over time. At one point I couldn’t have succinctly answered that question. Now it is crystal clear and seems like the pinnacle of common sense for a manager of a delivery team like me.

I value finishing work over starting work.

This simple realization has completely changed my viewpoint on how I approach nearly all aspects of my job. Now that I have had this epiphany, it seems unreal that I have to explain this or, especially, argue this point to get people on the same page with me on this topic. I often wonder why this isn’t common sense to all. It’s easy to forget I wasn’t always thinking this way.

In the beginning…

Initially there is comfort, amongst delivery teams and customers, in the feeling you get when you begin things. You begin this, you begin that, and you begin some more. You begin as much as possible. You value starting work. It is the measure of your success.

You continue on and on and on in that vein, but over time you grow unhappy. You wonder ,”What is going on, why are we so slow? Why aren’t we delivering anything? And why is my delivery team so stressed out all the time?” You probably don’t realize, even at this point, that you are valuing the wrong thing. Its so ingrained in you that it is not the first thing you think to change.

It is at this point that any competent professional whose responsibility includes ensuring delivery starts to investigate the problem and possible solutions. It was at this point that this particular professional stumbled upon Kanban.

The journey …

Studying Kanban, particularly reading David J Anderson’s book on Kanban, let me find ways to begin addressing the big concerns: how to begin delivering again and how to make my developers happier – or at least less stressed. The secret lies in introducing constraints in the system. Kanban does this by limiting work-in-progress (WIP). But, how does this solve my problems?

… to earlier and consistent delivery

I like to use a very simple example when explaining why limiting developers to 1 thing at a time is best for the people expecting the delivery. In the old days, a developer would take 5 items on. Each item, in a vacuum, would take 1 developer day. But, because you value starting work, you spend a % of time each day on each task — say 20% of the day’s time per task. Can you do the math? It would take five days before the client sees any value from the developer’s efforts.

However, when you limit work-in-progress to one task per developer at a time, the scenario changes. A developer has one item on their plate. The item takes one developer day to complete. Because the developer has a single focus, the client sees value in one day as opposed to five (and probably with better quality to boot).

You could argue that in five days the client would still get the same amount of value in either scenario. I’ll put aside the fact that context switching in the first model adds development time — I could do an entire additional post on the costs of context switching. The value of Kanban is the consistent delivery of items, the consistent flow of work through the workflow. Clients are generally happier when they get value sooner and consistently.

… to a less-stressed delivery team

When a developer has many things on their to-do list there is a underlying layer of stress that always exists. Its a feeling of being consistently behind despite your best efforts. Additionally, when you start work, there is the expectation that the item in question is actually in progress. If you have more than one thing in flight then the item is not actually in progress 100% of the time and this results in mismatched expectations. This results in developers experiencing repeated interruptions by the stakeholders to find out the status of tasks. This only compounds the time in which things are not actually being worked. The longer you spend in this state, the more prone you become to being reactive. The old adage “the squeaky wheel gets the grease” is almost certain in this scenario. All of this boils down to unhappy developers!

Focusing on one thing at a time correctly sets expectations on the developer and removes the underlying layer of stress that no longer applies. Now the developer just has to focus on being as efficient as they can while still producing quality work while managers and product owners manage prioritization. Developers also like to deliver. So now they have the experience of delivering value more often, which usually makes them happier.

The equal and opposite reaction

A by-product I have observed is that this setup forces the product owner to really understand the prioritization of their backlog. They no longer have a false sense of what can be accomplished in a given period and they become more aware of the value of their prioritization due to the constraints introduced to the workflow. Whereas the past seemed more like the client used a “fire and sit back and wait” mechanism to get items into their backlog, they are now more inclined to actually collaboratively manage their backlog.

If you are experiencing anything mentioned in this post, I really suggest that you look into Kanban and the possible relief it can provide for you!