View
1.951
Download
2
Category
Preview:
DESCRIPTION
Citation preview
1
Scrum! for Paris User Group!
–noun 1. flexibility, the capacity and capability of
rapidly and efficiently adapting to change. 2. ability to take advantage of opportuni6es
while controlling risk.
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 2
Agility (a·∙gil·∙i·∙ty)
The courage to be honest enough to admit that building soEware is complex and it can’t be perfectly planned since requirements change.
• More global compeLtors • More demanding
customers • More complex products • More features requested
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 3
Why is Agility important?
In other words: Because your customers demand it.
• Improved relaLonship with customers, regaining trust • Flexibility to turn on a dime • Improved producLvity and quality • Taking advantage of opportuniLes • Early eliminaLon of risk • Early realizaLon of value • Always knowing exactly where you are in a development/deployment
cycle • Easier to make changes • EliminaLon of waste • Lean products that reach market faster and are more targeted • Increased Return on Investment • Engaged, empowered workers • Reduced Total Cost of Ownership
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 4
What are some specific reasons to “be Agile?”
• Releases take longer and longer. • Release schedules slip. • StabilizaLon at end of release takes longer and longer. • While a release is being worked on, it is very hard if not impossible
to start another release. • Planning seems to take too long. • Changes are hard to introduce mid-‐release, even though they
consLtute 35% of the total work. • Quality is deterioraLng. • There have more and more arLfacts, documentaLon, and process • Death marches are hurLng morale. • More than 60% of the funcLonality is rarely or never used, yet
unfilled needs and commitments conLnue to build up while the current release is being delivered.
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 5
But, many organizaLons instead have …
Source: Advanced Development Methods, Inc.
Waterfall!
Plan Analyze Design Code Test Release
Plan for the entire project up-front, including requirements of all value. Nothing can be used until project is over.
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 6
TradiLonal Development Processes Are Not Agile
Scrum!
Waterfall!
Plan Analyze Design Code Test Release
Short, high value iterations that deliver valuable, opportunistic pieces of functionality.!
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 7
Scrum Is Just TradiLonal More Quickly
Plan
Analyze Design Code Test
Release
Plan
The same work, but processed differently and on fewer requirements.!
Scrum!Short, high value iterations that deliver valuable, opportunistic pieces of functionality.!
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 8
Scrum Is a Tool You Use To Become Agile
Plan
Analyze Design Code Test
Release
Plan
Work done by self-organizing, cross-functional teams that are highly productive, creative, and build high quality product.!
Scrum Team
Scrum (n): (1) framework within which people can address complex problems, and producLvely and creaLvely develop products of the highest possible value; (2)A tool you can use to become Agile!
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 9
May I recommend Scrum?
Image source: codecentric.de
Agile Overtakes Waterfall
Source: December 2008 Global Agile Company Online Survey
Waterfall %
Agile %
29 March 2011 10 © ADM 1983-‐2010 All Rights Reserved v2.0
Improve things with Scrum
Remove waste • Technical debt • Unnecessary documentaLon
• Unnecessary requirements
• Unused requirements • Architecture that must be reworked
Improve producLvity • Collocated, self-‐organizing teams
• Cross-‐funcLonal teams • FTF communicaLons • Improved decision making
29 March 2011 11 © ADM 1983-‐2010 All Rights Reserved v2.0
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 12
The first thing that Agility requires is empiricism
Empirical (adjective) 1) Derived from or guided by experience or
experiment.
The modesty to admit that you don’t know all the answers, and that is okay. The best soluLon emerges from collaboraLon with the team.
A thermostat for soEware development
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 13
5 MINS
Purpose: Understand the power of empiricism
Situa<on: You are in charge of keeping a 20 x 40 room in this building at a constant 22C temperature through the day. The room does not have a thermostat.
At the start of the day, 8:00 am, you have to set the heaLng, air condiLoning, venLng, and blinds so that they will adjust themselves at the appropriate Lmes to maintain this temperature throughout the day.
Ques<on: What variables will you have to take into account to know the senngs? (hint: number of people in the room will be one variable).
Time People Event 7:00 -‐ 8:00 5 Room setup
8:00 -‐ 9:00 50 Breakfast, ConLnental buffet style, Lyzure Amalgamated
9:00-‐ 10:30 55 MeeLng -‐ Lyzure Amalgamated
10:30-‐ 11:00 55 Coffee break
11:00-‐ 12:30 55 MeeLng -‐ Lyzure Amalgamated
12:30-‐ 1:00 5-‐20 Setup and next meeLng arriving
1:00-‐ 3:00 50 MeeLng -‐ Rexxus Ltd.
3:00-‐ 3:30 50 Coffee break
3:30-‐ 5:30 70 MeeLng -‐ Rexxus Ltd.
Variables might include, for any Lme during the day: • number of people in room • metabolism of each person • acLvity of each person • opening/closing of doors • weather: including sun, clouds, and outside temperature • temperature of adjoining rooms • construcLon material of the building • floor of the room • will food be served, when, what type, and how much • temperature of food brought into room
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 14
Controlling temperature isn’t that complex, but there are a lot of things to plan for!
Dimensions Of Complexity W
eath
er
Patte
rns
Building Construction
Simple: Everything is known
Complicated: More is known than unknown
Complex: More is unknown than is known
Chaotic: Very little is known
Source: Ralph Stacey, University of Herfordshire
29 March 2011 15 © ADM 1983-‐2010 All Rights Reserved v2.0
Empirical processes adapt to the future
• Variables are ignored. Actual temperature drives senng of air condiLoning, heaLng, blinds.
• Frequent inspecLon & adaptaLon (JIT) rather than predicLve planning
• Based on “actuals” rather than predicLons
• Requires transparency
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 16
The first thing empiricism needs is transparency
Transparency (adjective) 1) Easily seen through, recognized, or
understood. 2) All aspects are equally and commonly
understood by all observers
Most organizaLons struggle with transparency. It requires trust, courage and a lot of collaboraLon.
29 March 2011 17 © ADM 1983-‐2010 All Rights Reserved v2.0
Quality: A Developer’s POV
• I can readily understand the soEware and where & how things happen;
• When I change or add to part of the soEware, there are no unintended or poorly designed dependencies;
• I can read the code without looking for tricks or poorly defined and labeled variables or data;
• I don’t need the person(s) that wrote the code to explain it to me; • There are a full set of (automated) tests to check that the funcLon
works as expected; • When I change something and add to the tests, I can check that the
enLre change and product conLnues to work; • How things work and hang together is tranparent; and, • Standard, well-‐known design principles have been adhered to.
29 March 2011 18 © ADM 1983-‐2010 All Rights Reserved v2.0
Green Field SoEware
Time
Product Backlog (work)
Velocity (done work over time)
29 March 2011 19 © ADM 1983-‐2010 All Rights Reserved v2.0
Exercise The SituaLon: • You are a developer at xyz co,
building life-‐criLcal products. • Your Scrum team is one of seven
working on a new release of one product.
• Your team is going to select product backlog to turn into something done (no more work remains, potenLally shippable) within a two-‐week iteraLon.
• Each team has all the skills to fully develop the requirements into a “done increment.”
The Assignment: • What work would you have to do
to turn the requirements into a “done” increment?
• If you were developing a “done”, potenLally shippable increment, what would your definiLon of “done” be? Would it include, for example, refactoring? What else?
20 29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
Exercise (Cont.) Did your definiLon of “done” include these? Why not?
• Performance tesLng • Stability tesLng • Refactoring • Immunological response tesLng • IntegraLon with the work of the other six teams • IntegraLon tesLng with the work of the other six teams so the increment
is the totality of all seven teams • Release notes • InternaLonalizaLon to the six cultures where the product will be sold • User acceptance tesLng • Regression tesLng • Code reviews
21 29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
Plan Plan Develop Plan Develop Plan Develop Stabilize
Plan Plan Develop Plan Develop Plan Develop Stabilize
Undone
Undone Undone
22
StabilizaLon: What Undone Gets You
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
Case Study: TransCanada Pipelines • After three Sprints, Product Owner was delighted.
She wanted us to continue, but she wanted us to implement the first three increments so her department could start using them.
• We told her that she couldn’t. She asked why not. We said that we weren’t done. She said that it looked done. We said, yes, but not that type of done. She asked how long it would take to go from our type of done to the done that would be usable by her.
• Transparency was not present and trust was lost.
29 March 2011 23 © ADM 1983-‐2010 All Rights Reserved v2.0
StabilizaLon: Plan Vs. Reality Plan!9 Sprints, 3 release candidates and then release.!800-person development organization.!
RC P P P D D D RC P P P D D D RC P P P D D D Release
Actual!The release candidates were presentation of partially working functionality from the code branch for each team. A five+ month stabilization was required prior to release.!“Inadequate performance” was a bug logged in the first Sprint.!
RC P P P D D D RC P P P D D D RC P P P D D D Release Stabilization!
29 March 2011 24 © ADM 1983-‐2010 All Rights Reserved v2.0
Impact Of Integrated “Done” • 120 people, 18 teams!• Release 1: !
• Each team produced “done” increments each Sprint, but they were not integrated or integration tested until “code complete.”!
• Release 2: !• All teams produced an
increment of integrated, integration tested code every Sprint. !
25
Time!
# Defects!
Release 1!
Planned!Release!Date!
Release 2!
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
New Baseline Of “Undone” Work
Product Backlog
Undone Work
Perceived Work
Time
Actual Work Perceived Baseline
Actual Baseline Perceived Work + Undone Work
Actual Work
29 March 2011 26 © ADM 1983-‐2010 All Rights Reserved v2.0
27
Work Item Usual Rec. start Done Requirements analysis 25 25 25
Design of architectural components (UI, System, Data 15 15 15
Design review 0 5 5
Design of tests (system, user acceptance, integration) 0 10 10
Design review 0 3 3
Design of documentation 0 2 2
Design Review 0 1 1
Refactoring of existing design 0 0 8
Design of unit tests for new code 0 3 3
Design of unit tests for code to be refactored 0 3 3
Writing new code 10 7 7
Writing refactored code 6 3 3
Code review (or pair programming) 0 4 4
Write functional tests 8 4 4
Write integration tests 0 4 4
Write documentation 4 4 4
Unit test code 0 2 2
Identify and rectify defects 0 2 2
Subsystem/team build 6 2 2
Identify and rectify defects 1 1 1
Unit test for subsystem/team code 0 2 2
Identify and rectify defects 0 2 2
System/integration build 1 1 1
Identify and rectify defects 0 2 2
System, functional tests 1 2 2
Identify and rectify defects 1 2 4
Integration tests 0 0 2
Identify and rectify defects 0 0 5
Performance tests 0 0 1
Identify and rectify defects 0 0 2
Security tests 0 0 1
Identify and rectify defects 0 0 2
Regression test 0 2 2
Identify and rectify defects 0 8 8
Documentation test 0 1 2
Identify and rectify defects 0 1 1
Total work expended requirement 78 118 148 Work remaining per requirement 65 30 0
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
SoEware W/Low Value To Developers Core FuncLonality • Most significant new
funcLonality builds on it; • Also called infrastructure
and legacy soEware; • Is fragile, doesn’t have
complete test harnesses, and few people sLll know how to or are willing to touch it; and,
• Requires more Lme to work on; velocity working on it is less than new work.
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 28
Time
Product Backlog
Core Functionality
New Functionality
Gradual Impact Of Reduced Quality
NPQ - Normal Product Quality RPQ - Reduced Product Quality
29 March 2011 29 © ADM 1983-‐2010 All Rights Reserved v2.0
Reduced Velocity Puts OrganizaLon In Corner
6 5 7
Release 10
29 March 2011 30 © ADM 1983-‐2010 All Rights Reserved v2.0
Exercise • Your CEO comes to your development group. She tells you it is
mandatory to deliver three new pieces of funcLonality within three Sprints. Otherwise, compeLtors will decimate the company.
• Planned work consists of: – FuncLon 1: 20 units of work, 15 new, 5 core – FuncLon 2: 40 units of work, 25 new, 15 core – FuncLon 3: 30 units of work, 20 new, 10 core
• Velocity for new funcLonality is 15 units of work per Sprint per team.
• Velocity for core funcLonality is 5 units of work per Sprint total. • You need a release with all three funcLons in three months. • Can do you do? Can you save the company?
29 March 2011 31 © ADM 1983-‐2010 All Rights Reserved v2.0
How Does Design-‐Dead SoEware Smell?
0
5
10
15
20
25
30
35
1 2 3 4 5
Mainten
ance Cost
Release
29 March 2011 32 © ADM 1983-‐2010 All Rights Reserved v2.0
Maintenance/Velocity/Features CorrelaLon
29 March 2011 33 © ADM 1983-‐2010 All Rights Reserved v2.0
34 29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
PSTM (Professional Scrum Team
Member)
PSM (Professional Scrum Master)
PSPO (Professional Scrum Product
Owner)
29 March 2011 © 1993-‐2011 ADM, All Rights Reserved Slide 35
Filling In Scrum’s Holes
Successful SoAware Development
PSD (Professional
Scrum Developer)
Agenda • Basics of Agility • Value Driven Development
• Product Management • Plan a Release • Managing Requirements • Planning Releases • Managing Releases • Managing Products
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 36
Professional Scrum Product Owner course
• Teaches Product Owner how to achieve Agility.
• Complete course rewrite.
• For product managers, program managers, and development managers.
• Assessments and certification.
When Course April 11-‐12
Professional Scrum Product Owner course taught by ken Schwaber in Amsterdam
April 6-‐7 Professional Scrum Master course taught by Ken Schwaber in Brussels
29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 37
Next Step for You!
Register hvp://courses.scrum.org/ Visit hvp://www.scrum.org/
38 29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
QuesLons?
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0
39
Thank you!
Ken Schwaber • ken.schwaber@scrum.org • www.scrum.org
29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 40
Recommended