How to Prepare for and Implement a Project Using Scrum

Transcription

1 How to Prepare for and Implement a Project Using Scrum 2013 IEEE Software Technology Conference Salt Lake City, UT Dick Carlson Richard.Carlson2@Boeing.com Philip J. Matuzic Philip.J.Matuzic@Boeing.com BOEING is a trademark of Boeing Management Company.

2 Agenda Defense, Space & Security Introduction Part 1: Project Planning and Preparation Part 2: Sprint Planning and Execution Part 3: Stakeholder Collaboration, Interchange and Sustainment Part 4: Reflection and Process Improvement 2

3 Introduction BOEING is a trademark of Boeing Management Company.

4 Tutorial goals Provide a brief history of Agile Explain the simplicity of Scrum and its values and practices Emphasize critical activities prior to using Scrum Describe how to implement and deploy Scrum Present critical steps essential to implementing Scrum Show how any project can benefit by using Scrum s simplicity Offer tips on how Scrum should be deployed to ensure successful implementation 4

5 Why is this necessary? Defense, Space & Security Products take too long to build, are too expensive to make, and are deployed too late. Waterfall vs. Agile Siloed Culture Collaborative BUF Design Design Evolutionary Late Testing Continuous Conformance to Plan Measure of Success Adapt to Change Command & Control Leadership Sevant Leadership Individual Rewards Team Development Organizational Focus Enterprise Source: Dick Carlson 5

6 Cost $$ Defense, Space & Security Cost of software defects Code defect found during peer review Code defect found during Continuous Integration Design or code defect found during test-driven development (TDD) Requirement or design defect found through active stakeholder participation Requirement defect found during acceptance testing Design defect found during system testing Requirement or design defect found during just-in-time modeling Code defect found during system testing Escaped defect found during a peer review Requirement or design defect found during initial Agile modeling Blue Agile Red Traditional Length of Feedback Cycle (development lifecycle) Inspired by Scott Ambler: 6

7 Principles and practices of agility Defense, Space & Security Principles: Customer Satisfaction Frequent Delivery Motivated Team Working Software Technical Excellence Emergent Design Embracing Change Collaboration High Bandwidth Sustainable Pace Simplicity Continuous Improvement Practices: Close customer collaboration Daily stand-up meetings Planning Estimating Short sprints Prioritized requirements Product demos/reviews Self-organized teams Source: Dick Carlson 7

8 Manifesto for Agile Software Development We are uncovering 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 on the items on the right, we value the items on the left more. Source: 8

9 Agile Core Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 9

10 More of the Core Agile Principles Defense, Space & Security Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 10

11 About Scrum Scrum is an Agile project management method that focuses on delivering the highest business value in a short period of time A Scrum project is a series of sprints Every 2-4 weeks produces an increment of potential functionality, where decisions are made to release it as is, or continue to enhance it for another sprint Teams are fully empowered and self-organized to determine the best way to build and deliver the highest priority features The customer or business needs set the priorities Simple, straightforward, and productive Practices, artifacts, and rules are easy to learn No complicated process descriptions Effective project planning process No individual assignments 11

12 Why use Scrum? Simple and easy to learn Can be used to manage any kind of project Benefits are realized early and often Enhances visibility promotes openness and transparency Improves communication Encourages customer/stakeholder feedback Results are noticed and progress is made daily Risks are identified and mitigated in real time 12

13 Scrum Process 13

14 Scrum Values Scrum is based on a set of fundamental values that make up the backbone of Scrum s practices Commitment Be willing to commit to a goal Scrum provides people all the authority they need to meet their commitments Focus Do your job Focus all of your efforts and skills on doing the work you ve committed to doing Openness Scrum keeps everything about a project visible to everyone Everything about Scrum is transparent Respect Individuals are shaped by their experiences It s important to respect the different people who comprise a team Courage Have the courage to commit, act, be open, and expect respect Team members must accept the authority and accountability for product delivery and make decisions 14

15 Scrum metaphor Pigs occupy one of the Scrum roles (Team member, Product Owner, ScrumMaster) and are committed to the project Chickens are persons involved in the project, but do not have formal Scrum accountabilities and responsibilities (not a Team member, Product Owner, ScrumMaster) 15

