Jump to content
Double Fine Action Forums
Sign in to follow this  
Greg Rice

Production Update #2: What's a Producer?

Recommended Posts

Yeah, Scrum has swept so many software development companies. Are you acting as both Scrum Master and Product Owner?

When will the backers get another user story? We only got that brainstorm location one.

By the way, unrelated to the above questions, do you have any opinion on Kanban?

Generally, the project lead (i.e. Tim) is considered the Product Owner and the producer (i.e. Greg) is the Scrum Master. However, this is an area that we deviate a bit from canonical scrum.

In formal scrum, the product owner is envisioned as someone outside of the team, like an external client or high up executive. They are supposed to review the sprint, provide a set of user stories for the next sprint, and then GTFO until the end of the sprint. The idea is that this model is supposed to prevent the product owner from screwing the team by changing their mind (and the goals) mid-sprint and then wrecking a lot of work.

That sort of separation is not really practical here. Obviously Tim (or any other project lead) is very involved in the game on a daily basis, and no one is "just a manager". Tim writes all of his games, I programmed a lot of Once Upon a Monster, Lee did much of the concept art for Stacking, etc. That involvement is good and necessary, but it does make it harder to keep the sprint goals fixed during the sprint. In the end, we try to adhere to the spirit of "don't change the goals mid sprint" while giving the team and project leader the ability to tweak goals and priorities as they go.

Share this post


Link to post
Share on other sites
Nice post...Do you have retrospectives?

We've never had a really comprehensive process for retrospectives at DF. In practice, each team takes the approach they think best. On Brutal Legend, we had the HOF (Hour of Fun), where everyone in the company would take an hour to play the game and then meet and discuss feedback. However, this was was actually the Wednesday before the sprint end, and focused more on the game (including bug fixes we'd need to make before the end of the sprint) and much less on the process. Later projects have experimented with review meetings, Survey Monkey surveys (in a CPI sort of sense), etc. They all have pros and cons and it really depends on the needs of the project and team.

Share this post


Link to post
Share on other sites
Do you use a actual scrum board or do you note it all digital on scrumtious?

During BL we actually used a board w/ physical note cards in addition to scrumtious. I, personally, grew to hate the physical notecards. They take a long time to write (many people have dozens of tasks in a sprint) and pin up and move around and once you've written them they aren't very easy to update. I suspect the note card approach would be awesome for a small team of 5 people with no budget for project management software, but on BL we were 60-70 people, 4-5 scrum teams, and it was just a crazy amount of overhead. Scrumtious (which Gabe wrote) is vastly superior on all fronts* and we've never done physical note cards since.

*Scrumtious is amaze, but if you don't have your own personal Gabe, you could probably get similar advantages using any of the existing commercial agile/scrum softwares or even Jira/Bugzilla/etc.

Share this post


Link to post
Share on other sites
Great info, thanks! It would be great to hear also about more about problems of used methods and how you deal with them. It cannot be problem free? Any big negative surprises?

We are running small game project in our local University and we are using (very light version) Scurm also and it's great for us. We did not find any good sofware for it so we use Google docs spreadsheets. Great idea to mix (cursed) waterfall model to some parts of project. They say here in Finland that agile development is to blame for all the mess and delays in many big development projects nowdays (like new electric prescription system) so it seems that agile dev does not suite well for bigger projects.

These posts are already totally worth of my money!

This is a fantastic question, and touches on a subject close to my game developer heart. Forgive me if I write too much in response :)

We adopted Scrum at the start of BL in 2005, basically at the very beginning of when game devs were starting to try scrum. We used it throughout development, and while there is lots to love about agile development, we learned two very big lessons from using it on BL.

