Kanban — Is It Hurting Your Engineers?

Have you ever been on a diet? While two-thirds of Americans say they are on a diet at any given time to improve their health more than 90 percent of all diets fail. If anything had this failure rate in business, we would immediately stop doing it.

Except maybe applying extremely lean or Kanban approaches to software development. Now, I am not sure exactly what the success/failure rate is of Kanban or what metric you would use to measure it, but I have spoken with nearly 150 companies that build software over the last 60 days and the pattern is frightening. Kanban is leading teams to a very barren place. For nearly every company that has adopted Kanban, there is growing misery for product management first and engineering soon after.

I do not blame these companies — there is no doubt that they have adopted Kanban with good intent and a desire to thrill your engineers and deliver product faster.

If you are not familiar with Kanban, let me quickly describe it for you. Kanban (meaning signboard or billboard) is a scheduling system for lean and just-in-time production. It is a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno at Toyota to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary process improvement for organizations.

Unfortunately, if you have adopted Kanban and are like one large consumer software company that I recently spoke with from the East Coast, you no longer deliver market-impacting software to meet key external dates. You are losing thought leadership in market, and you are starting to see your engineers quit in droves. You are looking for a better way, but you are not sure where to head next.

If this sounds familiar, you have likely already started to assess why and what is needed to regain your mojo. From what experienced product and engineering managers have told me, there are a few reasons why Kanban is creating so much pain.

Engineers are not assembly line workers It’s almost embarrassing to write it because it seems so obvious. But if this were widely believed, why would we be turning engineers into widget producers? And if engineers understood what Kanban would do to them, why would they accept it? Is there any wonder that if you hand a very bright and well-educated individual a small piece of work, have them finish it, and then reward them with another small piece of work that they are not going to understand the business drivers, product strategy, or be motivated to finish their work faster? Engineers want to build what matters, and Kanban buries them in incrementalism.

You cannot trust yourself Kanban devalues your company’s own talent, culture, market and unique know-how. It teaches that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects. Worse, it trains the team to only focus on evolutionary improvements and avoid looking for major breakthroughs. Remember that Kanban was designed for continuous production system enhancement.

Restriction leads to rebellion Because Kanban forces a “one work item at a time” mentality and resists milestones, the rest of the organization gets angry because it is not being satiated. High-performance individuals and companies are goal and date-driven. Product management wants to deliver a collection of features to meet customer needs and outflank competitors, marketing wants predictable go-to-market launches to line up key press, analysts, events, and advertising spend, and sales is taught to sell solutions, NOT features. With the Kanban orientation toward improvement, everything else becomes forbidden — further driving the organization to want to binge on something substantial.

If this has you thinking, the following might have you reeling. What you may not know is that Kanban was never intended for software development. David Anderson, the creator of The Kanban Method (discussed above) wrote the following in late 2010.

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!”

If you have read this far, you are either interested in Kanban or have adopted it and this post rings true. So, if you have adopted it and are suffering, I suggest you stop the nonsense and stop trying to get so lean. Instead, focus on a few simple steps to start building great software, regain your confidence, and make sure your engineering team stays motivated (and remains at your company).

Goal first Sit down with product management and understand their strategy to delight customers and win in market. And it they do not have a strategy, press them for one and help create and write it. Once you understand and help refine the strategy, meet weekly because you need a plan to win and it is going to need course corrections along the way. Once there is a basic plan, work together to create clear user stories and lay out a framework for what the engineering team needs to deliver to reach those product and business objectives.

Trust yourself and the team I know you and the engineering team are wicked smart. So, trust yourself and the team to develop reasonable estimates for what it will take to deliver a collection of features that when combined, will have a material impact on customer delight, your market, and the business.

Be agile Commit to delivering collections for features by specific dates and be agile along the way. Work towards your shared business milestones, but be flexible and creative in terms of how the development team reaches them. Stay “goal first” and manage the details as required to deliver against the objectives and realize big wins.

Forgive The product management team is going to be wrong and so are you. Forgive them when they are and be easier on yourself as well when you and the team mess up. The weekly product team meeting is a great place to raise and work through complications and make cross-functional tradeoffs. Teams build cohesive strength working through and resolving problems together.

Now is the time to stop depriving yourself, your engineering team, and the company and get to a healthier place by going back to a basic goal-oriented development approach.