Kanban from the Inside: 11. Systems Thinking, Complexity, and the Learning Organization

This series of short excerpts from my book, Kanban from the Inside has reached Part II (Models). For the next few chapters we look outside to other important bodies of knowledge.

I’m not going to reproduce here chapter 11’s tour through Systems Thinking and related fields—I’ll jump straight to some of my conclusions. If they leave you hungry for the detail, you’ll have to read the book!


The Method’s Design

Several elements of the Kanban Method have their roots in the models outlined in this chapter. In particular:

  • The transparency practices (Chapter 1) create new leverage points, making the system more open to challenge and improvement. Furthermore, they can promote self-organization, a strategy for resilience in the presence of uncertainty.
  • Core practice 5, Improve collaboratively, evolve experimentally, connects collaboration (Chapter 3), knowledge, experimentation, shared learning, and evolutionary change.
  • Kanban shares with Lean (Chapter 13) a Systems Thinking approach to leadership (Chapter 6). In the long run, organizations get the leadership they deserve, the kind that their system recruits, encourages, and promotes. It follows that the most enduring organizations are those that have paid attention to this.
  • Albeit implicitly, the first foundational principle, start with what you do now, points both to Systems Thinking and to evolutionary change. I’ve added some extra emphasis by abstracting from this principle the understanding value (Chapter 7)—the goal is for organizations to value understanding and to have the discipline to make it the precursor to change.
  • Evolutionary change is explicit in the second foundational principle, agree to pursue incremental, evolutionary change (see Chapter 8, agreement).

Earlier chapters have made it clear that the Kanban Method leaves room for interpretation. This is a strength. It is articulated sufficiently clearly for a community to rally around it, yet it is applied with sufficient diversity that its community continues to learn, to develop lower-level practices, and to share experiences. It is satisfying to observe that the Kanban community itself demonstrates in some measure all five of Senge’s characteristics of the Learning Organization.

Application

Neither Kanban nor Systems Thinking should be one-off exercises or specialist, “ivory tower” disciplines that are kept separate from where the “real work” is done. John Gall advises this (sometimes known as Gall’s law):

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system[1].

Don’t worry that every step must be right first time. Keeping the system in motion with safe-to-fail experiments, there’s a limit to how much harm any one step can do, and any local difficulties will soon shake out. Under these conditions, suboptimization—the localized improvement that makes things worse globally—is less a problem than the loss of momentum caused by fear of it. “The perfect is the enemy of the good,” as they say.

[1] Gall, John. 2003. The Systems Bible: The Beginner’s Guide to Systems Large and Small, 3rd ed. Walker, MN: General Systemantics.


 

Next up: 12. Theory of Constraints (TOC). Previously: 10. Patterns and Agendas. Start from the beginning: 1. Transparency.

Are we there yet?

As seems to be the tradition, I was the opening speaker at Monday’s London Lean Kanban Day 2015, organised by Jose Casal and hosted by the BCS in London. My talk gathers together a few strands that appear on positiveincline.com from time to time:

Chapter 23 describes a process I’m now calling “Agendashift”. The deck (below) is I think its first public outing:


Kanban from the Inside: 10. Patterns and Agendas

The tenth in a roughly weekly series of short excerpts from my book, Kanban from the Inside. Chapter 10 wraps up Part I, Kanban through its values.


Does Kanban in some neutral way just create the conditions for change, or does it come with its own biases? Do the method, its practitioners, and their host organizations need direction—in the form, perhaps, of an external true north (Chapter 14, Lean)—or will they steer themselves? As a community, we’ve considered these questions several times.

By now you’ve seen enough of Kanban that you won’t be surprised to find that the answers turn out to be rather inclusive:

  • Yes, Kanban creates the conditions for change—in fact, developing the organization’s capability for change is one of its main objectives.
  • Yes, whether expressed as a “true north” or an evolutionary “fitness function,” it’s important to have measures of success.
  • Yes, not only does Kanban have some built-in biases, it’s helpful to make them explicit.

There is one “no” implied by that list of yeses: No, Kanban is not neutral. Today this seems obvious: How could something so intertwined with values—where, for the most part, “more is better”—ever be described as neutral?


