AntiAgile: Constructive Critique of Agile Methods in Video Game Development

1
Anti-Agile Constructive Critique of Agile
Methods in Video Game Development

• Sergei Savchenko
• Studio CTO/COO EA Montréal

2
Disclaimer

• EA Montréal has teams and partners using Agile
• Engaged Clinton Keith for one of our teams
• There is some anecdotal evidence of successful
  teams that use Agile methods
• The opinions expressed here forth are my own and
  dont reflect EAs stand on the matter. Moreover,
  the following cannot be used as an
  acknowledgement of EA having or not having a
  stand on the matter.

3
But

• There is about as much anecdotal evidence of
  failed projects that attempted Agile methods
• Is Agile always applicable?

4
What matters?

• Results
• Commercial success/Critical acclaim
• Cost/Time/Quality
• Applicability to Video Games Industry (video
  games are not software)

5
Agile

• Evolved in mid 90s as an opposition to Big
  Design Up Front methods
• Somewhat formalized in 2001 in Agile Manifesto
• Scrum
• Extreme Programming
• AUP, FDD etc.
• Lean Software Development

6
Agile Values
Does this include SCRUM or XP Processes?

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Working shippable software?
Who is the customer in this industry?
What is the nature of change in a video game
project?
7
Scrum

• Takeuchi, Hirotaka Nonaka, Ikujiro, The New
  Product Development Game, HBR, Jan-Feb 1986
• Iterative and evolving (Sprints, Retrospectives)
• Prioritized features (Product backlog)
• Multi-disciplinary and self-managing teams
  (Scrums)
• Access to the customer (Product Owner)

8
Words of caution

• Some words of caution are in order. The holistic
  approach to product development may not work in
  all situations. It has some built-in limitations
• It requires extraordinary effort on the part
  of all project members throughout the span of the
  development process. Sometimes, team members
  record monthly overtime of 100 hours during the
  peak and 60 hours during the rest of the project.
• It may not apply to breakthrough projects that
  require revolutionary innovation. The limitation
  may be particularly true in biotechnology or
  chemistry.
• It may not apply to mammoth projects like
  those in the aerospace business, where the sheer
  project scale limits extensive face-to-face
  discussions.
• It may not apply to organizations where
  product development is masterminded by a genius
  who makes the invention and hands down a
  well-defined set of specifications for people
  below to follow. (emphasis added)
• Takeuchi, Hirotaka Nonaka, Ikujiro, The New
  Product Development Game

9
Extreme Programming

• Kent Beck, Extreme Programming Explained
  Embrace Change, Addison-Wesley, 2000.
• Attempts to take best practices to the extreme
  level
• Values (5) e.g.
• Communication
• Simplicity etc.
• Practices (12) e.g.
• Pair programming
• Simple design etc.

10
A fad?
Scrum
Extreme Programming
11
Lean Software Development

• Ideas borrowed from Japanese manufacturing (Lean
  manufacturing)
• However, where is Japanese Google?
• Also, whats wrong with NIKKEI !? (N225)

12
Agile as opposed to Waterfall
Using a traditional waterfall-oriented process
leads to a cycle of write all the requirements,
analyze the requirements, design a solution, code
the solution, and then finally test it. Very
often during this type of process, customers and
users are involved at the beginning to write
requirements and at the end to accept the
software, but user and customer involvement may
almost entirely disappear between requirements
and acceptance. By now, we've learned that this
doesn't work. (emphasis added) Mike Cohn, User
Stories Applied
While a convenient target, no one uses this on
practice in video games industry or outside of it
13
Waterfall

• Somewhat of a historic accident. Mentioned (not
  by name) in Dr. Winston W. Royce Managing the
  Development of Large Software Systems IEEE
  WESCON 1970 as an example of what not to do

I believe in this concept, but the
implementation described above is risky and
invites failure Dr. Winston W. Royce
14
Waterfall (cntd.)

• Even MIL-STD-498 (1994) describes incremental and
  evolutionary methods in addition to Grand Design

