Over the last year or so I have seen a lot of hate directed at Scrum. There has been bashing at industry events, articles on respected websites about its failures, and just today I read another op-ed blog via Facebook link from a friend of a friend calling for the end of Scrum. The message is that using Scrum means you will have no documentation, have no way to know if you are on schedule, have no way to know if you are in budget, waste time on useless process, unfairly pressure team members, have low quality, and probably not ship your product. And (possibly) its proponents know this — all the while taking in that sweet, sweet consulting money.

Solutions range from going back to Waterfall ("what you have to use in the real world anyway") to having almost no process at all ("how startups can be so productive") to figuring out for yourself what works for your organization ("because every person and every organization and every project are so infinitely varied that there's no way to know what will work").

Let me clarify some terms. Scrum —BTW, not Scrumm, not SCRUM, not S.C.R.U.M. — is a methodology for project management. It is based on Agile principles, which are a reaction against Waterfall development (that I think are fair to characterize as "classic project management"). Other Agile-based methodologies include Kanaban, Lean Development, and Extreme Programming (XP). You could say that Agile became official with the creation of the Agile Manifesto in 2001. An excellent article on Agile (that is not too long to read) can be found on Wikipedia.

In the interest of full disclosure I like Scrum. I am a Certified ScrumMaster. I have served as a ScrumMaster/Project Manager on only one project with Scrum, and it was cancelled. By trade I am an engineer. I use a simplified version of Scrum on my personal, one-man projects. For the past 6 years most of the teams I have been on have used Scrum-like (Scrum-fall? Agile-esque?) methodologies. For over 15 years before that I used Waterfall.

The Scrum principles and practices that I value the most are:

Does Scrum work better than nothing? Yes. Does Scrum work better than Waterfall? Usually. Is Scrum the best possible way to manage a project? Probably not. Will strict adherence to Scrum practically guarantee a project's success? No.

Do you remember that one time you were on a project and it failed? Were you using Scrum? That must be why it failed! Or maybe there were other reasons. Let me come to Scrum's defense and offer some other explanations for your consideration, starting with the specific and moving to the general.

Not Actually Scrum

If you can say any of these things about your project you are not using Scrum, i.e. "you're doing it wrong":

Scrum has these required activities:

Scrum has these required artifacts:

The Scrum team has these required roles:

Did that failed project have all of the above? It hardly seems fair to blame Scrum if you are not using it properly. It's like dressing your your dog in people clothes and complaining they won't stay on. Buy dog clothes (or dress people).

Lack of Scrum Experience

Let's say you have a team of martial artists that go to Karate competitions. There are a wide range of skill levels, but you all do Karate. Your teacher has been doing this for 20 years. One day your parent organization decides to stop participating in Karate competitions and only participate in mixed martial arts competitions. Because of the success of Brazilian Juijitsu in these competitions you are to adopt that style.

Your instructor and other black belts go to a two-day Brazilian Juijitsu training. Every practice after that they teach the new style. Out of 10 or so core techniques your team manages to do about 2 right. You keep wanting to punch and kick, but your instructor keeps telling you to grapple. At your first competition every fighter loses. Afterwards your disheartened team debates the merits of Juijitsu. Many think that you should have stuck to Karate — even in a mixed martial arts competition. Some think you should have just stuck to Karate competitions. Your parent organization is very disappointed in your performance.

When a whole organization changes the way they do things without a critical mass of knowledge or experience in the new way, it is unlikely that they will be able to succeed. In particular your leadership needs to know the way to do things; it needs to be second nature.

Lack of Cooperation

More than just lack of teamwork (not supporting each other), lack of cooperation is when your team doesn't support the process. Whether it is failing to close Jira tickets, not bringing up blockers in the daily standup, or not providing feedback in the retrospective, lack of cooperation will ruin Scrum.

People don't cooperate when they don't believe in the process, they don't like change, they "just want to do their job", they want a different job than they have, they are lazy, or they just don't care. If you just read that sentence and thought, "That sounds like most people I work with," then a) you are probably right, and b) Scrum may not be right for your team. Guess what, though. All of those things are detrimental to any development methodology.

We have been using traditional project and people management for so long because it's built on the premise that people are terrible (paraphrasing), and we need rigid structure and hierarchy to coerce them into doing what we want. It doesn't prevent "lack of cooperation", but rather mitigates the damage. If you believe that's the way it has to be then all I can say is that personally I have been on several teams that were highly cooperative and highly functional.

Lack of Resources

Your team has a project to complete. You "may not" have enough resources to complete the scope within the schedule. (It has been known to happen.) Maybe you should realistically have 6 engineers and you only have 4. Or you have 6 with little relevant experience. Or one guy is a rogue coder and actually a liability. No matter what methodology you use, magic you weave, or gods you pray to, your lack of resources will prevent you from delivering your scope on schedule. Take an honest of assessment of your resources and balance your schedule-scope-resources triangle.

Bad Project Manager

How do you know when you have a good project manager? For starters they can (based on all currently available information) answer these questions immediately:

Additionally they pay attention, continually gather data, and periodically re-assess the answers to those questions.

A few years ago I was following another team developing a product I was interested in. For nine months their "project status" was green every week with an occassional yellow that was quickly corrected. One week before launch they went yellow. The next week, not having shipped, they were red. They said they needed time to figure out how much longer it would take to ship. How much time before they knew? One month. They stopped reporting status. After a month they presented a new schedule. Shortly after that the project was cancelled. Do I blame the engineers, the methodology, the technology, or the industry? No, I blame the project managers. They had no idea what state the project was in until one week before launch. How can you plan, execute, and measure (using any methodology) for 9 months and not know that you are not on track?

Bad Business Manager

Above the level of the project is the business. The project only exists in the context of the business goals of its organization — or at least that should be the case. It is the job of the business managers to know what business they are in, what projects should be undertaken, and how to measure success. It is important for the business managers to communicate these things to project managers. In terms of Scrum, the business managers are usually the Customer.

Sometimes a project is doomed from the beginning because it is a bad business decision to even start it. For example:

The best case is for this to be recognized and the project cancelled early. The worst case is to complete the project, spend marketing on it, then see it fail. Most likely, in my opinion, is that three quarters through the project business managers will finally realize that path they are on and cancel the project. In any case I think most will agree that the development methodology has nothing to do with the failure.

Even if starting a particular project is not a bad business decision, it can fail due to lack of communication or focus during development. From personal experience on a video game project, here are the changing messages I heard:

This project used Scrum, and we Agiled the crap out of it through changing business requirements, but in the end it was cancelled.

Conclusion

Scrum in not a silver bullet. The success of your project depends on many factors other than your development methodology — some of which you have no control over. Do what you can to make the best of your project. That might mean adjusting the team, reducing the scope, cancelling the project early, or even moving away from Scrum because it is not the right tool for you. You are empowered and responsible for your project. Don't blame Scrum.