Presentation is loading. Please wait.

Presentation is loading. Please wait.

Introduction to Scrum for Software Project Management Kevin Thompson, Ph.D. Project Management Professional Certified Scrum Practitioner Certified Scrum.

Similar presentations


Presentation on theme: "Introduction to Scrum for Software Project Management Kevin Thompson, Ph.D. Project Management Professional Certified Scrum Practitioner Certified Scrum."— Presentation transcript:

1 Introduction to Scrum for Software Project Management Kevin Thompson, Ph.D. Project Management Professional Certified Scrum Practitioner Certified Scrum Master http://www.linkedin.com/in/kevinthompsonphdhttp://www.linkedin.com/in/kevinthompsonphd -- kevin@kethompson.org http://www.linkedin.com/in/kevinthompsonphd

2 2 or, Dude, wheres my Gantt Chart?

3 3 What is the Purpose of this Talk? It is not to teach Scrum. It is not to teach Scrum. The philosophy of Scrum is simple. The execution is not. The philosophy of Scrum is simple. The execution is not. Learning Scrum adequately takes days, not half an hour. Learning Scrum adequately takes days, not half an hour. It is to provide a perspective on Scrum that makes sense to a trained Project Manager. It is to provide a perspective on Scrum that makes sense to a trained Project Manager. Scrum did not arise in a formal PM context. It can seem alien, or wrong, to Project Managers. Scrum did not arise in a formal PM context. It can seem alien, or wrong, to Project Managers. It uses unfamiliar terms It uses unfamiliar terms It makes unfamiliar optimizations and tradeoffs It makes unfamiliar optimizations and tradeoffs It is also to show how Scrum arises from basic principles. It is also to show how Scrum arises from basic principles. Define success. Define failure. Optimize process for success. Define success. Define failure. Optimize process for success.

4 4 What do Success and Failure Mean in Software Development? Success: Provide the right features to the customer, at the right time Success: Provide the right features to the customer, at the right time Failure: Provide the right features at the wrong time, or wrong features at any time Failure: Provide the right features at the wrong time, or wrong features at any time Too many software failures means company failure! Too many software failures means company failure!

5 5 What is the Right Time? 1. Some apps (e.g. business Web apps) are subjected to a continuing stream of feature requests Requests come in over time Requests come in over time Features are desired when requested Features are desired when requested 2. Some apps (e.g. flight control software) may have a fixed set of features Requirements are fairly static Requirements are fairly static Features may not be usable until platform is ready Features may not be usable until platform is ready We focus on Scenario 1 here We focus on Scenario 1 here

6 6 How does Success Relate to the Schedule of Feature Delivery? Ideal: Provide every useful new feature the day it is requested Ideal: Provide every useful new feature the day it is requested Key elements of ideal solution Key elements of ideal solution Instant turnaround (zero time to feature delivery) Instant turnaround (zero time to feature delivery) Maximum responsiveness (Yes to every request) Maximum responsiveness (Yes to every request) Note: Other definitions of success are possible! Note: Other definitions of success are possible! They could lead to optimal processes that are different from Scrum. They could lead to optimal processes that are different from Scrum.

7 7 How can we Approximate the Ideal of Success in the Real World? Instant turnaround Work in short development cycles Instant turnaround Work in short development cycles Within cycle, reduce risk, maximize delivered value by finishing each feature before starting next Within cycle, reduce risk, maximize delivered value by finishing each feature before starting next Maximum responsiveness Prioritize feature requests into rank order, and burn down the list from the top Maximum responsiveness Prioritize feature requests into rank order, and burn down the list from the top Revise the ranked feature list before each development cycle, based on current evaluation of customer needs Revise the ranked feature list before each development cycle, based on current evaluation of customer needs