16 Project Planning & Preparation BOEING is a trademark of Boeing Management Company.

17 Starting a Scrum project Sprint 0: What is needed before the project can start? Stable and baselined requirements Approval and support to use Agile by stakeholders Assess need for using Agile-Scrum Determine the most likely and significant risks Locate and bring in an Agile or Scrum Champion Train everyone on the use of Scrum Identify needed skill sets Identify personnel that meets requisite skill sets Identify Scrum Master and Product Owner candidates Create enough architecture that will support initial sprints Determine and confirm all needed infrastructures and environments 17

18 Determine the need Defense, Space & Security Why is Scrum being considered for use? What is attractive about Agile or Scrum? How do you know Scrum will fit into your culture? Determine the risks and their potential impacts Conduct an Agile assessment Base decision to implement Agile on environment, culture, facilities, personnel skills, and customer acceptance 18

19 Identify stakeholders Recognize those who have the greatest vested interest Who are they? Customer, senior/executive management, management program/project management, suppliers, systems engineering, software engineering, test engineering, product engineering, marketing/sales, contracts, finance, etc. Train everyone on Scrum implementation and show them the benefits that will be realized Include key stakeholders in all sprint reviews / demos and solicit their feedback often Encourage and teach stakeholders to engage without being an obstacle 19

20 Identify team members Defense, Space & Security Determine all requisite skills needed to complete all work Negotiate with management for the best of the best Include the team in all project planning activities Encourage the team s inputs for release planning Involve the team in estimating all work for the project Work with management to retain top-performing team members throughout the project lifecycle 20

21 Train everyone on Scrum Defense, Space & Security Encourage senior management include everyone in the organization to attend Agile training sessions Include project and program managers, Contracts, Finance, Security, Business Ops, SQA, SCM, and all engineering activities Demonstrate through training how each activity can apply Agile The more that are aware of Agile, the less the likelihood of resistance Institutionalize organizational Agile training 21

22 Facilities planning Defense, Space & Security Establish rooms where Agile teams can meet on a daily basis Establish a software development environment Establish software integration and testing environment Establish simulation environment Establish release/deployment/delivery activities 22

23 Initial product backlog Create the project s initial product backlog Should include all known requirements and customer / user needs Items in the backlog will represent project scope Not necessary to determine everything that will be needed Project is a discovery journey the team, in collaboration with key stakeholders will make this determination Initial product backlog is needed to drive evolutionary development of the project roadmap 23

24 Project Roadmap Updated prior to the start of each new release cycle Source: Dick Carlson 24

25 Project Storyboard Defense, Space & Security A detailed description of the project s Agile approach Structured as a detailed software development plan Should include project vision, info about project activities, performance goals, and deliverables, project roadmap, release strategy, sprint strategy, daily Scrums, demos, retrospectives, metrics, and most likely risks and their mitigation strategies Development must be coordinated with key stakeholders and approved by the customer 25

26 Execute! Stop planning and get going!! Too much planning assures analysis paralysis Once all project planning activities are complete, there s no reason to delay project implementation The product backlog items for the first 2 or 3 sprints should be decomposed to the point where they can be implemented during a single sprint Use the product roadmap as a guide for feature and functionality completion Have fun 26

27 Scrum Roles BOEING is a trademark of Boeing Management Company.

28 The Product Owner Project visionary Defines the features of the product Establishes and maintains the Product Backlog Places requirements on the Product Backlog Prioritizes items on the Product Backlog based on customer/user needs Decides on release date and content Adjusts features and priority every sprint, as needed Accepts or rejects Team work results 28

29 The ScrumMaster Facilitative team member that works closely with the Product Owner and other stakeholders Ensures Team is fully functional and productive Enables close cooperation across all roles and functions Removes impediments involving the organization outside the sprint to protect the Team from outside distractions Ensures Scrum process is followed Sets up sprint planning, daily Scrum, sprint retrospective, and sprint review meetings Keeps the Team focused on delivering Customer Value by coordinating with functional and other managers to make this happen 29

