Why do companies claim they're using Scrum, when they aren't?

Question

Being a software developer who interviewed with a lot of companies and switched jobs a couple of times, I noticed a lot of companies tend to claim they're using Scrum (e.g. during the interview process), when in fact they aren't.

Usually they'll use some terms from the Scrum Guide and follow some practices, but will also make a lot of exceptions. I assume that this results in lower job satisfaction and higher turn-over (as a lot of software developers enjoy proper Scrum and get frustrated when things doesn't work as expected).

So why would it make sense to advertise a Scrum approach one doesn't follow?

Answer 1

For most teams it's because they don't know any better. Many Scrum implementations start with someone reading the Scrum Guide and begin to follow what's written in there. Mechanistically. It's a process to follow, it's a list of checkboxes to tick. So they follow the process and they tick the boxes thinking they are actually doing Scrum.

Often, the prescribed ways of learning Scrum is through approaches such as Shu Ha Ri which unfortunately start with "obeying the rules". You focus on the tasks (in this case Scrum events and artifacts) without caring too much about the "why". You do so until you eventually "get it", and then you move to the next step and the next. Unfortunately many teams remain stuck in the fist step (the Shu) and keep doing something that they think is the right thing to do.

Because the "why" is lacking, whenever their Scrum implementation meets a roadbump (e.g. traditional project managers, executives, company policies, procedures and regulations, etc), since they don't understand what Scrum is all about, they start to bend its definition. And you end up with ScrumBut.

The thing with approaches such as Shu Ha Ri is that you need to "follow the teachings of one master precisely". This means an expert of some sort that you learn from: a true Scrum Master. And many teams don't have a true Scrum Master, it's just someone inexperienced who fills the role of Scrum Master because you need to tick that box, right? So many teams start by themselves with learning approaches like Shu Ha Ri, so of course they mess it up.

Everyone who does ScrumBut actually thinks they are doing Scrum but (no pun intended) they are not.

There are a lot of other reasons of course but from my personal experience this is the main reason. They use the word Scrum and they think they are doing Scrum, because they don't know any other Scrum implementations than the one they are doing, to compare it to, and see that it's actually ScrumBut.

You might also want to read:

• Aren't stakeholder expected to adopt an agile mindset when working in a Scrum framework?
• Why does management have to "buy into" Scrum?

Answer 2

There could be several reasons, but I'd posit the most likely would be:

1. It's a trap.
   • Scrum is attractive to job-seekers, so they claim they're doing it to get more/better applications.
2. The right hand doesn't know what the left hand is doing.
   • The HR people take a glance at the development people, see a few 'Scrum-like' things, and, not truly understanding, go 'oh, I guess we're using Scrum, I'll add that to the posting'.
3. They've modified Scrum to fit their purposes.
   • The modifications they've made actually make sense for their business. What they're doing may technically not be Scrum anymore, but for their purposes that's a meaningless distinction.

Answer 3

Scrum has been very well marketed over the years, and many folks believe that Agile IS Scrum.

But, there is another reason:

When adopting Agile, most companies and the management tasked with the adoption, are both too inexperienced in the topic (those tasked typically come from inside the company and lack any actual Agile experience), and too afraid of failure.

The result is that they pick what has become the industry standard with the premise that if they do it by the book and it goes wrong then it is the fault of Agile being unsuitable/incompatible with the company rather than it being their fault.

My answer was always: “10,000 flies can’t be wrong!”

I have seen multiple billion dollar companies try this even when there was no way that pure Scrum could ever work in their corporate culture (highly regulated, too big to fail, regularly audited, all development outsourced and offshored to companies that claim to be both Six Sigma and fully Agile)...

I remember one company tried Agile in a major business unit and decided to abolish all IT and Dev management positions because “manager” was not a role defined in the Scrum guide...

You can imagine the reaction of teams tasked with the delivery of $100M Regulatoty Compliance systems to that one!

Needless to say, Agile adoption within the business unit was nonexistent, and the manager responsible still got a nice promotion!

Answer 4

Scrum is too popular

The more followers you have the higher the percentage of amateurs are amongst them. And Scrum is everywhere..

Scrum is obscure

No one knows what Scrum is. Not anymore. Typically when people say Scrum they have a picture of ScrumV1 written in 2009. It was a clear guide that explained what, when, how. But then we got new versions of Scrum each becoming more obscure.

My understanding is that because too many people were rejecting Scrum authors started to modify it so that it suits a broader audience. "Hey, you don't commit - you forecast", "Hey, you don't have to finish tasks - you need to achieve Sprint goal" (whatever that means). Some people may decipher it (most of them simply pretend to), but you can't expect majority to figure it out.

Self-organizing teams are rare

Very rare. Usually we have some key people that guide and control others. When you take the guidance away - suddenly they stop understanding what managers want from them. So you impose Scrum and you may think that because you introduced the right meetings it became Scrum. But most team members keep waiting for orders from the key people.

Scrum is very ineffective

You can find countless blog posts from programmers (some of them are good programmers) that complain there's too much talking in Scrum. They want to work more and they see Scrum as an obstacle. And again manager tries to impose the process and calls it Scrum, but the team rejects it. It's an endless fight between common sense and processes.

It's sad that effective, modern methodologies (JiT, ToC, CD) were introduced for many years now, but most of the IT still tries to follow iterative approaches like Scrum or Waterfall.

Anyway.. High percentage of amateurs + obscure guides + rejection from engineers -> you get a visibility of Scrum.

Answer 5

Dunno ... Maybe I've been around this crazy business (which I still enjoy), for a few too many decades to treat "Scrum," or any of the many other "silver bullets" which have preceded it, out of context.

The one absolutely-unchanging part of this equation is ... "the machine."

Years ago, I encountered an e-book called Managing the Mechanism (I never saw it in print, but it's on Amazon and Apple ...) which articulated this point most clearly: that traditional project management strategies overlook the fact that "software is an autonomous, self-directing machine."

Anyway – "Scrum" is a "Scrum Guide," not a "Scrum Bible." It is a practical guide aimed at human project management in the context of self-directing machines. It cannot be and never pretends to be specific to your situation, whatever it is. Therefore, you must be your own guide. The principles are valid and well-tested, but they are necessarily generic. They are useful, but they are not – and never were intended to be – "rote dogma." Plan Accordingly.™