Kanban — The Secret Engineer Killer

Kanban -- The Secret Engineer Killer

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, very few are actually getting leaner. More than 90% of all diets fail. And 75% result in weight gain beyond the original amount lost*. If anything had this failure rate in business, we’d 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 sixty days and the pattern is frightening. Kanban is leading teams to a very barren place.

For nearly every company that’s adopted Kanban, there’s growing misery for product management first and engineering soon after. Consider this an early warning that if you have adopted Kanban you might be starving your teams and you better nourish them before they leave and get healthy elsewhere.

But before we further ponder Kanban, let’s consider why we keep falling for fad diets in the first place?  We know they don’t work and anyone who has been hungry understands that diets are guaranteed to make you cranky because they deprive you of something you want. To simplify, we keep doing it for three key reasons:

  • Peer pressure
  • We are more focused on how we look than our long-term health
  • We feel out of control

If you have adopted Kanban for software development, you have probably also done so for nearly identical reasons. But I don’t blame you, for there is no doubt that you have done it with good intent and a desire to thrill your engineers and deliver product faster.

And 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’s 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’s 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 can’t trust yourself
Kanban devalues your company’s own talent, culture, market and unique know how. It teaches you 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 don’t 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’s 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. Stop the Kanban insanity and get to a healthier place by going back to a basic goal-oriented development approach. Just like dieting, there are no quick fixes for healthy living or software development.

Building great software is hard, but it should not be excruciating. We built Aha! with this goal in mind — we wanted to create a new way for product and engineers managers to create brilliant roadmaps and be happy doing it. Sign up for a free 30 day trial now.

Follow the author @bdehaaff

(Comments on Hacker News)

*Please note that I am writing about people who diet who are within a “normal” BMI range and I am not suggesting that medically supervised diets or weight reduction treatments or programs are not important.