Scaling and Measuring Agile Success

Scaling and Measuring Agile Success

© 2012-2013 Eliassen Group. All Rights Reserved -1-

Damon Poole

• Chief Agilist, Eliassen Group’s Agile Practice
– Coaching: Transformation and Tune-ups
– Training
• 22 years of process change: small co-located teams to
multi-hundred team global enterprises
• Founder and past CTO and CEO of AccuRev
• Creator of multiple Jolt-award winning products
• Past President of Agile New England
• Author of “DIY Agile Kickstart”
• Consulted with Ford IT, Orbitz, Fidelity, Capital One,
ING Direct, and many others
• Taught Agile techniques to thousands of people

Agenda
• Scaling Agile
• Organizational Support for Scaling Agility
• Cycle Time – The Agile Adoption Forcing Function
• Measuring Success


Scaling Agile


“Scaling”
• What do we mean by “scaling?”
• A typical definition of scaling:
– Adding more resources adds proportionally more
capacity for doing work
• Does traditional development scale?


A Typical Iteration
#define a b
Traveller wants 3 /*
* This is great code.
to register with */
the system bool doStuff ( ) {
index++;
Sue }

#define a b
to enter a */
booking bool doStuff ( ) {
index++;
Bob }

#define a b
to delete a */
booking bool doStuff ( ) {
index++;
Sue }

#define a b
to see their */
upcoming trips bool doStuff ( ) {
index++;
Tom }

#define a b
to edit a booking */
bool doStuff ( ) {
index++;
Tom }

#define a b
Admin wants a 5 /*
report of site- */
wide activity bool doStuff ( ) {
index++;
Bob }


“One Piece Flow”

Done! Done! Done!

#define a b #define a b #define a b
/* /* /*
* This is great code. * This is great code. * This is great code.
*/ */ */
bool doStuff ( ) { bool doStuff ( ) { bool doStuff ( ) {
index++; index++; index++;
} } }

#define a b #define a b #define a b #define a b
/* /* /* /*
* This is great code. * This is great code. * This is great code. * This is great code.
*/ */ */ */
bool doStuff ( ) { bool doStuff ( ) { bool doStuff ( ) { bool doStuff ( ) {
index++; index++; index++; index++;
} } } }

#define a b #define a b
/* /*
* This is great code. * This is great code.
*/ */
bool doStuff ( ) { bool doStuff ( ) {
index++; index++;
} }

Done!


One Piece Flow All the Time – Kanban
Always
Deliverable

Product
Mgmt

$
Customers / Market

Organizational Support for Scaling Agility


High Level SDLC Overview

SYNCHRONIZATION
LOB CUSTOMERS / BUSINESS STRATEGY BUILD, TEST, DEPLOY,
MARKETS & PLANNING & MAINTAIN
RELEASE VEHICLE


Traditional Agile


Inspect and Adapt (Self-healing)
• Organizations, people, projects, markets are
constantly changing
• Healthy Agile requires constant monitoring
and adjustment
• Agile process improvement mechanisms
– Standups
– “Scrum of Scrums”
– Retrospectives
– Stop the line


Escalation Tree
Daily standup
Management Rapid
involvement turnaround.

Action Items Owner
S2 Team Z’s build server is down Joe
09:30am – Cover Joe’s unexpected absence Susan
09:45am
Resolve dependency between Pat
team X & Y

S1
09:00am –
09:15am


Escalation Tree
Frequent Retrospective

1 hour

1 hour


Misaligned, Functional Goals

Functional
✔ ✔ ✔ ✔ ✔ ✔
Goals

Late,
Not as
missing
Project A Project B relevant as
scope
hoped


Moving to Managing Business Value Delivery

• Switch to business value delivery metrics
• Align everyone connected to a line of business
or product to the same goal: delivering of
business value
• Examples:
– Old
• number of defects found per release
• coding tasks completed
– New
• test coverage per new user story
• # of story points associated with done stories


Fully Aligned Goals

Primary
✔ Project A ✔ Project B
Goals

