Agile 101

Who am I?
• Project/Program Management +18 yrs.
o Agile software development for past 5 years
• CSP, CSM, CSPO, Agile Trainer, Hansoft Certified Trainer

• Director – Portfolio Management Office (EAC)
o PMO, RMO & Studio Ops

• Sr. Development Director – EA Sports
o Madden, Tiger Woods, EA GameShow, EA|ON
• X360, PS3, PC, Facebook & Web

• Senior Production Expert @ Hansoft
• Project Director @ Universal Studios Creative

Waterfall
Concept

Pre-
Production

Production

Testing

Release

The Relay Race
• ―The… ‗relay race‘ approach to product
development…may conflict with the goals of
maximum speed and flexibility. Instead a holistic or
‗rugby‘ approach—where a team tries to go the
distance as a unit, passing the ball back and forth—
may better serve today‘s competitive
requirements.‖

• Hirotaka Takeuchi and Ikujiro Nonaka,
―The New New Product Development
Game‖, Harvard Business Review, January
1986.

What is Agile?
• It‘s a method for developing products using short
iterations
o Each iteration is like a short project in itself
o Uses ―inspect and adapt‖ practices to adjust the project plan
o It focuses on adding features in a value prioritized way, rather than a
resource prioritized way

• Agile doesn‘t solve problems!
• It is about brutal transparency
o Early & Often

• Inspect and Adapt

Test Driven Development
Repeat

(Re)Write a
test
Re-factor
Write
production
Code

Check if the
test fails

Clean up
code
If pass

Kanban/Lean

Not Started In Progress Implemented In Testing Done

The “Scrum” Process
24
Hours

1 - 4 Weeks Potentially
Product
Backlog Shippable
Sprint Increment
Backlog

Sprint Review

Waterfall Trip

Fuel
Food
Rest Stop

How is Scrum different

Fuel
Food
Rest Stop

“Agile” Manifesto
Better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

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

That is, while there is value in the items on the right,
we value the items on the left more.

Key “Agile” Principles
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress.
• Even late changes in requirements are welcomed.
• Close, daily, cooperation between business people and developers
• Face-to-face conversation is the best form of communication.
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design.
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

Product Backlog
• Often referred to as the big list of work
o The ―idea‘s for the project

• Very few ―tasks‖ in the backlog
• Definition of ―Done‖
• Single backlog for your project
o Not “A” backlog but “THE” backlog
o Viewable by entire team

• All User Stories should have a RELATIVE estimation
o (Story Points / Estimated Ideal Days)

• Prioritized at multiple levels (Theme & User Story)

Best Practices
• The team structure and the product backlog
structure should be aligned
• Themes, Epics & User Stories should be well
composed and focused on the end user.
• Clear Ownership
• Common terminology for your Project
• ―All‖ User Stories Start in the Product Backlog
• User Stories should be re-estimated and re-prioritized
after each release
o Include items just completed.

Obstacles
• Backlog seen as ―Overhead‖
o What is the ROI on the effort required to build and maintain the backlog

• Clarity is product ownership
• Not a mandate with some teams.

Value
• Team has a more clear understanding of what they
are building
• Business has confidence what can be delivered
• Right focus at the right time
• Change Tolerance – Ability to know impact of
change
• Helps to surface dependencies
• Gives Product leadership confidence
in the roadmap.

What is a User Story
• Should be focused on the user
• Simple and concise
• Hierarchical
• Prioritized
• User Story Template

“As a <user role>, I want <goal>
so that <reason>.”

Sprint Backlog
Developers
break story into
smaller
deliverables

Refining the backlog
Sprint

Priority/Time

Release

Long Term

Grooming the Backlog
• Keep tasks out!
• Structure, Structure, Structure
• Remove old/stale information
• Key information for all items
• User Stories are sized according to priority
and time.
o As items near implementation (releases/sprints) more detail
is applied.

Poker Planning
• Relative estimation of all backlog items
o How one items compares against others in terms of effort
o 1 Point item is ½ the effort of a 2 point item

• Story Points or ideal Days
o T-Shirt Sizes

• Team estimates each item
o Product Owner explains user story
o Using planning poker cards everyone picks a card
• Then discusses of there are differences in numbers
o Repeat until card draw until everyone agrees

• Estimation should NOT be based on time
o #1 Mistake in backlog estimation for teams

Relative Accuracy
• The challenge with estimating anything
o We are overly optimistic
o We are just not built to think in time

• Difficulty sizing things the large the value
1.6

1.4

1.2

