"Doing Scrum our own way"

Is it understood that Scrum is not being applied at all unless it is implemented in its entirety, and that the associated benefits are unlikely to accrue?

Changing the Scrum Framework “to suit the organization” avoids dealing with issues that would be exposed to scrutiny. What is being concealed here, and why? Are teams delivering valuable “Done” increments at least once every Sprint, for example, and are those increments being released into production?

Organisations are allowed to implement anything they want. However, if Scrum is not applied in its entirety, then please don't call it Scrum. 

Hi Matt,

tl;dr - not all deviations are created equally; you've got to dig deeper and have ongoing conversations to understand what the "real" problems are and how to solve them.

I'm sure we've all seen this "custom Scrum" thinking at one point or another (or many ...).

I don't know that it's possible to solve this problem overnight, but here are some thoughts that occur to me and that may be helpful to you:

Build relationships and be honest.

It may sound obvious, but this is a primary example of where one needs to build relationships to gain influence and establish trust over time. Coming into an organization and taking on a posture of Scrum referee (however correct one may be) will of course push people away, especially if the habits are entrenched in the organization and now they're being told they're "doing it wrong."

That said, it's important to be honest, especially around the most egregious deviations. If people are using language like "design sprint," "test sprint," "release sprint," etc., it's fair to respond by saying, "It sounds like you're still doing waterfall, but just throwing in some Scrum terms here and there. Why do you think that is?" Or "I know a lot of organizations try to 'customize' Scrum by doing it the way you are. Do you think that approach ever results in increased agility or value?" 

You may also need to have some heart-to-heart conversations with your leadership. "You brought me here to help you deliver value using Scrum, but as a professional Scrum Master I feel it's my duty to report some organizational obstacles that will make it difficult for me to do that." And then once you've said your piece, give it back to them: "So, how do you want me to proceed?" Basically, state your point of view while trying to turn the issues you see into shared problems.

Probe the origins of the deviations.

Be Socratic. Before pushing back on deviations, ask why the organization found itself doing something a certain way, how long it has done things that way, whose idea it was (and where are they now?), and what benefits it has achieved by doing things in that way.

If you ask the right questions, the underlying problems may even become self-evident to those standing up for the deviations and resisting change. Often, if you ask the right questions, they may admit that there was no underlying rationale for these deviations in the first place except, "It was just a lot easier ..." or "Our release management team said we had to do it this way ..." and so forth. This can help you better localize the root cause of what's going on.

Not all deviations are created equally. Be especially wary of vaguely defined or inconsistently followed deviations. 

In rare cases, you may find a semi-decent reason for a deviation. (I'm not endorsing deviations; just saying that they aren't all created equally!) For example, if your organization has a separate test team for legal/regulatory reasons, that's at least a better justification than "Because we've always done it this way!" And, more importantly, your response and the path forward would look very different in each case.

I think it's critically important to understand if the deviations are at least clearly defined and consistently followed, or if, instead, the teams are simply deviating haphazardly whenever following the Guide is inconvenient/difficult. The former may be a case of faulty but well-intentioned reasoning and implementation, but the latter is plain old excuse-making and shows a deeper lack of discipline/leadership/inspiration. I see both commonly, but they are completely different scenarios which call for drastically different responses.

Be empirical, and stick to a very simple test. 

If the organization is actively empirical, or open-minded, then there's plenty of hope. In that case, your recommendation of "let's try it by the book for a while" (great approach) makes a lot of sense. If the organization resists this, then you have to probe deeper on that point. What does the organization fear about being empirical? How does it make decisions if doesn't want to use evidence? Etc.

The ultimate question I would try to answer, and then repeat the same question to organization leadership, is this: is the organization able to consistently deliver valuable, working software on a regular basis of approximately one month? 

If the answer is yes across the board, then you're in the realm of optimization, and there is less to worry about. Can we get our sprints down to a month? To two weeks? Can we ensure our designers are part of the Development Team? Etc. I wouldn't worry about deviations in this context.

If the answer is no but everyone agrees that the goal is yes, then you've pointed out the organization's problem head on and you can then point out why the deviations are getting in the way and why Scrum is the solution.

However, you may find that the real answer is no but that leadership will tell you that yes, the organization is delivering software at this rate. In that case, solving the problem probably starts with addressing the lack of transparency, perhaps complacency at some levels, and so forth.

Finally, if (as you will sometimes find), the answer is no and the organization says that that's fine because working software in thirty days or less is not a reasonable/valuable goal anyway, then you're in the realm of an organization which wanted to do "Scrum" or "Agile" because it was trendy but without a true understanding of the value proposition, the trade-offs, the change required, and so on.

Once again, asking the right questions, listening to the answers, and digging deeper to understand the root causes is your best bet to solving these issues.

This is very helpful, thank you!