Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Simon Powers - Scaling Frameworks in Organisational Design
Ähnlich wie Simon Powers - Scaling Frameworks in Organisational Design (20)
Mehr von AgileCymru
Mehr von AgileCymru (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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
- 2. INTRODUCTION Pureenergy Quarks,smallparticles Atoms HumanBeing Collectiveconsciousness Cellularstructures SpiritualConsciousness Allofcreation Range of perception } Range of what is usually acceptable to talk about Simon Powers My role
- 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.
- 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
- 10. Diagram modified from David Anderson’s blue book Failure Load
- 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
- 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.
- 18. Source: Less Website Adoption workshop and migration path
- 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
- 21. Transformation cost / disruption
- 22. Transaction cost
- 23. Transaction cost
- 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
- 25. It’s always a people 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
Hinweis der Redaktion
- 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.