Your Agile Principles: mutate the immutable!

With the rise (and fall) of (too) many (Scaling/Enterprise) Agile Methods and Frameworks it becomes ever more unclear what the differences are, and what to adopt for our own company.

All include a set of values and principles proclaiming that if you do not follow them then you can’t claim you are using their method or framework.

I find that highly concerning, because:

• People (consultants and your own internal people) learn a specific framework and then try to force the teams/companies to follow the prescribed values and principles.
• However, no (agile) method/framework exists that is a fit for all businesses.
• Values and Principles are a reflection of your company’s identity, not of the method/framework you use.

Values and Principles should be a reflection of your common sense on how you want to run your business. Of course that common sense can fit with any set of method/framework related principles.

Example.

The below image shows the ? Scaled Agile, Inc. immutable, underlying Lean-Agile principles of SAFe.

Now tell me, honestly, wouldn’t you recommend such principles to ANY company in today’s high paced, continuously changing business environment?

I have to say, I have nothing for or against SAFe, I could have taken any other framework's 'principles', though I found it interesting that these are claimed "immutable" and "Lean-Agile".

• These principles are universal, and not ‘limited’ to the lean-agile scenario. You create your identity by giving them meaning. By creating meaning you likely will mutate them (a little).
• Immutable principle #8 only talks about knowledge workers. So what to do with the intrinsic motivation of ‘the other’ workers? Or is SAFe only applicable in organizations completely composed of knowledge workers?

On a side note: What is a ‘knowledge worker’ anyway?

According to Wikipedia

“Knowledge work can be differentiated from other forms of work by its emphasis on "non-routine" problem solving that requires a combination of convergent and divergent thinking. […], there is no succinct definition of the term.”        

If all people are focused on “non-routine” problem solving, then whose taking care of the daily routine tasks…? Is SAFe only applicable for people that solve non-routine problems? Is a PI Planning a routine task to solve a non-routine problem?

Ok, back to the topic before I drift off completely…

I believe that picking a number of statements and proclaiming them framework specific, immutable, and/or lean-agile principles only adds to the whole confusing agile ecosystem.

If you want your organization to be more agile, if you want agility to be part of your corporate DNA, your identity, pick the principles you need and give them meaning… using common sense…

You can read my perspective on how I would explain the SAFe principles, in some contexts, in the image.

Note that these are even still quite generic perspectives that might need further mutation to become a fit for your context.

A few years ago many articles appeared shouting that you shouldn’t copy the Spotify Model, but to learn from it and adjust it to your context.

Please do the same where it comes to YOUR way of adopting and being agile. Start from a set of values and principles that define YOUR agility.

What mindset, method, framework, and practices that leads to is up to you. It won’t be a 100% copy of an existing framework, so you may not be ‘allowed’ to call it SAFe, Scrum, LeSS, Nexus, or whatever, but who cares?

Your agility should work for your company, and not for being compliant to a generic framework.