Your SlideShare is downloading. ×

Agile 101

521

Published on

Sadly with Slide Share the Automation for the sldies does now work.

Sadly with Slide Share the Automation for the sldies does now work.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
521
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Pigs committed to the work, signing up to complete the work they said they could get done in the sprint.Chickens, sideline viewers those who cannot directly deleiver the Sprint (can block work from being deleivered)
  • Military:Fire team: 4 People each have specific skills but can support each otherSquad: 8 people (2 fire teams)This is for to reduce communication issues
  • Transcript

    • 1. Agile “101”
    • 2. 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
    • 3. WildMcG
    • 4. Methodologies
    • 5. WaterfallConcept Pre- Production Production Testing Release
    • 6. 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.
    • 7. 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
    • 8. Test Driven Development Repeat (Re)Write a test Re-factor Write production Code Check if the test fails Clean up code If pass
    • 9. Pair Programming
    • 10. Kanban/LeanNot Started In Progress Implemented In Testing Done
    • 11. The “Scrum” Process 24 Hours 1 - 4 Weeks PotentiallyProductBacklog Shippable Sprint Increment Backlog Sprint Review
    • 12. Waterfall TripFuelFoodRest Stop
    • 13. How is Scrum differentFuelFoodRest Stop
    • 14. What is Scrum
    • 15. “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 toolsWorking 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.
    • 16. 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
    • 17. Inspect and Adapt
    • 18. Product Backlog
    • 19. 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)
    • 20. 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.
    • 21. 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.
    • 22. 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.
    • 23. 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>.”
    • 24. Sample Stories
    • 25. Sprint Backlog Developers break story into smaller deliverables
    • 26. Refining the backlog Sprint Priority/Time ReleaseLong Term
    • 27. 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.
    • 28. 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
    • 29. 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
    • 30. 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
    • 31. Releases
    • 32. 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
    • 33. Release Planning• Multiple Development Sprints Release Hardening Hardening Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint• Hardening Sprint in Middle & End
    • 34. 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
    • 35. Sprints
    • 36. 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
    • 37. 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)
    • 38. 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
    • 39. 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
    • 40. Sprint Review• Review work delivered with entire team• Product Owner approves/rejects work• Re-plan work that was rejected
    • 41. 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
    • 42. 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
    • 43. 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…!
    • 44. 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
    • 45. 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
    • 46. Sprint Burndown• A visual representation of work complete• A projection of the work remaining (Hours)• Trend line indicating likely finish
    • 47. Quality Assurance
    • 48. 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!
    • 49. 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‖
    • 50. 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
    • 51. 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
    • 52. Roles
    • 53. The “Roles”• Product Owner• Scrummaster• Team• Customers• QA
    • 54. Scrum Joke
    • 55. Which are U? Pigs Chickens• Product Owners • Studio Leadership • ScrumMasters • PMO • Scrum teams • Marketing/PR • QA • HR/RMO • Facilities
    • 56. 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
    • 57. 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
    • 58. 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
    • 59. Team Size• Typically 7 people (+- 2) o Two pizza team• Military approach o Fire Team o Squad
    • 60. Team Area• Open seating• Seating Spaces 7-10 people• Low or no walls• Big whiteboard• Table for discussions
    • 61. 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.
    • 62. 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
    • 63. 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
    • 64. Additional Meetings
    • 65. 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
    • 66. 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**
    • 67. “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
    • 68. 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
    • 69. Training
    • 70. 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
    • 71. Recommended Reading
    • 72. Contact Information Director – Portfolio Management Office wmcgehee@ea.com
    • 73. Parking
    • 74. Reasons for Change
    • 75. 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 doesnt allow documentation o Documentation should be to the level needed de-risk the estimates• Agile doesnt 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.
    • 76. 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
    • 77. • 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
    • 78. “Todays problems come fromyesterdays "solutions”.” Peter Singe The Fifth Discipline
    • 79. ―It doesnt work to leap a twenty-foot chasm in twoten-foot jumps.‖ • An American Proverb
    • 80. Key “Lean” PrinciplesLean principles Lean principles shorto Eliminate waste » Respect for people (teamo Amplify learning empowerment)o Decide as late as » Continuous improvement possibleo Deliver as fast as possibleo Empower the teamo Build integrity ino See the whole
    • 81. Refining the backlog Sprint Level Release Level Time/Priority
    • 82. 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)
    • 83. The 11 Laws of the Fifth Discipline• Todays problems come from yesterdays "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
    • 84. Filling your Sprint Corporate Overhead Unplanned Time Plannable Time
    • 85. 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?
    • 86. Team Size and Productivity Steiner (1972)
    • 87. Training PlanAdd radial char to show key training areas1. Sprints 1. Sprint types 2. Sprint Backlog 3. Priority 4. Work Breakdown 5. Velocity 1. Work remaining2. Release 1. Planning 2. Velocity3. Product Backlog 1. Keys 1. Relative Estimation 2. Prioritized 1. Multiple levels 2. Team 3. Corporate

    ×