Going Agile - The 7 Simple Stages of Why and How to Get it Done (I’m not saying easy)

 Traditional big budget game development methodologies such as Waterfall; milestone based, heavy on the feature collection, and documentation have to change. Breaking video game project down into Alpha, Beta and so on have been around for a very long time and on the surface appear to be control oriented and logical. This Waterfall structure is all about delivering in large increments of art, animations and code that theoretically deliver great game play experiences.  That is, write up what the entire game is; write up all the technical requirements, art and animation needs, designs, story, etc.  and then break this all down to a week to week schedule and ultimately into a hopefully a bug-free demonstrable working product we can call a game.

Stakeholders (the business), and if there’s a publisher involved, the publisher are used to and even like this arrangement as they are paying for deliverables that are forecasted (if you will) but only after they are delivered.  In simple terms, milestone “A” reads XYZ, when deliverable “A” is XYZ, you get the signature and a check. The Lawyers like this too, it’s a defensive position just in case the developer has not been completely honest or just not able to deliver the experience they sold at all the pitching sessions. The Accountants especially love this arrangement, as you get paid for demonstrable results. The fact that you get paid for the work and costs (and let’s not forget about opportunity costs) you’ve already accumulated over that past few or several weeks or months, a constant cash flow challenge is not a problem for them at all. Developers are used to this as well, give the boss or publisher the features and tasks, lock it down and estimate the man-months. The Producer plugs it all into a spreadsheet and gantt chart and rolls it all up and this usually takes weeks of work. So why do we need to change anything? The obvious answer is that in the real world there are unanticipated issues. There are issues such as changing technology, hiring new people or restructuring team members, contractors, estimation errors, general  HR issues, and even culture issues. Internally and external to the team there are disruptions such as feature creep, dropped features, bugs, change requests, and the dreaded – “It works, it’s just not fun.” Ultimately can we expect to be consistently successful with this Waterfall approach? Generally speaking, I think there’s a ton of luck whenever a great game is produced from this development methodology.

If you think about it, with this Waterfall approach you’re sort of doomed from the beginning given that you are essentially asking your team to gather all the game’s features and requirements that they want for the game, all the game features and requirements that they may want, as well as gather all the features and requirements they think they may want. To top it off, you are also asking them to do this at a time when they know the least about the design, art, technology, and team member’s abilities and without the benefit of play testing and focus groups. If there’s a paying publisher involved, repeat all of this or times 2. If there’s a license, repeat much of this again. If it’s a F2P or MMO there are also a multitude of Live Operations requirements for CRM, business development, technical operations, live operations and development, PR and marketing as well. Honestly, it’s always impressive to me when anything comes out on-time and is fun to play when this is the methodology used for creating the game.

As mobile and web technologies continue to evolve rapidly, as well as micro transaction platforms and the need for games to be connected to a digital platform there is added pressure to develop and deliver games and content in weeks instead of months or years. The basic principle of Agile methodology is to keep things simple and avoid un-necessary overhead. However, for many developers transitioning and successfully adopting a new methodology is easier said than done. Hopefully this will provide some good high-level information about why you need to be (not do) Agile as well as provide some understanding about why it works. Agile has been around for about 10 years now and most companies have difficulties transitioning to it because it really is a culture change – top to bottom bit needed today than ever.

The Standish Group is based in Boston and is in the business of assessing risk, cost, return and value for Technology Investments.

Waterfall vs. Agile project and success:

An Agile approach to development is an empirical control method or a process of making decisions based on the realities observed in the actual development project. By using frequent and first-hand inspection for the work in real-time you can make better decision about your project, not to mention better decisions about the money you’re spending every day as well as the opportunity cost. Simply put, Agile is a collection of core principles, all of which can work well for big and small budget games:

Following an Agile approach, I prefer to focus on the Scrum framework which is sometimes confused with Agile methodology, empowers you and your team to build a more successful game, cheaper and on-time. It allows you to get instant feedback by working with the customer (gamer or stakeholders) instead of working against the clock, budget, and business infrastructure. It's a win-win situation but cultural changes are needed and usually the biggest roadblock to going Agile. In the long-term, experiencing a trusting partnership (measurable and verifiable in real-time) between customer, stakeholder and or publisher and the development team leads to the building of trust; and trust leads to higher efficiency, more creativity and effectiveness which increases your chance at a having a successful game. So what does this all look like and how does it work to “the boots on the ground”?

Stage 1: Vision

I think creating the game’s vision can be the easiest part; we’re all pretty good at this with the game’s “X” or essence statement and the vision usually come to life during the pitch process. This is really because there are instant feedback loops with the team, marketing, and others.  Components of effective vision are:

Stage 2: Have a Roadmap

Game and Technical Design Documents are good as long as they’re not used as a recipe. In Agile, there is a need for a roadmap, a formal written template of features, design, art vision and gameplay. The aim is to have a backlog of features that can later be estimated by the team that needs to do the actual work. The team needs (key word!) to be cross-functional. This is usually one of the first areas where you find out if your culture supports going Agile or not. Is everyone on the team able to honestly say everyday “Yes” to the following questions; “What can I contribute today?” and “How can I expand my contribution in the future?” Direct accountability to delivering and a little team competition is everything in the trenches. The roadmap should include:

