How to introduce Scrum in a company accustomed to Scrumbutt or Scrumfall?

Question

A colleague of mine works as a consultant. He is recently asked to help a software development company to improve their processes. The company is aware of some of the issues, like the number of bugs or the fact that they can't release their lead product more often than once per year, but nobody there knows what to do.

My colleague identified that they have a primitive in-house process which they call Scrum, but which isn't.

My colleague wants to suggest moving to “the real Scrum”. If he does that, he will encounter two issues:

• Managers will reply that they already use Agile, and that it wasn't helpful.

• It would be particularly tricky¹ to explain both to the managers and to the CEO of the company that it was not the real Scrum which was used until now, but rather a mix between Scrumfall and Scrumbutt.

What to do?

---

^{¹ In this company, two of the three managers claim they know perfectly well Agile and Scrum and apply it flawlessly to their respective teams. Claiming that they know nothing about any of those two subjects would create a hard to handle situation. My colleague's role is also not only to give his opinion, but to apply the “good” methodology for the next three months within this company. Starting by claiming that managers are incompetent in this context is not a solution.}

Answer 1

Don't fight them on a systemic level. What they are doing is what Scrum means to them, so using the word Scrum to mean anything but what they're doing will not make any sense to them.

Don't even fight the system. Some of the things they do might be working for them, even if they're not Scrum. Scrum is not a one-size fits all solution; I haven't even read two books on Scrum that can agree on all the details. It's all just advice, which may or may not work in the context of any given company.

As a consultant, the job is to sit down and take stock of all the things that are going wrong and find the solutions. You can pull those solutions from Scrum or XP or Kanban or you can just make them up. It doesn't matter.

But don't try to teach them something they believe they already know. Don't tell them that they're flat-out wrong, even if they are. Just figure out what they're doing wrong -- by which I mean, very specifically, what isn't working for them -- and teach them to do it right.

For example, why can't they release monthly, weekly or whenever they choose? Do they need a better (D)VCS? Do they need a continuous delivery system? Do they need to improve their deployment process? Teach them how to do those things, rather than pushing a single label on them for their entire development process.

Answer 2

Two suggestions:

• Either pick an Agile method different from Scrum, such as XP, without mentioning Scrum and avoiding talking about it or comparing it to XP.

• Or, if he's convinced that Scrum is more appropriate than any other method, apply Scrum without naming it.

Avoiding to talk about Scrum would help avoiding arguments, and especially two risks:

• The risk that one of the managers starts to argue that he knows Scrum better and that according to his deep knowledge, for example, it's the Scrum master who assigns work to team members.

• The risk for the team to take negatively every suggestion of the consultant. “We already tried Scrum, it failed, so why do you bother us with it again?”.

Answer 3

If I was in the same situation I would ask if they would like to hear what they wanted to hear or the unpleasant truth. If they want the truth, just give it straight up. If they don't want to hear it, it's their choice. Just walk away. But they probably expect him to be honest. Giving them the choice is a fair thing to do.

Answer 4

Do you do retrospectives?

If so, use the retrospective to raise and address this issue. Don't talk about doing real Scrum, because they already think they are. Raise specific problems and point out that more text book versions of Scrum already do this.

I was a Scrum Master (actually a manager of an in-house process called PP2). In that position, I did a number of things:

• Start doing Scrum. My team didn't care, as there was already a lot of variation in the way the in house process was applied. New joiners and external consultants really appreciated it being Scrum - a process they already knew.
• Printed out and stuck up a Scrum poster. Something that clearly showed how you are supposed to do Scrum in simple terms. No debate about this; I didnt make these posters, I just printed them out to help my team.

It sounds like the management are claiming to be doing Scrum; I would hope that means they want to be doing Scrum. Can you nudge them into the right path?

You should show the value of Scrum the best way to do this is to prove it in a new project or product.