Simon Powers - Scaling Frameworks in Organisational Design
1. 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
4. Certainty
Uncertainty
Stress over time
COMMITMENT
REAL OPTIONS
Chris Matts
Olav 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.
5.
6. 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
7. 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
8. Every problem is a people problem
Secrets of consulting – G. Weinberg
9. 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
11. Cost
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
12. Co-ordination cost
Optimise for no dependencies
Optimise for less disruption (ease of adoption)
Customer collaboration
over contract negotiation
13.
14. 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
15. Transaction and co-ordination cost at scale (> 8 teams).
1 product owner per product
Area product owners
More trains
16. Cost
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
17. Cost
Time
Cost
Time
Transaction and co-ordination cost
2-5 days 2-5 days
£150k
Per train
Higher levels
of hand off
and delay
Much lower transaction cost
No hand off or delay
8-12 weeks
Figures are approximate and based upon 125 people at £550 / day.
19. Cost
Time
Cost
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%
20. 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
24. 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
Example:
Buying a ticket to travel.
Sign off for product release – manager or group signs off
Reason – it mitigates risk.
Or does it?
Passes responsibility from one group to another.
How do we mitigate the risk?
Shared responsibility model is better.
And then a rollback option which we pay for, gives us the option but not the obligation to exercise that – now risk is mitigated.
Give us the ability to defer our decisions to the last responsible moment.
Very important ingredient for dealing with wicked problems
Stopping time is the time where a decision is likely to be made.
Come from when to stop a process, for example, a stopping rule is - we will stop investing in improvements when the code base has 80% coverage
We will complete our Agile adoption when we are the best we can be is not a stopping rule.
Cheap, fast, quick
Freedom , control
In consulting.
`Not blaming
Value added activities are all those which you want to do more of
Costs are ones you want to do less of
e.g. standup duration.
Classic split between the business and IT
Contract game – developers commit as a way to ensuring deadlines and dependencies are met
Surely it makes total sense to rip up the inefficiencies and start again
But does it?
Example of how hard it is: for years the team lead role has been a coveted position of responsibility and reward. The TL is hierarchically higher than the team with more pay and responsibility.
There is a TL for all 1000 teams. Many team leads have worked for years before being promoted, they are ambitious people with the need for a clear career path. and there is a 6 month training cycle to become one.
No we are saying all team members should be equal. That the SM will do most of the TL work, and the PO will take over the decisions on what to build. PMs are not needed anymore.
There is no HR track for improvement for SMs and the job role is not even recognised. How many team leads want to step into the SM role? Answer less than 5.
Go through number of roles
Customer collaboration over contract negotiation – SAFe much better than hand offs.
Planning overhead with this many teams forces the planning window to be large.
Clarification done by teams – LeSS assumes team members can speak to clients.
You can see that with such a high planning cost (transaction cost) the batch size must be higher
£550 * 125 * 2 days = £137.5k
£3.3M = 9months at 25% cost
Directly related to the co-ordination and planning approach.
Problems to overcome
Silo teams
Over specialisation of developers
Ball of mud code base
No testing or shared ownership
No contiuous integration / deployment
£550 * 125 * 2 days = £137.5k
£3.3M = 9months at 25% cost
Story of BNP Paribas
Collaboration at the code level not at the PO level.
Talk about change in job roles, change in reward structure, flattened hierarchy, removal of management waste, talk about history of organisations
Copy
Collect tequniques
It depends, different every time
Area under the curve is the stress
Conclusion on less and safe
Requires true feature teams – t shaped people who can do everything.
