1. Getting Started with Scrum
Silvana Wasitova, CSM, CSP, PMP, PMI-ACP
Frankfurt, April 2014
2. Managed projects in 12 countries, lived in 7
2002: PMP
2004: President of PMI Silicon Valley
2005: started practicing Scrum
2009: Scrum Coach & Trainer
2011: PMI-ACP
Silvana Wasitova, PMP, ACP, CSM, CSP
3.
4.
5. Rolland Garros
February
Yahoo-Eurosport: 2008 Event Schedule
January April May JuneMarch
Rugby 6 Nations Wimbledon
TDF
Euro
Paris-Dakar Tour de France
Moto GP
Golf, Athletics, Cycling
Basketball
Boxing
Horse Racing
Hockey, etc
FOOT:
Olympic Games qualifiers
World Cup qualifiers
30-Apr-14
5
6. Scrum Adoption at
Source: Gabrielle Benefield http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption
• 2004: One person experimented with scrum
• 2005: VP of Product Development hired Senior Director of Agile Development
• 2008:
3 coaches, each coaching approx. 10 scrum teams/year
200 scrum teams world wide, total approx. 1500+ employees
• Results in 2008:
Average Team Velocity increase estimated at +35% / year,
in some cases 300% - 400%
Development cost reduction of over USD 1 million / year
ROI on transition and trainings about 100% in first year
• Note: In first three years, 15-20% of people consistently DID NOT like Scrum
6
9. Why Scrum works:
1. Close collaboration with Customer
2. Transparency through daily reviews → risk reduction
3. LEAN ‘flow’ → frequent delivery of business value
4. Eliminate waste, focus on highest priorities
5. Inspect, adapt, improve - in each iteration
10. Scrum Adoption at G IT HQ
• 2010: One project experimented with scrum
• 2012:
42 projects with Scrum, expected another 12
3 coaches, 60 trained ScrumMasters, 10 trained Product Owners
700+ people trained in “Scrum Basics”
One division: We want Scrum Only, no more waterfall
• Results in 2012:
Better products
Better quality
Increased customer satisfaction
ROI on transition and trainings about 100% in first year
Note: Friction with budget-allocation & bonus-calculation models
11. from Shingo's “Seven Wastes of Manufacturing”
7 Wastes of Software Development
Partially Done Work (In-Process Inventory)
Defects (Defects)
Relearning (Extra Processing)
Extra Features (Over-Production)
Handoffs (Transportation)
Delays (Waiting)
1
2
3
4
5
6
7
Every bit of code that is
there and not needed
creates complexity
that will plague the code
base for the rest of its lifeTask Switching (Motion)
Ref: Implementing Lean Software Development: From Concept to Cash Mary Poppendieck
13. Waterfall, Agile and Scrum: Characteristics
When is a project a “Scrum Project” and when is it not?
30-Apr-14 13
Waterfall Agile : Iterative Development
Kanban DSDM
Upfront, Detailed Emergent Design
Linear hand-offs:
Dev then QA
Cross-functional &
collaborative: Dev & QA
Formal process,
implemented at end
Welcomed,
prioritized vs. backlog
At beginning and
at delivery Throughout cycle
Scrum
• Daily “standup” status checks ≤ 15mins
• Delivery rhythm in iterations (Sprints)
• Demo & Retrospective at end of ea. Sprint
Continuous Improvement
XP: eXtreme
Programming
• Automated Tests
• Pair Programming
• Automated / Continuous Builds
• TDD: Test-Driven Development
• Continuous Deployment
Teamwork
Change
Requests
Customer / User
Involvement
Specifications
Scrum is the most popular Agile method:
74% of Agile practitioners (2009)
14. Adapt to changing requirements throughout dev. cycle
Continuous improvement via Retrospectives
Early product delivery
Transparency: daily standup
Stress collaboration between developers and customers
Strip-off non-essential activities & artifacts
Regular reviews with Client/Product Owner
Agile Philosophy
1
2
3
4
5
6
7
15. • Specifications will never be fully understoodZiv’s Law:
• The user will never be sure of what they want
until they see the system in production (if then)
Humphrey’s
Law:
• An interactive system can never be fully specified,
nor can it ever be fully tested
Wegner’s
Lemma:
• Software evolves more rapidly as it approaches
chaotic regions (without spilling into chaos)
Langdon’s
Lemma:
Agile deals with:
16. Scrum Adoption Steps
Identify Product Owner, and Product to build
Articulate Product Vision and Goals
Explore User Stories
Construct a Product Backlog
Identify Scrum Master, Team
Construct a Sprint Backlog
Agree on “Definition of Done”
Agree on Sprint logistics
Sprint!
Inspect and Adapt
17. Mechanics of Sprint Planning
Activity Owner Timeframe
Product Backlog (PB) grooming
& prioritization
Product Owner (PO)
+ others as needed
Before Sprint
Start
Sprint Planning:
1. Take top priorities of PB
2. Break-down PB items into
tasks
3. Estimate effort
4. Commit to Sprint Content
Product Owner (PO)
+ Scrum Team
+ Scrum Master
(+ others as
needed)
At Sprint Start
Sprint Execution,
feature development
Scrum Team,
Scrum Master, PO
During Sprint
Acceptance Testing
of developed features
Product Owner During Sprint,
as developed
Demonstration of Sprint Results Team / PO;
Client/Users,
Stakeholders
At Sprint End
Retrospective: what worked
well, what to improve
Scrum Team, Scrum
Master, PO
At Sprint End
17
18. Example - Release Plan – initial version
30-Apr-14
Sprint 1 Sprint 6Sprint 2 Sprint 5Sprint 4Sprint 3
Mega
Menu
Top
Nav
Bottom
Nav
Left Nav
version
People
Picker
VSTTop Right
Nav
Test Env’t
Left Nav
Global
Nav
(Toolbar)
Bottom
Nav
Bread-
crumbs
Authoring,
Content
Mgmt
Search
Portal
Integration
Wizzard
Comms
Panel
Part 1
Comms
Panel
Part 3
Comms
Panel
Part 2
MAT
News
Rollup
Ongoing activities: update taxonomy
VST
Feedback
MAT
Feedback
Sprint 7
Prep for
Cutover
Planned
Go Live
Actual
Go Live
Sprint 8
21. Continuous Evolution of Product Backlog
21
Initial
R
1
R
2
R
3
Ready
R
3
S
1
S
2
S
3
S
4
R
2
Refined
R
1
R
2
R
3
End of S1
R
3
S
2
S
3
S
4
R
2
22. Agile Success Factors @
Commitment from Management & Execs
Trainings: Scrum Master, PO, Team members
Culture of learning -
apply retrospective findings
Respect teams to be self-organizing
Agile Coach at each location
24. Eight Steps to a Large Scale Change
John Kotter: Leading Change
1. Increase urgency
2. Build the Guiding Team
3. Get the Vision Right
4. Communicate for Buy-In
5. Empower Action
6. Create Short-term Wins
7. Don’t Let Up
8. Make Change Stick
25. Why Agile Adoptions Fail
1. Ineffective use of the retrospective
2. Inability to get everyone in the planning meetings
3. Failure to pay attention to the infrastructure required
4. Bad ScrumMasters
5. PO Consistently Unavailable / too many owners who disagree
6. Reverting to Form
7. Only "Checkbook Commitments" from Executive Management
8. Teams Lacking Authority and Decision-Making Ability
9. Not Having an Onsite Evangelist for Remote Locations
10.A Culture that Does Not Support Learning
11.Embracing denial instead of the Brutal Truth
Source: Jean Tabaka http://www.infoq.com/news/2007/09/why-do-agile-adoptions-fail