Agile 101

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 Sportso Madden, Tiger Woods, EA GameShow, EA|ON

• X360, PS3, PC, Facebook & Web

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

WildMcG

Methodologies

WaterfallConcept

Release

Testing

Production

Pre-Production

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

iterationso Each iteration is like a short project in itselfo Uses “inspect and adapt” practices to adjust the project plano 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

(Re)Write a test

Clean up code

Write production

Code

Check if the test

fails

Repeat

Re-factor

If pass

Pair Programming

Kanban/Lean

In ProgressNot Started Implemented In Testing Done

The “Scrum” Process

Sprint Review

ProductBacklog

SprintBacklog

Potentially Shippable Increment

1 - 4 Weeks

24 Hour

s

Waterfall Trip

Fuel

Food

Rest Stop

How is Scrum different

Fuel

Food

Rest Stop

What is Scrum

“Agile” ManifestoBetter 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 negotiationResponding 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.

• 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

Inspect and Adapt

Product Backlog

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” backlogo Viewable by entire team

• All User Stories should have a RELATIVE estimationo (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 releaseo 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>.”

Sample Stories

As a player I want to

see the enemy appear

closer when I use my

sniper scope so I am

able to see them from

long distances

As an Origin user I want to want to know which of my friends is online

As a content creator, I

want the asset

validation pipeline to

automatically catch

memory errors so that

there are fewer failed

assets in the build

Sprint Backlog

As a player I want to

see the enemy appear

closer when I use my

sniper scope so I am

able to see them from

long distances

Developers break story into smaller deliverables

Enable Right

Click to Zoom

(4)

Change zoom

position of object

when scope

(xZoom) is

selected (8)

Refining the backlog

Priority/Time

Sprint

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 efforto 1 Point item is ½ the effort of a 2 point item

• Story Points or ideal Dayso T-Shirt Sizes

• Team estimates each itemo Product Owner explains user storyo Using planning poker cards everyone picks a card

• Then discusses of there are differences in numberso Repeat until card draw until everyone agrees

• Estimation should NOT be based on timeo #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

Points 1 2 3 5 8 13 20 400

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

Release Plan• Theme or Narrative

o What is our high level goal

• Capacity based on empirical velocity from prior releaseso Based on team by team velocity

• Includes user stories with key data• Plan multiple releases

Releases

Release Planning• Multiple Development Sprints• 1 Hardening Sprint

o Integrations/Polish/Bugs

• Hardening Sprint length not tied to development Sprint length

Sprint

Release 1

Sprint

Hardening

Sprint

Sprint

Hardening

Release 2

Release Planning

Sprint

Release

Sprint

Sprint

Sprint

Sprint

• Multiple Development Sprints

• Hardening Sprint in Middle & End

Hardening

Sprint

Sprint

Sprint

Hardening

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

Sprints

Start/End Together• Don’t stagger sprint starts

• Sync Sprint Start/End Dates

Team 1 Team 1

Team 2 Team 2

Team 3 Team 3

Team 1 Team 1

Team 2 Team 2

Team 3 Team 3

Sprint Length• Most common Sprint length

o 2 – 3 Weekso 1 – Week for Social or Live teamso 4+ – Weeks is generally not suggested

• What Sprint length is best?o How long can your team go without shifting directionso Risk of what is being deliveredo 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

• Teamo Reviews sprint backlogo Commits to level of work it feels it can completeo Work is broken into “work remaining”

• Based on hours

Daily Standup• No more than 15 minutes• Attendees

o Product Owner, Scrummaster & Team

• 3 Questionso What did I complete yesterdayo What and I going to complete todayo 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 successeso Where did recent changes make improvements

• What went wrongo Where can we make improvementso Only make 1 improvement at a time

• Let it rest before making additional changes

• Never stop improvingo Find the next 1% change

Development Sprint• Team Goal based around structure

o Component based: Animation, SE, Scripterso Feature based: Feature X, Feature Y

• Sprint backlogo Populated from Product backlogo Includes relative estimationo Team commits to work and sets goals

• User Storieso Broken into tasks w/ work remaining hours

• Team worko 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 sprintso 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/technologyo 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

Quality Assurance

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 earlyo 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 nowo 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 Cycleo AAA Sports: 18,000 – 23,000 Cycleo AAA Game: 25,000 – 80,000 Cycle

Roles

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

Scrum Joke

Which are U?Pigs Chickens

• Product Owners• ScrumMasters• Scrum teams

• QA

• Studio Leadership• PMO

• Marketing/PR• 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 approacho Fire Teamo 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 userso Can lead to poor decisions on either side of the roles

• CCP (Eve Online)o Shared Scrummaster/Product Owner Roleso 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 2

Team 3

Cross functional Teams

• Scrum teams should include all skill sets to deliver the Sprint goals

• Exampleo 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

Additional Meetings

Scrum of Scrums• Attendees

o Each team sends an individual contributor

• Agendao Everyone answers four questionso Attendees discuss the product backlog for the scrum of scrums

• Frequencyo Weekly

• Not time-boxedo 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

Feature POs

Chief PO

Risks• ScrumFall

o Mixing of various processes into one

• Selective use of key principleso Must use certain tools from toolboxo Others are elective

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

Training

Training• CSPO

o Designers, Producers, Art Leads, QA Leads

• CSMo Development Directors, Technical leads, Producers, QA Leads

• Agile Estimating & Planningo Content providers

• Kanban/Leano Art, IS/IT

• Waterfallo Art

Recommended Reading

Contact Information

[email protected]

Director – Portfolio Management Office

Parking

Reasons for Change

Agile Myths• We don’t have long term plans

o All methodologies can fall victim to this problem

• We spend all day in meetingso Sprint Planning, Daily Standup, Sprint review, Sprint retrospectiveo Backlog Estimation, Release Planning

• Agile doesn't allow documentationo Documentation should be to the level needed de-risk the estimates

• Agile doesn't need up front designo Detailed designs should be balanced with likelihood they will be

implemented.

• Agile is a silver bullet solution to software engineering problemso There is no Silver bullet development methodology.

Architecture vs. Features

100

40

20

80

60

0

1 2 3 4 5 6 7 8 9

Per

cent

of

Effo

rt

Sprints

ArchitectureUser- Valuedfunctionality

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 SingeThe Fifth Discipline

“It doesn't work to leap a twenty-foot chasm in two ten-foot jumps.”

• An American Proverb

Key “Lean” PrinciplesLean principleso Eliminate wasteo Amplify learningo Decide as late as

possibleo Deliver as fast as

possibleo Empower the teamo Build integrity ino See the whole

Lean principles short» Respect for people

(team empowerment)» Continuous

improvement

Refining the backlog

Time/Priority

Sprint Level

Release

Level

Agile Coaches & Trainers

• Certified Coaches – (CSM, CSPO)o Mike Cohno Clinton Keith

• Agile/Hansoft Trainerso 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

Unplanned Time

Plannable Time

Corporate Overhead

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 PlanAdd radial char to show key training areas

1. Sprints1. Sprint types2. Sprint Backlog3. Priority4. Work Breakdown5. Velocity

1. Work remaining 2. Release

1. Planning2. Velocity

3. Product Backlog1. Keys

1. Relative Estimation2. Prioritized

1. Multiple levels2. Team3. Corporate