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…

I believe Kanban and REAL DevOps are a match made in heaven. I really do. I know I’m not the only one. Leading into Agile India 2015 InfoQ interviewed me about this. This was also one of the main themes of my talk in the conference and the DevOps Flow workshop I gave before the conference. (Contact me if you’re interested to hear about the next opportunity to participate in such a workshop).

While we’re waiting for the video from my talk to be processed, here’s a trailer…

I’ve been asked to deliver a pre-LSSC11 webinar on the topic of Lean Product Development flow. I’m going to introduce an approach to mixing Lean and Agile in order to achieve end to end agility. This is a major focus of my work in the recent 2 years with AgileSparks clients.

I want to share a solution I came up with together with a team of performance / non-functional testing, working in a product group in a large enterprise. This solution deals with the challenge of bridging the principles of "Those who build the system test it", "Non functional testing is a collaboration role", and the fact that specialized roles such as performance testers are usually stretched to cover the demand for their services.

This group wanted Performance testing for the product of course. What usually happened though is that the performance team only got usable features towards the end of the release (think waterfall like behaviour). This usually meant serious waivers and compromises around performance testing.

The first step taken by the product group was to work more on effectively breaking the features into smaller viable features and stories. Once this was done, it was easier for the performance testing team to get involved throughout the version, and achieve a more reasonable flow.

Things should have been great by now.

BUT then another problem surfaced, even while we were discussing how this would work.

It was clear that the capacity of the performance testing team wasn't sufficient to really address everything.

The naive policy meant that when a feature arrived at performance testing, they would decide whether they have time to cover it, do risk management and either test it or skip it.

The downside for this was that its a black/white decision. This misses the opportunity for the delivery agile teams to do at least SOME performance testing, even if they don't have the capabilities, tools, expertise of the dedicated performance testing team.

Our suggested solution was to use the concept of kanban Classes of Service to improve on this naive policy.

Since we already know not every feature requires the same performance test attention, lets not wait until it arrives at the performance team to make this classification. Lets do it earlier, before we go into development/testing.

With this classification, policies can be setup that can involve both the performance testing team as well as the delivery agile teams in the work of performance / non-functional testing.

We came up with a flag system:

•Red – performance team Must be involved hands on – probably by joining the Feature team working on this feature for the duration of the effort

•Yellow – performance team Advise/Consult, but most work is in Teams. Representative of the performance team will be visiting the Feature team quite often while the Feature is being worked on.

•Green – don’t need any involvement from performance team

This system helps drive collective ownership of non-functional testing. One of the first things that happened is that the Feature teams told the performance testers that there are some kinds of tests they can run on their own, although they don't have highly specialized performance tools.

We are also experimenting with systems like this for involving architecture teams, and it applies for most kinds of super-specializations that are not easily integrated into Feature teams.

Managing the overall flow using kanban will also help see whether a bottleneck develops, and what can be done further to overcome it.