When we operate in a world of scarcity (time and resource) we will develop processes implicitly whether we try to or not. This is a great post, John. Hear hear, in defense of GREAT process and frameworks.
“Most frameworks weren’t designed for broad use. They were designed for a particular context, with lots of implicit context.”
This is so true, that’s why frameworks or even dare I say Centers of Excellence are so destructive when not used correctly. It gives people a shortcut from actually understanding the problem and finding the best solution. They are like “we’ll just use the framework or do what we always did!”
What I see happening very often is management "hiring" a framework as a solution, and management being management (with little to no technical experience) they lack an understanding of what a framework is.
I see people thinking that the words framework, model, process, method, methodology can be used interchangeably, and all to often I find myself explaining that those are 5 different things.
People get thrown off when I explain them that Agile is "just" a bunch of values and principles and there is no operating manual of how to run an entire company.
When you talk with a software development team, they know what a framework is because they use them constantly to ship their work: they know that frameworks come in different flavors, that they have caveats, that they comes with enablers and constrains.
They know that Scrum isn't gonna solve all of their problems but in the meantime their management think that installing it will actually solve all their problems.
The fact that some of those frameworks come with the promise of doing twice the work in half the time or get sold with the idea of being self-scalable doesn't really help.
Nice framework to critically think about frameworks 😉
When we operate in a world of scarcity (time and resource) we will develop processes implicitly whether we try to or not. This is a great post, John. Hear hear, in defense of GREAT process and frameworks.
“Most frameworks weren’t designed for broad use. They were designed for a particular context, with lots of implicit context.”
This is so true, that’s why frameworks or even dare I say Centers of Excellence are so destructive when not used correctly. It gives people a shortcut from actually understanding the problem and finding the best solution. They are like “we’ll just use the framework or do what we always did!”
Love this! No framework (or map, or best practice, etc.) is independent of context. 💯
What I see happening very often is management "hiring" a framework as a solution, and management being management (with little to no technical experience) they lack an understanding of what a framework is.
I see people thinking that the words framework, model, process, method, methodology can be used interchangeably, and all to often I find myself explaining that those are 5 different things.
People get thrown off when I explain them that Agile is "just" a bunch of values and principles and there is no operating manual of how to run an entire company.
When you talk with a software development team, they know what a framework is because they use them constantly to ship their work: they know that frameworks come in different flavors, that they have caveats, that they comes with enablers and constrains.
They know that Scrum isn't gonna solve all of their problems but in the meantime their management think that installing it will actually solve all their problems.
The fact that some of those frameworks come with the promise of doing twice the work in half the time or get sold with the idea of being self-scalable doesn't really help.