Scrum day scaled agile - wolfgang hilpert - sascha gessler
1 like2,212 views
This document summarizes Sophos' transition to scaled agile practices from 2015-2016. It describes challenges with predictability and transparency in their previous process. Their goals for agile transformation included planning in 3 month cycles with 2 week sprints. Key insights included giving teams new experiences, aiming for feature teams, and investing in engineering excellence long-term. Scaling agile helped with alignment, quality, agility across teams, and continuous improvement.
Scrum day scaled agile - wolfgang hilpert - sascha gessler
- 1. 1 Sascha Gessler, wibas GmbH Wolfgang Hilpert, Sophos Technologies GmbH Scaled Agile @ Sophos: Eine lebendige Geschichte Enterprise Agility, agile Transformation, Erfahrungsberichte
- 3. April 2015 June 2016 You‘re good? So are we. Then lets start! Context
- 4. 4 Sophos Snapshot 1985 FOUNDED OXFORD, UK $450M IN FY15 BILLING (APPX.) 2,200 EMPLOYEES (APPX.) 200,000+ CUSTOMERS 100M+ USERS HQ OXFORD, UK 90+% BEST IN CLASS RENEWAL RATES 15,000+ CHANNEL PARTNERS OEM PARTNERS: KEY DEV CENTERS OFFICES
- 6. 6 Innovative, Integrated Approach to Next Gen Security HEARTBEAT ENDUSER SECURITY SOPHOS CLOUD NETWORK SECURITY SOPHOS LABS Project Galileo
- 7. 7 Network Security Dashboard (UTM/NGFW)
- 8. 8 Sophos Network Security Group (NSG) Standorte Karlsruhe (DE) Budapest (HU) Vancouver (CA) Ahmedabad (IN)
- 9. 9 April 2015 June 2016 Challenges and Impediments Context Challenges and Impediments
- 10. 10 Predictibility Issues - v1 • Case – Timeline: Lack of Predictability • v1 required 35% more time than initially planned • Long path towards Concept Commit • More time spent for stabilization than for development Reality Plan Planning Development Hardening
- 11. 11 Transparency Issues - v1 • Lack of transparency about test execution & test results • Lack of transparency of true quality status and project status overall • Issues found late in the process • Combined development and test would be more effective „move left“ by early testing
- 12. 12
- 13. 13 Diversity
- 14. 14 April 2015 June 2016 Agile@Sophos: What we aimed for! Context Challenges and Impediments May to June 2015 What we aimed for!
- 15. 15 Agile@Sophos Product Owner BC Planning Review Retrospective Prev. BC Next BC Planning 6 Sprints per Team Team Sprint 2 weeks 6 Sprints per Business Cycle Business Cycle 3 months Business Owner Business Backlog Business Increment Product Increment Preferred agile & lean approach: • Plan only next Business Cycle / 3 months business increment in detail • All other business epics to be added to and prioritized within business backlog
- 16. 16 April 2015 June 2016 Agile@Sophos: How to enable it! Context Challenges and Impediments May to June 2015 What we aimed for! Start of first Business Cycle: How to enable it? Aug. 2015
- 17. 17 Buy-in for Agile Transformation on all levels • Leadership provides the frame for the transition • Teams own the execution Agile Development Agile Support Development Level Management Level Executive Level
- 18. 18 Right Mix of People Mix of existing & new people, driver, heads
- 19. 19 Be aware who needs to be involved and how? Container Strategy, Environment, Budget TRANSPARENCY Management Product Owner – the what owns ROI & Vision Scrum Master owns Process Framework Team – the how owns Quality Stakeholders Customer User, Sales, Marketing; Support Separation of Concerns to optimize Outcome
- 20. 20 Aim for Feature Teams Product Owner Scrum Master UX-Lead Software Engineers Architecture-Lead QA Engineers QA/QM-Lead Line Manger
- 21. 21 Foster new experiences and change will happen
- 22. 22 April 2015 June 2016 Agile@Sophos: Key insights! Context Challenges and Impediments Setup May to June 2015 What we aimed for! Start of first Business Cycle: How to enable it? Aug. 2015 Running Agile
- 23. 23 Give room for new experiences •Learning new & „un-learn“ some old behavior, e.g. • Estimation by (project) manager vs. development team • „Build-when-we-can“ vs. daily (nightly) build AND integrate early • Component vs. feature teams
- 24. 24 Aim for Feature Teams • Case – Full Feature Teams • Observed scenario • To add a new incremental UI enhancement • Multiple teams (in different locations) need to contribute • Due missing separation of concern (APIs), every change had to be discussed in detail and several iterations • Frustrating for all teams involved; bad impact on team morale • Desired scenario • Feature teams are fully functional feature teams • Appropriate APIs and UI framework incl. documentation minimize need for skill-transfer & time zone impact optimal scenario observed scenario time effort communication and skill transfer work waste
- 25. 25 How to achieve this? Promote new experiences Existing rules are allowed and wanted to be changed! => True leadership and lean thinking PEOPLE THRIVE CHANGE => GET THEM INVOLVED AND TRUST THEM!
- 26. 26 Scrum hurts! Really? Scrum is: • Lightweight • Simple to understand • Difficult to master That is: • You will encounter impediments! At least we did. • Scaling Scrum will amplify this! At least we experienced that.
- 27. 27 Scrum hurts! Really? Scrum is: • Lightweight • Simple to understand • Difficult to master That is: • You will encounter impediments! At least we did. • Scaling Scrum will amplify this! At least we experienced that. How we act on this: • We tackle them TOGETHER and OVER TIME
- 28. 28 Scrum hurts! Really? • Some teams delayed their agile transformation • Historical reasons • Interface issues • Resistance to adoption • This hurts a lot: • Yet we were able to generate important insights. • We discussed it, we decided to improve in collaboration between teams and alligned all teams to an agile approach. • This takes time. Respect that and don‘t force people. June 2016 Agile Development Agile Support Development Level Management Level Executive Level
- 29. 29 Scrum hurts! Really? Organization and leaders promote this by „letting them invest time & money“ Do not blame people, help teams to overcome their existing issues! Teams deliver data, insights and ideas for improvements => Change is not a burden, IT‘S A CHANCE!
- 30. 30 Aim for Engineering Excellence 20% 40% 40% An example Engineering Excellence Escalation Feature Development 15% 20% 65% Long-term Goal Are 20% of capacity investment into engineering excellence sufficient to improve the quality long-term under the current circumstances ? Or do we need increased early investments for long-term benefits?
- 31. 31 How we think about it: Investment vs. Efficiency 15% 20% 65% Long-Term Target Investment Distribution Engineering Excellence Escalation Feature Development 1 2 3 4 5 6 StoryPointscompleted Business Cycles Resulting Velocity dependent on the ramp-up investment With significant ramp-up investment into EE WITHOUT significant ramp- up investment into EE Trend with investment Trend WITHOUT investment • Without investment into engineering excellence, even healthy effort distributions become less and less efficient. Reason: Even simple features take more and more time due to increasing inefficiencies and complexities
- 32. 32 How we did it: make it a team sport ...
- 33. 33 How to achieve this? Based on empirical process control (i.e. facts, data and learnings) we have to invest to get new results. “Put your money where your mouth is!” SCRUM HELPS YOU TO GAIN VISIBILITY, IF YOU WANT TO BE EFFICIENT YOU HAVE TO INVEST
- 34. 34 Scaling Agile – Step by step 0. Initially, only specific teams on Scrum one-team Scrum 1. One Business Cycle per product scaled Scrum on value stream 2. Consolidate & combine related business cycles ongoing Targets of Organization • Transparency • Predictability • Engineering excellence by introducing scaled Scrum Status quo
- 35. 35 How did scaling agile helps us so far? • Alignment of business priorities and engineering backlog on quarterly basis • A shared, clear, transparent and understood target and time-frame • Quality driven • Agility for entire value stream of Sophos products • Whole product focus • Customer & partner centric • Agile interaction between multiple teams • Addressing dependencies and risk well in advance • Key for complex and sizable projects • Lean thinking and engineering excellence • Local decision making, i.e. self-organization • Continuous improvement • An early integrated product • Risk mitigation (integration regularly and early) • Early feedback (Customers, End-Users, Executives, ...) • Opportunity to adapt along the way towards the shared vision