Upload
chad-holdorf
View
5.868
Download
7
Tags:
Embed Size (px)
DESCRIPTION
Here is a presentation I presented to management describing how waterfall transitions into scrum. Couldn’t have been done without slideshare.com slides. This is me giving back.
Citation preview
Waterfall into Scrum
|
Intro
Chad “Uber Scrum Master” Holdorf
Scrum Master / Program Manager: John Deere
Certified Scrum Master and Product Owner
Email: [email protected]
Blog: http://uberscrummaster.wordpress.com
2
|
Agenda
• Results• Overview of Framework (Scrum)• How Scrum fits with current Waterfall processes
3
|
What have been the results of other companies?
Increased Speed• SalesForce.com
• Prior to Agile• 1 Release per year
• Post Agile• 4+ Releases per year
• Inovis- EDI/Business Software• Post Agile: < 1 Month per Release• Industry Avg: 6 Months per Release
Increased Efficiency• Inovis Post Agile
• Average Release in Person Months: 12PM• Industry Release Avg: 34PM
More Examples in Backup Section at End
4
|
What is this Agile/Scrum Framework?
5
|
3 Facets of the Framework (Scrum)
Roles(Who)
Product Owner Team Scrum Master
Artifacts(What)
Product Backlog Sprint Backlog Potentially Shippable
Product Burndown Charts
Practices(How)
Sprint Planning Sprint Sprint Review Retrospective
6
|
Overview of Scrum Framework
7
Roles
Product Owner
Scrum Master Team
Artifacts & Practices
|
Product Owner
• Owns the vision of what should be produced to achieve business success
• Manages ROI through prioritization and release plans
• Gets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the vision
• Turns input into a single list of what should be produced, prioritized based on business value and risk
• Owns the Product Backlog
“The Product Owner’s focus is ROI. The Product Owner directs the project, sprint by sprint, to provide the greatest ROI and value to the organization.”
Product Owner
Scrum Master Team
8
|
The Scrum Master
• A new leadership role• It can be played by an existing person (such as a former Project Manager or team-
member).
• Serves the team• Helping remove any and all impediments that surface
• Protects the team• Teaches and guides the team’s use of Scrum• Facilitates – doesn’t “manage” (direct) the team
Product Owner
Scrum Master Team
“The Scrum Master is responsible for the success of the project, and helps increase the potential for success by helping the Product Owner select the most valuable backlog items and by helping the Team turn that backlog into functionality.”
9
|
The Team
• Owns the production and engineering process• Cross-functional - it has all the skills to produce the finished
product• Self-organizing and self-managing - it is responsible for making
a commitment and managing itself to hit the goals (or get as close as it can)
• Authority to do whatever is necessary to meet it’s commitment• The ideal team size in Scrum is 7 people +/- 2
Product Owner
Scrum Master Team
“The Team is responsible for managing itself and has the full authority to do anything to meet the sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.”
10
|
Artifact:
Product Backlog
• Single master list of features, functionality, and other work required
• Prioritized based on business value and risk, in the judgment of the Product Owner
• Items at the top of the list will be completed by the team first and should have more detail than lower priority items
• Constantly being revised by the Product Owner, to maximize the business success of the team’s efforts
• Product Backlog Items vary in size (typically 2-3 people, 2-3 days).
11
|
Artifact:
Product Backlog
12
Product Backlog
Item
Priority
High-Level Est.
|
Practice:
Sprint Planning Meeting
• Team selects what it will commit deliver by the end of Sprint• Team creates a task-level plan for how they will deliver• Team creates an initial assignment of tasks• Team compares total estimated task hours with total
estimated available hours, to make sure the commitment is reasonable
• Everyone on the team takes part, regardless of role and experience-level
13
|
Practice:
Sprint Planning Meeting
• Product Owner must not pressure the team into committing to more than they think is doable.
• Managers may initially be concerned that their team might under-commit.
• Many teams are initially concerned about the perception of the amount of work being completed, so they over commit.
• In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit.
14
|
Artifact:
Sprint Backlog
• Complete list of tasks required to meet the sprint goals and committed product backlog items
• Tasks include detailed estimate created by the team• Team tracks effort remaining to complete each task• Constantly being revised by the Team, to maximize
achievement of the sprint goal• Tasks vary in size but no larger than 2 days
15
|
Practice:
Daily Standup
• A short meeting daily to update each other on progress and surface impediments
• Strictly time-boxed to 15 minutes• 3 questions: what was done since last meeting, what will be done by
next meeting, and any issues/impediments• Scrum Master notes issues/impediments, and afterwards helps
resolve them• Others can attend the meeting if the team invites them, but they do
not speak. This meeting is not for monitoring the team
16
|
Artifact:
Burndown & Burnup Charts
• Each day, the team updates simple charts that show progress towards their Sprint goal.
• The Burndown Chart graphs the total hours left for all tasks.• The Burnup Chart graphs the total number of backlog items
completed in the Sprint.• These charts enable the team to successfully self manage and
deliver what they committed to by the end of the Sprint.
17
|
Artifact:
Burndown & Burnup Charts
18
|
Artifact:
Potentially Shippable Product
• The goal for the team is to complete 100% of what they committed to, ideally an increment of Potentially Shippable Product at the end of each Sprint.
• For software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects.
• Few teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.
19
|
Practice:
Sprint Review (Demo)
• Performed at the end of each Sprint• Product Owner, Team, Scrum Master, and Stakeholders come
together and see a demo of what the team has produced• Product Owner gathers feedback from everyone on the ways
to improve what has been built• Feedback is incorporated into the Product Backlog
20
|
Practice:
Sprint Retrospective
• Critical for continuous improvement of team effectiveness• Method for identifying and addressing critical problems• Retrospective meeting requires the Team, Product Owner, and
Scrum Master• Focuses on 3 questions:
1. What worked well?2. What needs improvement?3. What action items do we implement in the next sprint
21
|
Typical Project Lifecycle
22
|
Scrum Shifts the Drivers
23
Scope
Traditional ProjectThe plan createscost / schedule
estimates
Budget Schedule
Plan Driven
Fixed
Estimated
Value Driven
Budget Schedule
Scope
Scrum ProjectThe vision creates scope estimates
|
So how does the framework fit?
24
|
Sco
pe
Waterfall vs. Agile
25
Analysis/Design
Code
Component Test
System Test
Sch
edule
End to EndSmall Slices of work
20% Done = 100% usable
Ph2
Ph 3
Ph 4
Ph 5
Ch
Scope
Budget
ScheduleCh Ph2 Ph 3 Ph 4 Ph 5
|
Align w/ Waterfall Exits
26
Sco
pe
100%
Schedule/Budget
Product IncrementsPhase Exits
RequirementsSprints
Charter Ph2 Ph4Ph3
System Verification
Value
Team members dedicated
Not all requirements are written
Teams “sprint” all the time
Value is created quicker
“Trimming the Tale” Time to
move on
Goal is to remove this
phase through automation
Ph5
|
References
• Salesforce.com Agile Transformation • Inovis - Reformulating the Product Delivery Process• Project Management With Scrum
27