30 The Team Defense, Space & Security Typically consists of 7 people (+/- 2) Full-time employees Trained and committed to Scrum Self-organizing and self-managing Selects and negotiates work to be done from Product Backlog Defines done (with concurrence from Product Owner) Demonstrates work results to the Product Owner and stakeholders Membership changes only between sprints 30

31 How teams grow over time Defense, Space & Security Bruce Tuckmann Model: 31

32 Sprint Planning and Execution BOEING is a trademark of Boeing Management Company.

33 Sprint planning Defense, Space & Security A time-boxed negotiation session between the Team and the Product Owner about what will be developed during the next sprint The Product Owner and team agree on a set of sprint goals and the definition of done Goals are used to determine which product backlog items to commit to the sprint Team determines location and best time to meet for daily Scrums Everyone commits to the sprint 33

34 Sprint activities Defense, Space & Security Every sprint starts with a planning session Goals are established and commitments are made All necessary work is determined, estimated, and selected Large items are broken down into small chunks Daily Scrum meetings are planned Commitments are made Work throughout the sprint is focused and intense Multi-tasking (WIP) is limited Issues and risks are identified and solutions proposed and implemented Each sprint concludes with an informal review or demo Sprint reviews provide an opportunity for stakeholders to see incremental product development and provide feedback to the team Sprint concludes with a retrospective To identify lessons learned, establish best team practices, and opportunities for improvement 34

35 Keep things simple Do not change the process before project activities begin Allow changes to flow from the team through frequent retrospectives Do not require teams to use new, complicated, or hard-to-learn tools The 1 st value of the Agile manifesto is People and Interactions over processes and tools Everything should be visible to the team and the rest of the organization Maintain transparency 35

36 Taskboard Tasks To Do Checked Out (WIP) Done Analyze the Determine Interface for the Test the Design the Prepare the Design the Conduct trade on Document the Conduct trade on Analyze the Code the Test the Design the Prepare the Design the Conduct trade on Document the Test the Test the Determine Interface for the Analyze the Code the Code the Code the 36

37 Product Backlog A prioritized list of all project work (requirements) Expressed so each item has high business or customer value Owned and maintained by the Product Owner Team assists the Product Owner in periodically grooming the product backlog This is the Product Backlog 37

38 Breaking down PBIs Defense, Space & Security Most project work is allocated and defined at a high level The team should collaborate with stakeholders to break this work down into smaller chunks Not everything in the product backlog needs to be broken down Much of the work can be deferred until it is needed Concentrate only on the most important items first Items for the first few sprints should be adequate 38

39 Definitions of Done Defense, Space & Security Source: 39

40 Sprint Backlog Defense, Space & Security Product backlog items or requirements decomposed into tasks selected by the Scrum Team from the Product Backlog Tasks are broken down into chunks that will take 2 days or less of work Team negotiates significant differences with the Product Owner to get the right amount of work to take into the sprint with a high probability of success This is the Sprint Backlog 40

41 Commitments Among the leading reasons why projects fail Each member of an Agile project must identify their availability Sprint availability is the most important Once a member s availability is established, commitment is paramount Commitments broken guarantee project failure Commitments must be fulfilled by team members and their sponsors Multi-tasking is the chief reason for broken commitments 41

42 Establish some ground rules Defense, Space & Security Every project has its challenges Each sprint planning session should identify some business ground rules Some examples might consider rules for daily Scrums, maintaining task status, acceptable visitor conduct, action plans for process improvements, work estimating techniques, demo preparation, team etiquette, etc. Rules may change each sprint depending on circumstances 42

43 First Half What to build? Product Owner and Team spend 2 to 4 hours reviewing and discussing Product Backlog Items (PBIs) to be completed during the sprint Team members determine their availability (in hours/day) to establish their commitment and estimated velocity, or what they feel they can complete with a high rate of success Team decides on the time and location for daily stand-up meetings Team estimates each item in the product backlog targeted for the sprint and selects Product Backlog Items for the sprint The ScrumMaster ensures the Team selects the right amount of work for the sprint to ensure a high level of success 43

