Daily news, dev blogs, and stories from Game Developer straight to your inbox
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
Don't Blame Scrum
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.
February 9, 2016
10 Min Read
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":
"We don't do a daily stand-up because people are on such different schedules."
"We stopped making burndowns because they all looked the same. Everybody finishes all their tasks the last day of the sprint."
"Our backlog didn't allow us to be agile enough, so we just plan the next sprint based on what we learned from the last sprint."
"Our lead engineer assigns tasks and hours to everybody."
"We get a lot done every sprint, but I don't know when we are going to be done. I don't see the long-term or even the medium-term."
"One gal on our team is the ScrumMaster and the Product Owner. Her boss tells her what features we need to work on and when they need to ship."
"I almost always finish my tasks early and then work on other projects, but nobody else every finishes all their tasks."
Scrum has these required activities:
Product Backlog Grooming
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:
When will the project ship?
What features will be included?
Who is on the team between now and the ship date?
Bonus: What is the budget?
What are the dependencies and assumptions?
What are the risks, impacts, and mitigations?
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:
No consumer demand
Unfavorable market timing
Competes with another product from your own company
Does not fit in your company's portfolio/brand
Inaccurate cost/benefit analysis
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:
"We want a Facebook game with this licensed IP and a fast time-to-market."
"This game needs to launch at the same time as the console game so we can cross-promote."
"Let's have activities in this game affect the console game."
"This game is not ambitious enough for the IP. Forget the console tie-in and redesign the game."
"2D will not do justice to the IP. Switch from Flash in 2D to Unity in 3D."
"Instead of Facebook we need to be on mobile."
"Put less focus on combat and more on player progression and monetization."
"Combat needs to be more fun."
"We don't have confidence in the market viability of this product."
This project used Scrum, and we Agiled the crap out of it through changing business requirements, but in the end it was cancelled.
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.
Read more about:Featured Blogs
You May Also Like
Exploring the 2024 State of the Game Industry report - Game Developer Podcast ep. 39Feb 2, 2024
Phantom inspiration and the ethical auteur with Xalavier Nelson Jr.Dec 8, 2023
Designing Killer Queen: from playground experiment to modern arcade sensationOct 18, 2023
Rod Humble and King Choi illustrate the ambition of Life By YouSep 22, 2023
Get daily news, dev blogs, and stories from Game Developer straight to your inbox
Subscribe to Game Developer Newsletters to stay caught up with the latest news, design insights, marketing tips, and more