8 8 Does Scrum Approach the Ideal? It attempts to, because Scrum is a project-management framework designed to address rapidly-changing customer needs. It attempts to, because Scrum is a project-management framework designed to address rapidly-changing customer needs. Scrum is optimized for projects where Scrum is optimized for projects where Needs change quickly (scope is very fluid). Needs change quickly (scope is very fluid). Most implementation can be done quickly. Most implementation can be done quickly. Long lead times are not usually a major issue. Long lead times are not usually a major issue. Project is cyclic (always starts over in a few weeks, so new needs can be addressed then), not linear (only one chance to do it right). Project is cyclic (always starts over in a few weeks, so new needs can be addressed then), not linear (only one chance to do it right). Success is measured by customer satisfaction with responsiveness and turnaround time Success is measured by customer satisfaction with responsiveness and turnaround time

9 9 How does Scrum Differ from Classic Waterfall Project Management? Classic Waterfall Classic Waterfall Freezes scope, estimates schedule Freezes scope, estimates schedule Adjusts schedule first, scope second, as needed to meet target dates. Adjusts schedule first, scope second, as needed to meet target dates. Plans all features, designs all features, implements all features, tests all features, fixes all bugs, in that order Plans all features, designs all features, implements all features, tests all features, fixes all bugs, in that order Scrum Freezes schedule, estimates scope Never changes schedule. Adjusts scope, as needed, to meet target dates. Plans one feature, designs one feature, implements one feature, tests one feature, fixes bugs for one feature, then repeats for next feature

10 10 Are Scrum and Waterfall Similar? Yes, on paper, but no, in practice. Yes, on paper, but no, in practice. The key difference is about Feature Completion The key difference is about Feature Completion Scrum process finishes one feature at a time (all the way through testing). If specified scope takes 2X more time than expected, at least some features will be ready to ship. Scrum process finishes one feature at a time (all the way through testing). If specified scope takes 2X more time than expected, at least some features will be ready to ship. Waterfall process parallelizes work across features at each stage, finishing all features at end. If specified scope takes 2X more time than expected, it may be that no features will be ready to ship, as all are still in process. Waterfall process parallelizes work across features at each stage, finishing all features at end. If specified scope takes 2X more time than expected, it may be that no features will be ready to ship, as all are still in process. Other differences have more to do with customary practices than fundamental concepts (but in practice, make a huge difference). Other differences have more to do with customary practices than fundamental concepts (but in practice, make a huge difference). Scrum is like one waterfall per feature, end-to-end through the development cycle. Scrum is like one waterfall per feature, end-to-end through the development cycle.

11 11 How does Scrum Differ from Normal Project Management? It doesnt, really. It doesnt, really. It just makes a less-familiar tradeoff in the iron triangle of scope, schedule, and resources. It just makes a less-familiar tradeoff in the iron triangle of scope, schedule, and resources. Most non-software projects have a specified scope. One estimates schedule, and adjusts schedule to guarantee the scope. Most non-software projects have a specified scope. One estimates schedule, and adjusts schedule to guarantee the scope. Scrum projects have a specified schedule. One estimates scope, and adjusts scope to guarantee the schedule. Scrum projects have a specified schedule. One estimates scope, and adjusts scope to guarantee the schedule. It also uses terms that seem peculiar to Project Managers. It also uses terms that seem peculiar to Project Managers.

12 12 Why not Specify Schedule and Scope? Software development involves constant invention, not repetition of standard steps. Accurate effort estimation is impossible. Software development involves constant invention, not repetition of standard steps. Accurate effort estimation is impossible. Thus Scope and Schedule cannot both be guaranteed. Thus Scope and Schedule cannot both be guaranteed. Attempts to constrain both yield high uncertainty and high risk! Attempts to constrain both yield high uncertainty and high risk! The risk is to the projects criteria for success, which is customer satisfaction with responsiveness and turnaround time. The risk is to the projects criteria for success, which is customer satisfaction with responsiveness and turnaround time. Risk is minimized if only one variable is constrained. Risk is minimized if only one variable is constrained. Scrum chooses a predictable schedule over a predictable scope. Scrum chooses a predictable schedule over a predictable scope. We are much more likely to deliver on a commitment to schedule than on a commitment to scope. We are much more likely to deliver on a commitment to schedule than on a commitment to scope. We communicate the schedule commitment to customers, and meet it. We communicate the schedule commitment to customers, and meet it.

