scaling agile: a tale of two transformations by steve martin

Copyright © 2015 SolutionsIQ, Inc. and Steve Martin. All rights reserved.

6801 185th Ave NE, Suite 200Redmond, WA 98052solutionsiq.com1.800.235.4091

Scaling Agile: A Tale of TwoTransformations

Steve MartinEnterprise Lead Agile [email protected]

mailto:[email protected]

Copyright © 2015 SolutionsIQ, Inc. and Steve Martin. All rights reserved.Copyright © 2015 SolutionsIQ, Inc. and Steve Martin. All rights reserved.

AGENDA

Background

• Profiles of two companies

• Issues/Goals of transformation

Approach

The Experiences & Results

• Successful Company

• Not-so-successful Company

Questions to ponder both before and when scaling up a transformation

Parting Thoughts


BACKGROUND:

COMPANY PROFILES


TABLE 1: COMPARISON OF COMPANIES

FINANCE COMPANY INSURANCE COMPANY

Product &

Customers

Software used by

financial institutions

Software used by medical

professionals to review

patients’ healthcare

information

Internal/External

Customers?

External customers only Both internal and external

customers

Technology Mainframe based, heavy

back-end

Primarily web based


Common Issues

Severely dissatisfied customers

Solutions not addressing customers’ needs

Long lists of enhancement requests, from a few months to several years old

Low quality (in the form of high defects)

Long development and testing cycles


Common Culture

Regulated Industries

Mature Products, Mature Industry

Management Promoted Within

What do you think the culture was like?


APPROACH


USE

AGILE

to

ROLL OUT

AGILE


TABLE 2: THREE-TIER MODEL OF ROLES NEEDED FOR TRANSFORMATION

ROLE TYPICAL TITLES FOCUS AREAS

Executives Leaders of the organization, such as:• C-levels• Executive Vice

Presidents• Managing Directors

• Set vision, guideposts, and culture for Agile transformationo Is consistent and transparent on why they are

doing what they are doingo Empower Management and Agile Teams, then

get out of the way • Renegotiate contracts and relationships with their

customers’ Executives

Management Typically directly manages staff on teams• Associate Vice

Presidents• Directors• Senior Managers

• Paves road for smoother Team execution by removing organization-wide blockerso Empower Teams, then get out of the way o Regularly shows up to reviews and are

“present” to give valued feedback

Agile Teams Individual contributors • Deliver high valued, high quality working product• Alter direction as needed based upon feedback

from stakeholders


Delivery Teams Deliver high quality, high

value product

Scrum used to reduce risk associated product, uncertainty, build trust, increase quality, etc.

5 to 9 members

Cross functional

2 week cadence

Co-located

Dedicated “100%”

Backlogs focused on product…

Enablement Team Guide and enable Agile rollout

company-wide

Also followed Scrum-like approach, to help Management understand change

Up to 15 members

Cross functional

2 week cadence

Multiple locations

Available ~20%

Backlogs focused on transformation


Setting foundation essential for scaling Pilot in a vertical, focusing on enabling Teams to deliver high

value, high quality work product incrementally and iteratively

Incorporating feedback loop with actual customers

o User Advisory Groups (Appendix)

Inculcate culture

Of Quality

Of cross-team collaboration and transparency

Shifting roles of teams, management, executives

To pivot or persevere

Resist temptation to solve enterprise problems just yet

o Be wary / mindful of them

o Have roadmap, but take incremental approach


High Capability, Low Willingness

Have high degree of awareness when coaching; be ready to jump in and actively facilitate. Provide “personal” coaching, usually 1:1. If no change in a reasonable amount of time, then switch out/remove team member.

High Capability, High Willingness

This is your “sweet spot” where you ideally would like to have everyone on your team operate. This gives much greater chance for operating successfully under Agile.

Low Capability, Low Willingness

Consider immediate switch-out. Poor attitude combined in inability to deliver can be a toxic combination to the team. Ask why this person was put on team to begin with to gain perspective and understanding.

Low Capability, High Willingness

This is your second choice of team members. A good attitude with willingness to learn and embrace Agile values and principles greatly contributes to a high performing team. Over time, technical skills can be learned. Lo

w

Hig

h

Low HighWillingness

Cap

abili

ty All 3 levels with high capability, high willingness (Appendix)

Setting foundation essential for scaling


THE ROAD TO AGILE: THE FINANCE COMPANY


Six months in… “Vertical” pilots yielding

positive results

o Site A: 2 Scrum teams

