Descriptive versus Prescriptive

“Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” -Martin Fowler, Agile Manifesto signatory, from his October 2006 blog post, “Agile Imposition”

As a member of the SAFe community, I've heard and experienced a lot of concern and displeasure with what is perceived as a highly prescriptive Agile framework. However, having actually met and worked with Dean, Colin, and Alex, I have never felt they were trying to shove a framework down my throat. To me it felt more like "your organization is new to Agile and we come with decades of experience; try this framework on, including all of these recommended practices, see how it fits, then tailor it accordingly." Granted, that vibe came from face-to-face conversations, not websites and white papers.

This problem is not unique to SAFe. Pure Agilists have always pushed for a more "hands-off" approach. It's interesting to me how married some of agilists become to a certain methodology - conversations with these people usually boil down to "you should let people do whatever they want, but if you're a good coach and they really get the principles then they're most likely going to go with my favorite methodology." This is often coupled with, "I also offer Agile Coaching services..." The problem is, they've got a point about the coaching. You can't leave teams all to themselves; you have to support them somehow. I'm not saying all Agile teams need a dedicated Agile Coach, but they need the resources necessary to ensure the direction in which they adapt is in accordance with Agile principles and the environment that will support them when (not if) they fail.

Many of my thoughts on this subject have recently been affected by the information I was recently exposed to at OpenAgileAdoption.com. One of the references cited is Martin Fowler's "Agile Imposition" - an article written nearly seven years ago and more relevant now than ever before. Of course, Fowler and Open Agile Adoption are both focused more on organizational transformation than prescriptive frameworks, but I think the principles still apply. It all boils down to enacting change through influence but without mandate. It's a principle that every good Scrum Master is already familiar with - Servant Leadership. You've got to not only lead the horse to water but get them to realize just how parched they are!

So how do you do this within the context of a framework? My opinion: change the way you say what you're trying to say. More specifically, make it clear why you recommend certain practices, when they're relevant and highly likely to improve results, and when it might make sense to try something else. You're still going to lay out the recommended practices, but you'll be taking a descriptive approach to explaining them rather than a prescriptive approach.

The Scrum Alliance uses the term "Common Practices" instead of "Best Practices" to describe what would traditionally be considered "Best Practices". By changing the term they change the reader's perception. They're not saying "you need to do this or you can't be considered among the 'best'"; they're saying "this is something that a lot of people do in this situation, and here's why." That's the approach the entire industry needs to be taking. I would bet that many framework authors already think that way. The problem is that way of thinking is not reflected in their writings.

What do you think? Does this resonate, or am I way off base? How would you expect websites and other communication regarding what are typically seen as "prescriptive frameworks" to change to be more in line with a descriptive approach?