simon powers - scaling frameworks in organisational design
Post on 21-Jan-2018
413 Views
Preview:
TRANSCRIPT
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
top related