Waterfall is Agiles easy but irrelevant target
15
Agile Management as opposed to F.W. Taylors
Scientific Management
As the literature will attest, traditional
command-and-control management is largely derived
from the principles of Frederick Taylors
scientific management. In todays world,
however, we have trouble imposing
command-and-control management on teams because
working masses have been replaced by knowledge
workers. (emphasis added) Managing Agile
Projects, Kevin Aguanno editor
F.W. Taylor is an easy target however, there
was 100 years of management advances since
16
Brief History of Management

• F.W. Taylor Shop Management, 1903
• Management as science
• Henri Fayol General and Industrial Management,
  1916
• Organization theory
• The Hawthorne Experiments 1924-1932
• Performance is not just physiological but also
  psychological
• Mary Parker Follett, 30th
• Power with and not power over
• Douglas McGregor The Human Side of Enterprise,
  1960
• Theory X and Theory Y principles
• Tom Peters and Bob Waterman published In Search
  Of Excellence, 1982
• Understanding the customer, productivity through
  people

F.W. Taylor is Agiles easy but also irrelevant
target
17
Why Agile for Video Games?
Predicated on the ability of the team to identify
fun

• Find fun first
• Reduce wasted effort/crunch

Iterations may increase the amount of work and
often involve re-work (see The New Product
Development Game).
18
Whats special about Games?

• Games are not software but entertainment products
• We have mass market customer
• Game teams may have only 25-30 programmers
• Designers, Artists and Programmers dont work the
  same way
• Highly enthusiastic employees (many of whom have
  design ideas)
• Console games have an additional first party
  customer (Nintendo, Sony, Microsoft)

19
Whats special about Games?

• Game projects are constrained in terms of
• Resources
• Time
• There are often high expectations of
• Scope
• Quality

20
Whats special about Games?

• There is a wide variety of projects in the
  industry
• Internal packaged goods products (you can only
  ship once, not counting title update)
• New IP on a new engine
• Sequel on an existing engine
• MMO, MSG (updated on a regular basis)
• Contracted packaged goods products
• Contracted game modes (e.g. multiplayer)
• Mobile games
• Downloadable games
• Web games
• Internal tools, libraries and engines
• Middleware tools, libraries and engines

21
Agile in terms of

• Satisfying Customer
• Leading Teams
• Engineering Tech
• Planning

22
Customer

• Mass market
• Through representation of publishing, marketing
  and production
• Play tests/focus tests
• Publisher
• Worries about risk (expects the product to be
  true to the brand, on time and on budget)
• Will not give a good functional direction of what
  to build
• Internal customer
• In cases of building an engine or tools for the
  team
• Will give functional direction

23
Customer

• Iterative development may not succeed in cases of
  mass market products especially when you compete
  on innovation
• Having a person with the team who knows what
  good looks like anecdotally often correlates
  with success regardless of what process is used
  (These may not know what needs to be done though)

Agile is more appropriate when your customer can
give a functional description of what is needed
24
Customer

• The mass consumer may not know yet what it will
  want (rhythm music games are popular today this
  need didnt exist in the 90th)
• At the same time, when
• design may ask for specific technical solutions
• technology may provide new design possibilities

With Agile, relationship with the customer is
mostly one way. In video games successful
relationship is both push and pull
25
Leading Teams

• As a Leader
• One should be creating an appealing common end
  for the team
• As a Manager
• One is to understand teams true status
• One is to plan how to deal with project risks
  (including cost of change)
• For a group and work that needs to be done
  identify
• Outcomes to achieve
• Decisions that the team (or an individual) have
  power to take
• Available resources to use
• If the sky is falling, act as a Specialist and do
  someone elses job

26
Leading Teams

• Self organizing/self managed teams operate by
  consensus
• Chances of achieving consensus decrease with
  groups size (and so is groups productivity)
• Some will say that the ideal self-managed team
  has the size of three

From Advances in Sport Psychology Thelma S.
Horn editor
Self managing teams Agile advocates can only be
of limited size
27
Leading Teams

• Most western businesses are meritocracies
  (Results matter)
• It is possible to cede authority to natural
  leaders in a scrum (a group) when the group is
  large (the business may not survive though)
