2. "Sprint Zero"
is pre-production time.
Start the pre-production by putting all stories into the Scrum
backlog spreadsheet. Pre-production only lasts two weeks. Ignore any concern
that there still isn't concept art before Sprint 1.
Lesson Learned: "Sprint
Zero" is not pre-production. Creativity and innovation cannot be managed.
Team brainstorming might be visible while sitting in a conference room buzzed
on energy drinks but sometimes the best ideas come to mind while stuck in
traffic during the car ride home from work. You cannot demand that someone
comes up with the best creative game idea instantaneously. It doesn't help to
manage and track game ideas in a backlog spreadsheet, either.
Best Practice:
Pre-production for any great product involves lots and lots of prototyping. Think
on the magnitude of hundreds of prototypes. You would like to be able to mass
produce these prototypes. Some ideas may never
be more than a scribble on a little yellow piece of paper. Some prototypes
might be full-featured software demos with hundreds of tuning knobs and ways to
adjust content on the fly while the game is playing.
You need powerful
prototyping tools that allow non-technical people to do lots of iterations
every day. Pre-production does take time. The more prototypes that the team can
create and demonstrate quickly will result in a better product.
1. Start managing the
project by prioritizing tasks and asking for time estimates even before any GDD
is written.
In every two-week sprint planning meeting, repeat the same
behavior of prioritizing tasks before there is any design. This is about as dysfunctional
as signing a production contract with a licensor before there is any design
document or concept document. The worst case is then giving the licensor the
freedom to make any change to the design at any time during full production
with no regard for the cost of the team implementing the change.
 Lesson Learned: The
