w4 0245 agility_v1

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

Overview of The Enterprise Agility Model May 2013

Enterprise Agility


Damon Poole •  Chief Agilist, Eliassen Group’s Agile PracIce

–  Coaching: TransformaIon and Tune-‐ups –  Training

•  23 years of process change: small co-‐located teams to mulI-‐hundred team global enterprises

•  Founder and past CTO and CEO of AccuRev •  Creator of mulIple 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

•  Diluted Agile •  Sell the idea – The Financial IncenIve •  Enterprise Agility starts at the team level •  PracIces for cross-‐team synchronizaIon •  An organizaIon purpose-‐built for Agile •  Tooling to support Enterprise Agility •  The Enterprise Agility approach to transformaIon

•  Next steps for Monday morning


Agile DiluIon

Trad Prj Mgmt

Agile Teams

Requirements & EsImaIon

Design Planning

TesIng User

Acceptance Release

IniIaIon & Funding

PotenIally Affected •  ExecuIves •  Senior Leaders •  Business •  MarkeIng •  Sales •  Human Resources •  Finance (capitalizaIon) •  Product Management •  Architecture •  PMO / Project Management •  Release Management •  Customers •  Partners

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

Agile touches everything


PotenIal SoluIons


Approaches for CreaIng an Agile Ecosystem

SAFe Enterprise Agility

Others •  Larman/Bodde Scaling Frameworks: FW-‐1 & FW-‐2 •  Enterprise Scrum •  Roll your own (default approach)


CYCLE TIME 1-‐CLICK DEPLOY

Enterprise Agility Model

AGILE OFFICE

I3 I2 I1

LOB CUSTOMERS

ESCALATION

ARCHITECTURE

EPICS LOB BUSINESSLEADERS

DELIVERY BASED METRICS

PORT

FOLIO OF PR

OGR

AMS

CAPA

CITY BAS

ED IN

VESTMEN

T

AGILE PROJECT MGMT

AGILE SCM

RELEASE TEAM / OPS

DELIVERY BASED MANAGEMENT

FUNDING DECISIONS


The Financial IncenIve for Enterprise Agility


TranslaIng MVI to Business Benefits

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

months

$0 $300K $600K $900K

MVI 2 ? MVI 1 Project A


An Example of the Effect of Working by MVI

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

months

$0 $150K $450K

MVI 2

MVI 1

Receive an extra $450K


The Cost of Too Many Projects in Progress

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

Project F

Project E

Project D

Project B

Project C

Project A


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

An Example of the Effect of LimiIng Projects in Progress

Project D

Project A

$0 $600K $1.2M

Project F

$2.4M $3.6M

Project E

Project C

Project B

Receive an extra $3.6M

months

•  Requires smaller # of projects in progress •  Requires prioriIzing the order of projects


Team Level Enablement


What Defines Air Travel

•  Benefit: gepng from here to there quickly •  Plane

– Aerodynamic body – Control surfaces – More liq than weight – Landing gear

•  Trained pilot (s) •  At least two runways


Agreements and Boundaries

2 3 4

9 10 11

1

8

16 17 18

23 24 25

15

22

5

12

19

26

7

14

21

6

13

20

27

30 31 29 28

What it takes to get the benefits of Scrum


Team Level

•  Get incredible at wriIng small user stories – Well defined Who, What, and Why – DefiniIon of ready and done –  I.N.V.E.S.T. – Acceptance criteria – Story splipng – VerIcal slices

•  For soqware projects –  Implement TDD – Use automated tesIng for all new work


Team Level

•  There is a product owner for each team •  Apply Lean

–  Implement one-‐piece flow – Use a card wall: physical or electronic – Use WIP limits on a per-‐team basis


What does it take to get a hosix/patch to your customer?


“One Piece Flow”

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









Done! Done! Done!

Done!


Cross-‐Team Enablement


SynchronizaIon Points

4 8 2 6 10 Weeks

3 7 1 5 9

Example: common synch point: every 2 weeks

Kanban, con)nuous flow, done a0er every story, con)nuous synchroniza)on

