This post switches gears a little from my usual stuff, but it’s something I feel quite strongly about so I thought I’d post it. A while back I spent some time at a previous employer, playing poker, sprinting, spending a few minutes each morning in “the War Room” and generally dicking about with Post-It notes. In this post I aim to discuss a little about the scruming process and what I believe are its flaws. This post is a jab at scrum and a swipe at the way it’s haphazardly forced upon many studios by corporates after sending someone on a 3 day course and giving them a couple of books.

1. Something has to give!
It’s true enough… Something always has to give. When we consider programming and scrum that “thing” invariably ends up being testing as programmers try to cram as much code in as possible to sign off the user stories by the end of the sprint (why they do this is beyond me, and as you become more versed in the bullshit that is scrum you become acutely aware of one truth, there are no consequences for failure!). When you work in games with people who’ve been around the block (apart from all the cool hacks and craziness) you’ll occasionally get to hear these horror stories about people hacking “features” together to a standard that is just enough to pass a publisher milestone and then re-doing them completely later on in the schedule, sprinting makes me feel like I’m working at an indie developer in the early 90′s.

2. Programmers suck at planning.
Okay, so perhaps this is a little unfair, but planning and estimating things is hard, no matter how hard you try you’ll probably always end up with massively underestimating or overestimating the amount of work for a given task. When it’s the latter, user stories inevitably slip back to the backlog… This doesn’t really matter, as you can just pick them up again on the next sprint, no harm done, right?

3. Tech is implicitly unpredictable.
When you’re working on things that have never been done before, as is often the case at leading edge development studios your job is intrinsically unpredictable. Planning things that have never been done before is pretty tricky. Scrum advocates will claim that scrum forces you to break things down and yeah breaking them down is helpful, but this isn’t really an attribute of Scrum. Any sensible coder will just do this anyway.

4. Iteration is unsupported.
Look at any top game out there, what makes it have that 90+ metacritic? Okay, strong gameplay, style, originality, shit hot graphics and whatever else, but a big part of it is polish. Polish isn’t really quantifiable, it just takes time and effort and a love for the work. Look at your Drake’s Fortunes, your GTAs or your Geometry Wars. Polish is what makes these games great and guess what? It is entirely unsupported in scrum. I would argue a user story early in the production cycle simply can’t be delivered if it states “final quality”.

5. Why do I get a say?
Why do I have a say on art tasks? From a technical standpoint, I can appreciate that some degree of core technology opinion and influence is probably healthy, but in the main I have as little business telling an artist or designer how to model a character or design the flow of a level as they do telling me the best way to optimise pre-pass lighting on the SPUs. Lets face it, artists (in the main) know nothing about code and vice versa. Scrum teams mixing disciplines give everyone a say on everything… See point 8.

6. Scrum != Agile.
Is it just me, or is taking an entire sprint to react to changes not very agile?

7. Less done.
A simple equation…
More time fucking about + more time planning to work = less actual work done. But hey, we get to look at those pretty little, (hopefully, but mostly not) monotonic burn down charts in Hansoft right? Awesome!

8. Too Many Coders Spoil the Broth
Having four people actively developing, refactoring and writing the same systems together is usually stupid. It might increase knowledge, but it reduces code quality, increases hassle and creates bottlenecks because scrum rigidly insists that problems have to be tackled in priority order. Pair programming I don’t have a problem with, in fact I think it’s great, but again this isn’t a scrum-only thing, coders have been doing this for years.
Simple Tip: If you need to share knowledge (and simply talking to your co-worker who wrote the software in the first place won’t suffice), then just have your producer build in time for documentation…

9. Forced Demonstration
Making teams demonstrate user stories are complete in really contrived fashions is nothing short of retarded It wastes my time and the time of the poor, unfortunate senior manager paraded out every month to review your changes. If I have a user story to optimise a function what benefit is it to anyone if I produce a document demonstrating this to be the case? I’ll give you a hint: Fuck all. So what detrement is it? It wastes time, which wastes money, it makes other user stories slip, it invokes a mini-crunch to get features demonstrable (which is bad for morale) and if you fail the user story because the document or demonstration scenario wasn’t written properly, it means more farting about planning to repeat the entire exercise next sprint!

10. Maximum Churn!
Having a bunch of coders commiting code into a branch when you’re trying to get a build together is bad enough. The amount of code churn that results when a scrum team collapses an entire sprint’s work into a development line at the same time that several other teams do the same? That just completely sucks. This may sound a little anti-branchy but it’s really not. If there features were continuously integrated from a team’s branch there would be no problem. Of course, nothing in Scrum prevents this from happening, except of course in reality that it’s more time that you need to account for in your sprint plans up front, who’s to say that another team haven’t modified a load of stuff you’ve also changed and caused you untold merge pains?… It’s also something that will slip at the first sign that you’re going to miss the deadline for your user stories.

