3What 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 termsIt makes unfamiliar optimizations and tradeoffsIt is also to show how Scrum arises from basic principles.Define success. Define failure. Optimize process for success.
4What do Success and Failure Mean in Software Development? Success: Provide the right features to the customer, at the right timeFailure: Provide the right features at the wrong time, or wrong features at any timeToo many “software failures” means “company failure!”
5What is the “Right Time?” Some apps (e.g. business Web apps) are subjected to a continuing stream of feature requestsRequests come in over timeFeatures are desired when requestedSome apps (e.g. flight control software) may have a fixed set of featuresRequirements are fairly staticFeatures may not be usable until platform is readyWe focus on Scenario 1 here
6How does Success Relate to the Schedule of Feature Delivery? Ideal: Provide every useful new feature the day it is requestedKey elements of ideal solutionInstant 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.
7How can we Approximate the Ideal of Success in the Real World? Instant turnaround Work in short development cyclesWithin cycle, reduce risk, maximize delivered value by finishing each feature before starting nextMaximum responsiveness Prioritize feature requests into rank order, and “burn down” the list from the topRevise the ranked feature list before each development cycle, based on current evaluation of customer needs
8Does 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 whereNeeds 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
9How does Scrum Differ from Classic “Waterfall” Project Management? Freezes scope, estimates scheduleAdjusts 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 orderScrumFreezes schedule, estimates scopeNever 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
10Are 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.
11How 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.
12Why 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.
13What 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.
14Scrum has New Names for Old Concepts Project Managers sayScheduleScopeWork Breakdown StructureProductivityEstimate to CompleteScrum Masters saySprintSprint BacklogTask BreakdownVelocityBurndown Chart
15Scrum has New Names for Process Groups Project Managers sayPlanExecuteMonitor & ControlCloseScrum Masters sayDefine Backlog, Plan SprintDevelop and TestMove Stickies, have Daily ScrumsDemo, Release, have Retrospective
16Scrum has New Names for Roles Scrum MasterManages the process (enforces, tracks, expedites problem resolution)Runs daily Scrum and Sprint Planning MeetingsUsually a Project ManagerProduct OwnerResponsible for requirements (new features, bug fixes) and release datesWorks with customers to define user-facing featuresCollaborates with engineers, QA, Services, and Support personnel, to work out order of implementation of all requestsUsually a Product ManagerTeamSelf-organizes cross-functional members to implement and test featuresUsually software & test engineers, database architects, UI developers, etc.
17Scrum 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.
18E.g., a Development Team Cadence might Repeat Every 1—3 Weeks
19SummaryScrum is a particular Project Management framework for software development, withA short, fixed schedule per cycle, with adjustable scopeA repeating cadence of events, milestones, and meetingsA practice of implementing and testing requirements (stories and bug fixes) serially, to ensure some work is release-ready after each cycleScrum uses standard project-management concepts.Scrum addresses customer satisfaction by optimizing turnaround time and responsiveness to requests.