Framgångsfaktorer för Agil Utveckling av
Mycket Stora Programvaruprodukter
PMI Sweden Chapter
Passion for projects 2013
Sv...
?
Large Products?
Vafalls, Stora
Progamvaruprodukter?
Star Wars - The Old Republic
Lucas Arts, Bioware, Electronic ArtsMicro...
Why Agile?
• Are we and customers happy
with the lead time from idea
to volume deployment?
• Are we and customers happy
wi...
Sales
Volume
10% Efficiency
increase in R&D
10% Increased
speed
(Sales earlier)
R&D (~15%)
Jan Bosch - www.janbosch.com
Th...
Conclusion
• Conformance to original budget is secondary
• Conformance to original scope is secondary
• Time to market and...
The Themes of this Talk
• Look at product development holistically
• All development work is not the same
• Self-organizat...
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
• Qualit...
What is Our Job?
Opportunity
/ Problem
Value /
Solution
Product
management &
Development
Pre-study
Execution
Prestudy
Feas...
Key Ideas
• Focus on flow, customer-to-customer
– Optimize for short end-to-end lead-time
– Stop-the-line mentality regard...
Key Concepts
• End-2-End Cross Functional Teams for Development
• Pull based approach
• Continuous programs rather than fi...
Flow Based Organization
Analysis
Program
Development
Program
- Identify
- Analyze
- Prioritize
- Detail
- Design
- Impleme...
Seen Another Way…
Release Program (Projects)
Meanwhile @ Spotify...
23
Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-s...
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 ...
Low Architectural Impact
Custom Hardware + Firmware
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Driv...
High Architectural Impact
Custom Hardware + Firmware
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Dri...
High Architectural Impact
Custom Hardware + Firmware
OS Extensions
(e.g. Protocols, Scalability, Security etc.)
Device Dri...
Handling the Differences
• Low Architecural Impact
– Single Team with end-to-
end ownership
• High Architectural Impact
– ...
31
http://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.jpg
32
Self-organization
Why do we want Self-organizing
Teams?
33
A team is a group of people with
complementary talents and
skills, aligned to a common objective.
34
It is a Powerful Management Strategy
• End-to-end ownership  Motivation 
Higher quality results
• Local decision making ...
Typical Advice on Self-organization
• Don’t assign roles
• Don’t assign leadership
• Don’t assign tasks
• Don’t say how
36...
37
Foundations
Self-organization
People
Människo
r
Självorganisati
on
Foundations
 Objectives
 Knowledge/Learning
 Communication/Feedback
 Way-of-working/Deci...
Foundations
Självorganisati
on
People
 Motivated individuals
 Group development
39
Motivated Individuals
40
Autonomy
Competence
Relatedness
Self-
Determination
Theory
Self-Determination Theory, Deci and Ry...
Susan Wheelan, Integrated Model of Group Development
Group Development
41
Dependency
and
Inclusion
Counter-
dependency
and...
Grunde
r
Människo
r
Self-organization
 Values
 Results
 Balance
42
43
Balance
Permission to fail
Specialisation
Learning
Centralization
Consensus
Risk/Opportunity
Planning
Analysis
Creativity
...
GUT of Self-organization
45
 Values
 Results
 Balance
 Motivated Individuals
 Groupdevelopment
 Objectives
 Knowled...
Summary
• Focus on end-to-end flow
• Focus on product evolution rather than
running projects
• Distinguish functional enha...
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...
Thanks!
Svante Lidman, Sr Productivity Expert
svante.lidman@hansoft.se
@svante_lidman
www.slideshare.net/SvanteLidman
Licensing of this Presentation
50
The artwork in this presentation is licensed under the terms defined by each
respective ...
Framgångsfaktorer för Agil Utveckling av Mycket Stora Programvaruprodukter
Upcoming SlideShare
Loading in...5
×

Framgångsfaktorer för Agil Utveckling av Mycket Stora Programvaruprodukter

127

Published on

