I've worn many hats over the course of my career, but without question, working under the title of "Producer" was the most difficult. I've met a fair amount of master designers, engineers and artists, but only a small number of producers that have proven mastery over their craft. Largely, I think it's because if you ask 50 different producers, you'll get 50 different definitions of what it means to be one. There are fewer industry standards for this role compared to any other discipline.

That said, this post isn't about making an argument for or against any particular definition, but it is highly influenced by/only possible because of Jeff Morris, our Lead Producer on Star Wars: First Assault. The dude is a legend and the effectiveness of his production methodology is lightyears beyond any others that I've worked with. There are many Jeff-isms, but everything I'm about to discuss builds upon on this indirect, unsanctioned quote from him:

"You should be approaching your production process just like you approach the development of your game; it's all about iteration on a daily basis."

Maybe we should think about producers as "designers of process"? I am into this and that's why I became one for a time. And what's design about? Design is largely about careful examination and methodical iteration. If you disagree with any of this, maybe you're right, but you also might find the rest of this post dumb. Fair warning!

A Brief Argument For Process

There are A LOT of developers out there who aren't shy about expressing their disdain towards producers and process, in general. It's hard to blame them when so many projects have been mismanaged, but that is not an excuse to give up on creating great processes. In fact, you should get yourself involved! I'd argue that process is responsible for 20 metacritic points, if you want to try and quantify it with a slightly arbitrary number/rating system. Great process is also the reason your team isn't burnt out, attrition is low, moral is high and everyone lives to fight another day. Every developer needs to prioritize the development of their team's process appropriately. It takes a village to raise a production process.

So...get off my soap box, right?! Right. Let's talk about designing a production process for managing the day-to-day operations of your team, using my experience on Star Wars: First Assault as an example.

The Anatomy of a Sprint

Call it whatever you want, but this concept should be in place in some shape or form on your team. Here's a day-to-day breakdown of what ours looked like on Star Wars: First Assault:

Scheduled Work Day

These days were allocated for work specifically scheduled to be completed during the current sprint. This "work" came in the form of tasks with time estimates provided by the individuals responsible for completing them. Estimating tasks is an art form that needs to be practiced. Not to pick on them, but in my experience engineers are the first to say it's impossible. That's bullshit. You can get up to numbers like 80% accuracy of your initial time estimate if you pay attention and try hard enough. I've seen it, so I know it's real O_o I'd argue I was at 95% accuracy by the end of Star Wars: First Assault because we prioritized getting good at it.

It's worth noting that if we said a task would take 1 day, we meant a typical work day with all the normal interruptions. So, maybe 1 day wouldn't actually mean 8 hours, but you don't need to dissect it further. I've found that over time, people just get a "feel" for this and everyone develops their own heuristics for coming up with work estimates based on their individual work habits. If you try to come up with a generic formula, you'll never account for the special needs of each person on your team. Leave it up to the individual for more accurate results and for greater accountability.

Unscheduled Work Day

These days were un-schedulable and were used to fix bugs in our backlog, complete urgent tasks that were missed during the sprint scheduling process and they provided some padding on work estimates for your scheduled tasks. Note that 2 days in a 2 week sprint was standard, but engineers often had an additional day or two of unscheduled work time. Some people actually had less if they opted for it and were able to run at that level of predictability. Also, note that these days didn't need to be the final 2 days of the sprint. You worked the time into the sprint as needed, but kept track of that time by having an explicit "Unscheduled Work" task assigned to you. I know...I just read that last sentence twice, too. It's what I meant to say :)

To this end, be flexible and don't be dogmatic about process. Use common sense and always be adjusting based on the ever-changing needs of your team and individual teammates. That's how you're going to optimize every hour of every day. If that sounds like overkill, would an engineer say it's overkill to optimize every frame tick in your game? Doubt it.

Planning Day

For most of the team, these days are just another Scheduled Work Day. For strike team leads (feature owners with dedicated cross discipline teams) and discipline leads, it's a chance to evaluate progress made over the past sprint and reprioritize for the next one. To give a concrete example of what I spent my time doing as a strike team lead, I reviewed EVERY task in the backlog related to my features, adjusted their priority, ensured they had work estimates and tagged the ones that I wanted scheduled in the next sprint. When I got good at it, this took me about 4 hours. So, half a day of my time as a strike team lead in a 2 week sprint was spent planning. Totally worth it and necessary.

*Schedule Resolution Meeting

