Why Mixins?
“Some say that I should settle down, go slower and not push so hard, so quickly for such transformational change. To them, I say that you misunderstand the size of the problems we face, the strength of the status quo and the urgency of the people’s desire for change.”
– Eliot Spitzer
The Challenge
According to the latest VersionOne State of Agile survey 2018, the most prevalent scaled agile framework in use today is SAFe. Note that I didn’t say it was the most popular framework. I’m not sure that most people love SAFe, but I can say that most people use it. Why don’t people love it? Well, I’m sure there are lots of good reasons:
The framework is very prescriptive, often specifying “best practices” without much discussion of alternatives
The framework is overly dense, incorporating nearly every agile practice ever invented
The framework is designed as a first step for large organizations on their agile journey, but often it is also the last step
Implementations tend to be cookie cutter and not make allowance or provide guidance for change
I’m sure there are many more very good critiques of SAFe. It’s not my purpose to condemn the framework, but rather to highlight some weaknesses that I believe can be easily addressed. My goal is to consider how we can make SAFe, and frankly, many other scaling frameworks, better.
So how can we accomplish that? What can we do to improve this very full, relatively rigid, and somewhat context-free framework? My answer is fairly simple: swap in practices and processes that complement the framework and may provide a better “fit” for our transformation customers. Essentially, I’m arguing for the application of a little creativity. All of the frameworks have a planning process. But there are a lot of ways to do planning. We can vary the estimation practices like story points, WSJF, or #noestimates. We can vary how we prepare for the planning event by using extensive top down review, bottom up conversation, or LeanUX related practices.
The truth is, that we have a whole constellation of different practices that we can swap out within our scaling frameworks depending on the need. This gives us incredible flexibility to help our customers find the “right fit” for where they are at in the moment. This has some important consequences:
For engagements that begin with a very prescriptive bent (which often makes sense when teams are learning something new, think shu-ha-ri), using mixins is a great way to begin down the path of experimentation and continuous improvement
We even have the discretion, once we have learned how the framework works, to try our hand at de-scaling – that is, to remove processes that seem too heavyweight
Mixins give us the creative potential to continue to evolve our scaling frameworks far beyond what their creators may have originally envisioned
Using mixins during a transformation rollout can help us to avoid the cookie cutter implementation phenomenon
All of the practices that I propose as mixins are novel and innovative. Most have proven their value on their own in the agile community. It is the recombination of these ideas with Scaled Agile Frameworks like SAFe that I find so interesting. It feels like something very new. It’s an exciting challenge, are you up for it?