The first is that there is a subtle lie at the heart of scrum. Many people are familiar with the subtle lie at the heart of waterfall - that people can accurately predict details like tasks and dependencies months or years into the future. Much of the popularity of scrum is that it addresses this waterfall lie, but unfortunately it has its own. Scrum's deception is that it suggests you don't need to look into the future at all, that all you need is a prioritized backlog and then you just scrum your little heart out. The problem is that scrum assumes that if you do it right, you have a shipping product at the end of every sprint, so you can stop whenever you want. This is, obviously, a vast oversimplification. It may be true if you're writing a simple word processor, but on any project of scale (like a game or an electrical distribution project), you really can't just stop whenever. Complex software is like a living thing, you need all the parts in place for it to be a viable organism; you can't just make a liver and a brain and some bones and then call it a day. This fallacy does, I think, contribute to purely scrum projects taking much longer than expected, something we saw on BL and many others have seen, perhaps in Finland as well.

The second lessons is that scrum can encourage you to take on too much if you aren't very careful. True scrum avoids this problem, but it's hard to be true. In true scrum, you don't stop working on a feature until it's totally done and polished. However, in the real world it's very tempting to stop at 80%. One sprint, you work on melee combat and get that to 80%. Then, when you plan the next sprint, you think "hrm, we have melee combat but no vehicles, what should we do?" And then you decide that no vehicles is worse than unfinished melee, so you decide to be "agile", work on vehicles, and totally screw yourself. If you do this, which we did a lot on BL, you find that over time you have a huge list of features at 80%. You're committed to all of them in a deep way, but as they say, once you're 80% done you only have 80% left to go :P

Our solutions to these two things are pretty obvious. The first, as I described above, is to try to waterfall the game at a high level while using scrum for execution strategy (esp for programming and design). The solution for the second is to be disciplined and really force yourself to see features through.

My last point comes from my fiancee, who is also a programmer, but for industrial companies (including a big graphics software company and a green tech smart energy meter company). Both of these big companies decided to adopt scrum, but did it in a really dysfunctional way. In both cases, it was management that decided to adopt it, often without input or approval from line developers. Scrum is meant to be a grass-roots strategy, but many companies treat it like just another top-down, but somehow "hipper" protocol. That's a recipe for resentment and a lot of fail. Also, these same companies tended to forget the most valuable tenant of scrum - people over process. If scrum is used as just another top-down, rigid process, it loses much of its value.

The solution to that problem is, I think, pretty obvious, too :)

Share this post


Link to post
Share on other sites
Text

This is just so interesting. I remember learning about all these kinds of methodologies, but in the real world of business software programming, my experience has been like your fiancee's - top management generally imposes methodologies just in order to be able to check the "[x] agile" box, for example.

I'm a huge fan of actual "agile" development (not just the buzzword). Games seem to be some of the most complex software out there, so I find it really interesting to go "agile" with a game product. I imagine that for such a creative kind of project, scrum is a great way to keep some of the soul in it, while waterfall would inevitably end up needing iteration anyway, but there wouldn't be much of a structure in place for it.

Share this post


Link to post
Share on other sites

I'm pretty sure the producer is the one you blame if things go badly and forget to praise if things go well.

They're also the ones that the team grovels to while working but talks about when they're out drinking the troubles of the day away...

I wonder if that kinda stuff goes down in DFA? It really seems like the people there are fun and love what they do. A place I'd like to work at.

Share this post


Link to post
Share on other sites
Do you use a actual scrum board or do you note it all digital on scrumtious?

During BL we actually used a board w/ physical note cards in addition to scrumtious. I, personally, grew to hate the physical notecards. They take a long time to write (many people have dozens of tasks in a sprint) and pin up and move around and once you've written them they aren't very easy to update. I suspect the note card approach would be awesome for a small team of 5 people with no budget for project management software, but on BL we were 60-70 people, 4-5 scrum teams, and it was just a crazy amount of overhead. Scrumtious (which Gabe wrote) is vastly superior on all fronts* and we've never done physical note cards since.

*Scrumtious is amaze, but if you don't have your own personal Gabe, you could probably get similar advantages using any of the existing commercial agile/scrum softwares or even Jira/Bugzilla/etc.

