The document discusses success factors for agile development of large software products, emphasizing the importance of speed, product quality, and R&D efficiency. It highlights the need for a holistic view of product development, with self-organizing teams and continuous integration to enhance flow and reduce time to market. Challenges identified include fragmentation of work and communication issues, with a call for optimizing processes to improve overall outcomes.

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. Vafalls, Stora
Large Products?
Progamvaruprodukter?
Ericsson
Autodesk
Boeing
Star Wars - The Old Republic
Microsoft Lucas Arts, Bioware, Electronic Arts

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. The Importance of Speed
Sales
Volume 10% Increased
speed
(Sales earlier)
10% Efficiency
R&D (~15%) increase in R&D
Jan Bosch - www.janbosch.com

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?
Product Value /
Opportunity management & Solution
/ Problem
Development

10. What we set out for
Feature X

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

12. The Traditional Way
Pre-study
Feasability
Feasibility
Development

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

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

15. The Traditional Way
Pre-study
Feasability
Feasibility
Part 1 … Part N
Test

16. The Traditional Way
Pre-study
?
Feasability
Feasibility
? ? ?
Part 1 ? … ? Part N
? ? ?
Test

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

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 Development
Program Program
- Detail
- Identify Release - Design
- Analyze - Implement
- Prioritize
Program
- Test
(Project) - Document
- Package
- Verify
- Roll out

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. http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg
25

26. All Software is not the Same
Features
Application Specific
Domain Specific
Domain General
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Drivers
Custom Hardware + Firmware

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

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

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

30. Handling the Differences
• Low Architecural Impact • High Architectural Impact
– Single Team with end-to- – Many teams
end ownership – 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. Self-organization
32
http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg

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. Self-organization
People
Foundations
37

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

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

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

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

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

43. 43

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

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

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. Frågor på det?
47
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
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
50