project management cart does not go before the game design horse.
Best Practice:
Write a draft of the game design document and get feedback from engineers,
content creators as well as the publisher and licensor. Do this before making a
commitment to full production. Make sure that engineers and content creators
understand the product design before you start prioritizing tasks and asking for
time estimates.
Best Practice: You
may have a mental checklist for sanity sake, and doing things in the correct
order during a development cycle is important. Many developers have a gut feeling
about death march projects. If your gut feeling says this is going to be bad
unless the proper actions are taken, then it probably will be. Trust your gut
feeling about game development over the Scrum consultant's advice. Scrum
consultants don't make games; they get paid to give an all day Scrum Master
certification training class.
Conclusion
Scrum and Agile methods are just tools in the project
management toolbox. Suppose you had a crescent wrench, a vice grips, a channel
wrench, and a pliers in your toolbox. If you just use the crescent wrench for
everything without thinking about what it actually takes to get the project
done, you are going to end up stripping a lot of your nuts.
During many game development projects, some lessons are learned the hard way. The
hard lesson learned is that Scrum is not a silver bullet that makes video game
product development more successful. There are many technical details, know-how
and best practices that have been gained by years of experience developing
games, one development cycle after another, analyzing what went right and what
went wrong.
Employing Scrum as a complete replacement for already well-established
process and methods that existed before there was Scrum is a sure way to make a
project miserable punishment. When Scrum is added to the project to solve
problems and ensure success, it can easily become the cause of more problems
than it solves if the pitfalls are not remedied with appropriate timing.
This article has provided some contrasting insights about Scrum.
Certainly before making the executive decision to mandate Scrum, it should help
to hear from both camps: those who advocate Scrum religiously and those who
approach cautiously and play devil's advocate.
---
Title photo by royskeane, used under Creative Commons license.
Additional photos by star5112, Tom Hughes-Croucher, and Paul Downey, used under Creative Commons license.
|
Printer-Friendly Version
All that said, I have had very contrary experiences and learnings to a number of these learnings, and others seem very on target.
#10 - I think this could be number one, not number 10. Very important
#9 - I think you can see a pretty direct relationship between #5 and #9. If you let daily stand ups turn into status meetings then you have already lost. They are not status meetings, and you those speaking should not be reporting progress scrumaster or Project Manager. They are commitments to the rest of your team, in front of the team, to achieve the current sprint. No electronic tracking will every replace face to face interaction about what an individual is doing to make the team succeed, in my opinion.
#8 - Interesting approach, very cool if you can pull it off.
#7 - pretty straight forward, as long as the person is not compromising the sprint by pulling tasks from beyond it and neglecting tasks they could do in the sprint
#6 - This one is kind of a mess, you are talking about QA and process management in one item. They are seperate things. Integrating QA from the start is a HUGE win, 100% agree there. But I dont see where the "Decide that your Scrum stories and sprints are 100% completed months before" comes from, thats very un-agile. You should know that you cant possibly plan 100% of your stories months in advance, thats why you break them down as you get closer to their delivery (Epics/Themes/Stories).
#4 what? again a confusing entry. Of course scrum is just a tool in the toolbox, it shouldn't necessarily be mandatory for every process in the company. But then you switch to management feedback...kind of lost me there. Management feedback is important but whats that got to do with scrum being mandatory?
#3 - good point. We frequently employed design stories that were intented to guide future stories (in and outside the current sprint) to help solve this. Also employing XP in conjunction with Scrum helps here.
#2 sounds good
#1 kind of the same as #10...but agreed
Interesting read, thanks!
-jobe
Have you actually have a book describing Scrum, Agile or XP? Just one? Perhaps read a few more before applying it.
I think you need to think about the roles on the team, perhaps consider designer to be a customer. The customers generate user stories and the programmers generate the tasks for the back log. Often games design docs are fully of designers supposed technical information that is useless. This really cuts down the ammount of work the designer has to do.
With 9 non-Scrum games and 1 Scrum game under my belt (and another on the way), I am a firm believer that when Scrum is done right it results in higher morale, better games less risk and less overtime.
Every single problem mentioned (yes, all 10) come from a misinformed and improper implementation of Scrum and not adhering to the principals of Scrum and Agile development.
Scrum doesn't stop bad managers from being bad managers. No project management system in the world can do that.
Paul - it would be very interesting if you took a couple of nights and read "Agile Software Development With Scrum" by Schwaber/Beedle and reflected on your experiences with Scrum to see how they lined up.
http://www.agilegamedevelopment.com/2008/06/daily-scrum-question-2.html
http://www.agilegamedevelopment.com/2008/07/feedback-top-10-pitfalls-using-scrum
.html
Scrum is a tool, nothing more and it always takes great people to make great games. It only takes "weak" management or "feature creep" to destroy milestones.
You have to adopt processes before you can adapt them.
sad ,because the article tells the exact opposite
Again, game development needs to be treated as an entertainment industry devoted to creating projects - not as a conventional operating business, focused on maximizing efficiency. Efficiency isn't the aim - effectiveness is. You can efficiently make a piece of garbage (it happens all the time).
And his comment was completely erroneous.
There's a lesson in there somewhere...
The problem with software process critiques is that a software process is like a user interface. Everyone *thinks* they know the best way to do something. As a TD, I'm more interested in what works.
I usually find case studies on successful projects much more useful than top 10 lists. I like to hear a real story of how a successful project came to pass, rather than "this sucked", or "this was great".
Every organization has it's own context. I can imagine an environment where all 10 of these pitfalls were actually beneficial. If you can't, you haven't been around long enough :)
In other words, they are assigning tasks to individuals and waiting for them to know by themselves what to do next. Because in the first place they (workers) have to wait for management team they'll start to adopt that behavior.
Just an opinion ;)
It’s true that I can’t address Agile and Scrum methods to any real degree, as I’ve only a cursory understanding (I bought the books, etc – never actually on a project).
Nonetheless, I have been part of the game industry for a long time. So, like Mr. Christophe I have seen it done six ways from Sunday. I have spent years working with producers, designers, and engineers (artist too, but mostly the ones with the more nebulous interactions) in attempts to figure out best methods. Hmmm. I think I might be the guy that rolls his eyes every time I hear some “can’t plan a thing” wack-a-mole start talking about lack of communication. To me this is often more indicative of those not well versed in the job. Don’t get me wrong, please. I don’t want to be negative, or slight the strengths of any particular methodology. But that’s just it, some methods work better with certain sorts of development/developers, perhaps even based on genre or pre-existing technologies. I agree with the general consensus here (Grassroots, good stuff!). If you have a good idea and great people, and you can stomach microsoft project, then you have a chance at success (I'd like to think there’s some out there that can do it with postit notes). Mediocre staff, or vision/leadership, and all the scummin’ in the world won’t help. Anyway, your suggestions are forged from real world experiences. So even if these methods are a response to “those not managing scrum correctly”, they are valuable bits of knowledge for that very reason.
10. Nowhere does Scrum say that a GDD isn't used. Features and tasks are not Design specific, they are planned goals. If you need to collaborate there is a perfectly good way to get lots of people on a single document, and lots of crappy but "good enough ways". This is a failure to research collaboration tools or to read up on Scrum methodology.
9. Scrum meetings dont have to take place away from the developer's stations. A phone and a shared desktop view is more than enough for each station. In the end, people being late has to have consequences for there to be incentive to attend. Some take a soft hand to it, I always suggest a hard stance. It's a business requirement and making the product owner wait for a demo meeting versus making your team wait to start a scrum meeting needs to have the same impact. If you can't stomach that in the early stages, we'll replace you. You agree to come in to work every day, you better be on time when it counts and nap after, we have a couch.
7. Scrum tasks should be continually updated by the Scrum Master. It's a role with RESPONSIBILITIES. If the scrum master says he's creating a task, that should be good enough to start. Again, it's a matter of not being a dick about process. If you're gonna be a problem, you're gonna be replaced. If the task never gets made, add it to the story of the next task you work on. Documenting what everyone does is part of scrum.
5. This is exactly what most scrum meetings are. This is a Good Thing(tm), since it brings up issues commented on in later points as a complaint "where do we talk about this". Daily Scrum meetings is where. Once you see adherence to documenting whatever is said in the scrum meetings, just have the members mention the feature, task, and that's it. Joe: FEAT-31, task 2. Started FEAT-31 task 4 and 5. The Scrum Master should be reading through the task notations. All of them. Welcome to 50% focus factor OR LESS.
3. Design is not the scrum's concern. They are handed that BEFORE starting (Sprint 0). The fact that the features are obviously incomplete or not planning for the future is something you bring up during sprint planning. "We're not going to do FEAT-52 because xxxx was not thought of." as you pull things from the backlog and leave others behind and either the product owner revises, adds, rethinks FEAT-52 for next sprint, or replaces a member with some schmuck who will do it and that's a choice members have to make. Product owners make the decisions, developers implement them. If you wanna design games, change your job title.
As teams grow, you simply create scrum hierarchy with scrums of scrums. This is how Microsoft created the MSN AdCenter and a number of other products.
The primary problem with SCRUM is where Bugs fall into the work flow and how to categorize, prioritize, and handle them. Most people assume QA is handled outside of sprints which is terrible. Concurrent QA is necessary from the start.
Maybe I'm misunderstanding you here, but I disagree that design is not the scrum's concern.
One of the strengths of scrum is that each of the team members has an input into the design and therefore has increased buy-in into what they are creating. Sure there should be a high level design for each area of the game so that you have an overview, but the design for each area should be fully fleshed out by the team assigned to work on it in conjunction with the lead designer at the start of a sprint. This leads to greater motivation from team members and a fuller understanding of the overall area they are working in.
Agreed with your last point about QA though and about scrum masters being at about 50% focus.