my talk at pmi sweden congress 2013 on agile and large software products
DESCRIPTION
This is my "Success Factors for Agile Development of Very Large Software Products" as it was presented at the PMI Sweden Congress on March 11 2013. The title of the presentation is in Swedish but the material is almost completely in English.TRANSCRIPT
Framgångsfaktorer för Agil Utveckling av Mycket Stora ProgramvaruprodukterPMI Sweden ChapterPassion for projects 2013
Svante Lidman, Senior Productivity [email protected]@svante_lidmanwww.slideshare.net/SvanteLidman
?
Large Products?Vafalls, Stora Progamvaruprodukter?
Star Wars - The Old RepublicLucas Arts, Bioware, Electronic ArtsMicrosoft
Autodesk
Ericsson
Boeing
Why Agile?
• Are we and customers happy with the lead time from idea to volume deployment?
• Are we and customers happy with product quality?
• Are we happy with R&D efficiency?
• What will our situation look like tomorrow if we continue as we do?
SalesVolume
10% Efficiency increase in R&D
10% Increased speed
(Sales earlier)
R&D (~15%)
Jan Bosch - www.janbosch.com
The Importance of Speed
Conclusion
• Conformance to original budget is secondary• Conformance to original scope is secondary• Time to market and Quality is key!!
http://commons.wikimedia.org/wiki/File:PenroseTriangle.png
The Themes of this Talk
• Look at product development holistically• All development work is not the same• Self-organization
Holistically Speaking...
8
http://commons.wikimedia.org/wiki/File:Whole_onion.jpg
What is Our Job?
Opportunity / Problem
Value /Solution
Product management &Development
Feature X
What we set out for
Feasability
Prestudy
Development
FeasabilityFeasibility
Pre-study
The Traditional Way
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Development
Construction
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Construction
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Part NPart 1 …
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Part NPart 1 …
?
???
???
??
Common Challenges
• Time slicing of people• Handovers of documents resulting in distortion• Coordination issues • Quality issues uncovered too late• Lead-time too long• Very few people understand the overall system• Too many meetings• Blame games
Claim: The fragmentation of value(work)is the single most important root cause for these issues
What is Our Job?
Opportunity / Problem
Value /Solution
Product management &Development
Pre-study
Execution
Prestudy
Feasibility
Technical coordinationProject Leaders Integration Test
Program Management
ALM
FG
PG
BP4
PD1
PD2
PD3
TG1 TG2
TG3
Integration PlanningCCB
Design
Anatomy
Release Strategy
Go-model
Projects
Requirements Baseline
VisionResource Planning
Defect-handling
FEAD
1/3
2/3
System
Design
V-Model
PDU
PA
Project Plan
Business Case
CR-handling
War room
RequirementsManagement
Steering Group
Contract Management
Key Ideas
• Focus on flow, customer-to-customer– Optimize for short end-to-end lead-time – Stop-the-line mentality regarding faults
• This will expose inefficiencies and force:– Removal of handovers– Removal of overly detailed studies
and gold-plated designs– Removal of late and non-repeatable testing
• The focus on flow and lead-time will act as aforcing function to address impediments toquality and efficiency
http://commons.wikimedia.org/wiki/File:Bulbgraph.svg
Key Concepts• End-2-End Cross Functional Teams for Development• Pull based approach• Continuous programs rather than finite projects• Continuous Integration (and Testing)
– Automated, continuous, fast and reliable feedback to teams• Requirement Areas (RA) as scaling concept
– Yearly budgeting (in terms of teams) per RA coupled to business strategy– Independent prioritization per RA– Limits competence challenge for Teams without code ownership
http://commons.wikimedia.org/wiki/File:Stock_keyring.svg
Flow Based OrganizationAnalysisProgram
DevelopmentProgram
- Identify- Analyze- Prioritize
- Detail- Design- Implement- Test- Document
- Package- Verify- Roll out
ReleaseProgram(Project)
Seen Another Way…
Release Program (Projects)
Meanwhile @ Spotify...
23Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
25
http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg
All Software is not the Same
Custom Hardware + Firmware
OS Extensions (e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features
Low Architectural Impact
Custom Hardware + Firmware
OS Extensions (e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features
High Architectural Impact
Custom Hardware + Firmware
OS Extensions (e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features
CodeImpact
High Architectural Impact
Custom Hardware + Firmware
OS Extensions (e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features
Test Impact
Handling the Differences
• Low Architecural Impact– Single Team with end-
to-end ownership
• High Architectural Impact– Many teams– PO team– Anatomy to support vision
and rolling planning– May require pure test teams– Traps:
• Planning too much upfront• Locking down the plan• Disempowering the teams
30
31http://centrim.mis.brighton.ac.uk/events/irnop-2007/papers-1/Jarkvik%20et%20al.pdf
http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg32
Self-organization
33
Why do we want Self-organizing Teams?
34
A team is a group of people with complementary talents and skills, aligned to a common objective.
35
It is a Powerful Management Strategy
• End-to-end ownership Motivation Higher quality results
• Local decision making Adaptability Results more fit for purpose
• No hand-overs Reduced time-to-market
http://commons.wikimedia.org/wiki/File:Tic_tac_toe.svg
36
Typical Advice on Self-organization
• Don’t assign roles• Don’t assign leadership• Don’t assign tasks• Don’t say how
http://commons.wikimedia.org/wiki/File:Stop_hand_nuvola_alternate.svg
37
Foundations
Self-organization
People
38
Människor
Självorganisation
Foundations
Objectives Knowledge/Learning Communication/Feedback Way-of-working/Decision making High standards & expectations
39
Foundations
Självorganisation
People
Motivated individuals Group development
40
Motivated Individuals
Autonomy
Competence
Relatedness
Self-Determination
Theory
Self-Determination Theory, Deci and Ryan
41
Susan Wheelan, Integrated Model of Group Development
Group Development
Dependencyand
Inclusion
Counter-dependency
andFight
Trustand
StructureWork Break up
Child Teenager Young Adult Adult Retirement
42
Grunder
Människor
Self-organization
Values Results Balance
43
Committment
Trust
Openness
Respect
Courage
Communication
Feedback Simplicity
Honesty Transparency
Authenticity
Accountability
44
Balance
Permission to failSpecialisation
LearningCentralization
ConsensusRisk/Opportunity
PlanningAnalysis
CreativityFun
Expect successGeneralisationDeliveryDecentralizationQuick/Good decisionsPrecisionImprovisationActionQuality
Boring
45
GUT of Self-organization
Values Results Balance
Motivated Individuals Groupdevelopment
Objectives Knowledge/Learning Communication/Feedback Way-of-working/Decision making High standards/Expectations
Summary
• Focus on end-to-end flow• Focus on product evolution rather than
running projects• Distinguish functional enhancements from
architectural evolution• Foster self-organization consciously
46
47
Frågor på det?
http://commons.wikimedia.org/wiki/File:Ostrich2010_2.jpg
Selected References• Creating Effective Teams (Wheelan) - http://
www.amazon.com/Creating-Effective-Teams-Members-Leaders/dp/1452217076/ref=sr_1_1?s=books&ie=UTF8&qid=1362513243&sr=1-1&keywords=susan+wheelan
• Agile Software Requirements (Leffingwell) - http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841/ref=sr_1_1?s=books&ie=UTF8&qid=1362513353&sr=1-1&keywords=leffingwell
• Drive (Pink) - http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_2?s=books&ie=UTF8&qid=1362513408&sr=1-2&keywords=dan+pink
• Corps Business (Freedman) - http://www.amazon.com/Corps-Business-Management-Principles-Marines/dp/0066619793/ref=sr_1_1?s=books&ie=UTF8&qid=1362513452&sr=1-1&keywords=corps+business+the+30+management+principles+of+the+u.s.+marines
• The Principles of Product Development Flow (Reinertsen) - http://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?s=books&ie=UTF8&qid=1362513506&sr=1-1&keywords=reinertsen
• Scaling Lean & Agile Development (Larman) - http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_1?s=books&ie=UTF8&qid=1362513556&sr=1-1&keywords=larman+vodde
• The System Anatomy (Taxén ed.) - http://www.amazon.com/System-Anatomy-Lars-Taxen/dp/9144070748/ref=sr_1_3?s=books&ie=UTF8&qid=1362513689&sr=1-3&keywords=lars+taxen
• The Essence of Software Engineering (Jacobson, Ng, McMahon, Spence, Lidman) - http://www.amazon.com/The-Essence-Software-Engineering-Applying/dp/0321885953
Thanks!
Svante Lidman, Sr Productivity [email protected]@svante_lidmanwww.slideshare.net/SvanteLidman
Licensing of this Presentation
50
The artwork in this presentation is licensed under the terms defined by each respective source as indicated on each respective slide. If no source is given, then the artwork is in the public domain.
Trademarks and books, depicted in the presentation are owned by the respective tradmark owner and are only included for reference purposes and is not in any way an endorsement of the presentation contents.
If you make use of this material in whole or part, you should clearly state the source.
All original art work and the presentation as such is is licensed underCreative Commons Attribution-Share Alike 3.0 Unported license.See: http://creativecommons.org/licenses/by-sa/3.0/deed.en