Tag Archives: Kanban Method

Yes, SAFe 4.0 includes kanban. But does it include the beauty of Kanban?

Estimated Reading Time: 3 minutes

One of the things I like in SAFe (Scaled Agile Framework™) 4.0 is the fact that is includes kanban visualization and flow management so explicitly as part of its recommended practices/building blocks at all levels ranging from the Portfolio (which was part of earlier SAFe versions) through the Value Stream and Program all the way to the Team levels.

Together with the explicit and up-front discussion of Lean-Flow principles and Reinertsen’s work that is indeed great news for kanban fans.

A recent comment from one of Yaki Koren my colleague at AgileSparks that “He’s reminded of the beauty of Kanban” (Reading Mike Burrow’s “Kanban from the Inside” while spending most of his days knee-deep in SAFe/Scrum engagements) sparked a realization that has been bubbling up for me though. SAFe 4.0 might include kanban but it doesn’t necessarily include Kanban.

What do I even mean by that? Capital-K Kanban refers to the change method not just the visualization/flow management technique. That method that “Starts with what you have”, “Respects the current way of doing things” and uses flow visualization/management, WIP limitation, and making your current policies explicit together with evolutionary experimentation and feedback loops to help you improve your fitness for your purpose.

Regardless of whether you want to follow the Kanban Method as a change management approach in your context, I think it is important to REMEMBER what it is about, and discern what sort of kanban/Kanban you’re using and what’s the purpose when you use it as part of SAFe (or Scrum or Agile Marketing or whatever). Too many people out there including some Agile Coaches and probably most SAFe Program Consultants probably can’t tell the difference.

If we don’t do anything about it, I’m afraid over time the Kanban definition that is part of SAFe 4.0 will join the Kanban as defined by Scrum practitioners (both miss more or less the same points) to be the canonical definition of Kanban that Lean/Agile practitioners are aware of and the Kanban Method will become a secret/lost technique. You know what, there’s a good chance that’s already the state of affairs.

And it’s a shame. Because even as part of a SAFe implementation it might be very useful to leverage the Kanban Method and use the Kanbans you have at every level as an engine for that “Inspect & Adapt” you’re seeking.

Even with SAFe Start with what you do now; Agree to pursue incremental, evolutionary change & Respect the current process, roles, responsibilities & titles can all make sense. SAFe takes a slightly different approach about it but it actually respects the “project manager” role for example and fits them into the “Release Train Engineer” role. It can live with component teams even though it prefers Feature teams. Many extreme agilists call it “safe” and closer to waterfall with its approach to periodical planning. That can be seen as a form of “start with what you do now” or “Respect the current process and needs of your surrounding stakeholders/clients”.

And because SAFe starts safe, we need SAFe practitioners to “Agree to pursue incremental, evolutionary change” from their starting point. We want them to ascend beyond the “Essential SAFe” in an effective focused way. We want them to use flow-focused experiments to evolve towards a better fit-for-purpose. We want them to understand and harness the power of WIP limits to drive not just collaboration but also uncovering your impediments/bottlenecks and dealing with them systematically.

We want SAFe practitioners/consultants to consider how Kanban can help them deal with SAFe theater – with those organizations that follow just the “easy” parts of SAFe, for which PI Planning is just a meeting of managers/stakeholders, where planning is push-based rather than pull-based (Where “No we cannot fit it into this PI”), where dependencies abound because they stayed with the “easy” siloed component teams or even component trains that actually make life really tough when you try to create flow.

Let’s see how this message resonates. If it does, I have some ideas what to do next about it…



Helping with Kanban – Thoughts from reading Helping by Edgar Schein

Estimated Reading Time: 3 minutes

I recently read Helping: How to Offer, Give, and Receive Help by Edgar Schein (actually I listened to it on Audible and then read it again on kindle to better process/digest). I can highly recommend it if you are interested in ways to become a more helpful consultant, manager, person – one who is able to actually help people/organizations rather than just dispense advice/suggestions. I’m not doing a full review of the book here but there are a couple of points I found very interesting in the relation between the Helping approach and the Kanban Method, which I wanted to put out there. I will probably talk more about this in my Lean Kanban North America 2014 Interactive Workshop in San Francisco on May 8.

The key theme in the book is that in order to provide helpful help you need to be build the helping relationship – not jumping to the expert/doctor role of dispensing advise/diagnosing but first listening, understanding, working through what Schein calls Humble Inquiry which starts with Pure inquiry – understanding what is happening without trying to influence the client in any way. Only then moving to Diagnostic Inquiry which directs attention to other aspects in the story and Confrontational Inquiry which asks what-if questions thereby hinting at suggestions (which is close to the Doctor/Expert role).

“This kind of inquiry can best be described as accessing your ignorance and, because it is genuine inquiry, it is appropriate to call it humble. The helper becomes open to what may be learned through observation and careful listening. The helper’s expectations may be incorrect, and it is the helper’s willingness to accept new information that elicits trust and makes the client feel better about having a problem”

If we look at what we are trying to do with Kanban – it is quite similar. We start with understanding the system by visualizing it. Not trying to diagnose/probe too deeply before we understand – actually before the client/clients understand. Accessing our ignorance – we don’t know HOW the system is working, we don’t know how it SHOULD be working. Which is exactly what Schein is trying to do with process consulting – to build the understanding together, not be in a position to understand FOR the client but WITH the client. In Schein’s perspective this not only minimizes the chance we will dispense generic advise based on our experience of similar events but will help to equilibarate the relationship between helper and helped – listening and respecting the situation helps the client/helped gain back “face” that he lost by asking for help. If we don’t “bring the helped up” by doing this there is a chance he will “bring us down” by trying to be very critic and unaccepting of our suggestions by the way.

“Starting out in the process consultant role is the most likely to facilitate status equilibration and to reveal the information necessary to decide on what kind of help is needed and how best to provide it. Only when some level of trust has been established is it possible to get accurate information that allows the shift to the expert or doctor role. As the helping process proceeds, the helper may shift among all three roles many times as the situation demands.”

This humble inquiry approach is also aligned with our approach towards management workshops in AgileSparks. Our instincts over the years pointed us away from diagnosing and presenting solutions and towards a more humble exploration of the system/context in parallel to presenting some useful patterns like Kanban, Scrum, ATDD. I try to emphasize the diagnostic role of these patterns/frameworks and the fact that even when we go out of the room with a decision to do something, it is basically a continuation of this “humble inquiry” (I didn’t use the term until today obviously…). We are obviously shifting roles from process consultant to doctor and expert and one of my main takeaways is to be more conscious about the role I’m playing and whether it is the effective/helpful one at the moment. I’m definitely jumping to the doctor/expert one faster than I should – and I will try to work on that using some tips and tricks from the book.

To summarize – and as I answered Bob (Marshall) yesterday – this book leaves me: startled (discovering new perspectives of how I’m doing things), a bit ashamed (for being more of a Doctor/Expert), alert (to the potential of being more helpful using this approach) , curious (about whether I can actually leverage it and what will happen if I do), rejuvenated (by getting a fresh perspective to something so core to my work). So bottom line the Helping book was quite helpful.