Perhaps Frameworks Aren’t the Best (Initial) Path to Agility?

A few years ago, I wrote a book called Understanding Agile Values and Principles (https://www.infoq.com/minibooks/agile-values-principles/). I did this because years of training and coaching people and organizations suggested to me that many organizations start their path to Agility with a framework focus with limited, or no, knowledge of the Agile Values and Principles and what approach might be most appropriate for them. It is my practice, when I do Agile-related training, to address the Values and Principles because I believe anyone pursuing any Agile approach should think about the implications of the Values and Principles and do so before committing to any framework.

It’s not that I think frameworks are essentially bad. I just don’t think they should be the first (and perhaps only) introduction to becoming Agile. Indeed, for some organizations, initial framework training (and certifications) may hold them back from becoming truly Agile. It may turn out that “doing” a specific framework becomes the goal instead of some more meaningful goal or purpose for the organization. Indeed, when I initially talk to people about adopting an Agile approach, my first question is “Why?” Why do they think an Agile approach is the right thing to pursue and do they understand the implications of the Agile Values and Principles in doing so.

I think initial pursuit of a framework can constrain people to a mental model too soon before they have considered the possibilities for themselves. Frameworks lay out a set of things people must do and implement and suggest that “being” Agile is about “doing” the framework. There are various terms used to describe the early impact of a framework model: functional fixedness, anchoring, blueprint thinking. It would be better to first understand values and principles then consider the practices which would help them achieve those values and principles. Indeed, the authors of the Agile Manifesto had many different ideas about how to practice an agile way of working, but they agreed on a set of values and principles that broadly applied to becoming Agile.

One of the key ideas about agility is how an organization deals with change. Frameworks, though, are quite prescriptive about how one needs to behave. Though people talk about Agile approaches wanting you to inspect and adapt (your practices), they expect you to stay within the frameworks and not inspect and adapt, i.e., change, elements of the framework. Indeed, if you do, proponents of the framework will tell you that you are not doing the framework correctly and that’s why you are not being successful in adopting an Agile approach.

Therefore, it is believed that if you carefully implement the framework, you’ll be successful. Thus, they can be quite prescriptive in how you should behave and interact with one another. This has led to a view of agility as requiring training from recognized (certified) individual and organizations who offer certifications, in turn, to those who take their training. I believe this has led to excluding other ways of approaching agility.

I can’t blame this totally on the frameworks and those who promote them. After over 20 years since the Manifesto was written, we have many traditional corporate organizations wanting to pursue Agile. An important result of this happening in increasing numbers has been the companies needing to see legitimacy in the Agile movement before they commit to it. Broad training and certification programs are viewed as important evidence by such organizations for that legitimacy. The fact that, without really understanding what is trained and what certification means, companies have accepted the training and certification programs suggests a traditional large organizational view remains in seeing external evidence of legitimacy rather than internal understanding of what Agile means.

An interesting recent comment on this was Allen Holub stating that “If you can get a certificate in it, it’s not Agile. You can’t certify ‘do what works & if it doesn’t work, fix it.’ You can’t certify ‘talk to each other.’ You can’t certify ‘build small.’ You can’t certify ‘treat people with respect.’ You can’t certify ‘pay attention & learn.’” It’s also interesting to me to compare this to Alistair Cockburn’s Heart of Agile view that people can tell if they are collaborating, delivering, reflecting, and improving. You don’t need to be trained or certified to recognize that these things are happening.

Back in 2015, Andy Hunt noted that “agile practices are popular and more-or-less widely adopted, but practiced without understanding what it means to be agile …. We’ve forgotten that the aim is to adapt” and “tend not to tolerate any innovation in our methods.” He also observed that a “concept such as ‘inspect and adapt’” are likely abilities “only present in practitioners with much more experience” than people coming new to Agile ideas. He says “Agile methods ask practitioners to think, and frankly, that‘s a hard sell. It is far more comfortable to simply follow what rules are given and claim you’re ‘doing it by the book.’ It’s easy, it’s safe from ridicule or recrimination” and “there is safety and comfort there” though “to be agile — or effective — isn’t about comfort.…”

Let me close with a thought from Mile Cottmeyer (also from 2015) who said that the answer “to ‘Is Agile Right For My Company’ [is] almost always ‘no’.” Though a company could benefit from “a more agile approach to building products, most [aren’t] willing to fundamentally change anything to make agile genuinely work in their particular context.” My years of working with people and companies has only reinforced my belief in what Allen and Mike (and Alistair) have said.

[As a follow-up to my original book, I’ve started on a book I’m calling Implementing Agile Values and Principles. This post, and others to follow periodically, will contain examples of some of the ideas to be presented in that book.]