Agile at Large Scale - Conference at Agile Tour Brussels
ā¢Download as PPTX, PDFā¢
12 likesā¢2,339 views
This document discusses agile practices at a large scale project. It summarizes the challenges faced when initially implementing agile on a large, distributed project with 7 teams. Key lessons learned include visualizing the entire value stream, establishing rituals to coordinate large numbers of teams, focusing on continuous integration and quality, adapting practices like planning to the flow-based nature of large projects, using metrics to steer the project, and continuously improving tools and processes. The document provides recommendations in each of these areas to successfully implement agile at large scale.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to Agile at Large Scale - Conference at Agile Tour Brussels
Similar to Agile at Large Scale - Conference at Agile Tour Brussels (20)
Recently uploaded
Recently uploaded (20)
Agile at Large Scale - Conference at Agile Tour Brussels
- 1. Agile at Large Scale A Return on Experience from a Large Project 1 Ā© OCTO 2012
- 2. Who we are Mathieu DespriĆ©e ā Senior Architect @mdeocto HervĆ© Lourdin ā Project Director, @HerveLourdin Lean & Agile practice leader 2 Ā© OCTO 2012
- 3. Hypothesis You are not new with Agile You know what mean: User Story Story Point TDD Continuous Integration Retrospective You know SCRUM 3 Ā© OCTO 2012
- 4. We will focus on differences we noticed at large scale 4 Ā© OCTO 2012
- 5. Project context Wish to create a new innovative product New Technologies, New Architecture Touch screen for front office Web for the back office Strategic project for the company 9500 customers 5 M of sales transactions per day targeted Chosen Methodology: SCRUM 5 Ā© OCTO 2012
- 6. After 6 months of development This 1st agile experiment at large scale burns lot of project management resources The 7 distributed teams have difficulties to integrate their respective developments UA phases are painful because of unstable software A first major version is awaited by the market 6 months later 6 Ā© OCTO 2012
- 7. Agenda Create The Flow Quality At Large Scale Adapt Yourself To The Flow Steering The Flow Improve 7 Ā© OCTO 2012
- 8. 1 CREATE THE FLOW 8 Ā© OCTO 2012
- 9. CREATE THE FLOW Visualize The Flow Rituals At Large Scale Cadence 9 Ā© OCTO 2012
- 10. CREATE THE FLOW Visualize The Flow Rituals At Large Scale Cadence 10 Ā© OCTO 2012
- 11. TODO WIP DONE 11 Ā© OCTO 2012
- 12. At large scale, the Value Stream must be detailed Upstream & Downstream of the development phase 12 Ā© OCTO 2012
- 13. ā¦with an electronic version for geo-distributed teams 13 Ā© OCTO 2012
- 14. CREATE THE FLOW Visualize The Flow Rituals At Large Scale Cadence 14 Ā© OCTO 2012
- 15. Team Lead Tech Lead Dev. Tester Methodological Coach Team ambassadors Ops 15 Ā© OCTO 2012
- 16. Team Test Ops Support CTO Leaders Leader Leader Leader Problems Only 16 Ā© OCTO 2012
- 17. Multi-site demo France 3 teams Moldavia 3 teams Romania 1 team Vietnam 2 teams Skype Mikogo 17 Ā© OCTO 2012
- 18. CREATE THE FLOW Visualize The Flow Rituals At Large Scale Cadence 18 Ā© OCTO 2012
- 19. Iteration Cost Model Costs Coordination & Steering Transaction Value Added Work Transaction Cost Cost Time Iteration beginning Iteration end *Source : David Anderson 19 Ā© OCTO 2012
- 20. Iteration Cost Model Costs ~6 FTE Coordination & Steering Transaction Value Added Work Transaction Cost Cost 1 1 week week Time Iteration beginning TOTAL : 4 to 5 weeks Iteration end *Source : David Anderson 20 Ā© OCTO 2012
- 21. The Lack Of FEED BACK 21 Ā© OCTO 2012
- 22. On The Project Costs ~6 FTE Coordination & Steering Transaction Value Added Work Transaction Cost Cost 1 1 week week Failure Load Time Iteration beginning TOTAL : 4 to 5 weeks Iteration end *Source : David Anderson 22 Ā© OCTO 2012
- 23. Objective : 2 weeks Costs ~6 FTE Coordination & Steering Value Added Work Transaction Cost 1 1 day week Failure Load Time Iteration beginning Iteration end *Source : David Anderson 23 Ā© OCTO 2012
- 24. Agenda Create The Flow Quality At Large Scale Adapt Yourself To The Flow Steering The Flow Improve 24 Ā© OCTO 2012
- 25. 2 QUALITY AT LARGE SCALE 25 Ā© OCTO 2012
- 26. Only one Continuous Integration Site 2 45 Developers Site 1 Site 3 100 commits/day on Trunk SVN Build + Unit Tests every 3 min Continuous Integration Jenkins/Maven 26 Ā© OCTO 2012
- 27. You Gonna Have To Test All That ! 27 Ā© OCTO 2012
- 28. Specifying with Acceptance Tests sd 28 Ā© OCTO 2012
- 29. Specifying with Acceptance Tests 29 Ā© OCTO 2012 29
- 30. STOP THE LINE 30 Ā© OCTO 2012
- 31. Software Factory Developers Site 2 Site 1 Site 3 SVN Business Green Pepper Analysts Continuous Integration Jenkins/Maven 31 Ā© OCTO 2012
- 32. 32 Ā© OCTO 2012
- 33. You Build it? You Fix it! 33 Ā© OCTO 2012
- 34. 2 weeks !! Costs Coordination & Steering Value Added Work 1 0,5 day day Failure Load Time Iteration beginning 2 weeks Iteration end 34 Ā© OCTO 2012
- 35. Agenda Create The Flow Quality At Large Scale Adapt Yourself To The Flow Steering The Flow Improve 35 Ā© OCTO 2012
- 36. 3 ADAPT YOURSELF 36 TO THE FLOW Ā© OCTO 2012
- 37. BETTER TO PUMP EVEN IF NOTHING HAPPENS THAN TO RISK SOMETHING WORSE HAPPENING BY NOT PUMPING 37 Ā© OCTO 2012
- 38. Sprint Planning Costs Coordination & Steering Value Added Work 1 0,5 day day Failure Load Time Iteration beginning Iteration end 38 Ā© OCTO 2012
- 39. 39 Ā© OCTO 2012
- 40. Sprint planning Costs Coordination & Steering Value Added Work Time Iteration beginning Iteration end 40 Ā© OCTO 2012
- 41. Migrating to āPureā Flow : Gains More adaptability for the PO: continuous planning Teams estimate āon the flyā It is not necessary to calculate āhow much we can do for this iterationā Stories canāt be āhalf doneā anymore 41 Ā© OCTO 2012
- 42. Migrating to āPureā Flow : Warnings No more sprint planning does not mean no rituals anymore: Demo are still needed and, Retrospectives are mandatory! No iterative planning anymore but you need to check continuously the buffers 42 Ā© OCTO 2012
- 43. Product Requirement Validation on DONE Backlog (using tests) the fly Acceptance & in PROD Dev Infra gtw BUFFER BUFFER BUFFER (perf, sĆ©cuā¦) CHECK POTENTIAL FLOW DISRUPTIONS 43 Ā© OCTO 2012
- 44. Migrating to āPureā Flow : Warnings Ā« With Great Power, comes Great Responsibility Ā» Benjamin Ā« Ben Ā» Parker P.O. must be constantly available to support teams on: Planning Business / Functional questions 44 Ā© OCTO 2012
- 45. Component Teams 45 Ā© OCTO 2012
- 46. Component Teams FEATURE 1 Team A Component A Front Office FEATURE 2 FEATURE 3 Team B Component B FEATURE 4 Exchanges FEATURE 5 FEATURE 6 Team C Component C Back Office FEATURE 7 FEATURE 8 FEATURE 9 Team D Component D Batches FEATURE 10 46 Ā© OCTO 2012
- 47. Component Teams FEATURE 1 Team A Component A Front Office FEATURE 2 FEATURE 3 Team B Component B FEATURE 4 Exchanges FEATURE 5 FEATURE 6 Team C Component C Back Office FEATURE 7 FEATURE 8 FEATURE 9 Team D Component D Batchs FEATURE 10 47 Ā© OCTO 2012
- 48. Component Teams FEATURE 1 Team A Component A Front Office FEATURE 2 FEATURE 3 Team B Component B FEATURE 4 Exchanges FEATURE 5 FEATURE 6 Team C Component C Back Office FEATURE 7 FEATURE 8 FEATURE 9 Team D Component D Batchs FEATURE 10 48 Ā© OCTO 2012
- 49. Feature Teams FEATURE 1 Tobacco Component A FEATURE 4 Team FEATURE 5 Demat. Component B FEATURE 3 Team FEATURE 6 FEATURE 8 Press Component C Team FEATURE 9 FEATURE 2 Telecom Component D FEATURE 7 Team 49 Ā© OCTO 2012
- 50. Cross-Techno Team Developers Tester Team Leader 50 Ā© OCTO 2012
- 51. Feature Teams: Gains Create expertise on business and Give autonomy: Team / Team members should be able to take decision by themselves Teams can live at their own pace if required by their backlog priorization 51 Ā© OCTO 2012 51
- 52. Feature Team As a counterpartā¦ 52 Ā© OCTO 2012 52
- 53. Feature Teams FEATURE 1 Tobacco Component A FEATURE 4 Team FEATURE 5 Demat. Component B FEATURE 3 Team FEATURE 6 FEATURE 8 Press Component C Team FEATURE 9 FEATURE 2 Telecom Component D FEATURE 7 Team 53 Ā© OCTO 2012
- 54. Communities of Practice 54 Ā© OCTO 2012
- 55. Community of Practice A necessary counterbalance to feature-teams The practice leader is a senior developer, who : is in charge of the component architecture makes sure that software is built the correct way facilitates the sharing of practices 55 Ā© OCTO 2012
- 56. The Standard āStandard is the best-known practice, in the project team at the present day, to realise a certain type of taskā 56 Ā© OCTO 2012
- 57. Hands On 57 Ā© OCTO 2012
- 58. Collaborative Design 58 Ā© OCTO 2012
- 59. Todayās organisation Facilitation & methodology PRACTICE LEADERS Release management .NET Java Tests Business FEATURE-TEAMS LEADERS Area A Business Area B Business Area C 59 Ā© OCTO 2012
- 60. Agenda Create The Flow Quality At Large Scale Adapt Yourself To The Flow Steering The Flow Improve 60 Ā© OCTO 2012
- 61. 4 STEERING THE FLOW 61 Ā© OCTO 2012
- 62. The Story Map, our Roadmap 62 Ā© OCTO 2012
- 63. Story Points 63 Ā© OCTO 2012
- 64. Story Points 64 Ā© OCTO 2012
- 65. 65 Ā© OCTO 2012
- 66. idea from Jeff Patton Ā© OCTO 2012 66
- 67. Cumulative Flow Diagram (CFD) 250 200 INPUT QUEUE STUDY DEV - WIP STUDY DEV - DONE number of items 150 VALIDATION - TODO VALIDATION - WIP Lead Time < 2 weeks DONE - WAIT JAVA DONE - WIP JAVA 100 In Process : 15 User Stories DONE - IN CI DONE - DONE Lead Time = 6 weeks CANCELLED 50 In Process : 30 User Stories 0 09/08ā¦ 11/08ā¦ 13/08ā¦ 17/08ā¦ 19/08ā¦ 23/08ā¦ 25/08ā¦ 27/08ā¦ 31/08ā¦ 02/09ā¦ 06/09ā¦ 08/09ā¦ 10/09ā¦ 14/09ā¦ 16/09ā¦ 20/09ā¦ 22/09ā¦ 24/09ā¦ 28/09ā¦ 30/09ā¦ 04/10ā¦ 06/10ā¦ 08/10ā¦ 12/10ā¦ 14/10ā¦ 18/10ā¦ 20/10ā¦ 21/10ā¦ 25/10ā¦ 27/10ā¦ 29/10ā¦ time 67 Ā© OCTO 2012
- 68. Lead Time Distribution 13 12 Average = 11 Ļ = 12 11 n = 106 10 9 8 Occurences 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 days S M L XL 68 Ā© OCTO 2012
- 69. 69 Ā© OCTO 2012 Defects (20%) Features (50%) Improvements (30%) http://www.windhamsportspages.com/images/highschool/swimming/2008/122708/boy s/DSC_0779.gif
- 70. Metrics as of today Delivery: Every month: one major release Every week: one minor release Lead-time: DEV Q/A PROD M 4 weeks 4 to 6 weeks 10 WEEKS DEV Q/A PROD L 6 weeks 6 to 8 weeks 14 WEEKS 70 Ā© OCTO 2012
- 71. Agenda Create The Flow Quality At Large Scale Adapt Yourself To The Flow Steering The Flow Improve 71 Ā© OCTO 2012
- 72. 5 IMPROVE 72 Ā© OCTO 2012
- 73. Continuous Improvement Improve your tools Manage problems 73 Ā© OCTO 2012
- 74. Continuous Improvement Improve your tools Manage problems 74 Ā© OCTO 2012
- 75. 75 Ā© OCTO 2012
- 76. DevOps Collaboration Share your toys ! 76 Ā© OCTO 2012 76
- 77. Software Factory ā¢ A totally automated build and Site 2 deployment pipeline Site 1 Site 3 ā¢ Deployment to server and terminals in one single click, whatever the target environment SVN ā¢ More than 100 deployment to production in 18 months Business Green Analysts Pepper Jenkins Dev Q/A Automated PROD deployment Ops (chef) 77 Ā© OCTO 2012
- 78. Technical and Business Metrics as Feedback Loop Business Transactions Customer Creations ā¬ Mbps Load Connected clients 78 Ā© OCTO 2012
- 79. Continuous Improvement Improve your tools Manage problems 79 Ā© OCTO 2012
- 80. Donāt shoot the messenger ! 80 Ā© OCTO 2012
- 81. Establish a trust culture 81 Ā© OCTO 2012
- 83. YOU SAY IT ? YOU OWN IT ! 83 Ā© OCTO 2012
- 84. Team Leaders meeting Every week with CTO, team leaders, tech leaders, ops ā¦ Not a planning meeting Open Agenda: We share things that matter Problems Needs Risks Information etcā¦ And ā¦ improvement ideas! 84 Ā© OCTO 2012
- 85. ! CONCLUSIONS 85 Ā© OCTO 2012
- 86. Status after 18 months (more than 40 iterations !) 2500 customers on production systems, with a growth of 400 new per month Teams assimilated business and technical knowledge, and methodology Deployment rythm is sustained, deadlines are met A collaboration hand in hand Dev and Ops An actual collaboration between marketing team, and technical teams People saying they wouldnāt go back 86 Ā© OCTO 2012
- 87. Key factors of success Get control over the value production flow Give autonomy and responsabilities to people High trust culture Continuous Improvement Thereās no magical Agile recipe : youāll have to adapt yourself continuously 87 Ā© OCTO 2012
- 88. ? QUESTIONS / ANSWERS 88 Ā© OCTO 2012