Downloaded 16 times
More Related Content
Similar to Simon Powers - Scaling Frameworks in Organisational Design
Simon Powers - Scaling Frameworks in Organisational Design
- 1. Scaling Frameworks in OrganisationalDesign 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
- 2. INTRODUCTION Pureenergy Quarks,smallparticles Atoms HumanBeing Collectiveconsciousness Cellularstructures SpiritualConsciousness Allofcreation Range of perception } Rangeof what is usually acceptable to talk about Simon Powers My role
- 3.
- 4. Certainty Uncertainty Stress over time COMMITMENT REALOPTIONS 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.
- 6. Problem cannot beunderstood 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 Binarydecisions 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 isa people problem Secrets of consulting – G. Weinberg
- 9. What are wetrying 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
- 10. Diagram modified fromDavid Anderson’s blue book Failure Load
- 11. Cost Number of stories Amountof 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 forno dependencies Optimise for less disruption (ease of adoption) Customer collaboration over contract negotiation
- 14. Co-ordination cost 1 productowner 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-ordinationcost at scale (> 8 teams). 1 product owner per product Area product owners More trains
- 16. Cost Transaction cost Total cost SAFe’splanning 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-ordinationcost 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.
- 18. Source: Less Website Adoptionworkshop and migration path
- 19. Cost Time Cost Time Failure Load cost 9months 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 Shuand 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
- 21. Transformation cost /disruption
- 22.
- 23.
- 24. Differences between theframeworks 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
- 25. It’s always apeople problem
- 26. 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
Editor's Notes
- #5 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
- #7 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.
- #8 Cheap, fast, quick Freedom , control
- #9 In consulting. `Not blaming
- #11 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.
- #13 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.
- #14 Go through number of roles
- #15 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.
- #17 You can see that with such a high planning cost (transaction cost) the batch size must be higher
- #18 £550 * 125 * 2 days = £137.5k £3.3M = 9months at 25% cost Directly related to the co-ordination and planning approach.
- #19 Problems to overcome Silo teams Over specialisation of developers Ball of mud code base No testing or shared ownership No contiuous integration / deployment
- #20 £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.
- #21 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
- #22 Area under the curve is the stress Conclusion on less and safe Requires true feature teams – t shaped people who can do everything.