5-22 Popularity of predefined ways of working

They can be a good starting point, and usually shouldn't be the end point

A continuation of some of the thoughts in my previous post about apply concepts to structures they weren’t suited for

I wanted to take a step back and think about the popularity of predefined systems, such as Scrum or SAFe, and the frustration that people experience with them. If you look out on the internet, or attend a conference around digital product and/or software development, you can quickly find people who will say something along the lines of,

“Yeah, we tried <insert way of working> and it doesn’t work. It made things worse.”

Which is a reasonable response depending on where and how you tried to apply it, as well as your experience in the process.

I see coaches and consultants on Twitter who take a hard position of “don’t do <insert way of working>, it doesn't work”. And they get really frustrated and and assert that people are wasting their time because it's not valuable. Again, that is probably based on their experience working but I’m curious about their approach. What they aren’t doing is asking why are people so interested in this stuff? They're not seeking to understand what the value is that people are looking for from those frameworks, and oftentimes not considering what the value might be of a framework as it lends itself towards a team.

So let’s consider that for a moment…

If this happens over and over again, why are predefined systems so popular?

One of the reasons predefined systems are popular: they give a certain sense of clarity, of confidence, and that may be the way that people have been used to putting systems in place before. People may be uncomfortable with the concept of developing a system over time and understanding that it's an evolution. Perhaps their previous experience was "Here's the manual, go implement this and make this happen…" and so it's natural to want to gravitate towards something that seems like, “We can just go and if we do these things will be successful” when that's often not true that you can do this right out of the box.

Another reason: Contextually relevant, successful examples. Most of the examples people are referencing have two characteristics of being contextually relevant, often grounded in the same type of work like digital product creation, and they are success stories. People hear about all the good outcomes that a team experiences, painted with all of the benefits. Go read those books and blog entries and check their content. It’s mostly pretty positive, as would be expected if you’re trying to “sell” something. Sometimes the journey and the problems are talked about, but those are easy to gloss over.

A third reason: Creating a reference point. Predefined ways of working can accelerate this because the team doesn’t have to take the time to outline everything up front. There is also some value in having a consistent starting point as your learning that provides helpful patterns, that provides direction, and that helps accelerate some of the sense making and development of shared understanding. If everyone has the same reference point about your ways of working, it can help clear up confusion, and become a way of helping to guide conversation.

One more reason: Where time gets spent. Some people view the work of creating and improving the way of working as not “work”. They see it as “just the stuff we have to do to do REAL work” which usually means some sort of development activity like coding or testing. Picking up a predefined way of working seems like a good way to accelerate to those activities that are perceived as “valuable work”.

There are certainly more, but these were the ones that stuck out to me.

So how do we get from “Ooh this seems valuable” to “Ooh this sucks”

What happens between people’s impression of predefined ways of working and their experience?

At the heart of what happens I think is some sort of unmatched expectations.

I explored some of this in post 4-22 about mismatch but then how does the team react when their expectations about installing a system doesn’t work?

I think what I most often see is teams are developing is they do one of two things:

The first thing the teams often do is that they lock really hard into whatever the framework is, and then they paralyze themselves from evolving. They say "No, this is the way the framework is designed and so we have to do it this way." They aren’t really considering whether or not they're actually getting to the outcomes that they want.

The second thing I see is teams who want to evolve the system before they've ever really even given any of the practices a shot. It seems they are often very uncomfortable with the change in the first place, and so they'll naturally thrash right at the beginning, and you'll often hear things like "well this just doesn't work for us." These teams want to jump right to making changes, without really understanding the system and without really understanding the impact that their changes will have. These teams often end up evolving right back to where they were because they just want to get back to where their level of comfort is, where their safety is. May end up evolving back into a form of regression, and they also don't get to the outcomes that they want.

It comes down to their expectation of how creating ways of working happens in the first place.

What can we do about this?

First, set expectations up front many, many, MANY times. Like with any organizational change, communication and expectations are key, and having clarity and alignment around expectations will be critical.

Next, team members should be both openminded and skeptical. This may sound like a contradiction, and in a way it is, so it’s all about the mental approach. Being able to say,

“This could work for us. We can try it, but it might fail. How could it fail? What do we do if it does fail? We figure out why and make adjustments, but we can get better.”

Taking the mentality that there is improvements and outcomes you can get to, but it will take effort, and some experimentation to get there in some cases.

Lastly, understand that this is different than what most people have experienced before. Many people’s experience with figuring out operations boils down to:

• This is how I was told to do it

• This is how we all do it here

They have not had to design their operational system. They haven’t had to be a part of that work, nor have they been asked their opinion. Their experience does not look like the experience that they may have had previously, so expectations have to be set.