Introduction To Scrum
Upcoming SlideShare
Loading in...5
×
 

Introduction To Scrum

on

  • 2,445 views

Introduction to Scrum presentation which outlines common issues in software development, what is Scrum, and an introduction to the Scrum framework. This presentation has been used for training and ...

Introduction to Scrum presentation which outlines common issues in software development, what is Scrum, and an introduction to the Scrum framework. This presentation has been used for training and presentations to both technology and business audiences.

Statistics

Views

Total Views
2,445
Views on SlideShare
2,429
Embed Views
16

Actions

Likes
6
Downloads
105
Comments
0

3 Embeds 16

http://www.slideshare.net 7
http://www.linkedin.com 7
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • A list of “typical” problems. Some of these relate to us, some don’t. I’m sure some of these are recognizable
  • Here are some issues from the perspective of our customers.There are always delays, even if we are forced to sign in blood that scope wont change.“If development estimates are padded (some as much as 50-100%) why are projects often late?As software ages, we consistently see the same issues spring up over and over. Quality is perceived as being weak when this happens.I never know what to tell my team…when is this supposed to get done? You promised last week!?When changes are made (even simple ones), we are forced through a bureaucratic change process that always affects our deliveriesSince I don’t trust dates, timeframes, quality, I am going to ask for the WORLD, and hopefully I get “something” at the end!
  • I am never able to work on one thing at a time. I’m always asked to do something else half way through. (drive by)We don’t have time to do it right, lets just get it DONE. And if you find you’ve made a bad choice, just live with it. Similar to #1. Multitasking or time slicingAll the bad decisions force developers to make adjustments in order to “make the date”. The only variable that they truly have total control over is QUALITY. No more unit tests, no more peer reviews, no more discussion of any sort. We are now in superman mode! Just get it done! Customers don’t see unit tests!Since management doesn’t trust my estimates are anyway, tell them whatever they want to hear. We will just tell them later it will take longer, or maybe we can just store everything in a blob and forget the RDB or something. Or, we will just work 70 hours a week if we get in trouble!
  • We consistently see developers stretched in multiple directions throughout the life of a project. This typically causes massive loss of productivity. Developers need to focus on creative work and not have to switch from one side of their brains to the other throughout the day.
  • Managers love the defined approach because it gives the illusion that, if its on paper (or MS Project) and all the numbers tie out, the plan can be followed. “Buffer your estimates, give yourself some wiggle room, and just get it done!” is the war cry of most mangers.When it comes to designing and building a new software product, the work is part art and part science. There are multiple inputs and opinions as to what is needed, how it should look, requirements, interpretations of requirements, deadlines, market forces, business hurdles, technology hurdles….The process is fluid and rarely, if ever, the same.Therefore, we NEED inspection…we NEED adaptation. Not blind adherence to a plan.We need to guide the process, NOT control it.

