Frameworks provide us with:
- A list of roles, actions and artifacts which are useful
- A set starting point
However, frameworks don’t discuss:
- When they are most applicable
- How to transcend them after the adopting organization has successfully adopted them
Frameworks are also not meant to be modified. The reason for this is stated as self-evident & therefore rarely (ever?) discussed. However, there is much evidence that a framework being adapted to an organization while still providing a set starting point is a better way to go.
The net result of the above is that people tend to adopt a framework as is. And many tend to require adherence to it. All of the above strikes me as particularly non-Agile. We have put fences around what we can do. The justification for this has been twofold – people need to follow something until they can think on their own and it’s too difficult to come up with a tailorable model.
The first one strikes me as not having confidence in people’s ability to figure out what they need to do. The second one misses the point. I’m not suggesting that the people adopting a framework figure this out, I’m suggesting that consultants and trainers figure this out and be what they present to their clients.
If the underlying assumption is that frameworks =dogma, this makes sense. But that isn’t how I understand the use of any of the frameworks I know. Also there is a scale that I’ve seen which is less reliance on tried and true frameworks = higher cost in change management. Which is fine, just needs to be a conscious decision.
thanks for the comment. If there is no dogma to the framework then you can change it and it becomes closer to what i’m talking about.
But no framework I am aware of gives you optional starting points (SAFe tries to do this with different levels but when you pick a level there is one set way of doing it).