13 13 What are the Key Scrum Concepts? Software requirements are either chunked into small sets calledstories (often in narrative form), or are bug-fix requests. Software requirements are either chunked into small sets calledstories (often in narrative form), or are bug-fix requests. Small teams (37 people) work in short sprints (24 weeks) to implement stories in rank order. Small teams (37 people) work in short sprints (24 weeks) to implement stories in rank order. Requirements are frozen when sprint startsno change requests allowed! Requirements are frozen when sprint startsno change requests allowed! Teams self-organize to best apply member skill sets (coding, test development, testing, etc.). PM does not assign tasks. Teams self-organize to best apply member skill sets (coding, test development, testing, etc.). PM does not assign tasks. Team members collaborate to complete stories quickly, instead of working on separate stories in parallel. Team members collaborate to complete stories quickly, instead of working on separate stories in parallel. At end of sprint, completed stories are shipped, incomplete stories are not. At end of sprint, completed stories are shipped, incomplete stories are not. No exceptions! Schedule is not extended to complete work. No exceptions! Schedule is not extended to complete work.

14 14 Scrum has New Names for Old Concepts Project Managers say Project Managers say Schedule Schedule Scope Scope Work Breakdown Structure Work Breakdown Structure Productivity Productivity Estimate to Complete Estimate to Complete Scrum Masters say Sprint Sprint Backlog Task Breakdown Velocity Burndown Chart

15 15 Scrum has New Names for Process Groups Project Managers say Project Managers say Plan Plan Execute Execute Monitor & Control Monitor & Control Close Close Scrum Masters say Define Backlog, Plan Sprint Develop and Test Move Stickies, have Daily Scrums Demo, Release, have Retrospective

16 16 Scrum has New Names for Roles Scrum Master Scrum Master Manages the process (enforces, tracks, expedites problem resolution) Manages the process (enforces, tracks, expedites problem resolution) Runs daily Scrum and Sprint Planning Meetings Runs daily Scrum and Sprint Planning Meetings Usually a Project Manager Usually a Project Manager Product Owner Product Owner Responsible for requirements (new features, bug fixes) and release dates Responsible for requirements (new features, bug fixes) and release dates Works with customers to define user-facing features Works with customers to define user-facing features Collaborates with engineers, QA, Services, and Support personnel, to work out order of implementation of all requests Collaborates with engineers, QA, Services, and Support personnel, to work out order of implementation of all requests Usually a Product Manager Usually a Product Manager Team Team Self-organizes cross-functional members to implement and test features Self-organizes cross-functional members to implement and test features Usually software & test engineers, database architects, UI developers, etc. Usually software & test engineers, database architects, UI developers, etc.

17 17 Scrum has a Different Concept of Schedule MS Project schedules are possible, but not of much value. MS Project schedules are possible, but not of much value. A Scrum schedule is really a cadence, i.e. a repeating sequence of activities and events. A Scrum schedule is really a cadence, i.e. a repeating sequence of activities and events. Content of cadence varies by role or organization: Content of cadence varies by role or organization: Team, Product Management, Customer Support, Professional Services, etc. Team, Product Management, Customer Support, Professional Services, etc.

18 18 E.g., a Development Team Cadence might Repeat Every 13 Weeks

19 19 Summary Scrum is a particular Project Management framework for software development, with Scrum is a particular Project Management framework for software development, with A short, fixed schedule per cycle, with adjustable scope A short, fixed schedule per cycle, with adjustable scope A repeating cadence of events, milestones, and meetings A repeating cadence of events, milestones, and meetings A practice of implementing and testing requirements (stories and bug fixes) serially, to ensure some work is release-ready after each cycle A practice of implementing and testing requirements (stories and bug fixes) serially, to ensure some work is release-ready after each cycle Scrum uses standard project-management concepts. Scrum uses standard project-management concepts. Scrum addresses customer satisfaction by optimizing turnaround time and responsiveness to requests. Scrum addresses customer satisfaction by optimizing turnaround time and responsiveness to requests.

20 20 Q & A Questions? Questions? Answers! Answers!


Download ppt "Introduction to Scrum for Software Project Management Kevin Thompson, Ph.D. Project Management Professional Certified Scrum Practitioner Certified Scrum."

Similar presentations


Ads by Google