Introduction to Scrum Eamonn J Casey Enterprise Architect

Introduction to Scrum Eamonn J. Casey Enterprise Architect

Agenda • Session 1: – Background to Scrum (30 min) – Introduction to the Scrum Process (90 min) • Session 2: – An example of Scrum in action (30 min) Reference material thanks to:

Session 1: Background & Process

Why Scrum? • • 31 % of projects will be cancelled 53 % of projects will cost 190 % of estimates 16 % for are completed on time and on budget 42 % completed with originally functionality • Reasons why projects fail: – Lack of User Input (13 %) – Incomplete Requirements & Specifications (12 %) – Changing Requirements & Specifications (12 %) – Technology Incompetence (7 %) Standish Group International

Why Scrum? • Lack of User Inputs – The ‘user’ is a central member of the Team • Incomplete Requirements & Specifications – Evolution throughout the life of the project – Focuses on what can be completed • Changing Requirements & Specifications – Embraces change, recognizes change is normal and not the exception Using Scrum or any other agile method is more likely to: deliver higher quality; quicker; right functionality, greater value Agile Adoption Rate Survey (2006 – 2009) Scott Ambler

Origins of Scrum “ … ‘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. ” • • Jeff Sutherland • Ken Schwaber • Mike Beedle • • Hirotaka Takeuchi and Ikujiro Nonaka, “The New Product Development Game” Ken Schwaber and Mike Cohn – Initial scrums at Easel Corp in 1993 – Presented at OOPSLA 96 with Sutherland – Scrum patterns in PLOPD 4 – Co-founded Scrum Alliance in 2002 Scrum is part of the family of methodologies called Agile

Agile Software Development Manifesto Prefers: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Characteristics of an Agile Method • Incremental development – Small release with rapid cycles (2 – 4 weeks) – Focus on highest value in shortest time (priority items first) • Cooperative – Customers and team work closely together – Team self-organises to best deliver on goals • Straightforward – The process is relatively easy to learn and execute • Adaptive – Process, project and content can respond to change quickly

Scrum has been used for: • • • Commercial software In-house development Contract development Fixed-price projects Financial applications ISO 9001 -certified applications • Embedded systems • 24 x 7 systems with 99. 999% uptime requirements • the Joint Strike Fighter • Video game development • FDA-approved, life-critical systems • Satellite-control software • Websites • Handheld software • Mobile phones • Network switching applications • ISV applications • Some of the largest applications in use

The Chicken and Pig Story • Committed: Responsible for success, Authority to make it happen. • Involved: Interested in the result. No consequences for them on failure.

The Scrum Process • Introduction to the process, terminology etc. • We can adjust the process to fit the project

The Scrum Process: Overview

Scrum – 3 Main Phases • Pre-game phase – Planning. The initial set of requirements are generated – High level design. A design is generated using the known requirements • Development phase – System is developed in small increments – Each increment has a goal statement – Time, quality, resources etc are constantly monitored and controlled – Entire project plan is reviewed and reorganised • Post-game phase – Closing down of the project – Phase starts when there is an agreement that the product is complete

Scrum Framework 3 Roles Product Owner Scrum. Master Team Features, schedule and Return on Investment (ROI) Ensure that the team is fully functional and productive (5 -9) project leader, documentation writers, programmers, QA, expert users, designers, architects, etc. 3 Meetings Release & Sprint Planning Sprint Review Daily SCRUM ½ - 1 day planning and estimation of the next sprint. Complete review of the entire Product Backlog. 30 minutes. Typically a demo at end of Sprint. 15 minute stand-up. 3 questions. Yesterday? Today? Problems? 2 Documents Product Backlog Sprint Backlog Business requirements. Prioritised. Reviewed. Tasks, estimates, assignments.

Role: Product Owner • • • Define the features of the product Prioritize features according to value Managing the requirements Participating in the estimation process Decide on release date and content Be responsible for the profitability of the product (ROI) Adjust features and priority every iteration, as needed Accept or reject work results Can change features and priorities at the beginning of every iteration

Role: Scrum Master • • Enables the Team Keep the team working as productively as possible Ensure that the team is fully functional Responsible for Scrum values and practices Removes impediments Enable close cooperation across all roles and functions Shield the team from external interferences Typically no responsibility for the success of the project NOT the Project Manager

