Sign in to follow this  
Followers 0
DF Greg

Production Update #2: What's a Producer?

116 posts in this topic

Hello there, Greg here! You may recognize me from such things as that video where I wore a bunch of t-shirts, or that time when I played Full Throttle with my mom. Perhaps you thought to yourself, what does that guy actually do? Well, I'm the producer on Double Fine Adventure. But what is a producer? That's what we're here to talk about. The answer is, it varies greatly from one company to another and even from project to project.

In the simplest form, a producer is a facilitator. For an external producer at a publisher, this typically means overseeing many projects from different developers, monitoring and reporting their progress to upper management, and looking for any potential problems that may arise.

In the case of a third party development studio such as Double Fine, a producer generally has more of a hands-on role. Our primary goal is to ensure that the final game is delivered on time, on budget, and at a quality level worthy of the studio's name. A producer does whatever it takes to ensure this happens. This means we wind up doing a wide variety of things, but some common responsibilities include:

• Overseeing day-to-day activity of all team members

• Facilitating communication between different disciplines

• Looking to the future and assessing major risks of a project

• Ensuring each team member has everything they need to do their job

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

• Advocating for the team to upper managment

• Interfacing with external partners such as publishers, localization teams, and QA testers

• Budgeting and scheduling the project

In this post, I'd like to dive a bit deeper into that final bullet point. I talked a bit about budgeting DFA in my previous post, "Where does all the $$$$ go?" In that post I broke down where the money we earned through Kickstarter is going, and how we ended up with our final budget for the game. Once that was done we were able to determine our team size and the duration of the project. What I didn't discuss is how we schedule the team's time during that period.

At Double Fine we use a few different production techniques. One of these is called the waterfall model. This is a fairly structured method in which progress on each element of the game is made sequentially through distinct phases. An idea gets handed between different team members in a straightforward manner from conception to design to implementation to testing with little revision or experimentation. When a specific tasks and its dependencies are mapped out in the schedule, they often look like a series of waterfalls. Thus,

.

The waterfall model is useful towards the end of the development cycle or when much of the design work has been done up front, as was the case with Iron Brigade. By the time Matt Hansen and I joined the production staff on Iron Brigade (as Producer and Assistant Producer respectively) many of the remaining tasks were easily definable. In this case, production leaned more towards a waterfall method as it allowed a clean and clear daily schedule to be developed. Here's an example of what part of a team member's schedule looked like--in this case, Project Lead Brad Muir:

1.jpg

However, the main issue with the waterfall model is that it is fairly rigid and does not take into account the iterative nature of game development. Because of this, we at Double Fine typically tend to employ a different method called Scrum. Scrum is what is referred as an agile production technique. In this model, the entire team works together as one cross-disciplinary unit passing different elements of the game back and forth.

We break the development time down into "sprints" which last between a week and a month. Before a sprint starts, the team gets together for a sprint planning meeting in which goals are set for that sprint and user stories depicting these goals are created. The team then spends the duration of the sprint working towards these goals. Instead of focusing on individual tasks that need to be completed, we focus on what results we're trying to get.

In order to easily track the work being done, we use a tool called Scrumtious, created by Double Fine Senior Producer Gabe Miller. I must say, Scrumtious is totally awesome. Here's an example of what those goals and their related tasks look like in Scrumtious.

2.png

Once the sprint is underway, the entire team meets in the same area every day at 11:00 for stand-ups. Stand-ups are short (less than 15 minutes) meetings in which, one by one, all team members say what they worked on yesterday, what they plan on working on today, and whether they are blocked from working on a task by any obstacles. It allows each individual to constantly evaluate and determine which of their tasks they should be working on each day, which is great when working with such talented and experienced people like the ones here at Double Fine! One key benefit of Scrum is that it allows us to react to unpredicted issues and reprioritize tasks. Take a look at Brandon's task list from last sprint:

3.png

As you can see, this page gives us a lot of information about what Brandon has been up to. Check out that awesome little graph at the top right. That is a burn down chart that shows Brandon's progress throughout this sprint. Note that point in the middle around May 3 where the graph turns upwards. This is an example of a time when something unexpected came up and Brandon had to focus on a new issue. When this happens we move tasks into a backlog list of things to hit during an upcoming sprint. Like this!

4.png

When a sprint is complete, we have another meeting to run through the list of goals we set for that sprint and determine whether those goals were adequately met. Then we plan for the next sprint and repeat! Sometimes this will continue until the end of the game, and sometimes we'll end by just waterfalling out remaining tasks once everything is captured. It just depends on the project. But as you can see, we're making progress!

Share this post


Link to post
Share on other sites

Great update! Thanks for all the awesome insights!

I work at a company that does mainly waterfall development, so doing some scrum projects was a tough adjustment. You guys consider licensing your custom scrum tool? Seems like it could be a nifty opportunity and helpful to us scrum n00bs.

Share this post


Link to post
Share on other sites

So during a SCRUM, if you have and issue, when do you Ruck Over? Does anyone have to Shoot the Boot?

Also, as an IT Consultant it is interesting to see Agile Development methodologies applied to game development. Not surprising given the nature of software development, but it really looks like ya'll have this down pat. Good stuff. Definitely didn't think I'd be reading a post about Scrum and Agile on DF Forums.

Share this post


Link to post
Share on other sites

I've always been an advocate for the waterfall model, but then I wouldn't usually be involved until a few months before Alpha.

I do loves me some schedules.

Share this post


Link to post
Share on other sites

So you go waterfall near the end of development for most games, and scrum for the rest? Oooh.

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.

