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/kevinthompsonphd -- kevin@kethompson.org

or, “Dude, where’s my Gantt Chart?”

What is the Purpose of this Talk? It is not to teach Scrum. The philosophy of Scrum is simple. The execution is not. 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. Scrum did not arise in a formal PM context. It can seem alien, or wrong, to Project Managers. It uses unfamiliar terms It makes unfamiliar optimizations and tradeoffs It is also to show how Scrum arises from basic principles. Define success. Define failure. Optimize process for success.

What do Success and Failure Mean in Software Development? 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 Too many “software failures” means “company failure!”

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

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

How can we Approximate the Ideal of Success in the Real World? Instant turnaround  Work in short development cycles 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 Revise the ranked feature list before each development cycle, based on current evaluation of customer needs

Does Scrum Approach the Ideal? It attempts to, because Scrum is a project-management framework designed to address rapidly-changing customer needs. Scrum is optimized for projects where Needs change quickly (scope is very fluid). Most implementation can be done quickly. 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”). Success is measured by customer satisfaction with responsiveness and turnaround time

How does Scrum Differ from Classic “Waterfall” Project Management? Freezes scope, estimates schedule 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 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

Are Scrum and Waterfall Similar? Yes, on paper, but no, in practice. 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. 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). Scrum is like “one waterfall per feature”, end-to-end through the development cycle.

How does Scrum Differ from Normal Project Management? It doesn’t, really. 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. 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.

Why not Specify Schedule and Scope? Software development involves constant invention, not repetition of standard steps. Accurate effort estimation is impossible. Thus Scope and Schedule cannot both be guaranteed. Attempts to constrain both yield high uncertainty and high risk! The risk is to the project’s criteria for success, which is customer satisfaction with responsiveness and turnaround time. Risk is minimized if only one variable is constrained. 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 communicate the schedule commitment to customers, and meet it.

What are the Key Scrum Concepts? Software requirements are either chunked into small sets called “stories” (often in narrative form), or are bug-fix requests. Small teams (3—7 people) work in short “sprints” (2—4 weeks) to implement stories in rank order. Requirements are frozen when sprint starts—no change requests allowed! 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. At end of sprint, completed stories are “shipped,” incomplete stories are not. No exceptions! Schedule is not extended to complete work.

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

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

Scrum has New Names for Roles Scrum Master Manages the process (enforces, tracks, expedites problem resolution) Runs daily Scrum and Sprint Planning Meetings Usually a Project Manager Product Owner Responsible for requirements (new features, bug fixes) and release dates 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 Usually a Product Manager Team Self-organizes cross-functional members to implement and test features Usually software & test engineers, database architects, UI developers, etc.

Scrum has a Different Concept of Schedule 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. Content of cadence varies by role or organization: Team, Product Management, Customer Support, Professional Services, etc.

E.g., a Development Team Cadence might Repeat Every 1—3 Weeks

Summary Scrum is a particular Project Management framework for software development, with A short, fixed schedule per cycle, with adjustable scope 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 Scrum uses standard project-management concepts. Scrum addresses customer satisfaction by optimizing turnaround time and responsiveness to requests.

Q & A Questions? Answers!