Secondary
✔ ✔ ✔ ✔ ✔ ✔
Goals


One Solution: Organize around Business Value Delivery

Line of Line of
✔ ✔
Business A Business B


Top Ten Headwinds and Tailwinds

Area Traditional Agile
Delivery focus Projects Products & releases
Business & IT interaction Big handoffs Daily interaction
Teams Large, functional, Small, cross-functional,
project-based, product-based, long standing &
transient, & dynamic static
Metrics Functional, plan Team, business value delivery
based
Funding Full scope Incremental
Feedback loops Slow Very fast
Projects per person 2-5 1
Agile Skillset Low High
Tools and technology Traditional Agile-oriented
Test execution Primarily manual Automated & holistic


Enterprise Agility Model

DELIVERY BASED ESCALATION
MANAGEMENT

AGILE OFFICE
CAPACITY BASED INVESTMENT
PORTFOLIO OF PROGRAMS

AGILE
PROJECT
MGMT

AGILE SCM

LOB LOB EPICS
CUSTOMERS BUSINESS
LEADERS
DELIVERY RELEASE TEAM I1 I2 I3
BASED / OPS
METRICS CYCLE TIME ARCHITECTURE 1-CLICK
DEPLOY


Cycle Time – The Agile Adoption Forcing
Function


Cycle Time

Integration and
Preparation Development testing

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
months


A Typical Risk Mitigation Strategy That Can Increase Risk

• A Project is Prioritized after gathering
requirements and doing estimation for
multiple projects.
• This usually takes 3, 6, or more months.
• Requirement gathering and scoping for
multiple projects takes time away from
working on funded projects.


Cycle Time
18 month cycle time

Funding
(picking)

Integration and
Proposing Preparation Development testing

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
months


Cycle Time

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
months


Cycle Time

Pick Pick Pick Pick Pick Pick

Prep Prep Prep Prep Prep Prep

Do Do Do Do Do Do

Ship Ship Ship Ship Ship Ship

1 2 3 4 5 6 7
1 month iterations


Cycle Time
3 month cycle time

Pick

Prep

Do

Ship

1 2 3 4 5 6 7
1 month iterations

Measuring Success


Measuring Success
• Profits
• Net Promoter Score
• Business value anecdotes
• Value delivery rate
• Agile capabilities
– Organizational
– Team
– Individual (by role)


Value Delivery Vehicles
Load Your
organization’s
end-to-end
40 cubic meters delivery vehicle

Deliver
Payload

Cycle Time

Payload
Rate of Value Delivery =
Cycle Time


Value Delivery Vehicles

40 cubic meters Gold
Coal


Agile Maturity Indicators
Slows
Adoption Stable
Accelerates adoption

Impeded Transition Sustainable Agile Ideal
Metrics Function based Delivery based 50%+ of metrics 50%+ of metrics Metrics are
metrics are are delivery are delivery primarily
being tried, based. Old based and old delivery based
planned, or metrics are still metrics are no
discussed being tracked longer being
and used tracked or used
Progress Not Progress is Progress is Progress The team
tracking implemented tracked using tracked and information proactively uses
and/or doesn’t burnup, frequently usually progress
influence burndown, CFD influences the influences the information to
behavior or similar behavior of the behavior of the head off
method and team team potential
sometimes problems
influences
behavior


Relationship of Agile Maturity to Benefits

Benefit

Agile Maturity

The Path to Agility
Start
01234

44 Indicators Organizational

Team Dynamics

Team Structure

Per Team Product

Process Mechanics

Engineering Practices

The Path to Agility
Example Goal
01234

Organizational
44 Indicators Support

Team Dynamics

Team Structure

Per Team Product

Process Mechanics

Engineering Practices

Q&A

Dropbox with Enterprise Agility Materials
http://bit.ly/10hpvxb


Scaling and Measuring Agile Success

More Related Content

Similar to Scaling and Measuring Agile Success

More from VersionOne

Recently uploaded

Scaling and Measuring Agile Success