“You can’t put being in love on a scale. Either you are or you aren’t.”
― Jenny Han, We’ll Always Have Summer
Respectfully adapted…
“You can’t put being agile on a scale. Either you are or you aren’t.”
The world exists as a set of patterns. These patterns tend to repeat themselves in various contexts. A phenomenal example of this is concept is a fractal. Fractals can be seen throughout nature in all different contexts, and is thus a patterns that repeats itself and “scales” wonderfully.
A fractal is a natural phenomenon or a mathematical set that exhibits a repeating pattern that displays at every scale.
The underlying premise is a set of patterns exist out in the real world. These patterns can and should be applied when and where they make sense. Anything beyond understanding patterns and seeing that a hammer works best for a nail and a screwdriver works best for a screw simply adds unnecessary complexity to an already complex world. This law of the instrument can get us into serious trouble…
“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
― Abraham Maslow, The Psychology of Science
To that end, I was deeply saddened to read an article recently on Comparing Agile Scaling Frameworks, put together by Richard Dolman (LinkedIn, Twitter, Scrum Alliance, The Pragmatic Agilist) and Steve Spearman (LinkedIn, Twitter, Scrum Alliance, Swift Ascent). My sadness was not in the authors or the article itself, but in the fact that it has come to this. Instead of simply identifying, collecting and having the patterns available to use as needed, we as the agile community have felt the need to try and mix and match patterns in various ways, label them as frameworks, sell certifications for them and argue about which framework is the best. This has been ongoing and is being perpetrated as the focus is now on “scaling” agile instead of anchoring to the mindset if “being” agile. What this has caused is noise, confusion and many many less than stellar results then practitioners who try to lay these frameworks on top of organizations without first identifying what is needed.
A fellow practitioner, Si Alhir (LinkedIn, Twitter, Blog, Conscious Agility, Cars.com Transformation Journey) among others, has contributed some amazing work in this space. In a recent blog, Dynamics over Mechanics, he shares some interesting examples that have come up in the real world showing the law of the instrument in relation to the Scaled Agile Framework (SAFe).
For example, given the recent popularity of the Scaled Agile Framework (SAFe), we continuously find more and more of the notion of a “descaled agile framework” (DAFe or dSAFe) or “SAFe for a Team” where rather than embrace scale and then de-scale (that is, going from “big” to “small” based on need), one can embrace an essentialism or minimalism then scale (that is, going from “smallest” to “bigger” based on need) […]
As organizations grow, many tend to focus on processes and tools (mechanics) and less on the people (relationships, behavior and communication – the dynamics, the culture). This often means that the dynamics break down as more processes or more tools are put in place.
When organizations realize that they are no longer delivering the results or satisfying their customers, they often seek out a solution. Again focusing on processes or tools, they bring in a “silver bullet” of a new tool or a “silver bullet” of a new process, but more often than not they fail to understand and address the dynamics. These are often labeled as “change initiatives”, and when they often fail to address the dysfunction or achieve the result, they cause not only the people to suffer more, but often times lead to worse organizational issues.
Some Open Thoughts From Here:
- Patterns are essential. Patterns underline the frameworks. The frameworks are a collection of patterns that work in certain situations.
- We (as practitioners) should not be going into an organization with the intention of implementing a framework or tool. We should instead first seek to understand the dynamics and dysfunctions that may exist, then seek to create less dysfunction as we seek increased efficiency and effectiveness. Once we understand, then we can pull in the correct patterns to support and assist the organization and its teams, guided by the people in the organization that see the dysfunction every day. Essentially, because no two organizations are the same, no two organizations will have the same framework. Instead what they will have is their own framework, grounded in the correct underlying principles based on need.
I’d really like to hear thoughts from other practitioners. Have you seen these issues (or others) as a result of focus on frameworks instead of principles? What approaches have you used with success when working with organizations?
Love the title, Tom – and appreciate the perspective. It’s definitely controversial to focus on frameworks versus patterns – or even versus “de-scaling”. But one can argue that same logic would suggest not choosing a framework like Scrum either – but most of us find that appropriate for people at a Shu level.
Our goal was to provide a tool to think about alternatives and how to pick and choose the best ideas from them – patterns if you will. But we could probably add more links to some of the best current pattern thinking.
Regards,
Steve Spearman
Steve – Hope you had a great Thanksgiving and I really appreciate you taking the time to reply.
I actually love the concept of what you and Richard put together, I just believe the focus of what to compare when talking about scaling is where it could be improved. By comparing the frameworks, whether intended or not, it further perpetuates practitioners to pick between this framework and that framework. Each framework has positives and negative aspects, depending on context. What I would love to see (and let me know if you guys want to partner on something like this) would be something that instead lays out the underlying patterns of each framework and provides guidance for what situations they apply best in. Assuming that was created, then instead of comparing frameworks and thinking they have to pick and choose, practitioners could then understand the patterns and mix & match and create their own platform based on the needs of the situation.
On a somewhat related note, my colleague Si Alhir recently published an article regarding “Change: From Programs to Platforms” (https://www.linkedin.com/pulse/article/20141128091102-2518585-change-from-programs-to-platforms). This article references work from Gary Hamel and Michele Zanini (http://www.mckinsey.com/insights/organization/build_a_change_platform_not_a_change_program). The message in both of these articles is that we need to move away from change programs and instead focus on change platforms. Combine this with the concept of comparing patterns instead of frameworks, and we now get a powerful model for truly transforming organizations, instead of simply transitioning to a framework or implementing a change.
Again, thank you for the reply and I truly look forward to future discussions on the topic.