Kanban from the Inside: Understand the Kanban Method, Connect it to What You Already Know, Introduce it With Impact

Review

Kanban from the Inside introduces Kanban through a system of nine values that provides a fresh perspective on the method. If you’re familiar with Kanban, this will give you deeper insights about the method. The values – Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement, and Respect – are presented while being related to Kanban’s Core Practices and Foundational Principles.

However, after this first part, the book falls short on the expectations. With a good introductory part I, parts II (which covers outside influences important to Kanban practitioners) and III (which covers the implementation of the Kanban Method) seems to lack the same deepness from the first part.

Not that there are not good insights in parts II and III. On the second part, the chapters on Systems Thinking, Economy Approaches to Flow and Smaller Models are very insightful.

The chapter 11, on Systems Thinking, presents the Double-loop learning model and the need to engage in deep learning with the goal to remain competitive indefinitely. The chapter 15, on Economy Approaches to Flow, relates the Cost of Delay with the language of classes of services and presents a simple heuristic that simplifies the prioritization decision process. The chapter 17, on Smaller Models, explains how to read a Cumulative Flow Diagram, which helps to interpret visually the Little’s Law (which gives support to make changes in a kanban system).

The part III makes me think that this should not be a recommended introductory book for beginners. The implementation guidance is just too fast and shallow, probably because of the way this book is structured. Although not structured around the STATIK model (Systems Thinking Approach to Introducing Kanban), the David Anderson’s Kanban book provides a more straightforward recipe for introducing Kanban in an organization. After reading David Anderson’s book, Kanban from the Inside will give you a more humane understanding of the method, which will help you to discover other opportunities for improvement.

Some quotes

With our kanban board, we have made something quite special—a practical pull system for our invisible commodity, knowledge work.

Look at the quality of interactions around you. Do you see key processes that are hampered by low-quality interactions, delays, back-and-forth conversations, rework, and frustration? If that’s not bad enough, do you see individuals and teams who seem rarely to have the opportunity to engage in high-quality collaboration? Identifying these might be the trigger for something special.

Creative knowledge work isn’t just about what we already know. It is (and I use a piece of technical jargon quite deliberately) a process of knowledge discovery. Use your kanban board to keep reminding you: “What don’t we know?”

Upstream Kanban is about organizing needs and developing ideas so that there are always good choices on offer when delivery capacity becomes available.

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).

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).

Managers don’t determine how the system behaves; they merely interact with it.

This unlearning and relearning is hard work! Realistically, no one has the energy to engage in double-loop learning all the time, but neither can an organization expect to remain viable if it remains complacent for long. Somehow, the conditions for frequent double-loop learning must be created.

I have noticed that software projects are often managed under the assumption that the constraint is (and always will be) the development team. Specifically, keeping the developers busy is what counts, even when it is clear that high-quality requirements are in short supply, or that the team’s delivery capability is not being matched by the customer’s ability to realize the planned benefits of the new functionality they receive. Only by challenging these assumptions can we be sure that management attention is in the right place.

Hybrid solutions may be appropriate. For example, if a defect is discovered in a feature that has been released but is still in its validation state or warranty period, its still-visible ticket can be flagged in place and a new work item raised for the rework. This accurately represents two important facts: We have a defective feature out there in production, and its fix is progressing through the system.