This document discusses factors for successful agile development of large software products. It emphasizes focusing on time to market and quality over original budgets and scopes. Teams should have end-to-end ownership of work to increase motivation and quality. Not all software development is the same, so high and low impact work need different approaches. Self-organizing teams are important if founded on principles like clear objectives, communication, and standards. Development work should focus on continuous flow rather than projects, and distinguish enhancements from architectural changes.

1. Framgångsfaktorer för Agil Utveckling av
Mycket Stora Programvaruprodukter
PMI Sweden Chapter
Passion for projects 2013
Svante Lidman, Senior Productivity Expert
svante.lidman@hansoft.se
@svante_lidman
www.slideshare.net/SvanteLidman

2. ?

3. Large Products?
Vafalls, Stora
Progamvaruprodukter?
Star Wars - The Old Republic
Lucas Arts, Bioware, Electronic ArtsMicrosoft
Autodesk
Ericsson
Boeing

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

5. Sales
Volume
10% Efficiency
increase in R&D
10% Increased
speed
(Sales earlier)
R&D (~15%)
Jan Bosch - www.janbosch.com
The Importance of Speed

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

7. The Themes of this Talk
• Look at product development holistically
• All development work is not the same
• Self-organization

8. Holistically Speaking...
8
http://commons.wikimedia.org/wiki/File:Whole_onion.jpg

9. What is Our Job?
Opportunity
/ Problem
Value /
Solution
Product
management &
Development

10. Feature X
What we set out for

11. Feasability
Prestudy
Development
FeasabilityFeasibility
Pre-study
The Traditional Way

12. Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Development

13. Construction
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way

14. Construction
Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way

15. Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Part NPart 1 …

16. Test
Feasability
Pre-study
FeasabilityFeasibility
The Traditional Way
Part NPart 1 …
?
???
???
??

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

18. What is Our Job?
Opportunity
/ Problem
Value /
Solution
Product
management &
Development
Pre-study
Execution
Prestudy
Feasibility
Technical coordination
Project Leaders Integration Test
Program Management
ALM
FG
PG
BP4
PD1
PD2
PD3
TG1 TG2
TG3
Integration Planning
CCB
Design
Anatomy
Release Strategy
Go-model
Projects
Requirements Baseline
Vision
Resource Planning
Defect-handling
FEAD
1/3
2/3
System
Design
V-Model
PDU
PA
Project Plan
Business Case
CR-handling
War room
Requirements
Management
Steering Group
Contract Management

19. 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 a
forcing function to address impediments to
quality and efficiency
http://commons.wikimedia.org/wiki/File:Bulbgraph.svg

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

21. Flow Based Organization
Analysis
Program
Development
Program
- Identify
- Analyze
- Prioritize
- Detail
- Design
- Implement
- Test
- Document
- Package
- Verify
- Roll out
Release
Program
(Project)

22. Seen Another Way…
Release Program (Projects)

23. Meanwhile @ Spotify...
23
Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

25. 25
http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg

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

27. Low Architectural Impact
Custom Hardware + Firmware
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features

28. High Architectural Impact
Custom Hardware + Firmware
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Drivers
Domain General
Domain Specific
Application Specific
Features
Code
Impact

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

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

31. 31
http://centrim.mis.brighton.ac.uk/events/irnop-2007/papers-1/Jarkvik%20et%20al.pdf

32. http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg
32
Self-organization

33. Why do we want Self-organizing
Teams?
33

34. A team is a group of people with
complementary talents and
skills, aligned to a common objective.
34

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
35
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
36
http://commons.wikimedia.org/wiki/File:Stop_hand_nuvola_alternate.svg

37. 37
Foundations
Self-organization
People

38. Människo
r
Självorganisati
on
Foundations
 Objectives
 Knowledge/Learning
 Communication/Feedback
 Way-of-working/Decision making
 High standards & expectations
38

39. Foundations
Självorganisati
on
People
 Motivated individuals
 Group development
39

40. Motivated Individuals
40
Autonomy
Competence
Relatedness
Self-
Determination
Theory
Self-Determination Theory, Deci and Ryan

41. Susan Wheelan, Integrated Model of Group Development
Group Development
41
Dependency
and
Inclusion
Counter-
dependency
and
Fight
Trust
and
Structure
Work Break up
Child Teenager Young Adult Adult Retirement

42. Grunde
r
Människo
r
Self-organization
 Values
 Results
 Balance
42

43. 43

44. Balance
Permission to fail
Specialisation
Learning
Centralization
Consensus
Risk/Opportunity
Planning
Analysis
Creativity
Fun
44
Expect success
Generalisation
Delivery
Decentralization
Quick/Good decisions
Precision
Improvisation
Action
Quality
Boring

45. GUT of Self-organization
45
 Values
 Results
 Balance
 Motivated Individuals
 Groupdevelopment
 Objectives
 Knowledge/Learning
 Communication/Feedback
 Way-of-working/Decision making
 High standards/Expectations

46. 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. 47
Frågor på det?
http://commons.wikimedia.org/wiki/File:Ostrich2010_2.jpg

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

49. Thanks!
Svante Lidman, Sr Productivity Expert
svante.lidman@hansoft.se
@svante_lidman
www.slideshare.net/SvanteLidman

50. 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 under
Creative Commons Attribution-Share Alike 3.0 Unported license.
See: http://creativecommons.org/licenses/by-sa/3.0/deed.en