Share this post


Link to post
Share on other sites

You should totally list "Free ice cream" in job posts, best incentive ever :)

Seriously though very interesting post even if I only understand half of it...

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Thanks for the super-informative post! Just from glancing at Brad's schedule, did he really work for almost a full month straight without any days off? That's dedication! /two-handed salutes

Share this post


Link to post
Share on other sites

The description you provide of what a producer does also sounds a lot like the description for "manager". Is there a big difference between "producer" and "manager"? If so, can you elaborate more on that?

Share this post


Link to post
Share on other sites
goals are set for that sprint and user stories depicting these goals are created.
Is this saying that you create little vignettes that describe how the end-user of a goal will be impacted by its successful completion?

In Brandon's tasks, I see a section called "CoSes" where it says what programmers can do. I assume this is a "user story", correct?

I think that's an interesting visualization technique where success is not defined by completion of the task, but by the reward.

Is there a "CoSes" for the overall game?

"DFA: Players will be transported into an exciting world and participate in an engaging story by solving puzzles and interacting with interesting characters in artistically-rendered environments through the framework of a 2D point-and-click adventure game."

"DFA: Horrified onlookers will watch a chinchilla-based snuff film."

Share this post


Link to post
Share on other sites

Definitely an interesting read. I have been trying to work out a method kiiiind of like this on a project I'm involved with, but the work schedules of the team members make things... complicated. The main problem is that none of the members of the team are working on the project full-time. One team member might work a full eight hours on Monday and that's it. Another team member might work all five weekdays, but only from 1 until 6. Another team member might work only Thursdays and Fridays from 10 to 2.

I manage to get them all rounded up for a weekly meeting, where we discuss our progress and set tasks, but it's difficult to think in terms of target times/deadlines, because every person on the team is committing a different number of hours every week, so giving the same task to two different team members could be asking too much of one person and too little of another. Keeping them all in daily communication is a constant issue.

Still trying to work out a good system for our awkward arrangement, but this post did inspire a few new ideas.

Share this post


Link to post
Share on other sites

I thought I would mostly only be interested in the documentary videos, but I'm loving these updates.

It's nice to read a description of Scrum by someone in game development. Whenever I've heard it explained by someone I know (in my workplace), they always make it out to be some kind of monster work-til-you-drop machine but this makes it sound like something I would love the hell out of.

Thanks for the update, Greg.

Share this post


Link to post
Share on other sites

Nice post, I like the name Scrumtious for the scrum story overview. Personally (or rather professionally), I enjoy using Pivotal Tracker for story management - very intuitive.

Do you have retrospectives?

Share this post


Link to post
Share on other sites
The description you provide of what a producer does also sounds a lot like the description for "manager". Is there a big difference between "producer" and "manager"? If so, can you elaborate more on that?

A producer is one kind of manager--in some software development fields, the role closest to a game producer is called "project manager."

But there are also other kinds of managers, like a game's overall project lead, or leads of departments or disciplines (art, tech, audio, etc.)--those people manage staff as well, but are not producers.

Share this post


Link to post
Share on other sites

I found this post extremely interesting, as the software shown provides a very clean and concise task management. I am learning how to use Jira at my workplace, and sometimes it can be a bit tricky to see how a task/story is unfolding over a certain amount of time. It's interesting there's a set number of hours given for each task, and the burn down chart really shows how well these hours are working for a person. I am still very new to all this project management, but I really appreciated your insight.

Share this post


Link to post
Share on other sites
goals are set for that sprint and user stories depicting these goals are created.
Is this saying that you create little vignettes that describe how the end-user of a goal will be impacted by its successful completion?

In Brandon's tasks, I see a section called "CoSes" where it says what programmers can do. I assume this is a "user story", correct?

I think that's an interesting visualization technique where success is not defined by completion of the task, but by the reward.

Is there a "CoSes" for the overall game?

"DFA: Players will be transported into an exciting world and participate in an engaging story by solving puzzles and interacting with interesting characters in artistically-rendered environments through the framework of a 2D point-and-click adventure game."

"DFA: Horrified onlookers will watch a chinchilla-based snuff film."

CoS is an acronym for "Conditions of Satisfaction". Those are the things that must happen in order for the User Story (or goal) to be satisfied. That particular CoS was assigned to Brandon, so it shows up in his list like a task (but above his tasks). In general, the user stories and CoSes are more important than tasks. Tasks are just a means to a CoS. Hopefully that makes sense... Just remember C.R.E.A.M. (CoSes rule everything around me)

Share this post


Link to post
Share on other sites

Thanks for the update and insights!

Share this post


Link to post
Share on other sites

This is a very cool insight for people like me who are interested in the processes of real-world, creative team management. It's really exceeding any expectations I had when I first donated to this project. Thanks!

Share this post


Link to post
Share on other sites

So a producer isn't just a nickname for Gene Wilder or Nathan Lane? Damn you Mel Brooks, you lied to me!!!!

Seriously though interesting post. Good to know there's a good head on the shoulders of the person with the unenviable task of keeping everyone on task. Looking forward to the next update.

Share this post


Link to post
Share on other sites

I am loving the way DF is going with the transparency and handling of the project. In my world we have PM's not Producers but they do the same thing you do. ( or I should say they try to ). I Know this is not a reward but this updates would be available to have them in a PDF format? Love the programming, the money etc.. I think is a pretty good use case to reference.

Share this post


Link to post
Share on other sites

Awesome post

This is amazing I really hope we can see more of thise maybe a video of one of the sprint meetings?

Share this post


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