1

0.8

0.6

0.4

0.2

0
Points 1 2 3 5 8 13 20 40

Release Plan
• Theme or Narrative
o What is our high level goal

• Capacity based on empirical velocity from prior
releases
o Based on team by team velocity

• Includes user stories with key data
• Plan multiple releases

Release Planning
• Multiple Development Sprints
• 1 Hardening Sprint
o Integrations/Polish/Bugs

Release 1 Release 2

Hardening
Hardening

Sprint
Sprint
Sprint
Sprint

• Hardening Sprint length not tied to development
Sprint length

Release Planning
• Multiple Development Sprints
Release

Hardening

Hardening
Sprint
Sprint
Sprint
Sprint

Sprint
Sprint
Sprint
Sprint
• Hardening Sprint in Middle & End

Release Burndown
• Includes
o Empirical information from prior releases
• Using relatively estimated user stories
o Includes team by team velocity of work for each release

Start/End Together
• Don‘t stagger sprint starts
Team 1 Team 1
Team 2 Team 2
Team 3 Team 3

• Sync Sprint Start/End Dates
Team 1 Team 1
Team 2 Team 2
Team 3 Team 3

Sprint Length
• Most common Sprint length
o 2 – 3 Weeks
o 1 – Week for Social or Live teams
o 4+ – Weeks is generally not suggested

• What Sprint length is best?
o How long can your team go without shifting directions
o Risk of what is being delivered
o Lowest amount of Start/Stop time (for complexity of work)
o How well your teams estimates (over a span of time)

Sprint Planning
• Product Owner
o Pre-Assigns Sprint deliverables to sprint backlog
• Taking into account the prior sprint velocities

• Team
o Reviews sprint backlog
o Commits to level of work it feels it can complete
o Work is broken into ―work remaining‖
• Based on hours

Daily Standup
• No more than 15 minutes
• Attendees
o Product Owner, Scrummaster & Team

• 3 Questions
o What did I complete yesterday
o What and I going to complete today
o What is blocking me from completing my work

• Conversations take place after meeting

Sprint Review
• Review work delivered with entire team
• Product Owner approves/rejects work
• Re-plan work that was rejected

Sprint Retrospective
• What went right
o Call out key successes
o Where did recent changes make improvements

• What went wrong
o Where can we make improvements
o Only make 1 improvement at a time
• Let it rest before making additional changes

• Never stop improving
o Find the next 1% change

Development Sprint
• Team Goal based around structure
o Component based: Animation, SE, Scripters
o Feature based: Feature X, Feature Y

• Sprint backlog
o Populated from Product backlog
o Includes relative estimation
o Team commits to work and sets goals

• User Stories
o Broken into tasks w/ work remaining hours

• Team work
o Team picks up slack to reach sprint goals

Hardening Sprint
• Hardening/Polish Sprint
o Generally Shorter than normal Sprints (1-2 Weeks)
o Polish/tweak functionality implemented in prior sprints
o Sustained Testing of features (1-2 days)
o Improve Frame rate (Sim/Render)
o Memory fixes

• This is Polish not Finish…!

Spike Sprint
• Spike Sprint
o Generally Shorter than normal Sprints (days to a week)
o Explore risky or unknown feature/technology
o Expected outcome is a breakdown of the user stories & risk profile

Abnormal Termination
• If change cannot be kept out of a sprint...
o The sprint may be abnormally terminated

• An extreme circumstance
• Generally terminated by Product Owner

Sprint Burndown
• A visual representation of work complete
• A projection of the work remaining (Hours)
• Trend line indicating likely finish

What about QA
• Partners NOT Adversaries
• Two types of QA testing
o Embedded
• Focused on what is being delivered
• Where direct team interaction on is an advantage
o Centralized
• Bulk or heavy testing
• Edge case testing

• Setting expectations early
o How are we going to test?
o What is ―Done‖
• Then Stick to them!

Embedded Testing
• Verify TFCs/ Acceptance Tests
• Focused on finding Bugs in sprint/release
deliverables
• Special knowledge required
• Prioritized and Weight
• Max carryover length
• ―Clean‖ over more
o Focus on ―Done‖

External “Bulk” Testing
• ―Escaped bugs‖
• Typically found by external testing
• Should be prioritized
o Based on User Impact

• Work with Embedded QA
• Edge Case testing

Bugs Per Hour
• Don‘t let numbers build
• The snowball effect
o 1 Bug early in development generally results in 2.7 bugs later

• Should I fix a bug now
o Bug fixed in sprint can save up to 60% of fix time.