Role: The Team • Typically 5 – 9 people • Cross-functional: – Managers, technical, domain expert, etc. • Teams are self-organising – Every member has different skills that can be used to solve the problem – Every member has the intelligence, motivation and focus to apply their skills – Constant communication within the Team adjust how they work • Membership should not change during an iteration • Members should be full-time • Members have the authority and the responsibility

Role: Stakeholders • Are interested in the outcome of the project – But no real responsibility for doing any work • Communicate through the Product Owner to get items onto the Backlog • In Scrum they are ‘everyone that is not on the team’ – Some are risks: Not on the project, but like to have a direct input – Some are friendly: Contribute in a positive way to the success – Some are required: Not on the Team but a relationship exists • Stakeholders contribute to the project through the Product Owner and Sprint Planning activities – They can be safely ignore until the next Sprint

Dealing with outside influences • Lots of small distractions lead to big delays. • Making hidden tasks visible is a good thing. • Focusing on the right things and nothing else is a good thing.

Meeting: Sprint Planning Team capacity Product backlog Business conditions Sprint planning meeting Sprint prioritization • • Technology Sprint goal Sprint planning • Current product Analyze and evaluate product backlog Select sprint goal • • Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint backlog

Meeting: Sprint Planning • Team selects items from the product backlog they can commit to completing • Sprint backlog is created – Tasks are identified and each is estimated (1 -16 hours) – Collaboratively, not done alone by the Scrum. Master • High-level design is considered As a vacation planner, I want to see photos of the hotels. 12. 05. 09 Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)

Meeting: Sprint Review • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal – 2 -hour prep time rule – No slides • Whole team participates • Invite the world

Meeting: Daily Scrum • Parameters – Daily, 15 -minutes, Stand-up • Everyone answers 3 questions – What did you do yesterday? – What will you do today? – Is anything in your way? • Meeting every day allows the Team to adjust what they are doing and how it is done – Unnecessary work may be removed because of someone else – Problems for one may be solved by the skills of others • Discussions are taken after the Scrum • This for the Team and NOT status for the Scrum. Master

Meeting: Daily Scrum Q. How does a project get to be a year late? – A. “One day at a time” – Fred Brooks, The Mythical Man Month Q. Can Scrum meetings be replaced by emailed status reports? – A. No Entire teams sees the complete picture every day Q. Are Daily Scrums the same as project status meetings? – A. No For the team to allow them to work better together

Meeting: Sprint Retrospective • Periodically take a look at the Scrum process – What is and is not working • Adjust the Scrum process to make it work better for the team • Typically 15– 30 minutes • Usually done after every sprint – Possibly as an agenda item in Sprint Planning • Whole team participates – Scrum. Master – Product owner – Team – Possibly customers and others

Documents: Product Backlog This is the product backlog • The requirements • A list of all desired work on the project • Ideally expressed such that each item has value to the users or customers of the product • Prioritized by the product owner • Reprioritized at the start of each sprint • Contains size estimates

Document: Sprint Backlog • A detailed list of tasks that must be completed during the iteration • Individuals sign up for work of their own choosing • Sprint Backlog is updated on a daily basis: – Estimated work remaining is updated daily – Team can add, delete or change items – Unclear items get more clear as the Sprint progresses – Update work remaining as more information becomes available • (Un)finished work helps the Team understand: – The complexity of the project – The time it takes to complete a task – Project status – Number of tasks completed v. remaining tasks

Reports: Burndown Charts • • Two charts generated automatically Visual tool to increase visibility for the project A successful project will show charts approaching zero Project Burndown Chart – Generated from the Product Backlog – Shows requirements: new, changed, estimates, completed per Sprint – Projected project completion date • Sprint Burndown Chart – Updated daily from the Sprint Backlog – Shows tasks: new, changed, estimates & actual, status – Status of Sprint in relation to time remaining

Reports: Example – Project Status Initial requirements New requirements Work being completed Worst Case Most likely Best case Current position

Session 2: Scrum in action

Scrum. Master Disclaimer • This is just an example of how Scrum can be modified • Shows Scrum in action • Team together with the Scrum. Master decide process • Situation: – The project is very complex with many stakeholders – The requirements are not completely known – The budget and time is unlimited, but a product must be produced shortly – The Product Owner represents many groups and is not a domain expert – Everyone is new to Scrum, so the process must be adapted

Sample Scrum Process