•  Each team chooses 1 or more of the following: Scrum, Kanban, XP •  IteraIon lengths must synchronize every 4 weeks or less


Planning, Reviews & Retros Structure

Daily Weekly On a regular cadence


OrganizaIonal Enablement of Agile


Scaling Agile is More Than # of Teams 1.  Team Agility

1

Team(s)

2

2.  MulI-‐team CoordinaIon

CompensaIon

Projects in Progress

Metrics Funding Model

OrganizaIonal Structure

Tools & Tech Impediments

Management

Cycle Time

3

3.  Enterprise Agility

Scrum, Kanb

an,

and/or XP


Top Ten Headwinds and Tailwinds

Area Tradi)onal Agile Organiza)onal structure FuncIon & project Product, team, & delivery Funding Full scope Incremental Compensa)on Individual based Includes consideraIon of team,

and delivery Metrics FuncIonal, plan based Team, business value delivery Tools and technology TradiIonal Agile-‐oriented Impediments Rarely raised Focus on raising & addressing Management of Teams FuncIon based Delivery based Business & IT interac)on Big handoffs Daily interacIon Teams Large, funcIonal,

project-‐based, transient, & dynamic

Small, cross-‐funcIonal, product-‐based, long standing & staIc

Agile Skillset Low High


Tooling to Support Enterprise Agility


Dev

Design/Code

Test/Debug Automatable

CreaIve

Test ExecuIon

Release Data Gathering

Test Deploy Product Mgmt

Business Planning

Test Design

Releng


ConInuous *Everything* Au

tomatable

CreaIve

Build/Test Release Data Gathering

Design/Code

Business Planning

Test Design

Releng


The Enterprise Agility TransformaIon Approach


Agile Principles Applied to TransformaIon

•  Run the transformaIon as an Agile project •  The Simplest Thing That Could Possibly Work •  Measure every construct/pracIce against the Agile Manifesto

•  Incremental “architecture” – Evolve the organizaIon towards Enterprise Agile rather than create a big up front plan


Agile Maturity Indicators

Stable Accelerates adopIon

Slows AdopIon

Impeded (0) Transi)on (1) Sustainable (2) Agile (3) Ideal (4)

Metrics Metrics are all funcIon based

Delivery based metrics are being tried, planned, or discussed

50%+ of metrics are delivery based. Old metrics are sIll being tracked and used

50%+ of metrics are delivery based and old metrics are no longer being tracked or used

Metrics are primarily delivery based

Standups (or similar)

Not being held Not held every day and/or not effecIve, oqen looked at as a status meeIng, not a benefit for the team. Can't keep to the 3 quesIons and/or mtg takes more than 15 min.

Being held every day, 15 minutes, impediments raised, team understands it is for them.

Daily, short, effecIve. Runs well with or without Scrum Master. Team does an on-‐the-‐spot analysis of how things are going and takes correcIve acIon.

PosiIvely adapted to the needs of the team


The Path to Agility – StarIng Point

Team Dynamics

Product

Engineering PracIces

Process Mechanics

Team Structure

Per Team

44 Indicators OrganizaIonal Support

0 1 2 3 4


The Path to Agility – Example Goal

Team Dynamics

Product

Engineering PracIces

Process Mechanics

Team Structure

OrganizaIonal Support

Per Team

44 Indicators

0 1 2 3 4


Agile Maturity Radar Chart – Team Level


Enterprise Agility Summary

•  Enterprise Agility Model •  Enterprise Agility Guide

– OrganizaIon level pracIces – OrganizaIon level changes – Cross-‐team pracIces – Team level pracIces – TransformaIon approach

•  Agile Maturity Matrix Tool


Next Steps / Q&A

•  Download the materials – h~ps://summit.atlassian.com/archives/

•  Share with your team/organizaIon •  As a team/leadership, assess your team/organizaIon

•  Discuss the results and consider improvements

Text code below to 22333 or visit http://bit.ly/1bR9eGC

The Enterprise Agility Model

To join this session, send text 136888 to 22333

AWESOME = 2K

PRETTY GOOD = 2J

NOT BAD = 2I

MEH = 2H

Rate this Talk

w4 0245 agility_v1

Technology