Successfully reported this slideshow.

Xp2015 Scaling Agility explored - LeSS SAFe comparison

29

Share

Loading in …3
×
1 of 76
1 of 76

Xp2015 Scaling Agility explored - LeSS SAFe comparison

29

Share

Download to read offline

What is the problem that Scaling Agile is solving? How does it look from the perspectives of coordination, organizational control by William G Ouchi, batching and queues, and business. How are LeSS and SAFe addressing the real root causes?

What is the problem that Scaling Agile is solving? How does it look from the perspectives of coordination, organizational control by William G Ouchi, batching and queues, and business. How are LeSS and SAFe addressing the real root causes?

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Xp2015 Scaling Agility explored - LeSS SAFe comparison

  1. 1. © GOSEI Scaling Agility Explored Ran Nyman, Ari Tikka XP2015 27.5.2015 Wednesday 27 May 15
  2. 2. Gosei&Oy&all&rights&reserved. About this session 2 About Root causes and basic assumptions behind Scaling Agile For you to evaluate LeSS and SAFe How to analyze Coordination Organizational layers of control with the theory by William G. Ouchi Flow of work Batch size and Queues Corporate and business perspective Wednesday 27 May 15
  3. 3. Gosei&Oy&all&rights&reserved. Speakers 3 Ari TikkaRan Nyman Wednesday 27 May 15
  4. 4. Why to Scale Agile? 4 Wednesday 27 May 15
  5. 5. 5 Don’t! Adding more people just makes you slower. -- one of the directors of SAGE program 1950’s -- Frederick Brooks at Mythical man-month, 1975 Wednesday 27 May 15
  6. 6. Gosei&Oy&all&rights&reserved. Still want to scale up? 6 We have grown big, slow and wasteful. We are creating complex big products. We don’t want to become slow and wasteful.Jersey Shore www.joiseyshowaa.com Wednesday 27 May 15
  7. 7. 7 How do you end up slow and wasteful? Common sense and fashionable solutions Wednesday 27 May 15
  8. 8. Gosei&Oy&all&rights&reserved. “Hey, We have business! And it is growing!” “People just find their roles.” “Specialists are irreplaceable. We need to optimize their individual performance.” In the beginning 8 Wednesday 27 May 15
  9. 9. Gosei&Oy&all&rights&reserved. “It starts to get messy. We need someone to look after things.” “Lets hire a coordination specialist - the project manager.” Growing the using common sense 9 Wednesday 27 May 15
  10. 10. Gosei&Oy&all&rights&reserved. “The project managers really do their job.” “Obviously it is best to give responsibilities to the specialized people.” Growth continues 10 Wednesday 27 May 15
  11. 11. Gosei&Oy&all&rights&reserved. “Do You understand what is really going on?” “Blessed the are project managers. They get something out of this mess.” The coordinators become the heroes 11 Wednesday 27 May 15
  12. 12. Gosei&Oy&all&rights&reserved. “We are slow and expensive. Why are projects no more productive?” “People Resources are either idling or overloaded.” “The portfolio does not obey. Dependencies and maintenance dominate.” But… too much to be coordinated 12 ? Wednesday 27 May 15
  13. 13. Gosei&Oy&all&rights&reserved. Symptoms of fragmented organisation Wasting. Waiting. Scatter. Handovers. Loss of knowledge. Hunting for resources. Bad quality. Quick fix. Distress. Reorgs. Cost management. Gaps between roles. Nonproductive feedback. Misleading measures. Unclarity. Bad atmosphere. No time for learning. Knowledge and power is always elsewhere! 13 ? Wednesday 27 May 15
  14. 14. Gosei&Oy&all&rights&reserved. Would scaling Agile up help us? 14 We are slow and wasteful! Wednesday 27 May 15
  15. 15. 15 What to DO? Wednesday 27 May 15
  16. 16. Gosei&Oy&all&rights&reserved. Scrum works for one team 16 Wednesday 27 May 15
  17. 17. 17 Program Execution Scrum team Wednesday 27 May 15
  18. 18. 18 Customer-centric learning Wednesday 27 May 15
  19. 19. Gosei&Oy&all&rights&reserved. LeSS Framework 19 Wednesday 27 May 15
  20. 20. LeSS Huge 20 Wednesday 27 May 15
  21. 21. 21 Control Systems and Coordination Wednesday 27 May 15
  22. 22. Gosei&Oy&all&rights&reserved. Control Systems in organizations by William G. Ouchi 22 Measure Input (€) and Output (€). Contractual between parties. Exact contract! Written rules and processes. E.g. Employment agreement and supervision. Informal value based rules that allow innovation and collaboration. Only this works for unique, interdependent or ambiguous task. E.g. SW Development Market system Bureaucratic system Clan system Wednesday 27 May 15
  23. 23. Gosei&Oy&all&rights&reserved. William G. Ouchi Inventor of management control mechanisms Inventor of motivation Theory Z Addition to well know Theory X and Y Influenced by Japanese management style 23 Wednesday 27 May 15
  24. 24. Projects Coordinate Peoples Time and Technology Dependencies 24 Wednesday 27 May 15
  25. 25. Gosei&Oy&all&rights&reserved. 25 Market Control Bureaucratic Control Clan Control Project x Project Y Project z Projects control people Wednesday 27 May 15
  26. 26. Programs Coordinate Teams and Technology Dependencies 26 Wednesday 27 May 15
  27. 27. Component teamComponent teamComponent teamComponent team Gosei&Oy&all&rights&reserved. 27 Market Control Bureaucratic Control Clan Control Program x Program Y Program z Programs coordinate teams Wednesday 27 May 15
  28. 28. Gosei&Oy&all&rights&reserved. Control by SAFe 28 Bureaucratic System (process, written rules,role descriptions) Clan System (social rules) Market System (€) Wednesday 27 May 15
  29. 29. Gosei&Oy&all&rights&reserved. 29 What changes Risk or challenge Release trains and 3-month cadence instead of parallel projects. The parallel projects existed for a reason, which is not yet solved. Still need for substantial planning, because the underlying organizational design is unchanged. From time based resource planning to team output estimation. Improved communication by all hands release planning meeting. The amount of dependencies, and queuing them for solution remains a challenge and results in branching and late integration. Contract game remains for planning needs. Welcoming teams to middle management. Training and consultation for Lean- Agile best practices. Culture follows structure. Focus in coordination, not value adding work. Thinking and communicating in organizations differs from what is actually happening. *) *) Mats Alvesson and André Spicer: "A Stupidity-Based Theory of Organizations", Journal of Management Studies 49:7, November 2012. André SPICER: 2013 "Shooting the shit: the role of bullshit in organisations" M@n@gement, 16(5), 653-666, Cass Business School, CU London. Wednesday 27 May 15
  30. 30. Gosei&Oy&all&rights&reserved. 30 What is not changing Risk or challenge The numerous middle management roles are renamed. As before, scarce resources are moved from teams to management (e.g. UI design, Architects). The change does not happen. The change is not useful. Corporate layers of power and control legitimized to be Agile. No real change. No business Agility developed. Business decides, programs execute. Contract game with business. Little emphasis for structural change from functional to feature teams. Technical capability and competence limit the effectiveness of the change. Wednesday 27 May 15
  31. 31. Teams Coordinate Dependencies and Technology 31 Wednesday 27 May 15
  32. 32. Gosei&Oy&all&rights&reserved. Market Control Bureaucratic Control Clan Control Feature teamFeature teamFeature team Feature teamFeature teamFeature team 32 People work with technology Teams coordinate Wednesday 27 May 15
  33. 33. Gosei&Oy&all&rights&reserved. Focus from Projects to Customer 33 Customer Organizational design Wednesday 27 May 15
  34. 34. Wednesday 27 May 15
  35. 35. Wednesday 27 May 15
  36. 36. Wednesday 27 May 15
  37. 37. Wednesday 27 May 15
  38. 38. Gosei&Oy&all&rights&reserved. 35 Nooooooo! We can not change everything. Wednesday 27 May 15
  39. 39. Gosei&Oy&all&rights&reserved. Your Fear is Just Expecting big improvements without significant change is unreasonable! Changing “everything” in a small independent part is the ONLY way to real change. Experiment and learn with limited risk Resources for enough support Moore’s chasm 36 Wednesday 27 May 15
  40. 40. Project Y Project x Gosei&Oy&all&rights&reserved. Component teamComponent teamComponent team 37 Feature team Feature team Coordination cost Investment in learning Wednesday 27 May 15
  41. 41. 38 Flow of work Wednesday 27 May 15
  42. 42. Gosei&Oy&all&rights&reserved. Three Layers in (large) Organizations Business (top) management 39 Middle management Value adding workers Analyze Coordinate Intermediate Execute Technical reality Economical reality Internal reality Reward power Expert power Dependent power ->Politics Wednesday 27 May 15
  43. 43. Gosei&Oy&all&rights&reserved. Who is missing? 40 Business (top) management Middle management Value adding workers Analyze Coordinate Intermediate Execute Customer User Wednesday 27 May 15
  44. 44. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams Customer Problem Product Management Feature ?? Release Which team? Wednesday 27 May 15
  45. 45. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams Customer Problem Product Management Feature Specifiers Architects UI Release Wednesday 27 May 15
  46. 46. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams System integration Testing Deployment Customer Problem Product Management Coordination Feature Specifiers Architects UI Project Managers Release Wednesday 27 May 15
  47. 47. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams System integration Testing Deployment Customer Problem Product Management Coordination Feature Specifiers Architects UI Project Managers Release Bloated Backlog Wednesday 27 May 15
  48. 48. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams System integration Testing Deployment Customer Problem Product Management Coordination Feature Specifiers Architects UI Project Managers Release Bloated Backlog Wednesday 27 May 15
  49. 49. Gosei&Oy&all&rights&reserved. Technology specailization leads to functional silos 41 Component Teams System integration Testing Deployment Customer Problem Product Management Coordination Feature Specifiers Architects UI Project Managers Release Bloated Backlog Wednesday 27 May 15
  50. 50. Gosei&Oy&all&rights&reserved. Through backlog and specialists 42 Customer User Wednesday 27 May 15
  51. 51. Gosei&Oy&all&rights&reserved. From Technical To Customer Specialization 43 Wednesday 27 May 15
  52. 52. Gosei&Oy&all&rights&reserved. Flow of work with Customer Specialization 44 Customer Product Owner Deployment Release Wednesday 27 May 15
  53. 53. Gosei&Oy&all&rights&reserved. Flow of Work LeSS 45 Wednesday 27 May 15
  54. 54. Gosei&Oy&all&rights&reserved. 46 Nooooooo! It is too simplistic. We are so many! Wednesday 27 May 15
  55. 55. Gosei&Oy&all&rights&reserved. Yes, it is simple and not easy Technology, competence, identites and culture need to develop. Learning causes anxiety. Only survival anxiety is greater. (E. Schein) Takes time, like any real change. There will be worry and resistance. Leadership challenge 47 Wednesday 27 May 15
  56. 56. 48 Batch size and Queues Wednesday 27 May 15
  57. 57. Gosei&Oy&all&rights&reserved. SAFe Batch Size Planning cycle 3 months Create big batch of work to reduce total cost 49 Wednesday 27 May 15
  58. 58. Gosei&Oy&all&rights&reserved. LeSS Batch Size Planning 2 week increments Create small batches of work that will enable fast feedback 50 Wednesday 27 May 15
  59. 59. Optimal Batch Size Optimal Batch Size Gosei&Oy&all&rights&reserved. Why is the Batch Size Problem? 51 Wednesday 27 May 15
  60. 60. Gosei&Oy&all&rights&reserved. Product Development and Big Batches “We have found out that reducing batch size improves most development projects significantly.” -Six Myths of Product Development Stefan Thomke and Donald Reinertsen - 52 Wednesday 27 May 15
  61. 61. Gosei&Oy&all&rights&reserved. Queues SAFe 53 SAFe Loads the system full of queues for a Program Increment Optimizes resource utilization Wednesday 27 May 15
  62. 62. Gosei&Oy&all&rights&reserved. Queues LeSS 54 LeSS Tries to keep queues outside of system Optimizes outcome after each iteration Wednesday 27 May 15
  63. 63. Gosei&Oy&all&rights&reserved. General Problem With Queues and Big Batches 55 Big Batches Single Arrival Wednesday 27 May 15
  64. 64. Gosei&Oy&all&rights&reserved. Product Development and Queues “Queues delay feedback, causing developers to follow unproductive paths longer. They make it hard for companies to adjust to evolving market needs and to detect weaknesses in their product before it’s too late.” -Six Myths of Product Development Stefan Thomke and Donald Reinertsen - 56 Wednesday 27 May 15
  65. 65. 57 Coordination Summary Wednesday 27 May 15
  66. 66. Gosei&Oy&all&rights&reserved. Fundamental formula When coordinating the work to be done, the more technology-specialized the organization is and the more you want to optimize utilization the further into the future you need to plan. 58 Reach (length) of the plan = Utilization x Specialization Wednesday 27 May 15
  67. 67. Gosei&Oy&all&rights&reserved. Coordination Approaches Compared 59 SAFe LeSS Main control mechanism Solving dependencies Batch size Cost of dependencies Optimization Customer contact Organizational maturity Requires stability in Bureaucratic Clan Coordinate people People work with technology Big and slow tasks for scarce resources (people). 3-month releases needed to plan. Fast, small and parallel technical transactions. Sprint-long iterations. Coordination is seemingly necessary waste Learning to work with technology is investment Resource optimization (coordination) Outcome optimization Intermediated Direct Possible with lower skill Learning for the role “Natural” development Higher skill needed Learning what is needed Skilled evolution, leading learning Component organization functions in unchanging environment. Long-living teams adapt fast to changes in environment. Wednesday 27 May 15
  68. 68. 60 Business view Wednesday 27 May 15
  69. 69. Gosei&Oy&all&rights&reserved. Growth of the middle management 63 Customer, user From Agile Manifesto: Individuals and interaction Business and developers work together daily Face-to-face conversation Simplicity Self-organization Learning from reality Owner, capital, top management Front-line worker Wednesday 27 May 15
  70. 70. Gosei&Oy&all&rights&reserved. 1. New process and best practises by SAFe 64 Customer, user From Agile Manifesto: Individuals and interaction Business and developers work together daily Face-to-face conversation Simplicity Self-organization Learning from reality Owner, capital, top management Front-line worker Wednesday 27 May 15
  71. 71. Gosei&Oy&all&rights&reserved. 2. Dis-intermediating by LeSS 65 Customer, user From Agile Manifesto: Individuals and interaction Business and developers work together daily Face-to-face conversation Simplicity Self-organization Learning from reality Owner, capital, top management Front-line worker More with Wednesday 27 May 15
  72. 72. Gosei&Oy&all&rights&reserved. 66 Nooooooo! It will break! Wednesday 27 May 15
  73. 73. Gosei&Oy&all&rights&reserved. 69 Find your product to enable direct customer interaction. Build customer-oriented feature teams. Learning away from coordination chaos. Decoupling in practise. The Product Owner decides, customer interaction clarifies. The line management grows the value of the organization. LeSS Organizational design Wednesday 27 May 15
  74. 74. Your key questions What do you want? What do you dare? 70 Wednesday 27 May 15
  75. 75. SAFe LeSS Slogan Framed problem Value proposition for “Scaling Agile” Solution Main control mechanism Real-time delivery Adoption scope Program Execution Customer-centric Learning Internal efficiency Optimal response to customer demand Improved program execution Lean-Agile ways of working More with less: Effective and agile value-adding work Minimal bureaucracy Program process and best practises Organizational design: principles, guides, rules and 600 experiments for inspect and adapt Bureaucratic Market, Clan Detailed planned 3-month cycle. Continuously improve real-time delivery Program level One product first Gosei&Oy&all&rights&reserved. Questions 71 Wednesday 27 May 15
  76. 76. Thank You 72 Wednesday 27 May 15

×