Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Scaling Scaled Agile: Lessons Learned at
UnitedHealth Group
Ken Mair
Agile Management
Optum
Agile Delivery Director
AMX26S...
2 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
© 2015 CA. All rights reserved. All trademarks referenced herein belong...
Framing the Conversation
4
Optum - Who we are
5
What we are solving for on Polaris
Business Process Improvements:
Commitment to Flawless Execution of
the Details
Reduce...
6
• Executing against 5+ year roadmap of business deliverables
• Creating or significantly enhancing dozens of IT assets
–...
7
• Discuss our learnings to date on implementing Scaled Agile on Polaris
– How is the Polaris scaled agile approach the s...
SAFe Foundation in Our Implementation
10
• Value Stream Analysis informing future state
• Centralized, prioritized, refined portfolio* backlog
– Strategic Theme...
11
• Almost everything!
– Dedicated team members
– Common backlog executing from portfolio backlog
– Common roles (e.g. RT...
12
• Practically everything!
– Dedicated, cross functional teams
– Building working, tested software each sprint
– Plan PI...
How have we altered our SAFe implementation?
14
• Truly leveraging the portfolio swim lane of SAFe
– Instead of it just being a loose pass through
Adjusting for the sc...
15
• Product Management Council @ Portfolio Level
– Prioritizing & Refining Epics (Capabilities) multiple times per week
–...
16
• Roadmap planning
– 9 trains X 5 people max per train + portfolio people = LOTS involved!
– Getting people to think ou...
17
• HIP but at a much larger scale
– Balance of portfolio level sessions (e.g. Open Space, Innovation) vs. release train ...
18
• Dedicated Communication Team
• Scrum of Scrum of… Scrums
• Much more sophisticated Dependency Management
• Much more ...
What are We Doing Well?
20
• Commitment to agile execution from Senior Leadership on down
• Increasing maturity across all release trains
– PI & s...
What are Our Largest Challenges?
22
• It’s soooo big… it disrupts every process or system around it
– Change in mindset
– Existing waterfall based processe...
23
• Communication, communication, communication…
– How do you really effectively communicate to 700+people?
• Trusted mes...
24
• Balancing a carrot and a stick…
– How much to Centralize vs. Decentralize?
– How to build self-organizing teams that ...
25
• Dependency management
– Dozens of integrated applications with End to End flows
– Complex scenarios in a complex indu...
26
• Inspire people to inspire others
– Not like just running your own release train
– Can’t just directly solve problems
...
27
• Clarifying Program/Project Manager roles vs. Agile Practitioner Roles
– Did not fully rationalize roles prior to star...
28
• Co-location, within & across release trains
– Portfolio wide… impossible
– Program wide… very difficult
– Pushing tea...
29
• Ramping up or retooling existing resources
– Training & Coaching to hundreds of people
– Building deep vendor partner...
What Would We Do Next Time?
31
• Dedicated, training & coaching team (instead of relying on RTEs & Scrum Masters) to launch new trains,
teams, or impr...
32
• Relentless focus on building working tested software every sprint
• Cross functional problem solving team to manage a...
What is in Our Future?
34
• Stabilizing what we launched
• Way, way more sophisticated DevOps & Release Management
• Product Runway team at the P...
35
For More Information
To learn more, please visit:
http://cainc.to/Nv2VOe
CA World ’15
Scaling Scaled Agile: Lessons Learned at UnitedHealth Group
Upcoming SlideShare
Loading in …5
×

Scaling Scaled Agile: Lessons Learned at UnitedHealth Group

3,151 views

Published on

So maybe your organization has established a release train and it is going well. Now you have been asked to run multiple release trains as part of a portfolio. What’s the same? What’s different? At UnitedHealth Group, one of our largest agile portfolios has six plus release trains, 35 plus scrum teams and hundreds of people all working together to deliver a common business outcome using the scaled agile framework.

This interactive discussion will highlight what we have implemented, what lessons we have learned and what challenges lie ahead in our pursuit for continuous improvement.

For more information, please visit http://cainc.to/Nv2VOe

Published in: Technology
  • Earn $90/day Working Online. You won't get rich, but it is going to make you some money! ●●● https://tinyurl.com/y4urott2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Scaling Scaled Agile: Lessons Learned at UnitedHealth Group

  1. 1. Scaling Scaled Agile: Lessons Learned at UnitedHealth Group Ken Mair Agile Management Optum Agile Delivery Director AMX26S @TwitterHandle #CAWorld
  2. 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
  3. 3. Framing the Conversation
  4. 4. 4 Optum - Who we are
  5. 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. 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. 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. 8. SAFe Foundation in Our Implementation
  9. 9. 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
  10. 10. 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?
  11. 11. 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?
  12. 12. How have we altered our SAFe implementation?
  13. 13. 14 • Truly leveraging the portfolio swim lane of SAFe – Instead of it just being a loose pass through Adjusting for the scale
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. What are We Doing Well?
  19. 19. 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
  20. 20. What are Our Largest Challenges?
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. What Would We Do Next Time?
  30. 30. 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…
  31. 31. 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…
  32. 32. What is in Our Future?
  33. 33. 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
  34. 34. 35 For More Information To learn more, please visit: http://cainc.to/Nv2VOe CA World ’15

×