Kanban from the Inside: 21. Classes of service

This week’s excerpt comes from the chapter’s conclusion. If you think that classes of service is just a technical topic that has no human (or humane) dimension, think again!

Toward a Healthy Mix of Work

This much should be obvious: You can’t plan to have everyone occupied 100% of their time on fixed-date work, allow them to be interrupted by expedited items, and still expect predictability. Even without the interruptions, 100% utilization on work that must meet stringent deadlines is a recipe not for efficiency, but for extreme unpredictability and delay, not to mention pain at the human level. Systems need slack if they are to absorb variation rather than accumulate it, and people need it too.

You might be wondering what a “safe” (or “humane”) utilization level might be. 90%? 80%? I believe that this approaches the problem from the wrong direction. From direct experience as a manager, and from clients sampled by myself and David, fixed-date items need make up no more than 20% of the workload of most organizations; often, it can be significantly less. After allowing (say) 10–20% for intangible work, and a realistic provision for expedited and other unplanned work, the biggest category of all should be the high-value, urgency-driven work. This is exactly as you would hope it to be, assuming that you seek to maximize the flow of value to the business. Happily, predictability is achievable, too, thanks to the presence in the system of work items that can safely be delayed when time-critical work needs to take precedence.

Classes of service and other categorizations enable some broad-brush prioritization decisions to be made independently of potentially contentious decisions about individual items. Making these explicit creates the opportunity both to align them to wider corporate priorities and to match them to customer needs. So long as there is the short-term flexibility to trade between categories, it should be possible to satisfy both constituencies.

For your workshops, questions like these help guide the overall mix of work in the right direction and prompt discussion about system design:

  • What proportion of our portfolio is necessarily date-driven? Are we entering into date commitments unnecessarily, and if so, can we begin to bring this proportion down? Do we make reference to available capacity when scheduling? Are we able to respond when dates are under threat?
  • How much capacity do we need to hold in reserve for expedited and other unplanned work? What steps can we take to reduce and/or limit the amount we are servicing at any given time?
  • Are we doing enough intangible work? What space do we give people to explore better ways of doing things?
  • What capacity remains for standard, urgency-driven work? Do our systems reliably bring the right items to the front of the queue first?

If these questions make you uncomfortable, perhaps they should! Could it be that people are over-organized—“projectized” or siloed? If your organization lacks the ability to self-organize when and where it most needs it, it is paying a heavy price.

I have in the past described Kanban’s ability to deal with variety as one of its “killer features.” Arguably, the way STATIK encourages organizations to embrace variety is even more powerful. If only it were better known!

Next up: 22. Design kanban systems. Previously: 20. Model workflow. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and Kindle at amazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is available via the djaa.com store also.

Kanban from the Inside: 20. Model workflow

The end is in sight – this the 20th excerpt from my 23-chapter book. This week, two excerpts for the price of one!

This chapter looks at three different approaches to modeling the workflow that our kanban system is going to support:

  1. Sketching it out
  2. Top-down decomposition
  3. Bottom-up organization

It’s important to remember that the result that we’re working toward is a working kanban system, not a static model. It’s best not to get too attached to the products of this exercise—they will quickly lose their value once the system begins to evolve.

I’ll keep this simple by assuming that there is just one main workflow involved. If you have more than one, you can take each workflow in turn or use one as the baseline by which the others are described.


Before we move on, here are some good ways to check and improve what you have so far:

  • Quickly combine approaches to validate your model, such as:
    • Produce a sketch from your top-down or bottom-up model.
    • Make sure that actual work items map to your sketch or top-down model, then use the “what does this item need?” questions.
    • Consider whether it would be helpful to group, consolidate, or break down categories.
  • Check that queues are adequately represented and that you know where your commitment points belong.
  • Look to see where the dissatisfactions and frustrations discussed in Chapter 18 might originate.
  • Identify the kinds of knowledge discovery associated with each active state.
  • Seek to de-emphasize functional organization.
  • Present it to other people.

None of this should take long. Remember, sketchy!

Next up: 21. Discover classes of service. Previously: 19. Analyze demand and capability. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.