We did shed note cards after Brütal, but it's worth mentioning that there are a lot of elements of that process that I miss. Seeing note cards on the wall in various states of completion gives an instant visual graph of where everything is. Almost like a color coded defrag display. If you see a card that should be completed staying in the same place day after day, it raises a red flag for the team and invites conversation. In the digital space, you have to actively look for it, depend on each person to keep things updated properly, and then go find someone to talk things over if the data is even up to date. It is less organic. It also adds a bit of accountability for each member of the group when they have to show their work in front of the team. We haven't lost the standups, but it's easier to verbally gloss over things without the cards. We have a super senior responsible team, and don't often need to worry about that sort of thing, but it is human nature to take mental breaks once in a while. I think that process kept people on their toes a bit more than our current one. There is a Red Flags view in Scrumtious for production that shows a lot of these things (problems with work exceeding or coming in under estimates, who's ahead or behind by more than a day, etc.), but it's elective. The cards in the standups put things more in your face. I haven't found a way to completely recreate all the benefits of cards in a digital tool. I thought it was worth mentioning in case someone is interested in taking a stab at the cards. There is some value there.

As N8 mentioned earlier, one of the core tenets of scrum is "people over process". Since the cards added too much overhead for the team on smaller projects with tighter schedules and generally made everyone grumpy, we dropped it for the good of the team. It was not worth forcing that process if it was going to cause issues. Even though it helped having that extra layer of info for production, our job is to support the team, not put our needs ahead of it. Having redundant data is not a good practice either (cards + Scrumtious).

It is also worth mentioning that I DO NOT miss cutting up index cards or accidentally stabbing myself a million times with push pins! I'm sure Malena still wakes up in cold sweats over that.

Fun-ish fact: We actually saved every single index card from Brütal and had bins full of them that we were going to use for a celebratory brütal bonfire at the end of the project... we ended up just recycling them though.

Share this post


Link to post
Share on other sites
My last point comes from my fiancee, who is also a programmer, but for industrial companies (including a big graphics software company and a green tech smart energy meter company). Both of these big companies decided to adopt scrum, but did it in a really dysfunctional way. In both cases, it was management that decided to adopt it, often without input or approval from line developers. Scrum is meant to be a grass-roots strategy, but many companies treat it like just another top-down, but somehow "hipper" protocol. That's a recipe for resentment and a lot of fail. Also, these same companies tended to forget the most valuable tenant of scrum - people over process. If scrum is used as just another top-down, rigid process, it loses much of its value.

The solution to that problem is, I think, pretty obvious, too :)

This has been our biggest problem on past projects. The scrum methodology was not applied with buy-in from key stakeholders (or the whole team for that matter) but as a change to the process from management. It always seemed like they did it because it was the new thing vs. a better way to develop software and content.

But you all had your grievances with the first-time through as well. It sounds like it pays off for teams who are willing to go through the growing pains and stick with it for subsequent projects.

Edit: Never mind. I found my answer above.

Share this post


Link to post
Share on other sites
Text

This is just so interesting. I remember learning about all these kinds of methodologies, but in the real world of business software programming, my experience has been like your fiancee's - top management generally imposes methodologies just in order to be able to check the "[x] agile" box, for example.

I'm a huge fan of actual "agile" development (not just the buzzword). Games seem to be some of the most complex software out there, so I find it really interesting to go "agile" with a game product. I imagine that for such a creative kind of project, scrum is a great way to keep some of the soul in it, while waterfall would inevitably end up needing iteration anyway, but there wouldn't be much of a structure in place for it.

Yeah. In my experience, development processes are a lot like religions. They are all perfect in theory, but get messy in practice. Everyone interprets the subtleties differently, sometimes there are wars, very often there is much wailing and gnashing of teeth. Similarly, the keys to successful practice are all about being thoughtful, avoiding dogmatism, appreciating the good parts of other "faiths", and, as with everything, a ton of patience and grace.

Share this post


Link to post
Share on other sites

Nice!

We tried to use SCRUM for a client, but this:

this model is supposed to prevent the product owner from screwing the team by changing their mind (and the goals) mid-sprint and then wrecking a lot of work.

Kept happening all the time. :(

So it was impossible. Some clients are very difficult to deal with.

I'm glad you don't have a publishing house trying to alter the sprints or changind the goals. :)