Next up: 11. Systems Thinking, Complexity, and the Learning Organization. Previously: 9. Respect. Start from the beginning: 1. Transparency.

Kanban from the Inside: 9. Respect

The ninth in a roughly weekly series of short excerpts from my book, Kanban from the Inside. We’ve reached the penultimate chapter of Part I (Kanban through its values) and the last of the nine values.


Our ninth and final value is the third of our three leadership disciplines. What if all change could be conducted with understanding, agreement, and respect?

Respect underpins Kanban’s third Foundational Principle:

FP3: Initially, respect current processes, roles, responsibilities, and job titles.

It is sometimes suggested that this is redundant. Why would the humane, start with what you do now method need to state this principle explicitly?

I can think of at least three important reasons for its inclusion:

  1. It contains a pragmatic piece of change management advice: Don’t start your initiative by looking at roles.
  2. It points to an underlying philosophy: Find ways around obstacles to change.
  3. No other principle or practice expresses “respect for people” quite so directly.

Don’t Start with Roles

Changing the emphasis a little, let’s summarize some earlier advice:

  • Start with what you do, looking at how what you do meets (and fails to meet) the needs of people inside and outside the system.
  • Organize work; let people self-organize around it, allowing the system to change as a result.

A premature focus on roles would fatally undermine this process. If they need to be defined formally at all, roles can be aligned to process once it has been established—in context—that the process is sufficiently fit for purpose. Meanwhile, we’ll be making it very much easier for people to find that alignment for themselves. Why force the issue?


The Humane, Start with What You Do Now Method

Depicting Kanban as “the humane, start with what you do now method” highlights what I believe are two of the Kanban Method’s most differentiating features. They’re more differentiating than even the sticky notes and WIP limits, and that’s saying something!

Kanban is humane, not just because it has noble ideals, not just because it leads to better conditions for people, but because it is designed to be implemented in a way that is consistently respectful. Noble aims don’t justify unsafe organizational transformations. The goal of better conditions in the longer run doesn’t excuse riding roughshod over people in the interim. To my knowledge, few methods can claim Kanban’s internal integrity in its approach to implementation.

Also, there is something uniquely respectful in start with what you do now. It respects the journeys of all the people—past and present—who have brought the organization to where it is now. For all the good and the bad, it respects context, it celebrates survival, and it makes it easier to assume—however naively optimistic an assumption this might be—that people mostly did their best. I like that.


Next up: 10. Patterns and Agendas. Previously: 8. Agreement. Start from the beginning: 1. Transparency.

Kanban from the Inside: 8. Agreement

The eighth in a roughly weekly series of short excerpts from my book, Kanban from the Inside.


The Kanban method’s second Foundational Principle is very direct:

FP2: Agree to pursue evolutionary change.

In just a few more words: Agree that change is necessary; agree to pursue it with an evolutionary strategy.

The word pursue is very well chosen. So much stronger than adopt, it evokes the energy and tenacity to counter any complacency, and it reminds us that it’s an ongoing process. Pursuit combines challenge and commitment.


I’d like to remind you that the agreement principle (FP2) starts with the word agree. Don’t take for granted the people involved, nor those likely to be impacted by it.

By way of analogy, I’m reminded of a bumper sticker [1] that would be quite familiar to anyone who lived in the UK during the late ’70s and for many years afterward:

A dog is for life, not just for Christmas

Agreement is not just for the kickoff meeting! Most of the changes that will be catalyzed by Kanban will stick only through agreement, so start as you mean to go on. Part III will help you with this; it describes a highly repeatable approach designed to generate agreement in practice, not just the slippery agreement in principle that falls away as soon as there is work to be done.

[1] Clarissa Baldwin. 1978. The Dogs Trust. http://www.dogstrust.org.uk/az/a/adogisforlife/


Next up: 8. Respect. Previously: 7. Understanding. Start from the beginning: 1. Transparency.

Kanban from the Inside: 7. Understanding

The seventh in a roughly weekly series of short excerpts from my book, Kanban from the Inside.


A Pattern for Purposeful Change

Let’s make the understanding principle more concrete:

FP1 (expanded): Start with what you do now, understanding

  • The purpose of the system
  • How it serves the customer
  • How it works for those inside the system
  • How it leaves customers dissatisfied and workers frustrated
  • How it can be changed safely