Stage 3: Release Planning

Now that there is a roadmap, it’s time to break this down into a release schedule, with the most important features first. Initially, this creates two very important things as getting started can sometimes be the most difficult and critical stage of any development project. First, this gives the team something to rally around. Secondly, getting the most important features done first will let you know if the game should continue or be cancelled, and knowing this as quickly as possible is critical. After all, we live in the first to market world with greater importance given to opportunity cost than ever before.

Once the team has a plan and is participating on the estimation of work process you’ll quickly get a sense of their estimation abilities as well as the knowledge of just how fast or slow you’ll be able to deliver what you promised. Release planning usually includes:

Stage 4: Sprint Planning

If your Release Planning points to 2 week Sprints (the amount of time the team needs to deliver done, working, releasable bug free software) than you should allocate 2 hours each week for Sprint Planning, or one hour for each sprint week. This is where the team, facilitated by the “Scrum Master” will estimate the work to be done. There are a few ways to do this but the Scrum Master needs, above all to be in control and assertive so these sessions are productive. If this meeting starts to feel like a reality show, with drama then you’re losing it. This is another area where your culture will be on full display as far as which team members are going to work well, and which are going to be a challenge throughout the project. Sprint Planning is:

Stage 5: The Daily Scrum

Most are familiar with the daily stand-up or the daily morning meeting and unfortunately some think this is what Scrum and Agile are all about – short meetings with no chairs. Also, over the last few years, the word ‘transparent’ has been used more than the line, “…at the end of the day…” but here no one hides, no-one bloviates, no-one is better or worse than anyone else. The only focus of the daily Scrum is; “This is what I did yesterday, this is what I’m doing today, and these are the things impeding me.” We are building stuff people and nothing else matters. The goal is face to face updates and communicating issues and problems that the Scrum Master needs to solve. The Daily Scrum components are:

Reference: Platinum Edge, Inc.

This is the classic view of the Project Team (Scrum Team), Stakeholders (business) and Agile Mentor or Coach (recommended during cultural transformation from Waterfall to Agile) and Product Owner (Executive Producer or Game Director).

Stage 6: Sprint Review

After a completed Sprint, there is a need to formally demo the work. There’s a lot here behind the scenes about automated testing, architecture, how and what a definition of a done feature is, given the goal of every sprint is to have a bug free, completed working product that can be demonstrated to the Executive Producer or Game Director. Further, this is theoretically or realistically releasable to the marketplace. Obviously this methodology is being used more and more on mobile, F2P and Casual where there are on-going needs for updates, content, features and live operation’s needs. There is no pageantry here, no PowerPoint’s, no mock-ups or hard coded stuff – just running code. The entire meeting should take about 20 min. to an hour. Sprint Reviews are:

Stage 7: Sprint Retrospective

After the review and given there’s been essentially nothing but coding going on, against the backdrop of having a Scrum Master running around keeping distractions away from the team, there is a need to step back and ask, “What went well?” and “What didn’t go well?” This is again usually where cultural issues arise around people and politics as this methodology doesn’t really fix problems, it exposes them. However, the focus is really on what’s working, what’s not working and what needs to change. The lists of possible issues are virtually endless, could be art is too slow, could be design issues and so on. There are burn down and velocity charts to show the team’s performance and other challenges to the project. The purpose of the Sprint Review is:

Now, start the next sprint because while the team has been coding, the leadership has been refining the Road Map and Planning…

Reference: Platinum Edge, Inc.

A truly Agile approach encourages organizations to move away from yesterday’s traditional Waterfall approach and to develop a culture as well as structure at all levels that continually asks what’s best for the gamer, the game, the IP, partnerships and the organization. By constantly challenging the status quo on your Agile game projects you will reach new levels of efficiency and team productivity by having the customers receive working features quicker. Since this methodology is about frequent delivery, this also means that you get working features into the hands of customers and other stakeholders as quickly as possible. This ensures that the development team will receive informative, immediate feedback on necessary changes before it’s too late to change them. This will also help determine whether the project team is headed in the right direction in terms of the game’s essence, features and future tasks. Teams can quickly validate if they can proceed in a given direction, or if there is a need to make major or simply minor adjustments. This principle stresses the importance of embracing change on your projects. On Agile projects, you welcome change at all times, even late in development. Change helps you ensure the gamer will get exactly what they want or need, as well as gaining a competitive advantage over similar games or competitive titles.

There are naturally other considerations and disciplines to engage in all of this. Given company cultural issues such as the Lawyers, Accountants and business people, the internal empires and silos, the best approach is to start with qualified outside help and formal training and assistance. The bottom-line here is that when development team members get to choose their own tasks, the end result is maximum quality, creativity and team member collaboration. The productivity of the team as well as the quality and value of deliverables increases exponentially.