Agile: From zero to launch in 80 days – 7/16/13

Agile: From zero to launch in 80 days

Blog by Walt Yarbrough, producer, MassDiGI

The MassDiGI Summer Innovation Program has several overarching goals which influence our choice of Production methods.

Our primary goal is to produce fun, profitable, technically solid games.

Secondly, we want the SIP students to learn applicable real-world skills in a production environment.

Finally, we want the students to experience a complete product life cycle, from conception through release, to maintenance and updating.

With an 11 week program, our first production decision to reach these goals is easy. Ideally, roughly 50% of production time is devoted to bug fixing, tuning, and, increasingly, reaction to analytics. Given the initial week of orientation and team forming, plus the short Fourth of July week, the first six weeks are slated for production, and the remaining five weeks for ‘Beta’.

With the goal of teaching applicable skills, the choice of a Production method is also easy. Nearly all of our students had zero exposure to any production method, so we decided to use Agile (Scrum). Much like the decisions to use Perforce, Unity and shared documentation on Google Drive, we are not only choosing the industry standards for projects of this size, but also the best available technology and methods.

However, with four small teams co-located in two rooms full of production machines, the need for documentation and meetings to promote intra-team communication and coordination is minimal. Additionally, our projects do not have an Agile Project Owner available. And our Scrum Masters also must spend the majority of their time being individual contributors.

Not only would we need to teach each contributor Agile, we would also need to train Scrum Masters and Project Owners if we were to implement Agile “by the book”. Going by the book would also add to the documentation and meeting load on the teams. My post mortem of the 2012 Summer Innovation Program was that our teams got overwhelmed trying to fill all of the Agile roles and requisite documentation and meetings, an overhead burden that limited the benefits of Agile. This burden often fell completely on the Scrum Masters of the 2012 teams.

Walt Yarbrough

So, I chose to modify our Agile in the following ways:

We eliminated the Project Owner – replacing this role with weekly team goals on the whiteboard. Constant communication from management in the same room and daily builds are the tools used to keep the Projects on track.

We eliminated the Project Backlog and Sprint Backlog – replacing them with a standard set of preproduction documents for each team, including an Elevator Pitch, Sell Sheet, Design Document and Art Style guide.

We eliminated the Sprint Planning Meetings, Sprint Review and Sprint Retrospective – these proved to be too much of a burden on an inexperienced Scrum Master who is also charged with individual tasks.

With only six ‘production’ weeks, we set our Sprint length at five days – Monday to Friday. That gave us many chances to course correct each project, if needed, something that would have been extremely limited with two week or three week sprint durations. It also gave our students more practice and experience at estimating their own tasks, as for many of them this is their first games job – the first time they have been paid to work 40 hours a week, and the first time results are expected and measured.

While the elimination of the meetings helped reduce the burden on our inexperienced Scrum Masters, I didn’t stop there. We charged every contributor with delivering 32 hours of planned work to their team Scrum Master no later than noon on each Monday. I then took it upon myself to critique and request revisions on these task descriptions, to ensure that they were crisply defined. While the tasks would not be ‘by the book’ User Stories estimated in Planning Poker sessions, my review would ensure that they would match the spirit of Agile and be tasks that could be measured, delivered and agreed as ‘done’ by the team. In other words, I’ve taught everyone how to describe a user story correctly in their burndown without teaching them user stories.

We consciously did not specify how each team was to agree upon their 32 hours of work for each member – my experience and the post mortem of the 2012 SIP program was that small teams on small projects like this organically know their next steps to meet their overarching goals. A specific method to discuss and debate would just be an unnecessary burden.

Our Scrum Masters print one initial burn down Monday at noon – tracked in a Google doc spreadsheet, then hold standup meetings every day at the end of the day and print and post an update. The MassDiGI managers or other stakeholders can review the physical copies with a walk around the room or check the online repository for status and feedback.

With everything we eliminated from Agile – how can I even call this Agile? Remember, one of the key points was to look at this from the student’s perspective. As individual contributors, they are estimating their own tasks, standing up daily to report progress and seeing their progress tracked prominently in their workspace. All of these are key components of Agile from an individual contributor standpoint. The fact that this modified Agile allows MassDiGI management to track remotely and on-site with ease is just a bonus.

To date, the production changes we made for the 2013 program have worked out well – the students, at this stage, are writing clearly defined tasks, and productivity on all five teams is high. I can confidently state that the overhead burden required for Scrum has been more than offset by the benefits. The management has a clear communication tool to track progress, and the students have gotten great exposure to the industry standard.