44 Second Half How to build it? The Team decomposes Product Backlog Items into the individual tasks needed to complete them The team commits to the selected backlog items to be completed during the sprint As a task is selected, the team member includes an estimate in hours to complete the task The ScrumMaster creates the sprint backlog that includes all tasks, names of team members, commitments, goals, agreements, and the Definition of Done product 44

45 Requirements expressed as user stories Stories describe functionality that is valuable to a customer or users of the system. A story: Provides a clear and concise look at what is needed Is a unit of development work Expresses a need in a common language Is a brief discussion that helps flesh out details Includes acceptance tests that will validate the need Defense, Space & Security Story Template As a < Role > Who? I want to < Goal > What? So that < Reason > Why? Story Example As a system user, I want to generate reports, So that I can see critical system operations 45

46 What makes a good story? -- INVEST I = Independent stories are easiest to work with if they are independent (not overlapping in concept, and able to implement them in any order) N = Negotiable a story is not an explicit contract for features; a good story captures the essence, not the details V = Valuable a story must be valuable to all stakeholders E = Estimable good stories can be estimated S = Small good stories tend to be small Defense, Space & Security T = Testable a good story is testable; writing the tests early helps us know whether this goal is met 46

47 Converting shall statements into stories The system shall be capable of preserving mission integrity As an AV operator, I want to be able to command the aircraft into a "no transmit "mode, so that I may temporarily collect wave detection and preserve mission integrity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The system shall be capable of archiving flight motion imagery As an analyst, I want to archive the motion imagery from a flight, so that I can retrieve it when I need it 47

48 Conditions for Splitting Stories If implementing a story will take longer than the length of the sprint, the story should be split into two or more stories Large, epic-sized, stories should be broken down into smaller, more manageable stories A story may be small enough to fit within a sprint, but it won't fit within the sprint being planned because there isn't enough time left The team may feel they will have time to develop a portion of a story in the sprint but not the entire story 48

49 Epics Epics are typically large amounts of work that will take much longer to complete or implement than a single sprint Most epics contain multiple goals for multiple reasons and for multiple users Epics can be a shall statement, use case, user story, or a term for a specific capability or function The team should work closely with the Product Owner to decompose large epics for better planning 49

50 Breakdown of time and tasks Defense, Space & Security Source: Dick Carlson 50

51 Daily Scrum or Standup Time-boxed team meeting facilitated by ScrumMaster 15 minutes or less (preference on the shorter) Each team member answers three questions: 1. What have you done since the last meeting? 2. What are you planning to do next? 3. Do you have any impediments or issues? Discussions are limited the to questions asked Chickens (managers, visiting engineers, etc.) are not allowed to talk Problems, fixes, design solutions, and other discussions are discussed after the Daily Scrum 51

52 Scrum of Scrums A meeting conducted to promote awareness and communication throughout a large program Multiple projects are being conducted Attended by Scrum Masters from each project Frequency depends on need Recommend at least one meeting per week Share team progress, issues, problems, successes, metrics, etc. Communicate across entire organization 52

53 Estimating Product Backlog Items Estimating is an effort and decision made by the team only Estimates provided by those who will not complete or implement items are of little value A point system is used to convey the relative size or complexity of a product backlog item Product backlog items are estimated in Story Points Story points are nebulous units used for expressing the overall size of a user story Estimating is done by assigning a point value to each user story The number of story points associated with a story is the overall size of the story Scrum uses the Planning Poker technique for estimating story points

54 Planning Poker 54

55 How Planning Poker Works Each participant is given one set of the cards A Story is read and explained The Team is given an opportunity to ask questions for clarification Each participant selects a card representing the person s estimate Cards are turned over simultaneously so all can see Differences, especially outliers, are discussed Re-estimating continues until estimates converge Each estimate represents a Team decision - Must converge with rest of the team If the Team cannot converge, defer the Story or split it 55

56 Story Points Story points are values that reflect the size of a requirement or part of a requirement Influenced by how difficult it may be or how much there is to do not how much time it will take Estimating is done by assigning a point value to each story Relative values help to understand complexity or size: A login screen may be 3 story points in size A search feature may be 8 story points in size

