Real-World Kanban: Do Less, Accomplish More with Lean Thinking

Review

Real-World Kanban is a hidden gem of the Kanban literature. It is a collection of four case studies which will give you ideas to experiment on your Kanban initiative.

All the case studies are presented in the same way: the challenge is introduced and then how they started the Kanban adoption, how the process worked, what lessons were learned, a comparison of now and before and how you can make your own improvements.

The first and last case studies are my preferred ones. The first exposes a Kanban adoption that aimed to improve the full value stream. It is presented an idea to track the customer adoption of a newly released product in the last column of the kanban board, named Customer Usage. If the product idea did not get popular, a root-cause analysis was performed to identify opportunities for improvements.

The last case study is a Kanban adoption outside of IT, in a back-office team. The main improvement was the creation of time to prepare new team members, making everyone on the team be prepared to handle the different work requests.

The only flaw this book have are the small illustrations of the Kanban boards. Both in the online Kindle reader and on the device, it is hard to see the details of them. Fortunately, the illustrations are available on the author’s blog (search the Internet for “10 kanban boards and their context”).

Despite this technical flaw, this book is an excellent source of inspiration. Case studies are not blueprints that should be copied but there are always similarities between contexts that can guide you into adopting one or other idea that can improve your current kanban system.

Some quotes

The key to sustained progress is not so much about implementing a process, but about developing a conducive culture for thinking people to help you evolve — people who care about what and why. Managers who fail to nurture thinking people as their key objective will just copy and paste others’ solutions. These managers tend to be oblivious when their current approach fails to work.

Your leadership is only as strong as the conversation you are ready to have.

Clarifying your intentions, improving the whole, having regular conversations with people doing the work, and taking part in problem solving are examples of leadership behaviors that can help you build up trust capital.

A simple example of improvements that go unnoticed when perfecting parts is rework. Rework, often due to poor quality, hides between functions and is often invisible to the participants in a value stream.

The ability to learn is an essential competitive advantage.

Evaluating output. We achieved three things by shifting management’s attention away from executing detailed plans and toward evaluating and improving output. First, managers focused on quality and flow efficiency instead of resource-usage efficiency. Second, and even more important, managers began to question and reflect on the effectiveness of the current way of doing things. Third, we now had transparency of the current state, which is the stepping stone to impacting the future.

This became our most important feedback loop — were we delivering things of value? If the customer did not like the product idea, it was put into the Oh Crap! area. Conversely, if the customer liked the product idea and it became frequently used, it would go into the Popular area. If an Oh Crap! event occurred, we brought together the concept owner, the teams involved, and the facilitator to perform a root cause analysis.

The first time I reviewed these prospective new product ideas, I noticed that 40 percent of them did not have answers to the key questions, which would be essential to have a meaningful conversation with the development team. For example, impact was often missing.

Less rework is related to better-prepared inflow, earlier validation, better test coverage, and the ability to mitigate the impact of late changes.

The ticket system turned out to do a pretty good job, and the team was able to use it as a documentation tool rather than as a communication tool. We learned to keep both the system and the board in sync by having the team update the issue tracker before moving tickets on the board.

A challenge to using the 5-Why technique (similar to our root cause diagram) is knowing when to stop. If the cause is outside your sphere of influence, then stop. Strive to do something small that improves things, even if it isn’t the perfect approach. Over time, the small things add up.

We all know that meeting a tight deadline can be done if you work a massive amount of overtime. But the team learned something else. Right after the final release, the project manager noted, “You know what? The team doesn’t do overtime anymore.” That was music to my ears. We had learned how to achieve more of the right things by doing less!

We cultivated a strong sense of ownership by keeping a document on the left of the board listing all the agreed-upon changes.

Developing things that people want is more important than running faster.

Concepts can help you start a focused conversation so you don’t get lost in the details. If you cannot squeeze your product idea into an A3, you probably haven’t quite grasped its essence yet, so more discovery work is needed.