Moderator: Heather M. Chandler, Executive Producer, Media Sunshine

PMI: Karin Groepper Boosman, Localization Project Manager, Aspyr Media/ Agile: Rich Vogel, Co-Studio Director, BioWare Austin/ CMM PSP: Tobi Saulnier, CEO, 1st Playable Productions

This was a tough session to blog, with lightning fast slides and summaries, so forgive some incompleteness! The overviews were awesome though! It’s interesting to hear the different methods and their similarities and differences.

PMI – Project Management Institute is an international professional organization linking project managers across 70 industries and 170 countries, founded in 1969.

PMI – Backbone of Methodology: Methodolgy scales to current body of knowledge and development technology, but always includes the 5 process groups – Initiating, Planning, Executing, Monitoring/ Controlling, and Closing. In addition to the process groups, there are 9 knowledge areas – Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resources Management, Communications Management, Risk Management, and Procurement Management.

Quality management is something we do awesome in the games industry. Human Resources Management comes down to treating people as your most valuable asset.

Scope Management and Control and Risk Management are areas for immediate improvement.

Scope Control, best practices for quick results:

Determine Scope baseline at the start [ Document expected final results and ancillary attributes. Document how scope is expected to achieve your studio’s business results, which could be making a profit for the studio, just recoup costs, or establish a name for your business, leading to future sustainability.

Create a formal, transparent, cost-associated change process – Measure scope change requests against the scope base line. Associate a cost with each scope change.

Risk Management, best practices for quick results:

Create a comprehensive Risk Plan. 1 = nominal, 5 = unsalvageable

1. First figure out what your negative risk thresholds are. On a scale of 1-5, what cost amount, time variance and quality variance qualifies as 1, 2, 3, 4, & 5?

2. List all risks your team can think of – Creative risks, schedule/ cost risks, and methodology risks.

3. Analyze each Risk – Rank each risk for likelihood and severity of impact. Prioritize all risks rating an average of 3 or higher. Define and document causes, avoidance plans and mitigation plans. Probably most importantly, Share this information with your team and with your stakeholders. Assign owners whose responsibility will be to navigate the risk according to plan.

PMI offers well practiced tested methods and templates to help PMs and Producers to do their jobs efficiently and effectively. No need to reinvent the wheel! Leverage templates and processes already created. Adaptable to a variety of development styles. YOU decide which processes serve your project.

CMM – “Capability Maturity Model” – www.sei.cmu.edu. Was developed to address a crisis of Software Risk in US industry in 1984. “Software Engineering” focuses on state of the art versus state of the practice.

CMM Levels are perfect for gamers! There are five levels for any process: Initial, Repeatable, Defined, Quantitative, and Optimizing.

Level 1: Initial – Ad hoc and occasionally chaotic. Few processes are defined, and success depends on individual effort and heroics. Characterized by a tendency to over commit, abandonment of processes, and an inability to repeat successes.

Level 2: Repeatable – Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on similar projects.

Level 3: Defined – The game development process is documented, standardized, and integrated across the organization. All games use an approved, tailored version of the organization standard process for developing and maintaining assets.

Level 4: Quantitative – Detailed Data on the game development process and the game quality are collced. Both the game development process and games are quantitatively understood and controlled.

Level 5: Optimizing – Continuous process improvement through quantitative feedback from the process and from pioloting innovative ideas and techniques. Start looking at defects or bugs and how you prevent it and change processes.

Take aways for CMM include an intuitive framework for *any* process improvement effort, as well as a step-wise approach for organizational development. You can be at different places in different processes. You might have a code standard already and be at a Level 3, but you might introduce something like code reviews and jump right from a Level 1 to a Level 3. Once you have that level of understanding in your organization, you can start to standardize your process.

Barriers in “leveling up” are your party and their stats (RPG analogy). A lack of professional training or knowledge on how to measure and predict their own work impedes process. People may not understand their own process beyond “code and then fix it.” There is a gap in project team training, and skills needed are planning, tracking and changing plans! The software industry had to deal with this exact issue 25 years ago when they pioneered the software process.

Training: PSP and TSP (Personal Software Process and Team Software Process)

PSP is aimed at providing professional engineering skills to individuals. Develops process steps other than writing code, compiling it and then fixing the bugs. Teaches tools and techniques they can use, and using data to improve estimating and planning. Also learn how to improve quality and reduce defects.

Basic tools: Using data to identify problems early, come up with solutions and gain knowledge and insights.

Challenge in software is that data does not transfer across individuals. The only one that applies to individuals is their own performance data. Data moves up pyramid to information and then last to knowledge and intuition.

TSP builds on PSP tools and techniques. Motivates and guides customized data collection and resulting decisions. Started with a TSP launch at a project kickoff to establish goals, define team roles, assess risks, and produce a team plan. Gave the team the power to solve their own problems, notice they were falling behind on something before Manager had to notice. TSP is basically an “in project” team training, related to something you are actually working on as you are doing it.

A TSP launch is multidisciplinary, including the client. This allows ALL team members to understand the game they are going to create and feel equally responsible for delivery. It’s also focused, realistic, creative and efficient, being accomplished in FOUR DAYS.

TSP is not new at all, we’ve done this all before but TSP provides a structure.

Benefits are team morale and cohesiveness, individual ownership of tasks, lessened burden on leads and PM for scheduling and delegation. Process is way more simplified, and useful data is gathered for future planning such as lines of code per hour, animations per day, task hours per week and better metrics for components.

Change acceptance is hard and there are models for this. If you want people to change things you need 2 of the 3 following things: Leadership, Shared Need, and Shared Vision.

Agile

The goal is high quality games a lower cost and that as fun to develop as they are to play. High metacritic rating (www.metacritic). Less work and less time.

Challenges of waterfall are team size. Communication challenge increases faster than team size. Centralized decision making gets overwhelmed (decision bottlenecks). “Fun” typically requires an unknown amount of iteration.

Key motivations are communication, fun factor and “Parkinson’s Law”. Scrum is not the silver bullet. If you have a dysfunctional team, scrum will not help.

Product roadmap. Set milestones every 6 weeks, made of two 3 week sprints. Define only the first two milestones in detail.

Release roadmap includes offsite meetings to reduce distractions, define release objectives, create one product backlog for all teams.

Everyone at BioWare, artists and programmers, get Agile/ Scrum training.

Trent Oster gave a very valuable and information dense presentation of BioWare’s Agile Implementation. As with every BioWare presentation you get a sense of how well thought out things are at BioWare and how closely they pay attention to what is happening with the teams on a day to day basis. It makes sense based on the values driven culture that we heard about on the first day of the forum.

The presentation was in three parts:

1. An overview of what BioWare did to adopt agile
2. The problems they encountered
3. What they did to fix the problems

Adoption
BioWare made great use of a coach during their adoption of Scrum. Trent brought Mike Cohn in and said that they benefited greatly from his classes. BioWare formerly trained almost everyone on the team about Scrum. Teams were 3-10 people in size. Daily Scrums were run by-the-book with stand-ups, war-rooms and task boards.

Problems & Solutions
Trent covered the five significant problems and their solutions that they encountered adopting Scrum.

Technical Debt
Technical debt is any technical work on the project that isn’t “done done”, which Trent defines as proven in the game. Addressing technical loose ends has been a challenge for their releases (multiple sprints leading to a demo). BioWare has implemented improved goal communication and allowed for the last sprint of the release to be dedicated to addressing technical debt.

Technical and Architectural Oversight
BioWare identified the need for their princliple programmers to meet daily to discuss the technical vision and goals for the team programmers. This addresses the problems of having programmers distributed across multiple teams and the reduction in communication this causes.

Long term scheduling oversight
BioWare has maintained a “waterfall like” approach to long term schedules using Scrum releases. The problem they ran into with this approach was that their long-term schedules were not maintained well enough to match the reality of an agile project. To address this, they have allowed for frequent revisits of the schedule and have migrated from a large schedule to “rolled up deliverables” that are more easily maintainable.

Clear Acceptance Criteria
When they first started using Scrum, some teams didn’t go a good job defining what would be delivered. As a result, teams felt that they delivered early while customers felt they undelivered. To fix this, they introduced several practices:

• Short planning documents for each feature are written
• Meet to discuss the end user facing features.
• Write it up briefly and circulate for all parties
• Set up a review meeting before the work was started.

Optimistic Planning
Some Scrum teams were consistently overestimating the work they could accomplish during a sprint and consistently missing their sprint goals. While BioWare leadership understood this desire, they wanted the teams to be a bit more realistic rather than accepting failure. They used historical data to influence the team yet still allowed the team to drop work ahead of the deadline to still get a level of success.

Conclusion
BioWare has realized many benefits of agile and Trent’s talk was a very honest and informational description of their adoption.

I was very impressed with the first day of the forum. Plenty of great talks on leadership & production with a very focused group of attendees.

Every one of the ~six talks I have been to has raised the topic of agile in a positive light. One of the most encouraging comments that I have heard was from Trent Oster from BioWare who said that the internal BioWare teams using Scrum show a 2 to 2.5 times improved productivity.

The “Leadership in an Agile Environment” roundtable was very crowded and lively. It was great to hear that their are many common solutions to the common problems that face agile adopters (mostly Scrum). Among those are publisher relationships and the confusion about long-term planning.

One interesting thing to hear about is the topic of how much a team should change the Scrum practices up front. I hear a lot of comments like “we’re doing a hybrid of Scrum and Waterfall”. This seems to be a necessary phase for many company environments, but to me the jury is still out on how effective this is in the long run versus adopting full Scrum practices from the start and modifying them after they have been mastered.

Some observations:

• The lack of full Scrum adoption seems to cause some disgruntlement among the people who are enthusiastic about it.
• Many teams adopting Scrum don’t send at least one person through certification.
• Teams that adopt full Scrum from the start have a great deal of success, but it requires someone in charge to champion the cause.
• How design and art fit into Scrum is a point of contention.
• “New Scrum fanatics” can turn people off with their fanaticism.
• Some folks on the team firmly oppose agile from the start. “It’s the latest management fad” they say.
• Adopting Scrum halfway into a project creates lots of problems, but everyone who experienced these problems are excited to apply Scrum to the next new project.

Overall this forum has been a great experience. We’ve passed the tipping point on agile game development. There’s already talk about an “agile track” next year or even a separate agile forum.

Well done IGDA!
Clint