57 Velocity Velocity is a metric that is calculated by how much was completed during the previous sprint One of the challenges of planning is estimating the velocity of the team. Options to achieve this estimation include: For new teams, run a sprint to create an estimate baseline (not very accurate) Use historical values adjusted for current conditions for teams with a few sprints completed (a little more accurate) Ideally, if the Team has experience working together then it would use an average velocity that the Team exhibited over several sprints (not always accurate) 57

58 Team velocity estimation Defense, Space & Security Velocity = Amount of work completed (Done!) during an sprint PBIs to be completed at the beginning of the sprint Stories completed at the end of the sprint 8 Done! Estimated Velocity = 65 story points Done! Done! Done! Actual Velocity = 55 story points 13 Done! 13 5 Not started 5 5 Not started 5 58

59 Stakeholder Collaboration, Interchange and Sustainment BOEING is a trademark of Boeing Management Company.

60 Sprint review or demo A time-boxed meeting where the team presents to the Product Owner and stakeholders functionality implemented during the sprint Functionality not done cannot be presented Non-functional artifacts cannot be presented except when used in support of understanding the demonstrated functionality Team seeks valuable feedback from stakeholders Stakeholders are expected to provide feedback in the form of observations, criticisms, praise, questions, etc. 60

61 Documentation It is common to prepare documentation on projects Some documents bring value others do not All documentation needs can and should be negotiated with customers Document development should be incremental as the product is developed Consider identifying Leading and Lagging documents Leading documents should be the drivers of product development Lagging documents are not as important as leading documents and should be developed in increments with the product 61

62 Release demo / review activities A release review is conducted at the end of every sprint series for the customer, users, and other relevant stakeholders to see Best opportunity for customers to observe completed activities and work products May include a brief technical interchange meeting to review what was completed A demonstration of working prototypes completed Summarizes activities completed by the team Identifies strategic metrics (e.g. productivity, effort, defects, schedule, etc.) Identifies areas of improvement 62

63 Reflection and Process Improvement BOEING is a trademark of Boeing Management Company.

64 Sprint Retrospective A time-boxed meeting following the sprint demo Attended by the all team members, ScrumMaster, and Product Owner Team discusses and documents what went well during the sprint and how to improve future sprints Entire team participates Needed improvements beyond the team s authority are escalated to management Improvements not acted upon may adversely affect the team s overall productivity 64

65 Metrics BOEING is a trademark of Boeing Management Company.

66 Story Points (stories) Defense, Space & Security Sprint Burndown The sprint burndown chart shows daily progress during a sprint by plotting the amount of work remaining against each sprint day Iteration Burndown Story Points Planned Burndown Iteration Day 66

67 Story Points Defense, Space & Security Burn-Up Chart The burn-up chart is a sprint-to-sprint metric that shows the project s productivity throughout the duration of the project. Burn-up charts support program earned-value management system measures. Software Project Productivity Metric Planned Completed Iteration 1 Iteration 2 Iteration 3 Release 1 Iteration 4 Iteration 5 Iteration 6 Iteration 7 Release 2 Iteration 8 Iteration 9 Iteration 10 Iteration 11 Release 3

68 Agile / Scrum Books Succeeding With Agile Mike Cohn; Addison-Wesley; 2009 Scrum and XP from the Trenches Henrik Kniberg; C4Media; 2007 (free PDF download) Agile Estimating and Planning Mike Cohn; Prentice-Hall; 2005 Agile Project Management with Scrum Ken Schwaber; Microsoft Press; 2004 User Stories Applied: For Agile Software Development Mike Cohn; Addison-Wesley; 2004 Agile and Iterative Development: A Manager s Guide Craig Larman, Addison-Wesley;

69 Papers Considerations for Using Agile in DoD Acquisition ractsource=searchresults Agile Methods: Selected DoD Management and Acquisition Concerns ractsource=searchresults A Closer Look at 804: A Summary of Considerations for DoD Program Managers ractsource=searchresults DoD Agile Adoption: Necessary Considerations, Concerns, and Changes DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers ractsource=searchresults 69

70 Dick Carlson Philip J. Matuzic 70