Note: For background on the Kanban Method (what I refer to as Kanban below) please click here.

A blast from 2010…

http://www.djaa.com/principles-kanban-method-0Today I asked myself if “Kanban makes any value judgements?” I also told a friend something along the lines of “when first principles are considered heretical, we’re doomed” (file under deep-but-not-terribly-profound-yet-I-Tweet-it-anyway)

.

We were discussing the benefits of a single backlog, late binding to work, and swarming on high cost-of-delay opportunities. He likened a recent success in swarming on an opportunity as an example of “building trust in something new and risky” (actually, he used the example of lifting your hands off of the steering wheel of a self-driving car). The car thing really got to me.

For some reason this helped me crystalize something that has been bothering me for years now. When the new and risky is grounded in first-principles (limiting WIP and prioritizing by high cost-of-delay), you’ve got a problem. Even more importantly, when visualizing work — which in my mind involves absolutely no value judgements — is considered “sensitive”…wow, you’ve really got problems!

We’ll put things on linear calendars with dates and fanfare, and call our estimates commitments…but a program level board is considered heretical. Daggers!

Aside … I always love when a leader marvels at the benefits of focusing (and the teamwork that inspires), and then promptly returns to “business as usual” (with all the work they paused AND the new work) and expecting the same outcomes.

I’m overreacting. But let me explain…

Kanban doesn’t care about how you write code, structure and incentivize teams, develop roadmaps and backlogs, manage projects, manage people, scheduled meetings, or release software. Through visualizing our work, Kanban helps guide our continuous improvement efforts.

You could argue however that there may be some values baked into “slow, gentle, evolutionary, incremental approach”, “respecting current roles”, “making process policies explicit”, and “improving collaboratively (using models & the scientific method)”. Not to mention limiting work-in-progress and managing flow.

What would the opposite of these quasi-values look like? I dunno…

• Bold and visionary decision making.
• No one gets in your way.
• Information on an as-needed basis only. Resist formalizing process.
• Managers own decisions related to process selection
• Bite off more than you can chew. Stretch goals. Overcommit.
• Optimize for resource efficiency, not flow efficiency
• We value entrepreneurialism and individual action If you can have an alternative narrative of “right”, then we have baked in values. Kanban (sort of) deals with this by:

Respecting the current process, roles, responsibilities & titlesLet’s say that in your company continuous improvement on the program level is a closed-door activity between senior managers…well, you just have another Kanban board in that room. Or perhaps you don’t want to codify the current real-world process. Well… your process could be as simple (and meta) as “no process defined, ask someone”. Maybe the CEO wants the power to move any card on the board. Add a simple “CEO can move any card in this column, and any column to the left of this column.” Of course she won’t want that to be made explicit, but that’s another story.

So we’ve dealt with transparency and collaboration (sort of). But you still have flow efficiency, limiting WIP, and evolutionary change. Changing these things might be tough given the current process.

OK. Getting personal for a moment. I frequently get called out for having “strong opinions on how things should work” (mostly from managers and leaders). I’ll try to answer with something like:

I don’t really care about what happens as long as we can observe the system together (visualize work), talk about what is working and not working, ground what we’re doing in first principles, create an environment of psychological safety, and experiment and learnIn my mind, this is about as reasonable as you can get. I deeply, deeply believe in these things. But it is very much guided by my individual value system. And I see other system-thinker “agile” types get caught up in the same trap. We believe we’re being insanely pragmatic and open, but it sounds insanely prescriptive and heretical.

So the important question when introducing Kanban into an organization is something along the lines of:

How do you approach continuous improvement on the individual level, team level, team of teams level, department, cross-department, and organizational level?Most people have never even thought about it. “It just happens” or “we do it on a case by case basis” or “really, that’s a manager’s job” or “well, we do an employee survey quarterly” or “that’s what retros are for, right?” The real opportunities are frequently a step (or a couple steps above) the team level, but that realm is a murky mist.

Listen carefully. This is the root of the challenge. How does the group feel about continuous improvement? This is your starting point.

I have no grand conclusion other than that “meta processes” (things we believe carry no prescriptive qualities and just help us sense the problem) are often perceived as threatening and prescriptive.

Cheers!