In her post, "The What Not the How of Service Design", Sarah Drummond writes:
I’m witnessing a more negative tipping point right now, when the defined discipline becomes too formulaic because it’s been commoditised and we forget, at the essence of this, it is about designing services and creatively solving problems for organisations and/or systems.
She is hitting on something here that I've come across many times over the years. The problem with putting a label on something is that it becomes all too tempting to commoditize anything that uses the label, to standardize until everything in that label can be turned into a checklist or piece of software that simply steps you through a process.
My first real experience with this was with Knowledge Management. So much promise when I first came across the concept and started practicing it in the late ’90s, it wasn’t long (early ’00s) before KM was mostly synonymous with document/content/information management. An inherently complex endeavor well suited to navigating uncertainty was turned into an attempt to capture knowledge as if it were some static thing, to turn every situation into something that can be solved with a past best practice.
My first real experience with this was with Knowledge Management. So much promise when I first came across the concept and started practicing it in the late ’90s, it wasn’t long (early ’00s) before KM was mostly synonymous with document/content/information management. An inherently complex endeavor well suited to navigating uncertainty was turned into an attempt to capture knowledge as if it were some static thing, to turn every situation into something that can be solved with a past best practice.
I've also seen this in my personal life, as I learned more and more about autism and the lives of autistic people. As the parent of an autistic son, I had a lot to learn. The most important lesson I learned was, “If you’ve met one autistic person, you’ve met one autistic person.” And yet, it seemed as if everyone was trying to make me believe that all autistic children were the same, that the “cause” of their autism was the same, and that if I would only do [insert some craziness here] then they would no longer be autistic, or they would be better able to cope, or whatever.
Ooh, look, there’s a label, let’s come up with a way to standardize that and get people to use (aka buy) our method to do something with it. Though there may have been some sincere interest in helping parents help their kids or helping companies effectively navigate complexity and uncertainty, mostly it seemed to be about profiting from the situation without worrying about actually understanding the situation or helping anyone.
Ooh, look, there’s a label, let’s come up with a way to standardize that and get people to use (aka buy) our method to do something with it. Though there may have been some sincere interest in helping parents help their kids or helping companies effectively navigate complexity and uncertainty, mostly it seemed to be about profiting from the situation without worrying about actually understanding the situation or helping anyone.
Over the past few weeks I have - for various reasons - completed six Scrum certifications from scrum.org. When I first read the original Agile Manifesto many years ago I couldn’t help thinking, “Exactly.” While prepping for the Scrum certifications, I found that the Scrum guide and many of the learning resources spent quite a bit of time on the why of Scrum as the reason for the how. It seems so promising.
Back in the real world, though, it becomes all about the how. "How long should this meeting be?" "Should this be an Epic or a Feature?" "But [team member] didn't answer the three questions, isn't that wrong?" You spend more time trying to figure out how to "do Scrum" and less time "being agile", building and delivering things that actual users and customers want and will use.
Of course, a lot of this comes down to measurement, specifically ease of measurement. It is so much easier to measure *output* - all of the meetings were on time, followed the right schedule, we delivered the required number of story points, we made some service blueprints and journey maps - than it is to measure *outcomes" - whether that be business outcomes or customer outcomes. And, as we all know, that which is easiest to measure is what will most likely be measured.
How do you avoid this trap of focusing on output instead of outcomes?
This is an updated version of something I first published several years ago: Labels, Standardization, and Missing the Point
Back in the real world, though, it becomes all about the how. "How long should this meeting be?" "Should this be an Epic or a Feature?" "But [team member] didn't answer the three questions, isn't that wrong?" You spend more time trying to figure out how to "do Scrum" and less time "being agile", building and delivering things that actual users and customers want and will use.
Of course, a lot of this comes down to measurement, specifically ease of measurement. It is so much easier to measure *output* - all of the meetings were on time, followed the right schedule, we delivered the required number of story points, we made some service blueprints and journey maps - than it is to measure *outcomes" - whether that be business outcomes or customer outcomes. And, as we all know, that which is easiest to measure is what will most likely be measured.
How do you avoid this trap of focusing on output instead of outcomes?
This is an updated version of something I first published several years ago: Labels, Standardization, and Missing the Point