Share this post


Link to post
Share on other sites
Nice!

We tried to use SCRUM for a client, but this:

this model is supposed to prevent the product owner from screwing the team by changing their mind (and the goals) mid-sprint and then wrecking a lot of work.

Kept happening all the time. :(

So it was impossible. Some clients are very difficult to deal with.

I'm glad you don't have a publishing house trying to alter the sprints or changind the goals. :)

Yeah, SCRUM works best inside a company developing their own product to sell, not when you're answering to an outside entity.

Of course, if I'm an employee and my project manager changes course all I care about is the fact that I'm still getting paid whereas a company trying to deliver a product its investor wants is just strung along.

Share this post


Link to post
Share on other sites

I am finding this thread super informative for work- something I certainly did not expect when helping to fund a game! I can totally relate to what is being said about scrum being misapplied as a top down process rather than a grass roots effort which it was originally intended. My personal opinion is that smaller groups and companies are often more efficient at getting things done than large companies for the usual reasons. I think scrum was a way to get the benefits of small programming groups applied to large projects. There's no solution that's perfect for everything, but it seems like you guys (DF) have really honed it down from past projects. Lessons I'd like to take back to my work place.

Share this post


Link to post
Share on other sites
This was an interesting read, went into it not really having any clue what a producer does, and bam, info!

I would like you to elaborate on:

• Keeping the team motivated (i.e. buying ice cream as much as possible)

What have you tried other than ice cream? Do you offer face painting booths, or cat parades, or dance offs? Piggyback rides? Motivational diorama making?

This is important, I would appreciate it if you got back to me on this asap. Thx.

I'll jump in to say motivational beers work as well as ice cream at Double Fine.

I am liking that cat parade idea though.

Choco Tacos have been strangely effective at motivating the Cave team. For beer, the local IPAs seem to be the most popular.

I also keep a candy bucket on my desk to lure people over to get updates on their tasks.

Thank you both for answering my extremely important question. I do hope you demand much more difficult-to-provide morale boosters such as various animal parades. Just to keep him on his toes.

Share this post


Link to post
Share on other sites

Thanks a lot for the reply gsm, and I also find your input very interesting! I don't have anything else to add though so I'll leave it at that. :)

Share this post


Link to post
Share on other sites
Forgive me if I write too much in response :)

I don't think that there can be too much discussion for this matter if it seems that it is one of the key elements of successful project or in many cases life or death issue for companies. I can guess that there are hundreds of game teams that failed just because they did not manage to organize their project properly. Persons in game projects maybe be often even little more difficult, artistic, free-souled and hardheaded than usual developers, designers etc?? Thats because they usually have more passion and personal interests in play. Tell me if I'm wrong.

... Complex software is like a living thing, you need all the parts in place for it to be a viable organism; you can't just make a liver and a brain and some bones and then call it a day. This fallacy does, I think, contribute to purely scrum projects taking much longer than expected, something we saw on BL and many others have seen, perhaps in Finland as well.

Whole product is more than the sum of the parts, they say. If I (hopefully) some day have bigger game project running, I'll get help from somebody that has this kind of experience. It is shame that internet is only full of success stories. Reading them is great, gives motivation and good spirit, but failure stories would be much more educating. If anyone here knows good stories about game project failing or problems link here please!

...However, in the real world it's very tempting to stop at 80%.... but as they say, once you're 80% done you only have 80% left to go :P

Of why this sound so familiar, darn... We are doing under water game and I have made script that tries to move fishes realistic in 3D world. After many days hard work fishes are swimming ok, but not quite realistic I wish and I think that I'll fix that later and start working other things.

...but many companies treat it like just another top-down, but somehow "hipper" protocol. That's a recipe for resentment and a lot of fail.

Yeah, I'll get rash every time I'll hear these trendy words from mouth of company leaders or marketing guys. I think they really don't know the true meaning of these words and really don't know that will it make things any better for their companies... In example cloud services.. there has been learning material in Internet for decade now but now they call it cloud learning (it sounds even much more stupid in Finnish).

