Lessons learned from scaling Agile
Download as PPTX, PDF4 likes560 views
The document discusses lessons learned from scaling agile within organizations, emphasizing the importance of understanding the system of work, developing internal agile services, and cautioning against relying solely on frameworks. It highlights that scaling agile can be effective both in product development and organizational contexts, but also warns about potential side effects of increasing resources without proper management. Key takeaways include the need for a holistic approach and continuous improvement to enhance agile practices.
Lessons learned from scaling Agile
- 1. Lessons learned from scaling Agile Juhana Huotarinen
- 2. Juhana Huotarinen • Gofore Plc • Currently: Agile transformation advisor • Previously: Software developer, project manager, project director & executive committee member • Twitter: @juhanaOne • Blogs: www.linkedin.com/in/juhana- huotarinen @JuhanaOne
- 3. GOFORE PLC Software development, design, management and cloud services consultancy • Established in 2001 • Turnover in 2018 50 M€ (+49%) • Around 600 employees Financially solid and stable • Strong yearly growth of >10% for the past 12 years • Publicly listed since November 2017 Offices in Helsinki, Tampere, Jyväskylä, Turku, Swansea, Munich, Madrid, London and Tallinn
- 4. What does it mean to “scale Agile”? @JuhanaOne https://www.forbes.com/sites/stevedenning/2016/04/15/what-does-it-mean-to-scale-agile/#36e8291678b9 PRODUCTDELIVERY SCALING PRODUCT ORGANISATIONAL SCALING PLATFORM HORIZONTAL VERTICAL Product TeamTeam Team Platform/Suite Team Product Team Team Team Product Team TeamTeam Product Team Team HR IT Sale s ETC.
- 5. Lessons learned #1 - understand the system @JuhanaOne
- 6. Stay close to where the work happens @JuhanaOne vs.
- 7. 360 Organisational Competences Method / Process Psychosocial @JuhanaOne Take a holistic approach
- 8. Survey example 1. I know the project vision 2. We are delivering working, tested software every 4 weeks or less 3. We are delivering what the business needs most 4. Our process is continuously improving 5. The team has a product owner who is empowered, has knowledge to prioritise and has direct contacts with the team and stakeholders 6. Our product backlog is in a good shape (clear, manageable, prioritised by the Product Owner) 7. The team respects Definition of Done 8. Agile ceremonies are working effectively 9. Our estimation method works well
- 9. Competence matrix example Backend development Frontend development DevOps practices Agile practices Team 1 (average) • Person 1 • Person 2 • Person 3 Team 2 (average) • Person 1 • Person 2 @JuhanaOne
- 10. Lessons learned #2: Build an internal Agile service @JuhanaOne Agile coaches Vision Value proposition Key metrics Scope Constraints …
- 11. Services available @JuhanaOne • Agile methodologies, practices and tools • Building self-organising teams • Support for product development • Problem solving and facilitation • Software development practices • Organisational changes
- 12. @JuhanaOne Lessons learned #3 frameworks are for lazy organisations
- 13. @JuhanaOne
- 14. SAFe - Scaled Agile Framework LeSS - Large-ScaleScrum Spotify Model Nexus SoS - Scrum of Scrum DAD - Disciplined Agile Delivery Scrum at Scale Enterprise Scrum DSDM - Dynamic Systems Development Method Crystal Family Continuous Agile Framework Enterprise Agile Delivery and Agile Governance Practice Enterprise Transition Framework eXponential Simple Continuous Autonomous Learning FAST Agile Lean Enterprise Agile Framework MEGA Framework RAGE - Recipes for Agile Governance in the Enterprise ScALeD Agile Lean Development The Gill Framework
- 15. Scaling frameworks @JuhanaOne Scaling frameworks are operating only in the Product or Platform space
- 16. Case Basecamp • Planning / prototype phase • Six-week cycles • One feature / cycle • No backlogs • A few well-shaped, risk-reduced options • Tasks are not used for showing the progress • ”Hill chart” approach This works on Basecamp @JuhanaOne https://basecamp.com/shapeup
- 17. Lessons learned #4: Beware of side effects @JuhanaOne Adding more resources doesn’t necessarily mean increasing output
- 18. Alcohol price Addicts + – Money needed to support the habit @JuhanaOne
- 19. Costs Work rate (# tasks/week) Project completion date +– + + Productivity Goal Add more developers to the project Time for new development work #Task in progress Out of sequence work Work quality Rework + + –– – + Time for training and support + – – Communication & coordination overhead + Motivation– +
- 20. Conclusion @JuhanaOne You can scale Agile through a product development and an organisational space Lessons Learned 1. Understand the system 2. Build an internal Agile service 3. Frameworks are for lazy organisations 4. Beware of side effects
- 23. @JuhanaOne Juhana & the Swansea Crew
Editor's Notes
- #3: Almost 15 years at Gofore Agile Coach & Sctum Master Ramping up Agile capability Previlously developer and some management positions Twitter: Blogs
- #4: You can raise your hand if you know gofore Our mission is to change the world for the better THROUGH DIGITALISATION BY RENEWING WAYS OF WORKING We have services in all areas when it comes to transforming the organization Stats Profitable Operate 5 countries You recognize us from our t-shirts
- #5: different meanings of scaling. Left – up = simple type of scaling relating to the scaling of the practices of Agility across multiple team Right – up = multiple products that were part of a suite of products (“Platform”) Left – down = how do we take the concepts of Agility into different segments of the organization Left –right = move up the chain of command, dealing with the director and VP positions and the C-suite
- #6: System conditions when we are driving changes, systems conditions push back orginally designed to help the organisation Before you start chancing/scaling things, try to understand how the system works What processes the organisation has, how they communicate, what are roles, teams, responsibilities Try to understand the organisation /project domain. Not the product domain
- #7: Chris Coleman How work works Close to team Close to product owner Close to end-users Close to customers Close to steering groups Close to development practises Close to impediments
- #8: Tool for an interventionist Cgha Organisational approach structures, roles, teams, contracts, vendors Competences Technical excellence, product quality, team competences, business competences Method / process Agile practises, standards, tools, working agreements, metrics Psychosocial people feel, fear motivation Collaboration, interactions motivation, goals, hidden agendas
- #9: One survey excample. To understand the method / process
- #10: Result of the survey / workshop Make your team comperences visible
- #11: Create an internal agile service Backlog, weekly tasks etc Helps to focus essential If you have many agile coaches Dont get confused with Scrum of scums. it is typically just for reporting
- #12: Define your agile service scope Provide those services continously
- #13: SWARMing:Scaling Without A Religious Methodology
- #14: Define your agile service scope Provide those services continously
- #15: Why there is so many frameworks available 20
- #16: Many organisations are service organisations, not product development organisations
- #19: Systems thinking – is a method to analyse the relationships between the system's parts to understand the potential for better decision-making Coordinate system Causal links – one way to implement systems thinking. to visualise the ongoing dynamic interaction between elements Positive polarity Two variables move in the same direction Births population Negative polarity Two variables move in the opposite direction Deaths population
- #21: Rhossili Bay
- #22: https://www.mentimeter.com/s/f502f1f8132516811bae15bb46b7a649/da4fe5321a50/edit