This contains practice as well as principle—it’s actually a highly distilled summary of , the implementation approach described in Part III. It works both for Kanban’s initial introduction and for subsequent changes.

Understanding the purpose of the system takes us from what we do now to why we serve our customers in the way we do. For my former team in Budapest, it took us from “We build and support energy risk-management systems” to “We build and support the systems that enable our company to help our customers manage their energy risks.” For a team that would struggle to get past “We are software developers” (and we definitely weren’t one of those), understanding purpose could be a big step.

We take the dissatisfactions and frustrations as indications either that there are obstacles preventing the system’s purpose from being fulfilled, or that we don’t yet understand that purpose well enough. Acknowledging them, their possible root causes, and their effects is a key first step toward making impactful change.


Next up: 8. Agreement. Previously: 6. Leadership. Start from the beginning: 1. Transparency.

Kanban from the Inside: 6. Leadership

The sixth in a roughly weekly series of excerpts from my book, Kanban from the Inside. Chapter 6 on leadership is pivotal – it brings together the preceding five values and the three still to come.


What if [Kanban’s at every level] kind of leadership doesn’t come naturally to your organization?

Fortunately, Kanban doesn’t leave you to solve this problem on your own. When change is stimulated, it creates leadership opportunities both large and small. The more widespread, repeatable, and visible this process is, the more positive its impact on your organization’s culture will be.

Opportunity Everywhere

Let’s test that. Where can we find these leadership opportunities?

  • Transparency: In knowledge work, things don’t make themselves visible or explicit by themselves; leaders choose to make them so. This is as true in the small details—the wording of a policy, for example—as it is in the bigger things, such as institutional feedback loops.
  • Balance: Where are we overloaded, and why? Are our pain points obvious, or does the volume of work hide them? Is the mix of work right? There is leadership opportunity in asking these questions as well as in the decisions that may follow.
  • Collaboration: Making an introduction, reaching out, sharing a problem, noticing how people interact—all of these can be acts of leadership.
  • Customer focus: It takes leadership to acknowledge that the process may be ineffective at discovering and meeting real customer needs.
  • Flow: Are you seeing it? What is stuck today? Where do blockages repeatedly occur? Why is that? These are everyday questions of leadership.
  • Leadership: Encouraging leadership in others can demand real leadership on the part of the encourager. Kanban’s kind of leadership not only spreads, it reinforces itself.

What conditions are needed if that kind of leadership is to thrive? The next three chapters cover the remaining three values, namely the leadership disciplines of understanding, agreement, and respect. These get to the heart of the Kanban Method’s approach to change.


Next up: 7. Understanding. Previously: 5. Flow. Start from the beginning: 1. Transparency.

Kanban from the Inside: 5. Flow

This post is the fifth in a roughly weekly series of excerpts from my book, Kanban from the Inside. Chapter 5 is on flow. Like the preceding chapter, it is inspired by the third of the Kanban Method’s core practices, Manage flow.

CP3 (expanded): Manage flow, seeking smoothness, timeliness, and good economic outcomes, anticipating customer needs.


Organizations often get deeper into trouble because people think that the answer is to keep trying harder. They think that better project management will fix a problem of capacity management (scapegoating project managers, meanwhile), that stronger functional management will improve end-to-end performance (when it can easily make it worse), or that people should just try to do better (when the system is fundamentally unreliable).

Kanban’s unusual solution to this problem isn’t to address head-on the roles of project management and functional management; certainly it does not set out to replace them immediately with other things. Instead, it gives managers (and others, too, of course) the tools to see work and how it flows in new ways, together with controls on WIP that impact dramatically on problems of delay and unpredictability. Allowed the right scope, the improvements and the necessary new thinking grow hand-in-hand. If roles then need to change, fine!


It would be a mistake to think that managing flow is only a matter of removing impediments as they arise. Typically in knowledge work, we see work items vary widely in both content and value, and we see the overall workload varying greatly over time. This means that there will always be a place for managing work proactively:

  • Unusual risks and dependencies must be identified early and managed effectively.
  • Looking toward the medium term, anticipated workload must be met with adequate capacity.
  • Longer term, entirely new capabilities might be needed.