• EA Sports fix rate: .39-.42 (b.p.h.)
o Gold Product: 500 – 1500 Cycle
o AAA Sports: 18,000 – 23,000 Cycle
o AAA Game: 25,000 – 80,000 Cycle

The “Roles”
• Product Owner
• Scrummaster
• Team
• Customers
• QA

Which are U?
Pigs Chickens
• Product Owners • Studio Leadership
• ScrumMasters • PMO
• Scrum teams • Marketing/PR
• QA • HR/RMO
• Facilities

Product Owner
• Maintains the product backlog
• Continuous prioritization and grooming
• Conveys a shared vision
• Represents the customers and shareholders
• Participates in all Scrum meetings
• Accepts or rejects sprint results
• Guides releases, not sprints
• Accepts or rejects sprint results
• Communicates status externally
• Terminates a sprint if needed

ScrumMaster
• Remove impediments
• Protects the team
• Ensures all Scrum artifacts exist
• Facilitates Scrum meetings
• Support and guide the PO role
• Coaches & guides the team on agile/Scrum
principles

The Team
• Plans the sprint
• Commits to the sprint goals
• Members should be full-time
o Limit people to two teams (if possible)
o Require being on one team at least 60%

• Teams are self organizing
• Includes everyone needed to go from idea to
implementation
• Egos are put aside

Team Size
• Typically 7 people (+- 2)
o Two pizza team

• Military approach
o Fire Team
o Squad

Team Area
• Open seating
• Seating Spaces 7-10 people
• Low or no walls
• Big whiteboard
• Table for discussions

Mixing Roles
• Can the Product Owner and ScrumMaster also be
developers on the team?
o This is a challenge for even the most experienced of Agile users
o Can lead to poor decisions on either side of the roles

• CCP (Eve Online)
o Shared Scrummaster/Product Owner Roles
o When you are speaking to Scrummaster he/she will wear a Viking.

Scalability
• Scalability comes from teams of teams
o Factors in scaling
• Logical division of work
• Team size
• Team location

Team 1 Team 3

Team 2

Cross functional Teams
• Scrum teams should include all skill sets to deliver
the Sprint goals
• Example
o If you are developing a web presentation layer for the Sprint your team
should include:
• Web Artist, UI Artist, Scripter, General SE, QA & Designer
o This is not always possible but this will give your team the best
chance for success

Scrum of Scrums
• Attendees
o Each team sends an individual contributor

• Agenda
o Everyone answers four questions
o Attendees discuss the product backlog for the scrum of scrums

• Frequency
o Weekly

• Not time-boxed
o Take the time to get ―it‖ done

The Questions?
• What has each team done since we last meeting?
• What will each team do before the next meeting?
• What‘s in each team‘s way?
• What are you about to put in another team‘s way?

**Nobody gets burned**

“The Chief” Product Owner
• Visionaries for global/local products All members of
their teams
• Chief PO works with feature/functional product
owners to establish vision and priorities for their
teams Chief PO

Feature POs

Risks
• ScrumFall
o Mixing of various processes into one

• Selective use of key principles
o Must use certain tools from toolbox
o Others are elective

• Zealots…
o No methodology is perfect
o Agile will not solve all your problems

Training
• CSPO
o Designers, Producers, Art Leads, QA Leads

• CSM
o Development Directors, Technical leads, Producers, QA Leads

• Agile Estimating & Planning
o Content providers

• Kanban/Lean
o Art, IS/IT

• Waterfall
o Art

Contact Information
Director – Portfolio Management Office

wmcgehee@ea.com

Agile Myths
• We don‘t have long term plans
o All methodologies can fall victim to this problem
• We spend all day in meetings
o Sprint Planning, Daily Standup, Sprint review, Sprint retrospective
o Backlog Estimation, Release Planning
• Agile doesn't allow documentation
o Documentation should be to the level needed de-risk the estimates
• Agile doesn't need up front design
o Detailed designs should be balanced with likelihood they will be
implemented.
• Agile is a silver bullet solution to software
engineering problems
o There is no Silver bullet development methodology.

Architecture vs. Features
Percent of Effort 100
80
60
40
20
0
1 2 3 4 5 6 7 8 9

Sprints

User- Valued
Architecture
functionality

