Scaling Scaled Agile: Lessons Learned at UnitedHealth Group
3 likes5,092 views
The document discusses the implementation of scaled agile practices at UnitedHealth Group, particularly through the Polaris initiative, highlighting successes and challenges faced during the transition. It emphasizes improvements in efficiency, communication, and backlog management while also pointing out difficulties in managing dependencies and organizational alignment. Key takeaways include the need for dedicated training resources and enhanced role clarification for project management within agile frameworks.
Scaling Scaled Agile: Lessons Learned at UnitedHealth Group
- 1. Scaling Scaled Agile: Lessons Learned at UnitedHealth Group Ken Mair Agile Management Optum Agile Delivery Director AMX26S @TwitterHandle #CAWorld
- 2. 2 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD © 2015 CA. All rights reserved. All trademarks referenced herein belong to their respective companies. The content provided in this CA World 2015 presentation is intended for informational purposes only and does not form any type of warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA. For Informational Purposes Only Terms of this Presentation
- 4. 4 Optum - Who we are
- 5. 5 What we are solving for on Polaris Business Process Improvements: Commitment to Flawless Execution of the Details Reduced Technology Costs: Advancing the Capability of the Enterprise Market Facing Improvements: Delivering Market Value at Market Speed Front-end Improvements (efficiencies and quality improvements in product set-up, network set-up, provider demographics, employer installation). Back-end Improvements (claim processing efficiencies, reduction in rework, fewer member and provider calls). Lower maintenance costs, break-fix requirements, less testing time and lower capital investments in the future. Move configuration changes from IT to business to decrease implementation cost and increase speed. Improved speed to market, quality, compliance, satisfaction. Product and Network flexibility aligned with where the market is heading. 1 2 3
- 6. 6 • Executing against 5+ year roadmap of business deliverables • Creating or significantly enhancing dozens of IT assets – Several are targeted as commercialized assets • Influencing how software is developed within Optum and UnitedHealthcare moving forward • Leveraging full scaled agile practices for 80%+ of all development – 9scaled agile release trains – 45+ scrum teams – 700+ people involved So what are we actually doing on Polaris…
- 7. 7 • Discuss our learnings to date on implementing Scaled Agile on Polaris – How is the Polaris scaled agile approach the same as SAFe? – How is the Polaris scaled agile approach different than SAFe? – Is the Polaris scaled agile approach succeeding? • Discuss what would we do differently next time • Discuss what lies ahead for our implementation Objectives of the next 45 minutes…
- 8. SAFe Foundation in Our Implementation
- 10. 10 • Value Stream Analysis informing future state • Centralized, prioritized, refined portfolio* backlog – Strategic Themes (aligned to a major release concept) – Capabilities (will span release trains, will span program increments) – Features (within a release train, within a program increment) • All trains on the same cadence • Dedicated portfolio leadership • Epic ownership through Capability Ownership Model Our Experience with SAFe: What is the same at the Portfolio level? *Internally Polaris is considered a program
- 11. 11 • Almost everything! – Dedicated team members – Common backlog executing from portfolio backlog – Common roles (e.g. RTE, Product Manager, Dev Leader) – Build on cadence, deliver on… cadence • Some Variances exist based on release train size – Systems team & dedicated DevOps on largest train, but not on others… yet – Product Management Council vs. Product Manager refining backlog Our Experience with SAFe: What is the same at the Program level?
- 12. 12 • Practically everything! – Dedicated, cross functional teams – Building working, tested software each sprint – Plan PI every 10 weeks, sprint plan every 2 weeks – Common ceremonies (e.g. sprint planning, system demo, retrospectives) Our Experience with SAFe: What is the same at the Team level?
- 13. How have we altered our SAFe implementation?
- 14. 14 • Truly leveraging the portfolio swim lane of SAFe – Instead of it just being a loose pass through Adjusting for the scale
- 15. 15 • Product Management Council @ Portfolio Level – Prioritizing & Refining Epics (Capabilities) multiple times per week – Aligning product managers to then go get product owners aligned – Clearly defining themes for upcoming PI almost immediately after PI planning – Swarming on Epics Adjusting for the scale
- 16. 16 • Roadmap planning – 9 trains X 5 people max per train + portfolio people = LOTS involved! – Getting people to think outside of their silos and manage to the broader objective Adjusting for the scale
- 17. 17 • HIP but at a much larger scale – Balance of portfolio level sessions (e.g. Open Space, Innovation) vs. release train based (e.g. bug-a-thons, hardening, team building) • Modified PI Planning Agenda – Release train modifications for time zone differences – Time for Portfolio wide level set of the key themes (day before) – Cross program dependency management review sessions at end of Day 1 – Add in portfolio risk review after release train review • Cross release train demos – Mid-PI and End of PI for full portfolio Adjusting for the scale
- 18. 18 • Dedicated Communication Team • Scrum of Scrum of… Scrums • Much more sophisticated Dependency Management • Much more sophisticated Environment Coordination & Definition of Done Adjusting for the scale
- 19. What are We Doing Well?
- 20. 20 • Commitment to agile execution from Senior Leadership on down • Increasing maturity across all release trains – PI & sprint planning is becoming a well-oiled machine – Teams honoring commitments – HIP is working well • Significantly improving backlog management from Portfolio to Teams • Cutting edge DevOps practices – on 1 out of 9 release trains • Dedicated team of agile practitioners driving the overall transformation – Writing practical guidance that will be used for all of Optum moving forward • Leveraging Rally as a Source of Truth with extensive metrics to drive decisions • Not crumbling under the weight of it Things to be proud of
- 21. What are Our Largest Challenges?
- 22. 22 • It’s soooo big… it disrupts every process or system around it – Change in mindset – Existing waterfall based processes – Organizational alignment Things that keep me up at night
- 23. 23 • Communication, communication, communication… – How do you really effectively communicate to 700+people? • Trusted messengers • Weekly news letter • Nested distribution lists • Lots of Wiki based content – Regardless of the best ideas, communication is tough at this scale Things that keep me up at night
- 24. 24 • Balancing a carrot and a stick… – How much to Centralize vs. Decentralize? – How to build self-organizing teams that are heading in the same direction? Things that keep me up at night
- 25. 25 • Dependency management – Dozens of integrated applications with End to End flows – Complex scenarios in a complex industry Things that keep me up at night
- 26. 26 • Inspire people to inspire others – Not like just running your own release train – Can’t just directly solve problems – Can’t be everywhere at once Things that keep me up at night
- 27. 27 • Clarifying Program/Project Manager roles vs. Agile Practitioner Roles – Did not fully rationalize roles prior to starting – Agile practitioners morphed from coaches to RTE / Scrum Master Things that keep me up at night
- 28. 28 • Co-location, within & across release trains – Portfolio wide… impossible – Program wide… very difficult – Pushing team level co-location • Can still build a sense of community through – HIP – Flowdock – Face to face PI planning Things that keep me up at night
- 29. 29 • Ramping up or retooling existing resources – Training & Coaching to hundreds of people – Building deep vendor partner relationships – Build competency models for screening and hiring candidates Things that keep me up at night
- 30. What Would We Do Next Time?
- 31. 31 • Dedicated, training & coaching team (instead of relying on RTEs & Scrum Masters) to launch new trains, teams, or improve existing • Driving portfolio backlog maturity & swarming from beginning with clear epic ownership teams • Focus on DevOps right out of the gate – ATDD, common environments, tooling, automation • Better define what is mandated at the portfolio level: – Definition of Ready (DoR) – Definition of Done (DoD) – Non-functional Requirements (NFRs) – Environment standards & levels – Source of truth for requirements… Rally! – PI Planning cadence Hindsight says…
- 32. 32 • Relentless focus on building working tested software every sprint • Cross functional problem solving team to manage a continuous improvement backlog at beginning • Better rationalize roles & responsibilities of Project Management job family – Agile practitioners, Program & Project Management • Make a decision about Rally portfolio item hierarchy and just stick to it Hindsight says…
- 33. What is in Our Future?
- 34. 34 • Stabilizing what we launched • Way, way more sophisticated DevOps & Release Management • Product Runway team at the Portfolio Level • Continue to partner with Rally to: – Improve Dependency Management – Build an actual release object – Convert heaps of data into actionable information • Funding teams & not projects • …and more Next areas of focus
- 35. 35 For More Information To learn more, please visit: http://cainc.to/Nv2VOe CA World ’15