Are there any positives? In short nothing that one can really attribute to the scrum process. Team communication, pair programming and breaking tasks down are things that good programmers and teams will do anyway. I must stress before signing this rant off that these are just my opinions of scrum that I’ve experienced first hand, it may not be the same for everyone else, feel free to post any comments you have on the matter, it’d be good to hear from anyone who’s had a positive experience of the scrumming process. :) If you’ve made it this far, thanks for reading and see you soon!

Ste


Trackbacks/Pingbacks

  1. Tweets that mention SPUify.co.uk » Blog Archiv » 10 Reasons why Scrum sucks for Games -- Topsy.com
  2. THE PM MATRIX » When Coder’s Attack!!! Geek Aggro oh noes!!!:

13 Comments

  1. David Lovegrove says:

    In my experience no one single software process will solve all given problems. The problem with rigid processes is that you end up doing paperwork for what feels like no good reason. What you need to do is evolve a process and learn what you are doing wrong in that process. You might be interested in the PSP. In short, it outlines a process wherebye you track bugs not only in implementation but in all stages. This teaches you how to improve your process and it also helps you realise where you need to refine the documentation etc. I found that the first iteration of applying this system i customised the template documentation to taylor it to our team. Works nicely.

  2. Sam Martin says:

    Ah, the joys of software development ;)

    In seriousness, I think the main thing I believe you miss if you just ditched scrums/iterations/sprints is you run a huge risk of never actually really finishing anything. Sure your code base gets bigger and you have more features, but you can actually fail to iterate and polish and produce anything you can actually ship unless you force things to come to a close periodically. From my experience, I think this is the single biggest thing teams need to ensure they do – make sure things are really getting ‘done’. Where done means bug free, in use by artists, actually in the game. All the other details are sort of a means to that end :)

    Or perhaps you could think about it from a different point of view – actually empowering you to iterate. If you never really put stuff to bed properly you eventually trip yourself up in mess :) .

    You might be interested in this video, which I thought was a good argument in favour:

    http://video.google.com/videoplay?docid=-7230144396191025011#

  3. Dave Mariner says:

    This article should be more accurately entitled “10 reasons why anything done badly sucks for software development!”. Why not write an article about sending someone on a 3 day course on parallelisation giving them a PowerPC book, then complaining about how a game they were responsible for porting to PS3 sucks? Scrum doesn’t necessarily suck for games, it just sucks if it’s badly implemented! There is *no* silver bullet – but then again, scrum never claims to be one.

  4. Ste says:

    @Sam, I watched a chunk of the video you linked during my lunch hour (but I confess not the entire thing, yet). I think perhaps a major contributing factor to why I dont like scrum is that don’t tend to have to have shippable products after every sprint in the games industry, so what is the point in pretending that we do? We know our ship dates months and years in advance and are able to gear our deliverables to those ship dates, in the form of sensible milestones and alpha and beta builds. Sure productions that aren’t managed by scrum are by no means perfect and I don’t pretend to know what the right answer is, all I know is, it doesn’t appear to be scrum ;-) .

    @Dave, Thanks for your input and opinion, it is appreciated. I see your point and maybe there is a degree of that here, as I say at the start the post; it is written in the context of my experiences. Although, to answer your point directly, the reason the article isn’t about bad PS3 games is that the practice of giving someone a book on PowerPC and asking them to port to PS3 doesn’t tend to go on very much, at least I’ve personally not seen it, maybe it’s different at your studio? :) . If you have the time I’d be interested to hear in which ways the scrum practises I mention above are badly implemented (I’m sure they are, but in many cases they seem to just follow the advice of scrum gurus almost to the letter… Maybe that’s the problem in itself?)

    Ste

  5. Tim Gradwell says:

    Hi Steve. Your post got me thinking – I’ve posted a response on my own blog.

    http://programmingforpeople.blogspot.com/2009/11/10-reasons-why-i-like-scrum-for-games.html

  6. Hi Steve,

    Thanks for posting your experiences and opinions. As someone who focuses on adopting Scrum for game development, I’m always interested in hearing such stories. There are plenty of examples of successful games developed using Scrum as there are plenty of stories like yours.

    I’d love to dive in a discuss this point by point with you and learn more. The goal is not to change your mind, but to learn some of what happened with your particular adoption of Scrum. I hope we can catch up someday at a conference.

  7. Stephen Gaffney says:

    Good piece. I can see where/why these failure occur, because I’ve had them happen to me as a scrum master.

    In my experience, Scrum is doomed to fail if all the people involved in the project do not understand and stick to their roles. Most people incorrectly believe that scrum is a way to allow complete flexibility and no planning. It’s just a pre-described way of managing/coping with randomness by structuring regular planning/inspection/adaptation that some people have found works for them because their culture (both internally/externally) allows it to work. And it requires A LOT of planning, organisation and communication.

    The over arching goal is to allow the development team to have more control over their own work by focusing on regular delivery. It requires everyone involved to have complete trust in each other. It’s a perfect world system, but we live in an imperfect world.

    To comment on a couple of your points: I don’t think having a gfx programmer working with an artist for the sake of it is a good idea either. You shouldn’t be estimating someone’s work in planning poker if you have no expertise in their field. Scrum isn’t supposed to stop you using your common sense. If you’re working together to establish metrics/develop a new feature/prove new tech etc, then it makes total sense, but if you’re not working together for a fixed period for a common end, why are you in the same sprint? And while talking about art, scrum doesn’t really work for pipeline/process driven work like high poly/low poly game art. There are better ways to manage that.

    Demonstrations? It would be better to demonstrate the results of the sprint in a holistic manner, not every user story by rote. Whoever made you do that doesn’t understand the spirit of scrum, or why it’s supposed to work.

    Development needs to happen in a systematic way using whatever methodology works for the people using it. Otherwise your development success/failure is the result of randomness.
    *Any* methodology is only as good as the people using the system. You need a really talented Product Owner who has the trust of everyone to keep it together. If there’s anyone not doing what they’re meant to be doing or governing it officiously for the sake of it, it will fall apart.

  8. SeanOfBoston says:

    Unfortunately, this whole crap is designed for MBAs of McDonald style. Companies are usually run by marketing people who believes 2 hours of night school provides more insight than years of hard working.

    Every few years, some quacks would either sell common wisdom under a new name, or sell something which is totally against common wisdom. As to Scrum, depending how to use it, it could be easily hijacked by corporate thugs.

  9. Wow! So much I could say here but I’ll try to be brief and limit myself to one of your points.

    Your point 6 Scrum != Agile. I think you’re building a straw man argument here. Scrum does not state that you have to wait for an entire Sprint before reacting to change.

    The idea behind protecting the content of the Sprint is to let the development team concentrate on a series of tasks without interruption – to make product development more efficient.

    However, the Product Owner can stop a Sprint at any time. They need a good reason for doing so though, but a vital change would constitute that.

    Can I offer a flip-side to your view as well and ask you to consider this article:

    http://www.webgateinternational.com/2012/05/top-10-reasons-to-use-scrum-instead-of-waterfall/

    Cheers


    Derek

  10. Gabrielle says:

    1. Something has to give!
    It’s the teams decision to take the work on and figure out how to get it done. The team should reflect on why they all try to get finished and fix that issue. One way for example would be to focus on completing a user story fully rather than have 8 in progress that all need to be done at the end. The team should figure this out as Scrum will make a problem visible but the team has to fix it.

    2. Programmers suck at planning.
    Estimating is really flawed which is why Scrum is silent on what you do here. People assume planning poker and story points are a Scrum thing but they are not. The latest Scrum guide deliberately leaves it out. Value should be tracked not effort if you want to get the right outcome, not just a lot more output. If you suck at estimation stop doing it!
    3. Tech is implicitly unpredictable.
    Re: Scrum advocates will claim that scrum forces you to break things down and yeah breaking them down is helpful, but this isn’t really an attribute of Scrum. Any sensible coder will just do this anyway.
    Ahhhh so here you hit the core of it. Scrum was based on empirical evidence of practices and principles that worked in real life. This stuff has existed since the 60’s (documented) so right, nothing new which is why we know it works. It has been used over and over for decades but nicely packaged and spelled out in the simple Scrum framework.
    4. Iteration is unsupported.
    Re: Look at any top game out there, what makes it have that 90+ metacritic?
    I was speaking the head of Apple innovation labs many years ago and said ‘so how does Apple come up with such innovative ideas? What process do you use? The answer was basically f***ed if I know (probably said nicer). Games are like that – having the best process won’t give you the best game be it Scrum, waterfall or Aunt Dorothy’s secret framework. You know that old saying ‘slapping lipstick on a pig’ – well putting polish on a game still won’t make it great if the gameplay sucks. So I agree polish is necessary, Scrum never said it wasn’t did it?
    5. Why do I get a say?
    Re: Why do I have a say on art tasks?
    Scrum thinks have special skills is just fine but not if that’s all you do and you create a single point of failure. That is really risky. If there is a lack of some skill that you can pitch in and add value, then do so. There is a concept called ‘T-shaped people’; they have a core skill (think art etc) but can give some help in another area (maybe some testing). The idea is to share ideas to build knowledge, that doesn’t sound too bad right?
    6. Scrum != Agile.
    Re: Is it just me, or is taking an entire sprint to react to changes not very agile?
    Probably just you☺ Seriously, fix that. If shorter sprints won’t work then maybe you need to be more flow-based and build a kanban type approach depending where you are in your cycles.
    7. Less done.
    A simple equation…
    Re: More time fucking about + more time planning to work = less actual work done. But hey, we get to look at those pretty little, (hopefully, but mostly not) monotonic burn down charts in Hansoft right? Awesome!
    Scrum advocates try to get people to stop using tools that cause more pain than gain. Oh and get rid of all the fucking about too. Not sure why a one hour meeting to plan out the week of work and like 10 minutes of meeting each day, plus a one hour review and one hour improvement meeting (and these are max timings) per week add up to a whole lot of pain?
    8. Too Many Coders Spoil the Broth
    Re: Having four people actively developing, refactoring and writing the same systems together is usually stupid. It might increase knowledge, but it reduces code quality, increases hassle and creates bottlenecks because scrum rigidly insists that problems have to be tackled in priority order.

    It’s up to the team to figure out how to get the work done and to remove bottlenecks. Plus priority order – based on value and risk at the start of the Sprint, once in the Sprint the team figures this out so not sure why this is occurring but it should be fixed.
    Re: Pair programming I don’t have a problem with, in fact I think it’s great, but again this isn’t a scrum-only thing, coders have been doing this for years.
    Again yes, all based on things that work in practice not meant to be a ‘we invented it here’ syndrome. Scrum was based on research by IBM, Xerox park and Japanese lean companies not from a mysterious book delivered by aliens.

    Re: Simple Tip: If you need to share knowledge (and simply talking to your co-worker who wrote the software in the first place won’t suffice), then just have your producer build in time for documentation…
    Documentation can be part of ‘done’ and put in the backlog. I’ve been in gaming studios and some of them don’t seem to speak much. It’s like walking through a coma. Increasing feedback is often said to be the thing many people do like and documentation is a really poor form of communicating so personally I don’t think it’s enough.
    9. Forced Demonstration
    Re: Making teams demonstrate user stories are complete in really contrived fashions is nothing short of retarded.
    I completely agree with you. Contrived being the key here. I move the definition of done based on the value of the stage you are in. ‘Done’ early in development means done enough to make a decision on gameplay. ‘Done’ at the final stages means polished until the glare hurts your eyes. This is a problem in video game development for people not used to the industry and how you interpret Scrum to fit your context.
    10. Maximum Churn!
    Re: Having a bunch of coders commiting code into a branch … when a scrum team collapses an entire sprint’s work into a development line at the same time that several other teams do the same?. If the features were continuously integrated…
    So…again not a good implementation as the system should be merged regularly and CI is where you need to end up. Agile tells you to do this so this reason actually helps to advocate Scrum.
    >Are there any positives? In short nothing that one can really attribute to the scrum process. Team communication, pair programming and breaking tasks down are things that good programmers and teams will do anyway.
    Right and you can ditch the name but these are powerful drivers in the Scrum process which they took from trial and error and working through them in practice.
    This makes me a little sad. I see Scrum abused and misinterpreted and it shouldn’t be like that but it often is. In gaming there is so much pressure that in reality Scrum is often waterfall sped up and the system is gamed so we aren’t changing core behaviours and won’t improve. At the core of it, Scrum is so simple as it is all about the team figuring out what their problems are and trying to fix them. It’s not a bunch of mindless practices, although from your description it seems to have lost it’s essence and become this. Thanks for the post and I’m sorry things didn’t work out. Scrum is no silver bullet but from first hand experience, it’s a lot better than what came before.

  11. jch says:

    Great post. I’m right there with you on Scrum. Too much process takes the fun out of developing. Makes you feel like a cog in a machine, or some kind of assembly line worker rather than a skilled artist or craftsman. No fun = no creativity.

Post Comment

Please notice: Comments are moderated by an Admin.


Theme © 2005 - 2009 FrederikM.de
BlueMod is a modification of the blueblog_DE Theme by Oliver Wunder