“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…
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?