Being committed to self-organization doesn’t mean that you must always shy away from managing the most important work items more carefully. Not all work items are alike, and some are considerably more deserving of management attention than others. Dates—meaningful dates, at least—should be met. And when it’s justified by the business opportunity, it’s perfectly valid to sacrifice a little predictability and allow high-value items to jump the queue.


Next up: 6. Leadership. Previously: 4. Customer Focus. Start from the beginning: 1. Transparency.

Kanban from the Inside: 4. Customer Focus

This is the fourth installment in a roughly weekly series of short excerpts from my book, Kanban from the Inside. Chapter 4 covers the fourth of the Kanban Method’s nine values, customer focus.


Core Practice 3: Manage Flow

Is this a mistake? How do we get from Manage Flow to customer focus? Indulge me for a moment—let me cheat a little, expanding the wording of this core practice to express more fully what this practice really means:

CP3 (expanded): Manage flow, seeking smoothness, timeliness, and good economic outcomes, anticipating customer needs.

This chapter focuses on customer needs and how to anticipate them better. Smoothness and timeliness are covered in the next chapter, on flow. Keep in mind “good economic outcomes” as you read both chapters; economic decision-making is covered in Chapter 15.


Why Customer Focus?

Task focus, role focus, team focus, project focus, product focus, company focus, technology focus . . . the list goes on. So many ways to lose sight of what we’re in business for!

Just as it does inside the delivery process, effectiveness upstream depends on the values we’ve explored so far:

  • Transparency: The system must make visible the difficult choices that need to be made. The decision-making rationale should itself be explicit. Decisions are the focus of feedback loops (prioritization meetings, for example).
  • Balance: The amount of WIP in the system is controlled, both to maintain a reliable supply of high-quality ideas and to force timely decision making. If needed, additional control can be gained by allocating WIP by customer, budget line, risk category, strategic initiative, and so on.
  • Collaboration: The work of qualifying items for further development is shared among the originators of those items and the people who will service them. Instead of sucking risk into the system prematurely, all parties (and there may be several involved) keep their options open until commitment is timely.

Let’s see what customer focus adds:

  • Whose needs do we think are met by these ideas?
  • Are we meeting needs fast enough?
  • What is the data telling us? What are people telling us?
  • What might lie behind those needs?
  • What needs might be going unmet?
  • How can we test that?

In short: Can we develop a better sense for what will be needed?


Anticipating Needs

If there’s a single idea that I’d like you to take away from this chapter, it’s making the mental shift away from doing what is asked, taking orders, fulfilling requests, meeting requirements, and so on, and reorienting the process toward discovering and meeting needs. It’s a shift from an internal perspective (what we think we know) to an external one (what’s still out there to be discovered). It’s also a shift from the past (what we’ve been told) to the future (when the customer’s need will be met).


Next up: 5. Flow. Previously 3. Collaboration: Start from the beginning: 1. Transparency.

Featureban updates, March ’15 edition

I’ve recently facilitated a number of Featureban sessions:

This coming Thursday evening I’ll be in Derby, the guest of Agile Derby. It’s not often that I get to do Kanban-related stuff so close to home, so I’m delighted!

I’ve made some updates to the deck:

  • Encouragement in slide 5 for players to discuss their moves in a “standup” meeting.
  • “One of” and “Both” in slide 5 and what is now slide 8 are shown in bold. These are easily missed if not emphasised by the facilitator.
  • An additional debrief slide after each of the first two rounds, mentioning over the course of the two rounds all six core practices and their corresponding values (five out of nine). Feedback on this change has been very positive.

In the second debrief, facilitators should draw a distinction between visual management and the operation of true kanban systems. I make a point not to mention “collaboration” until it is mentioned from the floor (which it will, without fail). The likely mention of “multitasking” is the invitation to discuss how we have succeeded in limiting work in progress across the whole flow, and why that’s important.

A French translation is now available and a German translation is in the works; ping me for an introduction if you need one. If you’d like to make a new translation or any other derivative work you don’t actually need my permission (Featureban is published under a sufficiently friendly license) but do drop me a line if you’d like the original PowerPoint slides rather than the PDFs (see the Resources link above).