•
Items to Add
How do we become more agile and do this properly
• "Iterative and incremental death marches, agile teams that do not plan", Clinton Keith
• "Scrum is like the mother in law that lives with you, it tells you everything that is wrong with you.. That is it; it doesn‘t fix anything but it makes everything transparent"…. Ken Swabber
• "Product Owner is the most difficult role in Game Development" , Clinton Keith
• Winston Royce, waterfall
• Talk about culture of an organization
• Harvard Business review article
• GE 1930s workforce study to see impact of productivity through change.
• Product backlog iceberg
• User story: As a (user role) > I want (goal) > So that (reason)
• Waterfall schedule tend to have lower value up front and show more valve on a curve in alpha as everything is fixed and resolved.
• Games about ownership or teamwork (easy to play)
• 7 dysfunctions of a product owner
• Sharing roles (CCP has a Viking hat to tell you when you are listening to a specific role).
• Ralph Stacey, Stacey Diagram, Strategic management and organizational dynamics
• Buy a feature training, monopoly money
• Innovation games, luke
• Weisbaert.com/badscrummaster
• Discuss PM triangle - Think NASA going to the moon
• Switching teams context switch, count 1-26 and standup, count 1-26 but at a letter 1A, 2B
• Steiner 1972 Team Size Productivity
• Dubar numbers for team size
• Myths of a Scrummaster/Product Owner (sort with your team in 3 min)
• Human response story, monkey and banana tree story
• The new new product development game
• Sometimes component teams are required
• Sprint type, normal, hardening, component (Sprint 0, design Sprint not great idea but can do)
• Define Done for Sprint
• Slide on Daily Scrum
• Daily Standup meeting (KobioshiMaru) example (role play)
• Agile Coaching (book)
• Talking stick
• Silent count to 10 after asking a question
• Who attends Sprint/Release Reviews
• Danger of tools but reason you need them..
• Sprint Backlog
• Product backlog
• Sprint Goals
• Task Boards (show various types)
• Burndown slope vs drag example burndown
• Abnormal terminations
• Use battlefield to explain user stories, sniper rifle with flash suppressor (doesn‘t matter to a medic)
• Scale and scaling up small to extremely large teams (over 1000)
• Scrum of scrums
• Scrum of Scrums - 4 Questions, What has your team done since we last met, What will your team do before we meet again, what is in your teams way, what is your team about to put in another teams way
• Organizational - Backlog vs. teams (core services)
• As the point size increases as does the variance or accuracy of the estimation

“Today's problems come from
yesterday's "solutions”.”

Peter Singe
The Fifth Discipline

―It doesn't work to leap a twenty-foot chasm in two
ten-foot jumps.‖
• An American Proverb

Key “Lean” Principles
Lean principles Lean principles short
o Eliminate waste » Respect for people (team
o Amplify learning empowerment)
o Decide as late as » Continuous improvement
possible
o Deliver as fast as
possible
o Empower the team
o Build integrity in
o See the whole

Refining the backlog
Sprint
Level

Release
Level

Time/Priority

Agile Coaches & Trainers
• Certified Coaches – (CSM, CSPO)
o Mike Cohn
o Clinton Keith

• Agile/Hansoft Trainers
o Bill McGehee (CSP, CSM, CSPO)
o Brian Graham (CSM)
o Jorge Hernandez (CSM)

The 11 Laws of the Fifth
Discipline
• Today's problems come from yesterday's "solutions."
• The harder you push, the harder the system pushes back.
• Behavior will grow better before it grows worse.
• The easy way out usually leads back in.
• The cure can be worse than the disease.
• Faster is slower.
• Cause and effect are not closely related in time and space.
• Small changes can produce big results...but the areas of
highest leverage are often the least obvious.
• You can have your cake and eat it too ---but not all at once.
• Dividing an elephant in half does not produce two small
elephants.
• There is no blame.
Peter Singe
The Fifth Discipline

Filling your Sprint

Corporate
Overhead
Unplanned
Time

Plannable
Time

Missing details Details
• As a player I want to see enemies have hit reactions
when I melee them.
o Are the reactions physical or animated?
o How do we do collision detection?
o Is there a distance check with the enemy?

Team Size and Productivity

Steiner (1972)

Training Plan
Add radial char to show key training areas
1. Sprints
1. Sprint types
2. Sprint Backlog
3. Priority
4. Work Breakdown
5. Velocity
1. Work remaining
2. Release
1. Planning
2. Velocity
3. Product Backlog
1. Keys
1. Relative Estimation
2. Prioritized
1. Multiple levels
2. Team
3. Corporate

Agile 101

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile 101

Similaire à Agile 101 (20)

Dernier

Dernier (20)

Agile 101

Notes de l'éditeur