Blogpost: Why Scrum is fundamentally broken (but we still use it)

The simple answer to not delivering on time is not that Scrum is flawed, but rather poor release planning and estimating. This is an extremely difficult job to do, even for something fairly simple, let alone something as complex as a video game. However, it's not Scrum's failing, but rather the failing of dealing with anything sufficiently complex and changeable that accurate estimates are very difficult to come by. There's much too much that's unknown at the beginning and you make this clear in your post by saying that without sprints the requirements would change every day. Accurate estimates when a lot is unknown have to be large ranges, but marketing, sales and other functions of the organizations don't like ranges. They need to announce when the game is going to be released, and whether or not you have sufficient knowledge to predict how long it's going to take, you have to deliver it by then. Unless the scope is flexible, this usually results in people working at an unsustainable pace and buggy software, whether in game programming or anything else. Scrum doesn't fail here. It's just the nature of the problem and there's no solution to it other than changing the problem to be one of greater predictability or letting scope be flexible if you're going to fix the ship date.

I would like to also take issue with your understanding of "potentially shippable". The purpose of this is simply to convey that what you've completed to this point is "done" according to your definition of done and to drive down risk and drive up value as early as possible. You get it right in several points of your blog post by saying you work at the most important work remaining during any given sprint. However, because you complete that functionality doesn't make the entire product complete. You may (should) have put something together during release planning (not part of Scrum) that establishes a minimal shippable increment. Even if every sprint is done according to the definition of done, not everything has been completed in order to be shipped. You gave the example of requirements that console manufacturers give game makers. You're right that these should not be done first. They have to be done before the game is released, but because these requirements aren't met doesn't mean that the work you've completed to that point isn't done.

I also take issue with your claim at the end of the post that Scrum is bloated with too many rules. There are actually very few rules in Scrum and it's very simple. If you compare this to actual "methodologies" (of which Scrum is not one), the number of rules of what to do at any point are quite limited. Try CMMI some time, or Six Sigma. Sometimes this degree of control and rigor is required (building software for manned spaceflight, for instance), but not for building most commercial software. Scrum is lightweight in the extreme. I would say that if you feel that there are too many rules in Scrum, then you're either used to cowboy coding (where there are no rules), or that you're doing it wrong.

Let me just re-emphasize that determining deadlines and hitting them is not really a province of Scrum, but rather of release planning. You won't find "release planning" or "deadline" in the Scrum Guide. Maybe you see this as a problem, but it's deliberately agnostic on this point, just like it doesn't say you have to do TDD to do Scrum. There are lots of ways of determining what your release backlog is going to be and how much time it may take to get that done, but because human beings are fundamentally not very good at estimating complex problems where there is considerable uncertainty, this is built into most software development no matter how you approach the construction of the software itself.

Hi Joost,

I can feel the frustration. Using Scrum for game and mobile development is tough! One thing we need to understand is that Scrum never promise that it will deliver the defined scope at a defined date. I also disagree that during the Sprint the plan can not change, it is the Sprint goal that can not change but the plan, which is reflected by the Sprint backlog, can change (and will change from my experience).

So can you share with us how you use other project management methodology to meet deadlines?

> Console manufacturers provide long lists of certification requirements.
> If the game fails to pass their tests, it cannot release. Since the number
> of requirements is so large, implementing all of them is a very big task.
> For a game to be "potentially shippable" after every Sprint (as Scrum
> requires) the certification requirements should be implemented first.
> Which is a horrible idea

No, it isn't the certification requirements that need to be "implemented first". Those requirements are a quality invariant that should be captured in the Definition of Done. It is simply the ability to pass certification that has to be addressed during the Sprint. In other words the risk of not passing certification has to be mitigated. If that risk is reduced to an acceptable level then the increment can be considered "potentially shippable". A broadly similar situation can exist with the incremental delivery of life critical systems where FDA approval is needed.

