scaling scaled agile: lessons learned at unitedhealth group

Scaling Scaled Agile: Lessons Learned at UnitedHealth Group

Ken Mair

Agile Management

Optum

Agile Delivery Director

AMX26S

@TwitterHandle

#CAWorld

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

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

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

• 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

– 9 scaled agile release trains

– 45+ scrum teams

– 700+ people involved

So what are we actually doing on Polaris…

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…

SAFe Foundation in Our Implementation

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

• 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

• 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?

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 scale

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

• 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

• 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

• 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

What are We Doing Well?

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

What are Our Largest Challenges?

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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

What Would We Do Next Time?

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

• 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…

What is in Our Future?

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

For More Information

To learn more, please visit:

http://cainc.to/Nv2VOe

CA World ’15