• Governments operate towards common good,
  successful businesses have a common end hence
  democracy vs. meritocracy

Businesses usually dont survive as democracies
28
Tech Scaling
Caproni CA.60 Noviplano
Caproni CA.4
29
Engineering Tech

• It is hard to iterate over a fundamental
  technology hump
• One needs to
• Understand constraints
• Design on paper
• Experiment (perhaps many times)
• Prototype (potentially several times)
• Develop (perhaps through consecutive iterations)
• e.g. streaming tech for an open world game, a
  procedural animation system etc.

30
Technology shape of a project
iterative features
time
engine components
test, debug
implement
prototypes
design
experiments
design
31
Engineering Tech

• Iterative and evolutionary development works well
  for a large volume of medium depth problems

Agile is not necessarily a good approach for
solving deep technological problems or producing
innovation
32
Entirely unlikely scenario

• Over the course of last year two teams built
  racing game engines. One team was traditional
  and the other Agile.
• The projects got killed. The teams are to build
  dancing games instead with their engines.
• Which team is better off?
• Traditional or Agile?

33
Planning

• Did anyone on the team ship music games before?
  Or knows someone who did?
• If not,
• Agile team soon identifies a set of stories of
  value to the PO but will likely stumble with a
  very high rate of discovery for many sprints to
  come
• Traditional team should be guided towards
  identifying major risks. The focus of early work
  will be de-risking rather than value

34
Agile Planning

• Mostly relies on implicit planning
• Assumes that user stories are largely independent
• Pushes risk management to the task and iteration
  level
• Avoids explicit scenario planning

Agile planning is highly inaccurate in the
presence of unknowns. The team converges to
proper estimates after many sprints with very
high discovery rate
35
Planning

• Plans are predictive mechanisms and are there to
  adapt to reality
• They are there to identify risks
• Plans help to give an idea of the cost of change
• Historical data is invaluable for planning

36
Planning

• Balancing interdependent variables
• The risk is in being outside of the desired slice

resources
quality
scope
time
37
Planning

• For any significant risks identified
• Avoid (e.g. not implement a feature)
• Reduce (e.g. implement a cheaper fall back
  first)
• Transfer (e.g. acquire tech)
• Retain (e.g. suffer through)

Rather than actualizing risks, Agile pushes risk
management to task and iteration level
38
Other Commonly Mentioned Issues with Agile

• Lack of code durability and poor code performance
  (due to the chase after up-front features)
• Communication effectiveness (too many meetings)
• Only works with Sr. developers
• Not everything is a user story

39
Project Management Patterns

• Dont try to fit a project into a template (be it
  iterative, evolutionary or sequential)
• Use a set of building blocks to construct (and
  dynamically adjust) the plan and the development
  process

40
Project Management Patterns

• Phase
• A transition to a new phase occurs when the
  development model changes e.g. Concept discovery
  phase to pre-production phase production phase
  to finalling phase
• Time Box
• Proceeding in the order of feature value
• Done with an assumption that certain features may
  not be done

41
Project Management Patterns

• Sub-Divide
• Separate the project (and the team) into
  sub-parts that will interact through an
  established interface
• Block
• Realign all sub-teams for a deliverable
• Buffer
• Provide for extra work based on historic
  discovery rate
• Box Change
• Restrict changes to only certain systems (e.g.
  only game-play changes, no rendering changes)

42
Project Management Patterns

• Parallelise
• Sub-divide the team into sub-teams working on
  independent components (e.g. a sub-team per one
  map of the game)
• Prototype
• Develop a proof of concept using simplified
  technology that may or may not be discarded

43
Project Management Patterns

• Develop Alternatives
• Independently develop several feature
  implementations only one of which could be
  selected (e.g. multiple control schemes)
• Fallback First
• Develop a base-line implementation first of a
  risky feature to fall back on if a more risky
  approach fails in the future

44
Time box
Fallback 1st
Production
First playable
Alternatives
Concept discovery
Prototype
45
Questions?

• Sergei Savchenko
• ssavchenko_at_ea.com

ROUND TABLE Methodologies Room 513D, Today _at_
1715