Improving Frameworks by Attending to Patterns of Failure

Q: Where can we draw the line and attribute the cause of bad implementations as being the fault of practitioners Vs the fault of the framework/method?

A: The way to tell the difference is if there is a pattern of failure and a pattern of what’s ineffective or missing. Dark Scrum usually arises from well defined patterns of failure as well as having well defined solutions to avoid them.

Q: But the problems are often attributed to people – bad behavior on the part of leaders – micromanagement, not willing to trust people, etc. But these symptoms also manifest in frequently identified patterns of team behavior/interaction. Doesn’t that mean the answer to the original question may not be so straightforward.

A: Perhaps. The answer needs to accommodate both what a framework does directly and what it indirectly causes by not attending to culture and individual reactions to it. Few frameworks attend to this second issue.

Also, let’s be clear that when looking at who makes these attributions you’ll usually find them in the Scrum and SAFe communities and not from Lean, Disciplined Agile or FLEX community thought leaders. leaders. We don’t attribute to people do it for at least two reasons. First, we take a systems thinking point of view and recognize the framework is part of the system and has a significant affect on the attitude of the people involved. Secondly, the moment you blame the people involved is the moment you stop taking responsibility for how your approach affects them. This has you strive less for improvement with the result the framework  does not improve as much as it could.

Frameworks must attend to the culture an organization is in.  See Improving your company’s culture.

If a framework puts adopters in a situation where they don’t know how to do a practice, aren’t given proper guidance and aren’t offered solutions when the practice doesn’t apply, it should be expected that people will do the practice poorly or abandon it altogether.

Scrum and SAFe do little but have a prescribed starting point and a “do it until you figure it out” attitude. If you disagree, for Scrum, please let us know how it addresses the reaction to cross-functional teams if leaders don’t see how they can adopt them. For SAFe, how many times does it not have you start at the team-level with Essential SAFe. Again, let us know if you disagree.

Let’s illustrate how an approach can take responsibility for individual aberrant behavior. 

Let’s consider auto accidents. Most accidents are caused by people, not the cars themselves. Car makers have taken dramatic steps to avoid accidents. Instead of saying “accidents are the fault of the drivers” they look at way to have the car prevent accidents. It was developed (and continues to get upgrades) by looking at patterns of driving. Instead of saying   and did something about it. Or look at the roads. Accidents that used to kill people now only damages cars.

What are our frameworks doing to prevent these “accidents?” Most statements I hear regarding poor adoption are in defense of frameworks or attribute much of it to complexity. I find these arguments are  really “i’m not going to change my mindset” or “I don’t know how to do better, so i’m going to pretend there isn’t a better” or “since I can’t do it, it can’t be done” or “stop saying bad things – this is the best I’m capable of” in disguise.