Kanban from the Inside: 19. Analyze demand and capability

We’re two chapters into Part III and getting into the nitty-gritty of Kanban implementation using the STATIK model. This week’s excerpt comes from the chapter introduction.

The previous chapter was all about context and perceptions, mostly keeping implementation considerations off the table. This chapter is about gathering some specific qualitative and quantitative facts about the current process that will inform the design of kanban systems.

If you can do this collaboratively, you will further reinforce the work of the previous chapter. If that’s not practical, you will need to share and review what you find after you have done the legwork.

This analysis needs to generate both qualitative and quantitative understanding. Qualitatively:

  • Understanding the different types of work involved will help you to identify the different variations in workflow that need to be managed.
  • Understanding the different sources of work will help you to prepare for, shape, and manage demand as it arrives.
  • Understanding why the work is needed will help you to understand the types of risk involved so that they can be managed appropriately.


  • Understanding the quantity of work involved will help you choose a manageable granularity to visualize and control it.
  • Understanding the gap between actual process capability (measured in terms of delivery rates, lead times, predictability, etc.) and the expectations of customers and the wider organization will highlight what kinds of improvements are needed.
  • Quantitative analysis of work recently delivered, currently in progress, and waiting to be worked on may tell us where improvements are most likely to be found.

Next up: 20. Model Workflow. Previously: 18. Sources of dissatisfaction. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

Kanban from the Inside: 18. Sources of dissatisfaction

We’re at the start of Part III, which explains how to implement Kanban using the STATIK model.