This was a chance for strike team/discipline leads to sign off on all work scheduled for the next sprint and resolve any conflicts after they completed Planning Day. As a strike team lead, you were responsible for scheduling tasks for your features across all disciplines. As discipline lead, you were responsible for scheduling related tasks that didn't belong to a specific feature and for ensuring the proper resources were allocated to all other tasks requested by strike team leads. This process actually put a lot of responsibility on strike team leads and discipline leads had to give up a fair amount of control. That's not easy, but it's necessary for proper accountability to exist.

On a side note, the reason this wasn't scheduled on the last day of the sprint was so that you had time to follow up on issues not resolved in this meeting. At one point I'm pretty sure we scheduled it for the last day, but being true to Jeff's iterative methodology, we quickly adjusted it.

Morning Standups & Task Progression

The only way the sprint schedule above could be executed was by holding 15 minutes-or-less morning "stand ups" across the entire team. During these stand ups, every team member gave a quick update on tasks they completed the day before, updated time remaining on unfinished tasks, added new tasks that popped up and called out what they were going to work on that day. Also, every task/bug assigned for the sprint was printed out and pinned to a sprint board that had 5 progression states:

Blocked: These tasks couldn't be started due to another dependency not being met; whether it be another task that needs to be done first, a technical issue that has arisen, etc.
Not Started: These tasks hadn't been started yet, but were ready to be.
In Progress: These tasks were actively being worked on.
To Verify: These tasks were claimed complete by the person assigned to the task, but still needed to be verified by the task owner. The task owner was usually the strike team lead and/or discipline lead who requested it. If a task failed verification, it was sent back to the In Progress state.
Done: These tasks made it through the entire pipeline. YAS, QUEEN!

Every discipline was assigned a different card color on the physical board and tasks assigned to the same person were grouped together so they could find their cards more easily. Usually they were in the same spot on the board for each person every sprint, too. This is the level of detail I'm talking about that will get you down to 15-20 second updates per person when you're running a morning stand up at the level of a Master Producer. These are the types of adjustments you have to be looking for on a daily basis.

Some of you are probably thinking, "Why the hell do you need a physical board? Can't you just model stuff like this in software and give/receive updates via email or something?" Sure you can, but that sucks. There's something satisfying about moving a tangible card across the board in front of your peers to signify you've completed a task. Also, there's a communal, team building aspect about seeing everyone's beautiful face every morning at 10am. Showing up to that stand up is a daily affirmation that you have each other's back.

When cards reached the "To Verify" column, they were taken down from the board and distributed to the task owner so they could make sure it was completed to their specification. The cards were then returned to Jeff, our Lead Producer, and he'd put them back on the board in the appropriate column. Just below is an example of a task card I designed for the sprint board. For whatever reason, I feel like having cards printed out instead of hand writing them gives them more weight and legitimacy. I have an Excel file where you can paste an exported a list of tasks, which then auto-populates cards like this through a linked Visio file for quick & easy printing. Note that I wasn't a producer at this time. I wasn't even a lead. I was just a systems designer, but I had an interest in this stuff and offered my help.

Should be noted: Hansoft can print cards similar to this right from the application.

These morning stand ups probably shouldn't happen all at once for your team. We split ours into two sessions; one that focused on systems development and one that focused on level development. There are many ways to skin this cat. Again, when in doubt, don't be dogmatic and do what's best for your team. At our best, these stand ups lasted less than five minutes with a group of 20 people. Jeff timed each one and announced how long it took once the last person gave their update. Every day. This type of discipline is essential to evaluating the quality, efficiency and effectiveness of your process appropriately. If I were to pick one thing that keeps stand ups short and sweet, it'd be immediately recognizing issues that need to be followed up on after the meeting without 19 other people standing around wasting their time listening to you yammer about something that has nothing to do with them.

Task/Bug Tracking Software & Maintaining A Backlog

I could write an entire post about this, and I will, but that'll be part 2 of this series.

Handling Dependencies & Long Term Planning

These are another two, intertwined aspects related to this discussion, but they also require a dedicated post. I'll cover them in part 3 of this series and it should be clear why there's a bucket in the image at the top of this post.

The end...for now!

I can't believe you made it this far, but thanks for sticking through it. Trust me, I know there's nothing glamorous about these topics, but ignoring them is probably why process sucks on your team. If you love your game, you should love your process, too. It's like eating your vegetables and if you're anything like me, you hated them when you were younger, but over the years you'll acquire a taste for them.

Designing A Production Process: Part 1