Failure to take care of this will cause technical debt to accumulate throughout the development of the increment, and waste will be incurred should rework be needed to pass certification. Incidentally, managing the risk of such wastage isn't just a Scrum thing, it's a core precept of lean and agile practice in general.

Thanks for the replies, folks! Really interesting! :)

JackOLantern:
... Scrum doesn't fail here. It's just the nature of the problem and there's no solution to it other than changing the problem to be one of greater predictability or letting scope be flexible if you're going to fix the ship date. ...

The reason I call that a failing of Scrum is that I actually visited some Scrum courses where the trainers said that Scrum would make you meet deadlines. If Scrum doesn't really claim to do that, then of course Scrum does not 'fail' in that regard.

However, meeting deadlines is one of the most important goals of project management. Either by working more efficiently or by doing better estimation so you can set less unrealistic deadlines. I am not aware of any methodologies that 'solve' this problem reall well though. I am just concluding that Scrum does many things well, but does not provide a really good solution to one of the most important issues.

JackOLantern:
I would like to also take issue with your understanding of "potentially shippable". The purpose of this is simply to convey that what you've completed to this point is "done" according to your definition of done and to drive down risk and drive up value as early as possible.

The only reason I took such a literal interpretation of "potentially shippable" is those Scrum trainers who claimed that Scrum would make you meet deadlines because whatever you had at the last Sprint was releasable. If "potentially shippable" is interpreted in a more lenient way, then their point falls apart. I totally agree with you that it shouldn't be used to literally. :)

JackOLantern:
I also take issue with your claim at the end of the post that Scrum is bloated with too many rules. There are actually very few rules in Scrum and it's very simple.

Scrum is lightweight compared to most other methodologies, but still most trainers cannot fit all of the core principles into a presentation of one hour. Just look at the Scrum Wikipedia and you'll see that there are a lot of different meetings and artefacts that you need to know about to do Scrum well.

Joshua Partogi:
So can you share with us how you use other project management methodology to meet deadlines?

I am not claiming to have a better solution, only that Scrum does not solve the very important problem of meeting deadlines, while some Scrum trainers say it does.

Ian Mitchell:
No, it isn't the certification requirements that need to be "implemented first". Those requirements are a quality invariant that should be captured in the Definition of Done.

Unlike what I suppose you seem to think, certification requirements are not something that you just need to keep in mind with everything you build. There are a lot of requirements there that every game developer just needs to implement separately and the whole set of requirements can easily take months to build, especially for developers who are new to console certification.

Some requirements are part of a system (like error handling), so you might argue that those should simply be implemented with the system. However, those are often so much work to get completely right that in game development it is generally much smarter to implement them at a later point. For example, in practice it is best to juist build basic file reading and handle the gigantic set of error handling rules later, so you can first focus on whatever is needed for the game itself.

> certification requirements are not something that you just need to keep in mind
> with everything you build. There are a lot of requirements there that every game
> developer just needs to implement separately and the whole set of requirements
> can easily take months to build

If you don't release for several months then you will end up with a huge batch of work, all of which represents risk. The challenge is to find ways to mitigate that risk and this is where Scrum adds value.

Out of all of those requirements that can easily take months to build, some can be built in the current sprint and elevated to an environment that takes them closer to production. Each sprint can and should increase this potential for release. It's a journey that has immediate benefits as it allows a team to reduce the risk that is inherent in owning a large batch size.

Hi Joost,

I would say that Scrum actually solve a much more important problem than just meeting deadlines, which is maximizing product value. There are far too many products that is delivered on time but with low value. The whole paradigm shifted from project point of view to product point view.

Posted By Joshua Partogi on 25 Mar 2014 02:23 AM
Hi Joost,

I would say that Scrum actually solve a much more important problem than just meeting deadlines, which is maximizing product value. There are far too many products that is delivered on time but with low value. The whole paradigm shifted from project point of view to product point view.

Ideally I would have a method that solves both problems, but yeah, I do agree that Scrum is great at maximizing product value and that this is a great thing. :)

Let me know if you found a method that solves both problems. I would probably use it too. :-)