Kanban from the Inside: 13. Agile

In this series of short excerpts from my book Kanban from the Inside we’ve reached chapter 13, on Agile. Following the pattern of the preceding two excerpts, we’re skipping the main content of the chapter and reproducing some of my main conclusions.


Kanban and Agile

Compatibility

We’re often asked, “Is Kanban Agile?” To anyone who understands Kanban as the start with what you do now method, that’s a slightly odd question, but still, it deserves a respectful response.

When “Agile” is used as an adjective like that, it’s worth drilling down a bit to find out what’s really meant by the question:

  • Are the values of Kanban and Agile compatible? Yes, absolutely! There is a basis here not just for comparison but for integration.
  • Can Kanban help “improve agility” or make things “more agile,” improving an existing software development process—explicitly Agile or otherwise—in directions entirely consistent with Agile values and principles? Not only is the answer to that question a resounding “yes,” it is what the method was first developed to do.
  • Is Kanban, in the words of the manifesto, a way of developing software? No. We are splitting hairs, perhaps, but in this sense it is misleading to describe Kanban as an Agile method. It isn’t a development process (or any other kind of delivery process) at all; there is nothing in the definition of the method that ties it to software. It is a management method that is broadly applicable to creative knowledge work, with a particular focus on organizational change.
  • Is Kanban part of the Agile movement? Kanban’s community identity makes sense both inside and outside the Agile movement (note that both communities have a similar relationship with Lean). Some people seem to be troubled by that ambiguity, but actually it’s helpful and necessary. Ideas find room to grow and flourish in their own communities, and when the time is right, there is ample opportunity for cross-fertilization. And to providers of supporting services (trainers, coaches, consultants, and so on), the ability to choose from multiple identities can be very convenient.

At the level of methods and practices:

  • Does Kanban work with iterative methods, Scrum in particular? Yes, and in the case of Scrum, the combination even has a name—Scrumban (described in Chapter 16). Kanban can work both inside Scrum, where it mainly drives team-level improvement, and outside it, where it helps a deliberately team-centric framework address the challenges of scale.
  • Doesn’t Kanban mean abandoning iterations and other elements of Scrum? This is a serious misconception. Kanban is the start with what you do now method; we would be the first to warn you not to drop aspects of your current process in an uncontrolled fashion. However, it would be dishonest of us to pretend that your pursuit of flow won’t at some point test your commitment to timeboxes, story points, and the like. How you and your organization deal with that will be a matter of choice.
  • Do Agile and its methods and practices represent important models for Kanban practitioners? Most definitely yes—it seems almost unthinkable that an effective Kanban practitioner working in the software development domain would get very far without a deep understanding and respect for Agile.

When to Use Kanban

One question remains: In an Agile context, when and how might Kanban help? More questions about your current situation will help answer that:

• Is Agile’s principle of sustainable pace still just an aspiration? Are people still overburdened in a process that doesn’t seem to fit all that well? Could Kanban-style transparency (Chapter 1) and balance (Chapter 2) provide some relief?

• Is your collaboration (Chapter 3) focused mainly inwardly? Does customer focus (Chapter 4) suffer as a result of over-protective intermediation around the team or of excessive internal focus on the technology, the product, or the team?

• Are team-centric and process-centric approaches failing to deliver needed gains in end-to-end flow (Chapter 5)? Are local gains even making things worse elsewhere?

• Are leadership (Chapter 6), understanding (Chapter 7), and agreement under-appreciated? Is respect (Chapter 9) too easily forgotten when the big decisions are being made?

It is hard to change how organizations tick. Agile adoptions face that challenge all the time, and it should come as no surprise that issues such as these arise. Whether you are just planning to set out down that road or are already well along the way, the start with what you do now method is there to help, not to judge.

If your wider organization is ready to make the kind of changes called for by a hard and disruptive [1] Agile adoption and you can be very sure of success, it’s possible that you might not need Kanban. For organizations unprepared to take that risk, Kanban offers an alternative path to agility, an open-ended journey of co-evolution in which better ways of doing things are waiting to be discovered.

The Agile Model

Don’t be fooled by [the preceding part of this chapter’s] necessarily process-centric treatment of FDD, XP, and Scrum. With any of these methods you can go through all the iterative motions and still find that:

  • People serve the process, not the other way around.
  • The product is driven by the loudest internal voices, not the emerging needs of actual customers.
  • Lots of work gets done without the end product ever being used for real.
  • Changes in direction cannot be contemplated, let alone accommodated

On its own, process gets you only so far. If the aim is to be Agile, the Agile values need to be evident. Technicalities aside, if it’s working neither for the team nor for the customer, call it something else!

Agile has been and still is a game-changer. It has legitimized evolutionary delivery, wresting control of swathes of the software industry away from a plan-driven style of project management that was often ill-equipped to deal with uncertainty. No self-respecting Kanban practitioner can afford to ignore it.

[1] http://www.controlchaos.com/storage/scrum-articles/Scrum Is Hard and Disruptive.pdf


Next up: 14. TPS and Lean. Previously: 12. Theory of Constraints (TOC). Start from the beginning: 1. Transparency.

Kanban from the Inside: 12. Theory of Constraints (TOC)

In this series of short excerpts from my book Kanban from the Inside we’ve reached chapter 12, the second chapter of Part II (Models). As last time, this excerpt comes from near the end of the chapter. I must therefore explain for the uninitiated that POOGI is TOC’s Process Of Ongoing Improvement (acronyms are unavoidable here I’m afraid).


POOGI and the Five Focusing Steps

Like many Kanban trainers, I like to reference POOGI and the Five Focusing Steps when I teach Kanban. I particularly remember one class in which a small company’s entire middle management layer was in attendance. It dawned on us that if the company had a constraint (and surely it must), it had to be represented by one of those managers in the room.

All eyes turned to the finance manager. Everyone saw how important it was that she got what she needed when she needed it. Her colleagues resolved to remove from her and her small team its overhead of chasing for paperwork, clarifications, and corrections. Special priority would be given to activities that brought in cash. Everyone in the room determined that things were going to be better, not just for that team but for the company as a whole.

That’s a great story, but Kanban is not “POOGI with kanban boards.” The constraint—typically presented as some kind of bottleneck—is rarely the Kanban practitioner’s first line of attack. Get past the delicate issue that no person or team wants to be labeled a bottleneck, and you still have the problem of identifying them. How sure can you be of the location of your bottlenecks when WIP is high, there are orders-of-magnitude differences in lead times between work items, people can easily move between activities, and (give or take) everyone gives the impression of being equally busy?

Perhaps bottleneck should be added to that list of tools, concepts, and metaphors that don’t translate from manufacturing work to knowledge work quite as readily as some would have you believe. Chapter 14 identifies some more of those.

The bottleneck may not enjoy a first-class status in the Kanban Method, but POOGI will long continue to be taught. It promotes understanding, and there is still power in the idea that you need to keep on identifying and addressing your system’s constraints, especially when your mind is open to the possibility of much broader constraints—lack of knowledge, feedback, learning, trust, and so on, or the attachment to unhelpful ways of thinking.


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

 

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.