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

3.
Framing the Conversation

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

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.
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.
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.
How have we altered our SAFe implementation?

13.
14
• Truly leveraging the portfolio swim lane of SAFe
– Instead of it just being a loose pass through
Adjusting for the scale

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.
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.
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.
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.
What are We Doing Well?

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.
What are Our Largest Challenges?

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.
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.
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.
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.
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.
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.
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.
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.
What Would We Do Next Time?

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.
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.
What is in Our Future?

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.
35
For More Information
To learn more, please visit:
http://cainc.to/Nv2VOe
CA World ’15