Föreläsning av Senior Productivity Expert Svante Lidman för PMI Sweden Chapter Passion for Projects 2013

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
127
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • -Vadmenar vi med framgångsfaktorer?Vadmenar vi med agilutveckling?Vadmenar vi med programvaruprodukter?Vadmenar vi med mycketstora?Organizations developing large software-intensive products need to look at their software development in a life cycle perspective toget full benefit from adopting agile and lean. Naïve adoption can cause as much damage as benefit. Over the last couple of years I haveworked with several large scale software product development organizations around the world that are in various stages of adoption ofagile/lean practices. These are organizations that involve hundreds of software developers. In this presentation I will talk about typicalchallenges, solution patterns and transition strategies for this kind of development.KEY TAKE AWAY: How to build a large lean/agile software product developmentorganizati on
  • The problem with this is not the ideas or the principles that there is so much terminology and to some extent structure that is somewhat arbitrary. This will typically lead to terminology adoption rather than adoption of principles, annd values/behaviors which is what counts in the end. Remember Continuous Improvement....
  • Här kan vi läsa på i Kandidatuppsatsen
  • -Vadmenar vi med framgångsfaktorer?Vadmenar vi med agilutveckling?Vadmenar vi med programvaruprodukter?Vadmenar vi med mycketstora?Organizations developing large software-intensive products need to look at their software development in a life cycle perspective toget full benefit from adopting agile and lean. Naïve adoption can cause as much damage as benefit. Over the last couple of years I haveworked with several large scale software product development organizations around the world that are in various stages of adoption ofagile/lean practices. These are organizations that involve hundreds of software developers. In this presentation I will talk about typicalchallenges, solution patterns and transition strategies for this kind of development.KEY TAKE AWAY: How to build a large lean/agile software product developmentorganizati on
  • Framgångsfaktorer för Agil Utveckling av Mycket Stora Programvaruprodukter

    1. 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. 2. ?
    3. 3. Large Products? Vafalls, Stora Progamvaruprodukter? Star Wars - The Old Republic Lucas Arts, Bioware, Electronic ArtsMicrosoft Autodesk Ericsson Boeing
    4. 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. 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. 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. 7. The Themes of this Talk • Look at product development holistically • All development work is not the same • Self-organization
    8. 8. Holistically Speaking... 8 http://commons.wikimedia.org/wiki/File:Whole_onion.jpg
    9. 9. What is Our Job? Opportunity / Problem Value / Solution Product management & Development
    10. 10. Feature X What we set out for
    11. 11. Feasability Prestudy Development FeasabilityFeasibility Pre-study The Traditional Way
    12. 12. Feasability Pre-study FeasabilityFeasibility The Traditional Way Development
    13. 13. Construction Test Feasability Pre-study FeasabilityFeasibility The Traditional Way
    14. 14. Construction Test Feasability Pre-study FeasabilityFeasibility The Traditional Way
    15. 15. Test Feasability Pre-study FeasabilityFeasibility The Traditional Way Part NPart 1 …
    16. 16. Test Feasability Pre-study FeasabilityFeasibility The Traditional Way Part NPart 1 … ? ??? ??? ??
    17. 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. 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. 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. 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. 21. Flow Based Organization Analysis Program Development Program - Identify - Analyze - Prioritize - Detail - Design - Implement - Test - Document - Package - Verify - Roll out Release Program (Project)
    22. 22. Seen Another Way… Release Program (Projects)
    23. 23. Meanwhile @ Spotify... 23 Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
    24. 24. 25 http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg
    25. 25. 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
    26. 26. Low Architectural Impact Custom Hardware + Firmware OS Extensions (e.g. Protocols, Scalability, Security etc.) Device Drivers Domain General Domain Specific Application Specific Features
    27. 27. 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
    28. 28. 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
    29. 29. 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
    30. 30. 31 http://centrim.mis.brighton.ac.uk/events/irnop-2007/papers-1/Jarkvik%20et%20al.pdf
    31. 31. http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg 32 Self-organization
    32. 32. Why do we want Self-organizing Teams? 33
    33. 33. A team is a group of people with complementary talents and skills, aligned to a common objective. 34
    34. 34. 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
    35. 35. 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
    36. 36. 37 Foundations Self-organization People
    37. 37. Människo r Självorganisati on Foundations  Objectives  Knowledge/Learning  Communication/Feedback  Way-of-working/Decision making  High standards & expectations 38
    38. 38. Foundations Självorganisati on People  Motivated individuals  Group development 39
    39. 39. Motivated Individuals 40 Autonomy Competence Relatedness Self- Determination Theory Self-Determination Theory, Deci and Ryan
    40. 40. 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
    41. 41. Grunde r Människo r Self-organization  Values  Results  Balance 42
    42. 42. 43
    43. 43. 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
    44. 44. GUT of Self-organization 45  Values  Results  Balance  Motivated Individuals  Groupdevelopment  Objectives  Knowledge/Learning  Communication/Feedback  Way-of-working/Decision making  High standards/Expectations
    45. 45. 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
    46. 46. 47 Frågor på det? http://commons.wikimedia.org/wiki/File:Ostrich2010_2.jpg
    47. 47. 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
    48. 48. Thanks! Svante Lidman, Sr Productivity Expert svante.lidman@hansoft.se @svante_lidman www.slideshare.net/SvanteLidman
    49. 49. 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×