o Site B: 2 Scrum teams + 1 unofficial Kanban

Significant increase in quality

Partnerships, greater trust established with clients

o Strong feedback loop

Comfortable with incremental, iterative development

…yet we stalled Enablement Team fizzling,

interest felt waning

o Management stopped attending sprint reviews

o Weekly Enablement Team meetings were risk reviews

o Not spending 20% time

o Behaviors starting to ripple into Dev Teams

But wanted to launch up to 5 new Scrum teams


Reset Enablement Team to enable scaling

Go from “Governance” to “Working Team”

Held to same standards as Scrum Teams

Teams & Process

Technical(CI, QA)

Executives

Product

2 ScrumMasters (SMs) (Primary – Site B, Secondary – Site A)

2 Product Owners (POs) (Primary – Site A,

Secondary – Site B)

Split ~15 members into 4 areas, 3 to 5 people per area:


Reset, continued…

Held Agile educational workshops at the clients’ customers

o Focused on product (visioning, prioritization, etc.)

o Laid foundation for Executives to renegotiate contracts

Hosted Release Planning workshops with multiple customers present in same room

o Shifted from enhancement requests to valued features

Created SM Community of Practice (CoP)

o Share experiences, common “templates”, metrics, etc.

Attempted Scrum of Scrums

o Found redundant with SM CoP and Enablement Team

Established and executed organization-wide communications plan


The Product Owner Forum


Sprint 1 Sprint 3Sprint 2


Theme T1S1 Theme T1S2 Theme T1S3



PO Team 1

Chief Product Owner(CPO)

PO Team 2

PO Team 3

Day 9: Next Sprint Look Ahead

Day 4: 3 to 5 Sprint Look Ahead







PO Team 1


PO Team 2

PO Team 3


Sprint 4

Theme T1S4

Theme T2S4

Theme T3S4

D4:3-5 D9:

Next








PO Team 1


PO Team 2

PO Team 3


Sprint 4

Theme T1S4

Theme T2S4

Theme T3S4

D4:3-5

D4:3-5

D4:3-5D9:

Next

D9:Next

D9:Next




Seeing the forest and the trees at the same time.


Outcomes

CHARACTERISTIC OUTCOME(S)Scrum Team Performance Generally good to excellent –

90% fewer bugs Delivered double the scope (2X) than expected Collaboration within Team greatly increased; teams

functioning as teamsManagement Capabilities Transitioned from managers to “Servant Leaders”Executive Team Activities Adopted mindset of Minimum Marketable Features

(MMF) for customers Excellent engagement with their Customers

Customer Satisfaction Generally quite higher at the Scrum team level via continuous delivery of working software and making adjustments due to feedback

Moderate improvement at the Customer’s Executive levels (still some uneasiness, but happier than before)

Did Scaling happen? Yes – at least eight Agile teams, with more planned upon leaving


Not always rainbows and puppies…


THE (ROCKY) ROAD TO AGILE: THE INSURANCE COMPANY


There’s a “model”

that worked at the

last company. Let’s

try that approach

here with some

tweaks.


Keep the same Use Agile to rollout Agile

3 levels of involvement (Teams, Mgmt, Execs)

Pilot small number of teams

o Co-locate

o Cross-functional

o 5 to 9 members

o “100%” time

Est. Enablement Team (Mgmt as team members, Execs as “customers”)

Introduce PO Forum

ModificationsOut of the gate:

Have the Enablement Team split into 3 sub-teams (Tech, Process, Product)

Set expectations that an Enablement Team is a “working team” not “governance” or status meeting


Some foreshadowing…

Sounds great in theory. Will never

work here.

We’re fantastic fire fighters!

Agile is the process we need to ensure

we’re all doing it the same way.

I’m overbooked already. I’m free 3

weeks from now for 30 mins.

I guess I’ll just add this to the

8 other projects I’m working on.

I need for all features committed for next 2

years


The story unfolds… An extreme example with the first team…

o Series of medical leaves – 4 PO switches in 3 months

o 5 Dev changes. 3 QA changes. 3 BA changes.

As more 2 team scrum teams rolled out, resource poaching becomes common by Management

o Allocations went from “100%” to as low as 25% to work on emergency issues.

Management wondering why work isn’t getting done

o Put more controls in place - up to 5 different weekly statuses, all with same information

o Weekly then bi-weekly “RYG” Dashboard

o Rarely attended Sprint Reviews


Enablement Team disintegrating

o Focus on fire-fighting vs root cause resolution

o Disband Enablement Team and put a Release Management Team in its place