Last November (two months after Kanban from the Inside was published, I posted here Understand motivation for change. Bear in mind as you read this week’s excerpt that any major revisions of the book will very likely involve a change of title to this chapter. Possibly one of emphasis too!

Any kind of deliberate change needs two key pieces of context:

  1. Its scope—some boundary around what we do now, within which the change will be focused—the “what” of the change
  2. Its objective—an expression of what we hope to achieve from the change, relative to how things currently are—the “why” of the change

In the beginning, it is unlikely that either of these will be known in any great detail. Don’t let that worry you unduly—it’s much better to start by exploring the problem space than to try to nail down solutions prematurely. And let’s be realistic about this: Scope and objectives are often determined more by what people feel is organizationally possible than by what is necessary. As change agents, we can find this very frustrating, but it’s okay: Let’s start with what’s possible; the impossible we can do later!

We start with sources of dissatisfaction because they lead very quickly to something much more positive: a set of things that people might want to achieve. Additionally, when we take the trouble to explore properly why these dissatisfactions are a problem to people, important issues like scope and sponsorship tend to become much clearer.

This is not the time for isolationism. You will need to talk to people! Be prepared to go out and meet them or to bring them in; make them part of the conversation.

Two Perspectives

Given even just a rough idea of scope, we can easily identify two quite different perspectives:

  1. The perspective of those working in the system—their first-hand understanding of the system itself, their impressions of how it is perceived externally
  2. The perspective of those outside of the system (customers, higher-level management, providers of related services)—how it helps to meet their broader needs (and what those might be), their impressions of how their immediate needs are serviced

Because we are getting people to look both inward and outward, it is no disaster if we later decide that we got the scope boundary wrong. Wherever we place that boundary, we learn a lot a by reconciling the two perspectives and accounting for any important differences. Opinions on the placement and nature of the boundary may be revealing, too.

Next up: 19. Analyze Demand and Capability. Previously: 17. Smaller Models. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

Kanban from the Inside: 17. Smaller Models

The purpose of chapter 17 is to cover a number of models that help explain things we’ve seen already in parts I and II or might need for Part III (Implementation). I’ve thrown in a few bonus items also! All together:

  • Little’s law, a beautifully simple formula with a nice visual interpretation (and an excuse to revisit cumulative flow diagrams)
  • The Satir change model, the late Virginia Satir’s powerful description of the change process
  • Two coaching models, the very useful thinking tool GROW, and Toyota’s A3 (first mentioned in Chapter 14)
  • Jeff Anderson’s Lean Change Canvas via a digression into the Pyramid Principle
  • Various models of facilitation, including games
  • Two models of leadership and collaboration, T-shaped leadership and triads

This week’s excerpt introduces the last of those.

Models of Collaborative Leadership: Triads and T-Shapes

The Triad is a very simple model of collaboration and collaborative leadership that has been practiced deliberately in a surprising variety of places. Thanks to Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization, the book by Dave Logan, John King, and Halee Fischer-Wright, we understand its applicability to corporate and community life. Triads appear in some churches in the form of prayer triplets (my wife, Sharon, has been a member of several of these); the model was even practiced by the KGB!

A triad connects three people, united by some common purpose. Sometimes it is the result of one person introducing two previously unconnected people; sometimes they are formed to perform some specific task. Effective triads obey two rules:

  1. Each member takes some responsibility for the relationship between the other two members, providing strength.
  2. Growth comes not by turning triads into quads, but by forming additional triads involving one or two members of existing triads, thereby creating networks.

I’m the kind of person who approaches a “networking event” with dread, and the triad model is just about the only form of networking that works for me. I have learned to make a point of introducing people whom I know to share some common interest. That’s rewarding in itself, but often I reap double or triple the benefit in the form of fruitful collaboration and new introductions.

Triads express collaborative leadership when they are used deliberately to share knowledge, to create opportunities, and to form bridges between different parts of the organization. I have encouraged graduate recruits to form long-lasting triads and to help one another to grow their networks from them, and I have used them short-term to solve specific problems.

Morten Hansen describes T-shaped management, which is somewhat analogous to the T-shaped people I alluded to in this book’s preface. His T-shaped managers encourage collaboration in two quite distinct ways:

  1. Much in the manner described in Chapter 3, close collaboration inside their part of the organization
  2. Addressing the downsides of collaboration described at the close of Chapter 3, “disciplined” collaboration across the wider organization

The key to Hansen’s model is that this second kind of collaboration is required to be purposeful and effective; it is not about networking for its own sake, and it is expected to deliver results in healthy proportion to the effort expended. Ill-disciplined collaboration may be worse than no collaboration at all.

Both models are entirely compatible with Kanban’s at every level kind of leadership. Triads don’t need to respect organizational boundaries at all, and those T shapes can emanate from anywhere. We can all do it.

Next up: 18 Understand sources of dissatisfaction. Previously: 16. The Kanban method. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle on amazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

Kanban from the Inside: 16. The Kanban Method

Chapter 16 of my book Kanban from the Inside condenses into a single chapter the following:

  • Some historical context
  • The principles and practices of the Kanban Method
  • “Contextualized Kanban” — Personal Kanban, Portfolio Kanban, and Scrumban
  • So-called “enabling concepts” —values, agendas, the Kanban Lens, etc
  • Implementation guidance —an overview of STATIK, to be covered in part III (chapters 18-23)

This week’s excerpt comes from that “Contextualized Kanban” section.


Scrumban is a name coined by Corey Ladas, for what happens when what you do now is Scrum and you apply Kanban.

I stress again the cautions of Chapter 13: Kanban does not mean recklessly throwing out all of your Agile discipline; rather it’s a transformative process that takes time, thought, care, and collaboration.

This progression is typical:

  • Already practicing a degree of visualization, the team organizes work according to its “done-ness.” This extends beyond “code complete,” “demo-able,” or “potentially shippable” to cover acceptance, deployment, and customer validation states.
  • Increasingly, standup meetings are organized around the board.
  • Already limiting work-in-progress through the sprint mechanism, the team pays more attention to the amount of work started but not yet finished. As a result, they start to see work items getting completed sooner. Immediately or after seeing the board operating well, explicit WIP limits may be introduced.
  • With work items completed sooner and more visibly, greater attention is given to the later stages of the process. Impediments to continuous delivery start being addressed. The nature of the sprint begins to change as releases are planned independently (if they need much planning at all).
  • Having decoupled releases from sprint planning, the system now easily accommodates work of different types and speeds. The team pays attention to the cost of delay of individual items and to the mix of work overall. Mid-sprint changes become much easier to accommodate; classes of service may be offered.
  • The rhythm of sprint planning continues, but the meeting itself gets easier. Estimating the right amount of work for the sprint seems less important; it’s enough to ensure that there is sufficient work of high enough value and quality and that the riskiest items have been identified and broken down where necessary.
  • With the need for customer validation made more visible, new feedback loops begin to emerge.

Different attitudes toward the Scrum practices and roles will of course lead to different outcomes. It’s not unusual for teams to go through changes of the kind described here and for them still to identify themselves with Scrum. That’s completely fine with us—it’s “Kanban with,” not “Kanban versus.”

The team I’m currently [mid 2014] working with as its interim development manager is a long way down this path. The planning rhythm is still there and I’m in no hurry to see it disappear. The highlight of my working fortnight is the “Show and Tell” (the sprint review), a lively meeting in which the project team is outnumbered by customer representatives and outside observers (as a “digital exemplar,” one of a number of pioneering citizen-facing projects delivering services online for UK Government departments, we often receive visitors from other departments and public agencies interested in how we do things). Not only do we review progress and show what we’ve recently built, we often review pertinent videos of outside customers interacting with the live system or with prototypes. These are highly motivating—sometimes even moving—and the shared experience adds to its impact.


Next up: 18 Understand Sources of Dissatisfaction. Previously: 15. Economic approaches to flow. Start from the beginning: 1. Transparency.

Kanban from the Inside: 15. Economic approaches to flow

We’re at chapter 15 of Kanban from the Inside, on economic approaches to flow. This excerpt expands on the third of three principles of Real Options as identified by Chris Matts and Olav Maassen [1, 2]:

  • Options have value
  • Options expire
  • Never commit early unless you know why

Never Commit Early Unless You Know Why

This looks like another truism, but it is well worth repeating. How different would most projects look if for every planned feature someone asked this question [3]:

What would have to be true for this option to look fantastic?

Where the answers to this question are unknown, a new layer of exploratory options can be generated.

Typically, the project provides the perfect mechanism for avoiding this question. Scope, duration, and cost are all decided before the questions are even asked, let alone answered. By design, changes to any of these cause drama and stress!

Contrast that to an options-based approach. Instead of a predetermined project backlog, we have a portfolio of options, a growing pool of uncommitted ideas that may or may not come to fruition. Options get exercised—that is, work gets pulled—when they will generate the most valuable information relative to all their alternatives.

Options thinking also does something interesting to risk management. Outside the development process, uncommitted options remain in the hands of those best placed to manage them, for example, those with the market knowledge to maximize opportunity. Once inside the system though, the risks change in both nature and ownership—there are expectations to meet. There is more than meets the eye in the act of pulling of work across these boundaries—it creates obligation and transfers risk. It is not to be done lightly.

[1]Chris Matts and Olav Massen. 2007. “Real Options” Underlie Agile Practices (InfoQ)
[2] Chris Matts, Olav Massen and Chris Geary. 2013. Commitment Hathaway te Brake Publications.
[3] Roger L. Martin, in Lafley, A. G. and Roger L. Martin. 2013. Playing to Win, How Strategy Really Works Boston: Harvard Business Press.

Next up: 16. The Kanban Method. Previously: 14. TPS and Lean. Start from the beginning: 1. Transparency.

Coming soon: Agendashift

[Update: Now cross-posted to Agendashift’s new blog. View on blog.agendashift.com]

Imagine a change process based on choice and collaboration:

  • You (an individual or team) take an assessment of your choosing, invite a coach to facilitate one with you, or opt to participate in a survey
  • You explore online an analysis of your own inputs and the aggregated inputs of your colleagues, identifying strengths, weaknesses, leading and lagging areas
  • You identify the prompts or categories that best describe your collective agenda for change
  • You track actions through to completion until it’s clear that they have taken hold and are delivering the benefits expected

No emailing of spreadsheet-based questionnaires. No being left wondering what’s happening to your inputs. No imposition of priorities from on high. No failure of ownership and follow-through. These are my “itches to scratch”. Whether you’re a consultant, a client, or managing without external support, Agendashift can help you too.

Right there are Agendashift’s four A’s: Assessment, Analysis, Agenda and Action. Of course it doesn’t have to be as linear as that: given time, Action should dominate, kept on track with periodic recalibrations from the other three.

You’ll see a free version launched in the next few weeks that anyone can try without obligation. A little after that, paid accounts will bring the ability to design new assessment templates and to manage client/team workspaces.

Agendashift will launch with a “Values-based delivery” template adapted for public consumption from my book with the help of some much-appreciated collaboration. If you have ideas for other templates (your own practice’s tools perhaps, or more specifically Agile or Lean than mine), do get in touch.

Meanwhile, leave a comment, follow @agendashift on Twitter or sign up at agendashift.com to be sure of receiving launch news.

Kanban from the Inside: 14. TPS and Lean

I really enjoyed writing this chapter! My goal was to illustrate the extent to which things can look radically different and yet share the same underlying principles and philosophy. The excerpt below comes after a description of a production line at Toyota; the “TPS” of the chapter title is the Toyota Production System.

Beyond the already-familiar “Kanban“, a number of Japanese terms are introduced. I use them freely in this chapter but rarely elsewhere (and I explain why).

This [preceding] description is rather simplistic, but there’s enough here for some striking characteristics of the system to be noted:

  • All three tools (kanban, heijunka, and andon) are examples of visual management.
  • Inventory of all kinds is limited. Neither basic supplies nor WIP (the subassemblies, or partially-built products) will be replenished until equivalent amounts have been pulled from downstream.
  • Even though, perhaps, it might seem more efficient to do so, the production line doesn’t work in large batches of similar items. Instead, it produces a variety of products spread over the course of the day.
  • Workers on the production line would rather stop the line (for everyone) than allow work of inferior quality to proceed.
  • This system and the kanban boards from Part I work very differently. On the production line, the kanban [1] are sent upstream to signal that there is demand to be fulfilled. On our boards, the cards represent work items as they flow downstream; signals are implied by the gaps between the actual amount of work in progress in each state and the corresponding WIP limits.
  • The heijunka box and our kanban boards both allow the mix of work to be managed.

It seems perverse, not only setting things up to work in this deliberately difficult and seemingly inefficient manner, but empowering workers to bring it all to a halt at any time! Clearly there must something special about the company’s culture for this to work at all, but why would they choose to do things this way?

TPS and Lean in Perspective

To answer that question you must understand TPS as a magnificent example of systems thinking.

It starts with a vision, a true north that gives the direction for change:

  • Single-piece flow, in sequence, on demand, with zero defects; 100% value-adding activities and security for the people performing them

The technology does not yet exist to make it economical to run the entire production line in batches of one (which is what single-piece flow means), but the pursuit of this perhaps impossible vision is what propelled Toyota from its struggles in postwar Japan—where land, factory space, plant, and materials were all in short supply—to the global market leadership position that it now occupies.

The tools support one or both of two purposes:

  1. Satisfying customer demand as quickly and as smoothly as (currently) possible with the minimum amount of inventory
  2. Evolving the company to take it closer to its vision, harnessing the abilities of its entire workforce to smooth flow, reduce inventories, prevent defects, eliminate other forms of waste, and (not least) design new products that customers really want and that can be produced both profitably and sustainably

The two pillars of just-in-time and respect for people are shorthand for those sub-goals.

Often missed is this crucial point: The pillars and the tools can been seen in their proper perspective only once it is grasped that Toyota’s pursuit of perfection is a multi-generational challenge. Toyota works not only to build cars, but also to build the company capable of delivering on its vision.

Divorced from that kind of thinking, the tools of Lean can seem shallow. Without the tools, it can be even worse—too often we hear Lean reduced simply to a short-term focus on waste (perhaps to dress up exercises in cost cutting), or to continuous improvement (important, but very hard to sustain in isolation). The challenge of the Lean movement is to make sure that the thinking is packaged up with the tools so that people can apply them appropriately in context.

[1] “Kanban are like sheep” – One kanban, two kanban, …

Next up: 15. Economic approaches to flow. Previously: 13. Agile. Start from the beginning: 1. Transparency.

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


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.