OK, it is one thing to believe something called Scrum (or agile, kanban, lean, you name it) will easily fix you broken process and it is another to take Scrum in general the orthodox way. With the former I’m with you. You can send a few people to Scrum training but most of the time it won’t fix broken process unless most of the people are committed to improve. And then it can be any consistent method which would do the job.

On the other hand: is Scrum a methodology? Yes. No. Maybe. Depends how you use it. Depends what you understand as Scrum. Depends on modifications you’ve applied. Depends on hell lot of things. You want it or not Scrum became a buzzword which can mean Scrum by the book implementation or well-thought, Scrum-based custom approach or old crappy process with addition of daily stand-ups.

You can be perfectly right with your skepticism when people tell you Scrum is their methodology but the other team can be totally puzzled with your questions. Depends on situation. Depends on context.

When I hear some company is agile or works with Scrum I’m naturally skeptical since these terms are so often abused these days. But I’m equally skeptical when I meet people who put too much weight into labels. After all these aren’t labels which write the code.

It’s tempting to call Scrum a meta-methodology. I’m not sure that’s entirely accurate, but it’s at least a pointer in the right direction. It’s hard to wrap your mind around though. I think Scrum is misunderstood because this idea is so radical and counterintuitive.

Hearing a client tell me “we use Kanban with a set of best engineering practices” (or even “we don’t use anything specific”) would be great. It would mean the client really does understand the engineering process — and while they may be looking for ways to improve it, at least they know what they’re doing.

The reason I care about this kind of thing is simple: More often than not, it’s my job to “fix” (or “de-risk” or “improve the process”) situations that are out of control. Often a great deal of the problem stems from a few root causes, one of which can be a complete misunderstanding of what Scrum is. By fixing the vernacular and finding a way to express how complex software and hardware engineering really is, it becomes clear how a more formal method may help solve a problem. It also helps dispel the belief that sending a few people to Scrum training is going to deliver a complete engineering process and solution to a customer’s needs. (These are worst-case situations but they do show up!)

Thanks for the comment! Hope to see you back again.

Very true. The most important bit is to get the conversation started. Inevitably, it rolls around to why Scrum is “failing” (in the customer’s eyes, at least) — next comes the education phase in which Scrum is properly positioned. Somewhere along the line, the lightbulb comes on as the customer realizes that Scrum is a great tool, but not the right tool for every problem. That leads to selecting the right tool (proper development methodology) and implementing a solution.

Good point — thanks for making it!

1. What methodologies would you recommend for teams considering using Scrum as a management process? I know there won’t be a single answer, a few candidates would be okay.

That is more or less the root of the problem. Without knowing the parameters of your particular situation, it’s impossible to recommend a methodology that makes sense. For instance, if I were to suggest Rational Unified Process, I might be pushing you toward something that has far too much process and rigor for what’s needed in your environment. Likewise, to suggest Extreme Programming could do you a disservice unless your team was senior enough, and the project simple enough, to fit the methodology.

2. Do you feel this misunderstanding of Scrum as ‘methodology’ is the reason Scrum is taking so much heat?

Yes, at least to a degree. Many of my clients have been expecting Scrum to be ‘the solution,’ without gaining a proper understanding that it can’t solve all their problems. The expectation is: Send a few people to get Scrum certified, and we’ll be all set with a comprehensive methodology we can apply throughout the company. Unfortunately, the team members that go to training rarely come back saying “wait a minute, Scrum is great, but it’s not going to get the whole job done here!”

Personally, I think Scrum is fantastic — but, it doesn’t address the methodology end of the problem. For that you need an awareness that your team/organization needs Scrum as well as something else. This is one reason Rational Scrum was born, because it provides a “single solution” to the problem by delivering both management process (Scrum) and a development methodology. But, it’s only one solution and it fits somewhere in-between the XP-methodology and RUP-methodology, so to speak. Depending on the amount of rigor you need, you have to choose the right methodology. Spacecraft tend to need Waterfall, while social networking sites work great with Agile methodology.

Actually if you wanted to have all these labels most of the time you’d hear “we don’t use anything specific” answer since many companies just use some of best practices along with common sense as their software development methodology.

If you asked me what do we use I’d answer it is Kanban supported with a set of best engineering practices and a lot of common sense. As far as I know we don’t follow anything specific. Does it mean we don’t have methodology? Come on, what a question.

And after all, who cares?