Keep up the good work, I'm reading and learning ;)

Share this post


Link to post
Share on other sites

Just a thought, would it be hard to make a digital equivalent to the physical note cards with scrumtious?

A lcd TV with updated goals and whatever info was previously on cards. Placed wherever you had the board earlier.

That might give you those benefits you felt you had, wout the need to glue and scissor it...

This in response to Gabe Millers last post.

Although, not sure I would have liked to have my goal progress be looking at me every time I pass it.. Imagine it could have a de-moralizing effect. But hey! If done right!

Share this post


Link to post
Share on other sites
The first is that there is a subtle lie at the heart of scrum. Many people are familiar with the subtle lie at the heart of waterfall - that people can accurately predict details like tasks and dependencies months or years into the future. Much of the popularity of scrum is that it addresses this waterfall lie, but unfortunately it has its own. Scrum's deception is that it suggests you don't need to look into the future at all, that all you need is a prioritized backlog and then you just scrum your little heart out. The problem is that scrum assumes that if you do it right, you have a shipping product at the end of every sprint, so you can stop whenever you want. This is, obviously, a vast oversimplification. It may be true if you're writing a simple word processor, but on any project of scale (like a game or an electrical distribution project), you really can't just stop whenever. Complex software is like a living thing, you need all the parts in place for it to be a viable organism; you can't just make a liver and a brain and some bones and then call it a day. This fallacy does, I think, contribute to purely scrum projects taking much longer than expected, something we saw on BL and many others have seen, perhaps in Finland as well.

I wrote my diploma thesis on quality factors of agile software development a few years ago. The thesis was heavily theoretical, but I actually found a lot of sources describing this particular problem. It is not really a question of waterfall vs. agile, but more of up-front design vs. continuous design (design meaning software/framework design). Both have pros and cons, so we need to find the right balance.

The best model I found to describe the interdependency of both paradigms and to balance them in an agile way is Alistair Cockburns economic coorperative game model. It basically says that development is a round-based game with two competing goals: 1. Finishing your work in this round and 2. setting "markers" that help you to finish quicker in future rounds. The players (the dev team) need to work out the best strategy for their project in every round.

In plain english: Keep in mind that some early design choices can be helpful later, and that some outlook into the future is necessary for this to work. But also keep it basic and try to drive the implementation mostly through user stories or what you call it.

Scrum does not explicitly prohibit additional design documents and methods (as XP does), so I don't see any reason why you shouldn't ditch ye olde waterfall altogether.

Share this post


Link to post
Share on other sites

... It is not really a question of waterfall vs. agile, but more of up-front design vs. continuous design (design meaning software/framework design). Both have pros and cons, so we need to find the right balance.

...

In plain english: Keep in mind that some early design choices can be helpful later, and that some outlook into the future is necessary for this to work. But also keep it basic and try to drive the implementation mostly through user stories or what you call it.

You basically just summarized the major lesson of my entire career :)

Scrum does not explicitly prohibit additional design documents and methods (as XP does), so I don't see any reason why you shouldn't ditch ye olde waterfall altogether.

Agreed that it does not explicitly prohibit more long range plans, but it suggests (or at least is commonly interpreted to imply) that they are unnecessary. I think at this point we mostly agree and it's mostly semantics. You'd say "abandon waterfall, adopt modified scrum" I'd say "waterfall your project/schedule at a very high level up front, scrum the details". And then I think we both say "and modify your long range plans as you go based on your near term experiences".

Share this post


Link to post
Share on other sites

Yeah, I mostly agree. What I'm missing a little bit in your model is the ability to realize in the middle of sprint 5 that you need to put some additional effort into some high-level planning as a team and do that without aborting the sprint and switching to waterfall.

I'm pretty sure you wouldn't actually do that, so I'm asking: Can you really distinguish those two phases so exactly?

But you have a point: As long as the team size is too small for Scrum (1-2 devs) it's probably easier to plan tasks and resources in a gantt-y way.

