My talk at PMI Sweden Congress 2013 on Agile and Large Software Products

560 views
457 views

Published on

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.

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

  • Be the first to like this

No Downloads
Views
Total views
560
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
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
  • My talk at PMI Sweden Congress 2013 on Agile and Large Software Products

    1. 1. Framgångsfaktorer för Agil Utveckling avMycket Stora ProgramvaruprodukterPMI Sweden ChapterPassion for projects 2013Svante Lidman, Senior Productivity Expertsvante.lidman@hansoft.se@svante_lidmanwww.slideshare.net/SvanteLidman
    2. 2. ?
    3. 3. Vafalls, Stora Large Products? Progamvaruprodukter? EricssonAutodesk Boeing Star Wars - The Old RepublicMicrosoft Lucas Arts, Bioware, Electronic Arts
    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. The Importance of Speed Sales Volume 10% Increased speed (Sales earlier) 10% EfficiencyR&D (~15%) increase in R&D Jan Bosch - www.janbosch.com
    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? Product Value /Opportunity management & Solution / Problem Development
    10. 10. What we set out for Feature X
    11. 11. The Traditional Way Pre-study Prestudy Feasability Feasibility Development
    12. 12. The Traditional Way Pre-study Feasability Feasibility Development
    13. 13. The Traditional Way Pre-study Feasability Feasibility Construction Test
    14. 14. The Traditional Way Pre-study Feasability Feasibility Construction Test
    15. 15. The Traditional Way Pre-study Feasability FeasibilityPart 1 … Part N Test
    16. 16. The Traditional Way Pre-study ? Feasability Feasibility ? ? ?Part 1 ? … ? Part N ? ? ? Test
    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 gamesClaim: The fragmentation of value(work)is the single most important root cause for these issues
    18. 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. 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 ownershiphttp://commons.wikimedia.org/wiki/File:Stock_keyring.svg
    21. 21. Flow Based OrganizationAnalysis DevelopmentProgram Program - Detail- Identify Release - Design- Analyze - Implement- Prioritize Program - Test (Project) - Document - Package - Verify - Roll out
    22. 22. Seen Another Way…Release Program (Projects)
    23. 23. Meanwhile @ Spotify... 23Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
    24. 24. http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg 25
    25. 25. 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
    26. 26. Low Architectural Impact Features Application Specific Domain Specific Domain General OS Extensions (e.g. Protocols, Scalability, Security etc.) Device Drivers Custom Hardware + Firmware
    27. 27. 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
    28. 28. 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
    29. 29. 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
    30. 30. 31http://centrim.mis.brighton.ac.uk/events/irnop-2007/papers-1/Jarkvik%20et%20al.pdf
    31. 31. Self-organization 32http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg
    32. 32. Why do we want Self-organizing Teams? 33
    33. 33. A team is a group of people with complementary talents andskills, 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 35http://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. Self-organization People Foundations 37
    37. 37.  Objectives Knowledge/Learning Communication/Feedback Självorganisati Way-of-working/Decision making on High standards & expectations Människo r Foundations 38
    38. 38.  Motivated individuals Group development Självorganisati on People Foundations 39
    39. 39. Motivated Individuals CompetenceAutonomy Relatedness Self- Determination Theory Self-Determination Theory, Deci and Ryan 40
    40. 40. Group Development Child Teenager Young Adult Adult Retirement Counter- Dependency Trust dependency and and Work Break up and Inclusion Structure FightSusan Wheelan, Integrated Model of Group Development 41
    41. 41. Self-organization Människo Values r Results Grunde Balance r 42
    42. 42. 43
    43. 43. BalancePermission to fail Expect success Specialisation Generalisation Learning Delivery Centralization Decentralization Consensus Quick/Good decisionsRisk/Opportunity Precision Planning Improvisation Analysis Action Creativity Quality Fun Boring 44
    44. 44. GUT of Self-organization Values Results Balance Motivated Individuals Groupdevelopment Objectives Knowledge/Learning Communication/Feedback Way-of-working/Decision making High standards/Expectations 45
    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. Frågor på det? 47http://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 Expertsvante.lidman@hansoft.se@svante_lidmanwww.slideshare.net/SvanteLidman
    49. 49. Licensing of this PresentationThe artwork in this presentation is licensed under the terms defined by eachrespective source as indicated on each respective slide. If no source isgiven, then the artwork is in the public domain.Trademarks and books, depicted in the presentation are owned by therespective tradmark owner and are only included for reference purposes andis not in any way an endorsement of the presentation contents. If you make use of this material in whole or part, you should clearly statethe 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 50

    ×