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 200
Redmond, WA 98052
solutionsiq.com
1.800.235.4091
Scaling Agile:
A Tale of Two
Transformations
Steve Martin
Enterprise Lead Agile Consultant
smartin@solutionsiq.com
617-999-7753

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
transformation
o Is consistent and transparent on why they are
doing what they are doing
o 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 blockers
o 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.
LowHigh
Low HighWillingness
Capability 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
Chief
Product
Owner
(CPO)
PO Team 2
PO Team 3
Ahead
Sprint 4
Theme T1S4
Theme T2S4
Theme T3S4
D4:
3-5 D9:
Next
Look Ahead

PO Team 1
Chief
Product
Owner
(CPO)
PO Team 2
PO Team 3
Ahead
Sprint 4
Theme T1S4
Theme T2S4
Theme T3S4
D4:
3-5
D4:
3-5
D4:
3-5D9:
Next
D9:
Next
D9:
Next
Look Ahead

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 teams
Management 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
Modifications
Out 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 place
Executive 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 their
behavior 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)

Scaling Agile: A Tale of Two Transformations by Steve Martin

Recommended

Recommended

More Related Content

More from Accenture | SolutionsIQ

More from Accenture | SolutionsIQ (7)

Recently uploaded

Recently uploaded (20)

Scaling Agile: A Tale of Two Transformations by Steve Martin

Editor's Notes