Henrik Kniberg, author of the popular book “Scrum and XP from the Trenches,” shares some experience on how to implement Scrum. The bad news: There will always be some pain. The good news: There is potential for immense improvement.

What are the general things to think about when implementing Scrum?
“First of all you need a clear goal. Why are we implementing Scrum? What results do we hope to achieve? To most companies, the answers are things like:

• Improved productivity.
• Faster time-to-market.
• Improved team motivation.
• Higher customer satisfaction.

Secondly, you need people that are generally positive to change. Implementing Scrum will reveal organizational problems fairly quickly, usually problems that have been deeply embedded in the company for a long time. This will hurt, sort of like when the dentist starts digging around in cavities that you didn’t know you had. If there is no willingness to spend time discussing and fixing these problems, if everybody is happy with the current process and not willing to question anything, then you might think twice about implementing Scrum.”

Some companies choose to implement Scrum with a big bang and some choose to do it step by step. What pros and cons do you see in these alternatives?
“I’ve tried both and I can’t say that I prefer one or the other – the decision is very context-dependent.

• Incremental implementation hurts less, but hurts over a longer time. It’s like pulling out one hair at a time. If the current processes are working fairly well, I would lean towards an incremental approach. It gives you time to experiment more and generate buy-in as the process spreads naturally throughout the organization (Scrum is quite contagious). The downside is that you get “impedance mismatch” with Scrum teams having to interact with waterfall teams or customers that don’t “have time” to talk to the team.

• Big bang implementation hurts more, but only for a short time. It’s more like pulling out all your hair at once (ouch!). If the current process is significantly flawed, I would lean towards a big bang approach. Especially if we believe that the new process ‘can’t possibly be worse than what we have now’ (a fairly common argument for big bang). You really have to build a strong commitment from everyone involved first. The upside is less impedance mismatch – no neighboring waterfall teams to grind against. The downside is that it will be quite chaotic at first, since we are likely to get many things wrong initially.
It is extremely important to quickly get over the big bang phase and get back to a steady rhythm of incremental improvement. So big bang doesn’t replace incremental implementation: it is just a way to kick-start the whole thing.

What lessons have you learned personally when implementing Scrum?
“That Scrum works. That doesn’t mean Scrum is the ultimate, perfect process-to-end-all-processes. It just seems that the traditional way of developing software is so riddled with waste that even a poor implementation of Scrum causes significant improvements in short time.
Just getting people to talk to each other instead of hiding behind documents and tools is an immense improvement. The downside to this success is that many companies implement Scrum only partially and then stop, not realizing the enormous benefits that can be achieved by going all the way.”

Sometimes you hear people say that “Scrum is not enough”. What is your reaction to that statement?
“They are right. Scrum is just a framework. It doesn’t say anything about how to write code, how to test, or how to brush your teeth. You need to fill in the blanks yourself. Here are some example of nice complements to Scrum:
• XP for the engineering practices
• Lean practices such as Value stream mapping and one-piece flow to find bottlenecks and decide where to create Scrum teams and backlogs.

There is a pattern we’re seeing with some of our clients now. Some teams (usually within maintenance and operations) find that, although Scrum works better than what they did before, it feels unnatural and wasteful to batch work into sprints. So we help them experiment with one-piece flow (also from Lean) using techniques such as Kanban boards. Sort of like Scrum without sprints (although I wouldn’t really call that Scrum).
Scrum is a great tool. But it is certainly not the only tool, and should never be used alone. That would be like a carpenter with only one really good hammer and no other tools …”