Introduction To Scrum Introduction To Scrum Presentation Transcript

  • Introduction to Scrum
  • Agenda Co Common Issues in So t a e Development o ssues Software e e op e t What is Scrum? The Scrum Framework 2
  • Introduction to Scrum COMMON ISSUES IN SOFTWARE DEVELOPMENT 3
  • Problems Many Companies Face Time to market Time-to-market for products is too long Project failure rate is unacceptably high Responding to change is difficult and costly p g g y Customer involvement is weak Software quality is poor Productivity is extremely low Employee morale, drive and accountability is low Widespread micromanagement is required Employee turnover rates are too high 4
  • Common Issues From a Business Standpoint 1. Our planning never yields precise results 2. Quality is poor and an increasing issue with our customers 3. Communication and visibility are lacking and I can’t set y g expectations with my team (the “users”) 4. I’m not able to make changes to scope easily without derailing the ti th entire project j t 5. I don’t trust that my needs will be met 5
  • Common Issues From a Development Standpoint 1. 1 Priorities and scope keep shifting based on the current emergency and focus is totally lost 2. Unrealistic deadlines dictate poor architecture and design, as well as implementation choices 3. Production support issues pull developers away from new project work and timely enhancements to our product suite (too many balls in the air) 4. Poor historical decisions are being paid for now in the way we write code, rollout products, maintain systems, etc. 5. I don’t trust that my needs will be met 6
  • Working on the Wrong Priorities is a Waste Features and functions used in a typical system Sometimes Rarely 16% 19% Often or always used: 20% Never Often 45% 13% Always 7% Rarely R l or never used: 64% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman 7
  • The Multi-Tasking Myth Multi Tasking Even adding a single project to your workload is profoundly debilitating by Weinberg's calculation. You lose 20% of your time. By the time you add a third project to the mix, nearly half your time is wasted in task switching. Quality Software Management: Systems Thinking by Gerald Weinberg 8
  • Process Control Defined Process Control: Empirical Process Control: • Every task must be completely • The empirical model of and unambiguously understood process control provides and • Inputs are completely and exercises control through unambiguously defined frequent inspection and adaptation • When given a well-defined set of • for processes that are inputs, the same outputs are generated every time imperfectly defined • and generate unpredictable and unrepeatable outputs Illusion f Control: Development organizations t i ll d f lt t a “d fi d Ill i of C t l D l t i ti typically default to “defined process control” based on an outdated notion of how software is built. Has anyone heard the “building software is like building a house” metaphor? 9
  • What We Need A way for customers to see and evaluate progress before its too y p g late A process that gives stakeholders more visibility, early and often A process that’s more agile and responsive t changes th t’ il d i to h A process that allows development teams to “own” their commitments A process that accepts change but has enough rigor to yield a quality result A process that helps us be much more predictable We need more Trust! 10
  • Introduction to Scrum WHAT IS SCRUM? 11
  • Scrum is is… S pe a e o Simple framework Disciplined approach Commitment oriented Commitment-oriented Results-oriented Collaborative effort Empirical process “Scrum is not a methodology – it is a pathway” (Ken Schwaber) ) 12
  • What Is Scrum Being Used For? Large-scale enterprise software p j g p projects Consumer software products US FDA-approved software for X-Rays, MRIs High availability systems (99.9999% uptime) Financial payment applications Large database applications Embedded systems CMMi L Level 5 organizations l i ti Multi-location development Sustaining and Maintenance Projects Non-software projects 13
  • Scrum Shifts the Drivers Traditional Project Scrum The plan creates The vision creates cost / schedule feature estimates estimates Features Fixed Cost Schedule Value Driven Plan Driven Cost Schedule Estimated Features 14
  • Benefits of Scrum Sc u a o s tea s o peop e de e op co p e Scrum allows teams of people to develop complex products in environments of uncertainty and change. Scrum is a simple but powerful framework for teams and customers to i d t t inspect and adapt as th product i t d d t the d t is produced. Scrum provides a high degree of clarity and transparency to everyone involved – team, customer, management, and others. Scrum rapidly surfaces dysfunction, and enables teams and organizations to continuously improve their effectiveness. effectiveness 15
  • Typical Results with Scrum 3rd Annual Survey: 2008 “The State of Agile Development” 2319 Completed Surveys Conducted June-July 2008 By VersionOne 80 Countries Represented 16
  • Introduction to Scrum THE SCRUM FRAMEWORK 17
  • 3 Facets of Scrum Roles Artifacts Practices (Who) (Wh ) (What) (How) Product Owner Product Sprint Team Backlog Sprint Planning S Scrum Master Sprint Backlog Meeting Potentially Daily Standup Shippable Sprint Review Product Sprint Sprint Retrospective Burndown Chart 18
  • Overview of Scrum Framework Roles Artifacts & Practices 19
  • Role: Product Owner O st e so o Owns the vision of what s ou d be p oduced to ac e e at should produced achieve business success Manages ROI through prioritization and release plans Gets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the vision Turns input into a single list of what should be p produced, p , prioritized based on business value and risk Owns the Product Backlog “The Product Owner’s focus is ROI. The Product Owner directs the project, sprint by sprint, to provide the greatest sprint ROI and value to the organization.” 20
  • Role: Team O s t e p oduct o and engineering process Owns the production a d e g ee g p ocess Cross-functional - it has all the skills to produce the finished product Self-organizing and self-managing - it is responsible for making a commitment and managing itself to hit the goals (or get as close as it can) Authority to do whatever is necessary to meet it’s commitment The ideal team size in Scrum is 7 people +/- 2 “The Team is responsible for managing itself and has the full authority to do anything to meet the sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.” 21
  • Role: Scrum Master A new leadership role e eade s p o e It can be played by an existing person (such as a former Project Manager or team-member). Serves the team Helping remove any and all impediments that surface Protects the team Teaches and guides the team’s use of Scrum Facilitates – doesn’t “manage” (direct) the team “The Scrum Master is responsible for the success of the project, and helps increase the potential for success by helping the Product Owner select the most valuable backlog items and by helping the Team turn that backlog into functionality.” 22
  • Practice: Sprint The tea works for a fixed pe od of time. e team o s o ed period o t e Sprints are typically 1-4 weeks in length. Some recommend starting Scrum with 2-week Sprints. Sprints occur one after another, without any down-time between them. Working at a sustainable pace is very important to avoid team burn out burn-out. Team and Product Owner decide the Sprint length in advance. 23
  • Practice: Sprint Scope Time frame a d co e a e and commitments do not c a ge t e ts ot change Do not adjust schedule—end date of Sprint is fixed The team s commitment is for length of Sprint team’s Enables the team to make and keep commitments Gives the team focus and stability during the Sprint Trains Product Owner to clearly think through what is on the Product Backlog In special cases, Product Owner can direct the team to terminate the Sprint prematurely and start a new one. 24
  • Practice: Sprint Scope Future work utu e o Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint. Product Owner can add, remove, reorder, or change backlog items. Product Owner can also ask the team to re-implement work that has already been completed. 25
  • Artifact: Product Backlog Single master list of features, functionality, and other g y work required Prioritized based on business value and risk, in the judgment of the Product Owner Items at the top of the list will be completed by the team first and should have more detail than lower priority items Constantly being revised by the Product Owner, to maximize the business success of the team’s efforts Product Backlog Items vary in size (typically 2-3 people, 2-3 days). 26
  • Artifact: Product Backlog Example Title Status Priority Estimate Reference Money Market Access (BMG) checking data into FMG DW(5275) In Progress Critical 1.00 SCR 5275 Develop Sales Rep Dimension Critical Product Create Cognos catalog subject area - Dividends In Progress Critical 30.00 Create Cognos catalog subject area - SAM In Progress Critical 30.00 Backlog Create Cognos catalog subject area - SAD In Progress Critical 30.00 Analyze Call Center Reporting High SCR 5276 Items Modify CARMA to maintain WFFD terms & conditions High 52.00 SCR 5271 2003 and 2004 AUM differences clean-up High 0.00 SCR 5166 Unknown Sponsor / Strategy in FMG DW for Managed Accounts High 0.00 SCR 5165 Priority Create effective dating for Territory Maintenance High 215.00 Create territory overrides High 215.00 Populate FMG-DW with territory informationOrder High 215.00 Prepare for production readiness High 100.00 Administrator group access on Windows servers High Sybase Upgrade - UAT In Progress High 5.00 Managed Account Suspension Item 2 - Copy Back High 0.00 MAPS: Error - Rep info missing from Rep-EOM-CD High High-level Document overall data flow for populating the D Sales Rep dimension In Progress High 7.00 Design a Code dimension In Progress High 20.50 Design a CRM HQ Company dimension Estimate In Progress High 7.50 Design a CRM Company dimension In Progress High 7.50 Design a Channel dimension In Progress High 9.50 Design an integrated Territory dimension In Progress High 10.50 VAS/PowerBroker Medium Husky and FTP100 Tech Refresh Medium Update User Created SQL Process Low SCR 5271 27
  • User Stories “…are p o ses for a o go g co e sat o s a e promises o an ongoing conversations” Mike Cohn’s User Story template: “As a <Some Role> I want <Some Business functionality> So that <Some Business Value or Justification> For Developers, the “I want” clause is what counts, For P d t O F Product Owners, the “so that” clause is what counts th “ th t” l i h t t 28
  • Types of User Stories Epic High level may contain only 2 of 3 components of user story As a <user role> I want an application, so <business justification> Used as place holders to create product roadmap Themes – in between Story – I.N.V.E.S.T. criteria Independent Negotiable Valuable Estimable Small Testable
  • User Story Example As Tim (tired morning pe so ), I want my usua s (t ed o g person), a t y usual Kwikoffee so that I can get to work and without rushing. “Done” when A simple cup can be ordered from the kiosk Automated tests written for all UATs User documentation written for new/modified functionality 30
  • Definition of Done Defined by bot t e Product O e a d t e Team e ed both the oduct Owner and the ea Everyone agrees on the definition of done Goals Deliver complete “slices” of the system Iterate over robustness Tools Solid engineering practices Solid engineering infrastructure 31
  • Practice: Sprint Planning Meeting Team se ects what it will co ea selects at t commit to deliver by t e e d o t de e the end of the Sprint Team creates a task-level plan for how they will deliver Team creates an initial assignment of tasks Team compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonable Everyone on the team takes part, regardless of role and part experience-level 32
  • Practice: Sprint Planning Meeting Product O e must not p essu e t e tea into oduct Owner ust ot pressure the team to committing to more than they think is doable. Managers may initially be concerned that their team might under-commit. d it Many teams are initially concerned about the perception of the amount of work being completed so they over completed, over- commit. In reality, most teams have the opposite problem: it may y, pp p y take them several Sprints to learn to not over-commit. 33
  • Practice: Sprint Planning Meeting Example o Agenda a p e of ge da 1:00 – 1:30. Product Owner goes through the sprint goal and summarizes product backlog. 1:30 – 3:00. Team breaks down items and estimates time. Product Owner updates priorities as necessary. 3:00 – 4:00. Team selects the backlog items to be included in the sprint and makes commitment to Product Owner. 34
  • Artifact: Sprint Backlog Co p ete st of tasks equ ed Complete list o tas s required to meet the sprint goals eet t e sp t goa s and committed product backlog items Tasks include detailed estimate created by the team Team tracks effort remaining to complete each task Constantly being revised by the Team, to maximize achievement of the sprint goal Tasks vary in size but no larger than 16 hours 35
  • Artifact: Sprint Backlog Example Detail Backlog Item / Defect Task Owner Status Estimate Done To Do Complete development of Office Confirm business rules Zigler, Al,Carter, Tammy Checked Out 4.00 3.50 2.00 Merge screens Update Search results integration tests Minor, Brian 4.00 4.00 Complete b i C l t business rule validation l lid ti Grayson, John G J h 5.00 5 00 5.00 5 00 Review business rule validation Zigler, Al,Minor, Brian,Grayson, John,Carter Checked Out 5.00 2.00 3.00 Review business rules with PO Zigler, Al,Carter, Tammy Done 2.00 1.00 2.00 Backlog Develop Onyx table update Grayson, John Checked Out 6.00 2.00 4.00 Items Add integration tests for Office merging Procedure test script Grayson, John Grayson, John 6.00 6.00 6.00 6.00 Peer review Minor, Brian,Dupont, Jason,Grayson, John 3.00 3.00 Review database changes Grayson, John Lin Grayson John,Lin, Kim Done 1.00 1 00 1.00 1 00 0.00 0 00 Add Effective date - logical/physical models Lin, Kim 1.00 1.00 Add Effective date - implementation Lin, Kim 1.00 1.00 Update caliber Lemke, Linda 1.00 1.00 Tasks Review requirements - Onyx batch impacts/bShavasi, Sudhir Checked Out 2.00 2.00 0.00 Review requirements - Onyx batch impacts/bZigler, Al,Carter, Tammy,Shavasi, Sudhir Checked Out 3.00 1.00 2.00 Update test scripts Shavasi, Sudhir 3.00 3.00 p Review test scripts Zigler, Al,Lemke, Linda,Carter, Tammy,ShavChecked Out g , , , , , y, 4.00 5.00 2.00 Test data prep Shavasi, Sudhir 6.00 3.00 3.00 Execute component testing Shavasi, Sudhir 16.00 16.00 Issue resolution Minor, Brian,Grayson, John,Shavasi, Sudhir 12.00 12.00 Environment Build Create list of database for Rlse 1.0 Lin, Kim Done 1.00 1.00 0.00 Review list of Release 1.0 changes Minor, Brian,Lemke, Linda,Grayson, John,Lin, Kim,Carter, Tammy 5.00 2.00 4.00 Re-apply Release 1.0 changes - DEV Lin, Kim 4.00 1.00 3.00 Implementation Release 1.0 in local FMG Van Camp, Fred,Lin, Kim 2.00 2.00 User Training Manual Define scope, audience, and deliverables Lemke, Linda Checked Out 4.00 1.50 4.00 Document approach Lemke, Linda Checked Out 6.00 6.00 Draft Format of Manual Lemke, Linda 6.00 6.00 Draft Content Lemke, Linda 10.00 10.00 Review approach with product owners Lemke, Linda 4.00 4.00 Review & Update content with product owne Lemke, Linda 3.00 3.00 36
  • Practice: Daily Standup A short meeting da y to update eac ot e o p og ess s o t eet g daily each other on progress and surface impediments Strictly time-boxed to 15 minutes 3 questions: what was done since last meeting, what will be done by next meeting, and any issues/impediments Scrum Master notes issues/impediments, and afterwards helps resolve them Others can attend the meeting if the team invites them, them but they do not speak. This meeting is not for monitoring the team. 37
  • Artifact: Burndown & Burnup Charts Each day, the team updates simple c a ts that show ac t e tea s p e charts t at s o progress towards their Sprint goal. The Burndown Chart graphs the total hours left for all tasks. t k The Burnup Chart graphs the total number of backlog items completed in the Sprint Sprint. These charts enable the team to successfully self- manage and deliver what they committed to by the end of g y y the Sprint. 38
  • Artifact: Burndown & Burnup Charts Example Agile V Scorecard 39
  • Artifact: Potentially Shippable Product The goa for t e tea is to complete 100% o what t ey e goal o the team s co p ete 00% of at they committed to, ideally an increment of Potentially Shippable Product at the end of each Sprint. For ft F software, this means f thi functionality that has been ti lit th t h b designed, fully implemented, and fully tested, with no major defects. j Few teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this thi goal. l 40
  • Practice: Sprint Review (Demo) Performed at t e e d o eac Sp t e o ed the end of each Sprint Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced d d Product Owner gathers feedback from everyone on the ways to improve what has been built Feedback is incorporated into the Product Backlog 41
  • Practice: Sprint Retrospective C t ca o co t uous p o e e t of team effectiveness Critical for continuous improvement o tea e ect e ess Method for identifying and addressing critical problems Retrospective meeting requires the Team, Product Owner, and Scrum Master Focuses on 3 questions: 1. What worked well? 2. What needs improvement? 3. What action items do we implement in the next sprint 42
  • Practice: Sprint Retrospective Example o Agenda a p e of ge da 1:00 – 1:30. Review the commitment results for Sprint 1:30 – 2:00. Brainstorm everything that worked well 2:00 – 2:30. Brainstorm areas of improvement 2:30 – 3:00 Brainstorm action items to address areas 3:00. of improvement 3:00 – 3:30. Select action items to implement next sprint and commit to improve 43
  • Practice: Sprint Retrospective What went well? All code was delivered ahead of schedule which helped in testing progress. Code Review’s added Review s More continues development time Requirements Update continued Developers were able to take others tasks to help completion based on obstacles that came What can we improve? Revisit the meeting time of the huddle g Who closes stories/ tasks Defines Goals in Advance Requirements delay based on capacity and change in direction Would like to continue to focus on collaboration between dev/req review Requirements still key and needed. Difficult to determine focus split on documentation for Too many stories Difficult in switching views in VersionOne Can we go to 4 week iteration? Stories should not be added after the planning Capacity concern with business partner time also. Might need to have multiple days to digest and review with other business counter parts. Action Items Implement code reviews Hold more design meetings, reviews with the Business Owner Add Business owner tasks to VersionOne 44
  • Typical Project Lifecycle Product / Project Release A Release B Planning Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint Sprint Sprint Sprint Sprint Sprint Planning Planning Planning Planning Planning Planning Sprint Sprint Sprint Sprint Sprint Sprint Review & Review & Review & Review & Review & Review & Retro Retro Retro Retro Retro Retro 45
  • Introduction to Scrum QUESTIONS 46