Executives took passive role – how was I going to fix their problem?

o Desire guarantees of what’s in the next release

o Took 90 days to create a 90 day release plan

o 13 MMFs to 21 MMFs

Customers getting angry (again)

o Customers start to bow out of sprint reviews, since feedback wasn’t incorporated

o Intermediary put between Teams and Customers

The story unfolds…


Despite the drama, there were wins…

Several Teams were performing better.

Collaboration, willingness to help each other

In earlier sprints, initially gain trust of customers

Started to understand incremental builds

Quality improved

Brought in Continuous Integration

Roles started to blur (UX, Devs doing testing)

Brought some rigor to the Release Planning Process

Made Release Process more transparent, incorporating multiple departments along the way


Outcomes

CHARACTERISTIC OUTCOME(S)Scrum Team Performance Generally fair to good-

Moderately better quality software than with waterfall Delivered on par to what was expected Collaboration based upon an individual’s personality;

some teams worked well together, some teams were just a collection of people

Management Capabilities Continued to “manage” and put more controls in placeExecutive Team Activities Little change in behavior observed

Was aware of concept of MMF, but deferred to big bang rollouts versus incremental delivery

Customer Satisfaction Less overall satisfaction in the end from their customers, especially from the Executive levels

Exception: Some “bright spots” sporadically from Scrum Teams

Did Scaling happen? No – stalled at four Agile teams


QUESTIONS TO PONDER


What factors enabled greater

success?

Why “successful” at finance company, yet

not so much at insurance company?

Image © Andres Rodriguez


Finance Co

Tremendous work ethic

Belief in product

Demonstrating Agile Principles at 3 levels

Dedicated, Continuous Teams

Sprint Review Participation

Execs/Mgmt Curiosity

Work through pivots

Set foundation to scale

Actions

Insurance Co

Tremendous work ethic

Belief in product

Demonstrating Agile Principles at Team level

Non-dedicated, high turn-over teams

Sprint Review Absence

Execs/Mgmt Missing

Pivots are hard…

Difficult to set foundation

Words


Agile Transformations are Multidimensional

Environment

Teams

Leadership

Values & Principles

Process

Business/Market Drivers

… just to show a few areas

for consideration


Example Questions to Ponder(Complete list in Section 8 of paper)

#2 - Do your Executives:

• Believe there is a problem with the status quo?

• Buy into the concept they will likely need to alter theirbehavior in order for the organization to change?

• Understand they will likely need to reestablish relationships with their top customers, help their customers come along with the transformation journey as well?

• Have the fortitude to prioritize on a limited set of key strategic initiatives and let others go?


Example Questions to Ponder(Complete list in Section 8 of paper)

#7 - When it comes to the act of releasing product incrementally:

• Is your organization willing to do incremental releases?

• Are your customers willing to accept incremental releases?

• Can you identify a set of early adopters willing to provide candid and valuable feedback on incremental releases?


My more successful

transformations and

scaling efforts had more

“yes” answers than “no”

answers to these

questions.

Copyright © 2015 SolutionsIQ, Inc. and Steve Martin. All rights reserved.Copyright © 2015 SolutionsIQ, Inc. and Steve Martin. All rights reserved.

Small Groups Activity

As an Individual, scan through the list of

8 areas to Ponder.

- Select one area you’re experiencing challenges.

Get in group of 3ish folks

Each person share areas of challenge.

Rest of small group short brainstorm ideas to

address challenge (90 seconds/person)

- Think “Headlines”

- Rotate until all members have several ideas

Get contact info to continue conversation after

this session…

44


PARTING THOUGHTS


For more successful Transformations and Scaling outcomes…

Use Agile to roll out Agile

o Start small – Pilot. Learn. Adjust.

o Scale in verticals, then go vertical by vertical.

Set strong foundation before scaling

o Initial focus on team delivery

o Have 3 levels working together towards common goals

Move the needle on culture

o Transition to enterprise in waves later on

It’s OK to pivot – not only the product (Dev Teams), but also the transformation itself (Enablement Team)


6801 185th Ave NE, Suite 200Redmond, WA 98052solutionsiq.com1.800.235.4091

Scaling Agile: A Tale of TwoTransformations

Steve MartinEnterprise Lead Agile [email protected]

mailto:[email protected]

scaling agile: a tale of two transformations by steve martin

Technology

reserved culture

testing cycles copyright

agile transform

financial institutionssoftware

medical professionals

mature industrymanagement

years oldlow quality

tier model of roles