Changing customer expectations, “burning platforms,” competitive pressures, and increasing regulatory requirements are just a few of the substantial challenges that modern business leaders face. These pressures have pushed many businesses from the merely complicated to the complex domain, requiring new approaches to management — evolutionary agility at scale.
Definitions
These words will be defined as follows throughout this post (taken from this article on the Cynefin framework):
- Complicated: in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense – Analyze – Respond and we can apply good practice.
- Complex: in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe – Sense – Respond and we can sense emergent practice.
- Obvious: replacing the previously used terminology “Simple” from early 2014 – in which the relationship between cause and effect is obvious to all, the approach is to Sense – Categorize – Respond and we can apply best practice.
SAFe 4.0 and Kanban
A growing number of companies are turning to the Scaled Agile Framework (SAFe) to scale the Lean and Agile practices that the technology industry has accepted as best practice. Organizations thriving in their SAFe transformations operate with an understanding of the following: the complexity of transforming an organization, the role of a clear “Big Picture” starting point, and a relentless pursuit of evolutionary change using various guiding principles and models.
The much wider inclusion of Kanban in SAFe 4.0 is a significant step forward on that last point. But unless your organization has a wider understanding of the change management properties of a well-organized Kanban system, this will remain an untapped opportunity.
“Scrumble” Beginnings
A few years ago, I was consulting on Kanban and Scrumban at a large financial services company at the same time as one of the earliest SAFe implementations was taking place. It fascinated many of my fellow Agile coaches, but I was less impressed. At that time, SAFe was seen as a rigid top-down process. It also failed to account for complex value streams or allow for demand- and capacity-balanced systems at the team and organizational levels.
Since those early days, SAFe has evolved considerably; today, it’s a framework and library that supports solving common problems in both simple and complicated domains. PI planning, for example, is one of the many successful SAFe practices that exposes assumptions and risks across teams prior to implementation. Effective, collaborative planning enables better decisions and reduced risk.
Context Matters: When SAFe Gives a False Sense of Security
However, when the context shifts from complicated to complex, new challenges emerge that less experienced SAFe practitioners may miss. There’s a risk of creating the illusion of certainty where it doesn’t/can’t exist if a speculative process that’s effective in one obvious domain is applied in another domain. Good examples of this are:
- Technical debt from poor design that remains unrecognized.
- Introducing an inordinate amount of waste into the planning process in order to artificially “align.”
- Using one type of work or context as a reference class to another without realizing they are not comparable.
By contrast, SAFe practitioners who take a more evolutionary and pragmatic approach can avoid some of these dangers by paying close attention to results and adapting their thinking and approaches accordingly. In a word, they apply Kanban.
Pragmatic SAFe(ban)
As of the 4.0 release, Kanban is now a first class citizen in SAFe, with the implementation of Kanban encouraged at all levels of the Big Picture. Here are just a few of the questions that the Kanban Method can help answer in a SAFe implementation:
- How can you leverage stability and lead time data from various systems to help determine tightly coupled cadences (a.k.a., Program Increment)?
- How can you use optionality to improve the service experience for the customers of a value stream or a release train?
- Why and how does the limiting Work in Progress principle work?
- What assumptions do SAFe practitioners commonly make (and shouldn’t)?
- What assumptions need to be true for connected Kanban systems to work as a network?
- How do we manage the value streams and release trains as a network of connected systems and services?
- How can organizational feedback loops work within a context of a release train using Kanban?
- How does Kanban’s STATIK scale?
- How can we use Discovery Kanban to probe, sense, and respond in a complex environment?
Just as the term Scrumban is used to describe the application of Kanban in a Scrum context, I would suggest SAFeban as a similar hybrid of the Kanban Method applied in a SAFe context. SAFe now recognizes the importance of connected Kanban systems, and the survivability agenda of the Kanban Method. These integrations of Kanban into SAFe are a major step forward.
It’s an exciting time in the development of mature processes for leading strong, agile technology organizations.
Acknowledgements
Thanks to Alexei Zheglov, Yuval Yeret, Shyam Kumar, Kevin Callahan, Diana Reddy, and Dimitar Bakardzhiev for feedback and suggestions on this blog post.
