simon powers - scaling frameworks in organisational design

Scaling Frameworks

in Organisational Design

Simon Powers

www.adventureswithagile.com

@agileadventures

Free events

Support Network

Training

Consultancy

Taking the pain out of organisational change with a little help from Agile and Lean

INTRODUCTION

Pure

energ

y

Quark

s,

sm

all

part

icle

s

Ato

ms

Hum

an B

ein

g

Colle

ctive c

onscio

usness

Cellu

lar

str

uctu

res

Spiritu

al C

onscio

usness

All

of cre

ation

Range of perception

}

Range of what is usually acceptable to talk about

Simon Powers

My role

Religious Fanaticism

Cert

ain

ty

Uncert

ain

ty

Stress over time

COMMITMENT

REAL OPTIONS

Chris MattsOlav Maassen

Commitment

Why do we stick to our tribes?

Options come in course grained sizes like frameworks

Medium sized concepts like theory of constraints,

And fine grained like guiding values and principles.

Problem cannot be understood until after the formulation of the solution

(often with indeterminate scope and scale)

There is no stopping rule

Solutions are not right or wrong, or good or evil

Problems are essentially novel and unique

Every solution is a ‘one shot’ operation because it changes the space so

trial and error often not possible.

Are wicked because of:

• Incomplete or contradictory knowledge,

• The number of people and opinions involved,

• The large economic burden,

• The interconnected nature of these problems with other problems

WICKED PROBLEMS

Framing the problem

Binary decisions

Decisions involving the elimination of contradictions as a sign of faulty thinking

• Dichotomy – ‘either – or’.• Dilemma – no clear good

outcome• Dualism – ‘both .. And ….’

Paradox decisions

Decisions involving the balancing of two mutually opposing forces that define each other and cant exist without each other

Every problem is a people problem

Secrets of consulting – G. Weinberg

What are we trying to achieve by using a framework?

• Faster time to market

• Ability to change prioritisation without wasted work

• Productivity

• Better quality

• Ease of implementation

• Better product / tech alignment

• Lower cost

• Lower risk

• Building the most valuable thing

• Happier and more motivated people

Diagram modified from David Anderson’s blue book

Failure Load

Co

st

Number of stories

Amount of code not live

(Batch size and frequency of release cycle)

Transaction cost of deployment

Reduce transaction cost of deployment

Cost of non-live code in Complexity, Merging, Management

and Collaboration.

Untested by real customers (business risk)

Total cost

Diagram modified from Don Reinertsen’s work

Co-ordination cost

Optimise for no dependencies

Optimise for less disruption (ease of adoption)

Customer collaboration

over contract negotiation

Co-ordination cost

1 product owner per product

Multiple teams Scrum

1 product owner per team

Multiple Scrum teams

Team Team Team

Team Team Team

Dev Ops Team

UX Team

Architecture Team

Systems Team

Infrastructure Team

Release Management Team

Business people and developers must work daily together throughout the project – 4th Agile Manifesto principle

Transaction and co-ordination cost at scale (> 8 teams).

1 product owner per product

Area product owners

More trains

Co

st

Transaction cost

Total cost

SAFe’s planning activities are essential for silo teams and therefore force the overall

cost higher and the planning window longer

Holding cost

Failure Load

Co

st

Time

Co

st

Time

Transaction and co-ordination cost

2-5 days 2-5 days

£150kPer train

Higher levels of hand off and delay

Much lower transaction costNo hand off or delay

8-12 weeks

Figures are approximate and based upon 125 people at £550 / day.

Source: Less Website

Adoption workshop and migration path

Co

st

Time

Co

st

Time

Failure Load cost

9 months

Learning how to test

Building test frameworks

Improving quality

Paying down tech debt

Stabilise velocity

£3.3M

Increasing technical debt due to

contract based time pressure, low

overall ownership, lack of

investment into technical debt

repayment.

Results in instable velocities and

reduction of planning ability

Figures are approximate and based upon 125 people at £550 / day at 25% capacity for 9 months.

20% - 75%

Frameworks are Shu and Ha

Transformation cost / disruption

How it is taught

Level of prescriptionHigh High

Level of disruptionVery High Medium

Pre-requisitesVery High Low

ApproachRestructure Layer on top

Transformation cost / disruption

Transaction cost

Transaction cost

Differences between the frameworks

1. LeSS requires amazing developers who can do everything

2. LeSS requires teams that can work on any items in the product backlog

3. LeSS requires a single product with no or simple dependencies on other products

4. LeSS requires feature teams with continuous integration, deployment, and shared code ownership

5. LeSS requires huge organisational change in structure resulting in a flattening of hierarchy

6. LeSS once implemented is way more efficient than SAFe

7. LeSS is not a business

1. SAFe is start big picture and remove what you don’t want

2. Everyone is trained up front

3. SAFe does not require the move towards feature teams although encourages it

4. SAFe combines techniques from lots of places –

e.g. Scrum, XP, Kanban, Lean, WSJF, Beyond Budgeting

It’s always a people problem

Simon Powers

www.adventureswithagile.com

Consultancy

@agileadventures

www.adventureswithagile.com/youtube

LinkedIn Group - AWA

Taking the pain out of organisational change with a little help from Agile and Lean

Free events

Support Network

Training

Consultancy