I'm beginning to think that we are talking about the same thing. Maybe "waterfall" simply does not describe very well what you are doing - this term is commonly being associated with a very strict plan-build-test-run scheme and often different people working on these phases. One or two smart developers on their own usually work in a pretty agile way instinctively. They don't need a process like Scrum since there is no need to coordinate a team.

Share this post


Link to post
Share on other sites
I'm beginning to think that we are talking about the same thing. Maybe "waterfall" simply does not describe very well what you are doing - this term is commonly being associated with a very strict plan-build-test-run scheme and often different people working on these phases. One or two smart developers on their own usually work in a pretty agile way instinctively. They don't need a process like Scrum since there is no need to coordinate a team.

Yeah, perhaps I am using the term "waterfall" in too loosely given its formal baggage. What I mean is that at the start of a project, I'm an advocate of saying "ok, we have a budget of X million dollars and want be done at date Y" (the common initial conditions for a game) "let's think through the whole game at a high level". That means, to me, breaking that project down into milestones (concept, pre-pro, production, alpha, etc), splitting those milestones into sprints, writing down the major chunks of work you need to do (at a granularity of one month chunks), and then lay those chunks out in a dependency order. If you have a baseline staffing plan, assiging these chunks to people can be productive. The goal of all of this is to think through and enumerate major dependencies (i.e. "networking should be done before we start on the monster AI") and also to help give you some signposts (i.e. "if networking isn't done by April, we should start to worry about X, Y, and Z or maybe the whole game being late". The end result of this process looks something like a traditional waterfall, gant chart, but it's really more about the thought process and placing mile markers than something you use with the team on a daily basis.

Also, teams can (and do!) repeat this process whenever. On OUAM, we did something like this when we signed with WB, after proproduction, and a smaller shift about half-way through production as it became clear some of our assumptions about dependencies and workload weren't fully baked.

Share this post


Link to post
Share on other sites
That means, to me, breaking that project down into milestones (concept, pre-pro, production, alpha, etc), splitting those milestones into sprints, writing down the major chunks of work you need to do (at a granularity of one month chunks), and then lay those chunks out in a dependency order.

So you actually have a wrapper around your scrum development process providing high-level milestones and plans which can be adjusted whenever necessary from within the scrum process. This makes a lot of sense. The only thing you need to be aware of is to handle a delay in the wrapper milestones in a way that doesn't conflict with scrum. You have a few options like including adding more staff (which has its pitfalls too) and dropping functionality, but "work faster", "work longer", "finish only 50%" or "skip the testing" should be out of the question.

I saw that a lot of people in this forum seemed to be interested in agile development, so I thought i'd share the high-level quality factors of agile development (not limited to scrum) with you all. If you neglect any of those in your process and work culture, your project will most certainly be delayed or fail:

- communication

- experience (with technology, project domain and development process)

- timeboxing (also in the meaning of "finish your tasks 100%")

- involvement of the customer

- successive design and refactoring (containing the trade-off between up-front and continuous design)

- continuous integration

- process improvement

Have fun!

Share this post


Link to post
Share on other sites

As an Agile software developer working with Scrum, I feel absolutely delighted by this thread. I am already getting more than I backed for. Screw adventure games, I want Double Fine to make our next ERP system.

Share this post


Link to post
Share on other sites

What would you say are the top skills or pieces of experience one would need to become a producer? What are people looking for?

Share this post


Link to post
Share on other sites

Thanks so much for sharing all this, it means a lot to me that you guys are willing to share every little detail on how you guys work. I really want to move up in the video games industry and all of the posts have helped inspire and motivate me to do so.

Share this post


Link to post
Share on other sites

I agree. You dont usually get to see this kind of insight to the going on's behind doors. It's intriguing to see this kind of information.

Share this post


Link to post
Share on other sites

Great post, thanks for talking about the process used by DF. I have worked for companies using both of them but never for one that used both in the same project :)

Share this post


Link to post
Share on other sites

In the programming degree I just completed we had to work together as a team to create a simple game, and we used agile to set up everything.

I wish we had something like Scrumtious when we were working, it looks awesome!

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...