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

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

3. 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.

4. 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!”

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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.

12. 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.

13. 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.

14. 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

15. 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

16. 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.

17. 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.

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

19. 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.

20. Q & A
Questions?
Answers!