Pre-game phase • Team has configured Scrum: – Sprint of 10 days (2 weeks) – Adjusted the Scrum process to fit the way they work – Where to meet for the Daily Scrum – Seating arrangements, whiteboards and other practical things • Scrum. Master has: – Planned the first Sprint Planning meeting (booked a room) – Briefed everyone on how Scrum works • Product Owner has: – Prepared the Product Backlog (description, priority, QA, etc. ) • Release Planning meetings fill the initial Product Backlog

Sprint Day 1 – Sprint Planning Session Who Tools Agenda Demonstration PO Team SM Sprint Backlog Product What has been achieved in the last Sprint What has not been achieved How to deal with unclosed tasks PO Team SM Product Backlog Present Product Backlog (PO) Define Sprint Goals (Team & PO) 1 hr Sprint Goals 2 – 3 hr Define tasks to Team meet goals SM Sprint Backlog Break down tasks into smaller tasks (hours instead of days) Prioritise & estimate ‘Sign-up’ for tasks Experience Discuss any improvements to be made to the Scrum process 2 – 3 hr Retrospective 30 minutes Team SM

Sprint Day 2 – 6 • Daily Scrum – Daily, stand-up meeting attended by the Team & Scrum. Master – Chickens are invited, but they’re not allowed to say anything! – Answer 3 questions – Any conversations should be taken after the Scrum • What is the Product Owner doing? – Preparing for the next requirements workshop and Sprint Planning meetings. – Changing priorities of items no in the current Sprint – Adding more detail to what should be in the next Sprint – Responding to input from stakeholders

Sprint Day 7 – Release Planning 1 • Attended by: Product Owner, Scrum. Master, Team • Duration: 2 – 3 hours • Goal: Enable the Product Owner to make informed decisions about the Product Backlog • Agenda: – Present any new / changed requirements – Discuss any concerns / questions for the next Sprint – Assign initial estimates or change existing estimates • After: – PO can change the Backlog in response to the feedback – PO generates a prioritised Backlog for next Sprint

Sprint Day 8 – Release Planning 2 • • Attended by: Product Owner, Scrum. Master, Team Duration: 2 – 3 hours Goal: Better understanding for the next Sprint Before: – PO has created a prioritised Product Backlog (typically 130 % of the capacity of the Team) • Agenda: – Present the part of the Product Backlog for the next Sprint – Answers any questions raised in Release Planning 1 – Team estimates the effort and high/low estimates are discussed • After: – Team has a Product Backlog they can use in Sprint Planning – Any open issues have time to be answered before the next Sprint

Sprint Day 9 – 10 • Daily Scrum • What is the Team doing? – Investigating any open issues after the planning session • What is the Scrum. Master doing? – Preparing for next Sprint Planning session – Advice on how to improve the process • What is the Product Owner doing? – Preparing for the next Sprint Planning session

And then we do it again and again…

Until we are done… • Enough of the Product is completed that the Product Owner(s) are happy – This can be signalled at any time or in one of the planning meetings • The ‘cost’ of continuing is higher than the ‘value’ that would be achieved – Signalled by the Product Owner • Time / resources run out – Because each Sprint is ‘complete’ and only the high value / top priority were target, the Product is complete

Sample Scrum Process • Before the project started: – Initial project plan & design – just enough to get us going – Initial Scrum setup • How did we change the Sprint layout? – Sprint planning on Day 1 as in ‘regular’ Scrum – 2 Release Planning meetings on Day 7 & 8 • • Gave the Product Owner a chance to clarify requirements Gave the Team a change to understand the next set of requirements Gave the project a chance to QA with others Helped the Sprint Planning be based on facts and run smoothly • Product Owner stopped the project when ‘enough’ was done – One final Sprint to QA things before final release

So thanks to: Ensuring the Team did only the right things Being available if the team needed answers Stopping the project when enough was completed Guidance and advice to ensure the team kept focus Suggesting method / tools to improve process Taking the initiative and making things happen Big round of applause to you guys!!! Talking with the Product Owner to improve the product Leaving the Team along to get on with it

Final Words • A Scrum Team typically misses their first deadline – Underestimating the complexity of the tasks – Overestimating their ability to deliver – Getting used to working together within the Scrum process • Software development has an 80 / 20 rule – 20 % of the software is used 80 % of the time • Scrum is all about focusing on the high priority, high value items – Low priority, low value items probably don’t need as much attention • People are the key to the success of a project • The Scrum. Master is here to facilitate your work

Further Reading Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn www. mountaingoatsoftware. com/scrum www. scrumalliance. org www. controlchaos. com

Q&A