Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Illuminating the potential of Scrum by comparing LeSS with SAFe

1,511 views

Published on

Scrum implementations have the characteristics of an iceberg. The tip of the iceberg is what is explicit in the Scrum Guide whilst the much larger mass under the waterline is deep adoption of the implications of Scrum and Lean. This is where far greater payoffs from Agile adoption are to be found. Unfortunately, few people are aware of many of the deep implications and far fewer have experienced a Scrum adoption that goes beyond the tip of the iceberg.

The recent articulation of LeSS and it’s contrast with SAFe is drawing attention to the difference between shallow and deep Scrum. This session will take you in a submersible below the waterline and use a spotlight to illuminate the vast potential to improve your organisation through deep Scrum.

In comparing LeSS with SAFe, we illuminate ways to…

1. Scale vertically, not just horizontally to help thousands pull together as one.
2. Reduce bureaucratic control and increase business-development collaboration.
3. Transform the win-lose contract game between business and IT into a win-win co-operative game.
4. Focus everyone on the end-customer and re-structure around this.
5. Produce a potentially shippable product increment every fortnight.
6. Enable the organisation to "turn on a dime, for a dime".
7. Enable anti-fragile self-optimising of both What customer value is created and How it is created.
8. Radically simplify organisational structure without the overheads of unnecessary specification, co-ordination and reporting roles.
9. Unleash the potential of real self-managing teams without this being unwittingly constrained.
10. Allow managers to shift from managing the what, the how and tracking to the much more impactful work of capability building.

Published in: Leadership & Management

Illuminating the potential of Scrum by comparing LeSS with SAFe

  1. 1. Illuminating the potential of Scrum by comparing LeSS with SAFe with Rowan Bunning, CST and CLP
  2. 2. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Please note • Goal of this session: awareness of the potential of ‘deep’ Scrum adoption at any scale. • More about that than an comparison between SAFe and LeSS. • There is lots to learn about Scrum by understanding the differences. • This is not an introduction to Scaled Agile Framework (SAFe) and Large- Scale Scrum (LeSS). • Appreciating the importance of some concepts may require deeper exploration than we have time for.
  3. 3. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Session outline • Unrealised potential • Key things to know about SAFe and LeSS • Business - Development relationship • Team structure and batching • Organisational control • Co-ordination • Where Scrum’s potential can be found
  4. 4. Unrealised potential
  5. 5. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Payoff vs Extent of Scrum Adoption Overall Payoff Extent of Scrum Adoption Deep Scrum including implications of Scrum and Lean principles Implementation as per what is explicit Scrum Guide only Superficial Scrum as typically implemented
  6. 6. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum adoption iceberg Scrum as typically adoptedWhat is Explicit in Scrum Guide The implications of Scrum that are implicit Explicit in LeSS The endless potential of continuous improvement Shallow adoption Deep adoption
  7. 7. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Single-function job titles No job titles or sub-teams Individuals accountable outside of team Team is accountable as a whole Content and timing of releases decided by committee Content and timing of releases decided by Product Owner Sprint Review involves inspection Sprint Review involves collaborative adaptation Shallow Scrum as typically adopted WhatisExplicitintheScrumGuide The Tip of the Adoption Iceberg…
  8. 8. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Content and timing of releases decided by Product Owner Sprint Review involves collaborative adaptation Pseudo / Potential Team Real / Exceptional Team Undone work each Sprint Potentially Shippable Product Increment Team work focus Whole Product focus Managers decide what, how and do tracking Managers support and build capability Co-ordination mostly centralised Co-ordination mostly decentralised Contract Game Co-operative Game Single-function specialists People with T-Shaped skills Temporary Projects Long-lived Product Development Component teams Feature Teams Bureaucratic control Market + Clan control Steep hierarchy Minimum viable hierarchy Team membership changes to fill skills gaps Stable teamsCentralised specifier roles Decentralised specification Multiple localised process improvement efforts Whole of organisational system process improvement ScrumMaster focussed on team ScrumMaster focussed on organisational system WDeepScrum-ImplicitinScrum Organisation as Factory Learning Organisation Deep Adoption…
  9. 9. Key things to know about SAFe and LeSS
  10. 10. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com 150 people Applicability Thousands of people >8 teams LeSS LeSS Huge SAFe - single ART Value Stream of ARTs 2 teams 12 people 50 people ART sweet spot: “100 or so” Who is working with a group of between 12 and 50?
  11. 11. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Different framings of the problem Customer-centric LearningProgram Execution
  12. 12. © 2014 Scrum WithStyle scrumwithstyle.com Not agile Thanks to: Joseph Pelrine
  13. 13. © 2014 Scrum WithStyle scrumwithstyle.com Becoming agile… Thanks to: Joseph Pelrine
  14. 14. © 2014 Scrum WithStyle scrumwithstyle.com Not like this though… Thanks to: Joseph Pelrine
  15. 15. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum Space for context-specific elements to emerge Prescriptiveness How detailed, complicated and fully-defined a framework is High • Not contextual enough • Over-specification makes it difficult for org. learning • In practice, leads to method bloat Example: Learning Organisations (Peter Senge, Chris Argyris etc.) Low • Just a few principles • Not enough that is concrete to know what to do • Easy to ‘fake-it’ Intent: • Sufficient enabling structure • Plenty of freedom for Empirical Process Control & learning Thanks to: Craig Larman
  16. 16. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com SAFe contains Scrum Scrum Scrum Team Program Value Stream Portfolio
  17. 17. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com LeSS is Scrum Team Program Value Stream Portfolio Scrum ➡
  18. 18. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb LeSS takes a different approach Rather than having Scrum as a building block for a scaled framework, we need to look at Scrum and for each element ask “Why is it there?” followed by “If we have more than one team, how can we achieve the same purpose on a larger scale?” - Craig Larman
  19. 19. 💡Insight… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum need not be limited to the ‘team level’. It scales vertically.
  20. 20. Business-Development relationship
  21. 21. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com External contracts spawn internal contracts Business External customers Development / I.T. External contract Internal contract
  22. 22. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com We want a solution. How much is it going to cost? How long is it going to take? Product Management R&Dstart end (release) www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business Development
  23. 23. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) content freeze (release contract agreed) more, more, more! 1 The Milestone point is arbitrary The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business Date & Scope Development
  24. 24. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) content freeze (release contract agreed) The Milestone point is arbitrary more, more, more! less, less, less! 1 2 The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business Development The date and scope contract point represents the time that both parties have maximised the ability to shift blame when something goes wrong. Date & Scope
  25. 25. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) content freeze (release contract agreed) The Milestone point is arbitrary The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business Development Date & Scope
  26. 26. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) content freeze (release contract agreed) The Milestone point is arbitrary The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Date & Scope Responsibility low control low flexibility low transparency big batches cannot release early not “done” until the end Business have completed date and scope move Development shifts
  27. 27. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Who has seen something like this going on? Who is working to an scope & date agreement now? Show of hands "
  28. 28. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) content freeze (release contract agreed) * Development Phase for The Contract is controlled by R&D. * The order of work is decided by R&D. * Product Management does not have control, and there is low visibility into the status of true progress. The Contract ineffective bonus schemes and "tracking to plan" behaviors are injected, since there is no real control or visibility www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business • Development Phase for The Contract is controlled by the development group • The order of work is decided by the development group • The Business does not have control, and there is low visibility into the status of true progress. Development
  29. 29. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Shifting blame Product Management R&Dstart end (release) content freeze (release contract agreed) The Milestone point is arbitrary The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. DevelopmentBusiness There’s been a surprise! But you committed! Date & Scope sign-off
  30. 30. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com We have a two party competitive game your faultyour fault Product Management R&Dstart end (release) your fault your fault The Contract www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business Development
  31. 31. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Now development pulls out the ‘Secret Toolbox’ including… • Stopping testing • Crappy code • No longer thinking about the design • No longer taking time to learn • Not fixing weakness in organisation • Overtime leading to attrition of the best people
  32. 32. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb On the SAFe PI Planning game “This planning process has history with Nokia Phones, where the upper management decided the schedule and content for the next model. Even when at the talk level this is assumed to communicate realism upwards, the process is really commitment game. Even, if the management culture accepts the spirit of realism, the process itself assumes that you are able to commit locally for the common good. The teams are "staying in the room" until they vote yes or no for the plan. They quickly learn to vote yes, because no means re-planning :)” - Ari Tikka (formerly at Nokia Mobile where SAFe began)
  33. 33. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com External contracts spawn internal contracts Business stakeholders External customers Agile Release Train PI scope and date commitment External demand
  34. 34. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com External contracts spawn internal contracts Business stakeholders External customers Teams External demand ✘ No Scope and Date contract ✔ Business steers directly ☸PO 📖
  35. 35. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com To eliminate the win-lose contract game between Business and Development and shift to a win-win co-operative game. To end the blame game. To begin rebuilding trust.
  36. 36. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com What does the Agile Manifesto have to say about this?
  37. 37. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Two simple but critical questions… Who is the customer to focus on? What is the product to focus on?
  38. 38. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Insurance company What is our Product really? Insurance Sales Underwriting Solution Premium Billing Claims System Quoting engine Leads and Opportunities Policy provider application Rules engine Premium system Insurance booking system Premium payment system Claim checker Pay back engine Underwriting workflow manager Thanks to: Viktor Grgić for the example The Market I see a Get Insurance system …and a Handle Claim system ‘System of systems’ (SAFe) or ‘Product’ (LeSS) Insured Customer Head of Department No, This is a product Architect No, This is a product Project Manager This is a product
  39. 39. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Whole Product Focus - Bas Vodde “It is really really hard to get teams to always consider the whole product instead of just “their tasks”. And in the LeSS Framework we do everything we can to avoid sandboxing, such as not preselecting items to teams, not having separate backlogs, not having separate POs, etc.” Lean Principle: Optimise the Whole
  40. 40. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com to help the organisation focus on the end customer by defining your product in terms of what creates value for the customer.
  41. 41. Team structure and batching
  42. 42. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Component teams lead to planning complexity Item 1 Item 2 Item 3 ... Item 20 … Item 42 current release: need more people next release: need more people System next release current release Comp A Team Comp B Team Comp C Team Component A Component B Component C www.craiglarman.com www.odd-e.com Copyright © 2009 C.Larman & B. Vodde All rights reserved. How to manage these dependencies?
  43. 43. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Planning around component teams Image credit: boost.co.nz
  44. 44. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com LeSS emphasises Feature-teams that are multi-component Item 1 Item 2 Item 3 Item 4 … … Comp A Team Comp B Team Comp C Team Component A Component B Component C Product Owner Feature Team Red tasks for A tasks for B tasks for A tasks for B tasks for A tasks for C contains ex-members from component teams A, B, and C, and from analysis, architecture, and testing groups system www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  45. 45. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Dependencies are pushed from planning to integration Item 1 Item 2 Item 3 Item 4 ... … system comp C Team comp A Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery of low-value items. Work scope is narrow. Product Owner comp B Team comp A Team comp B comp C Item 1 Item 2 Item 3 Item 4 ... … Team Wu Product Owner Team Shu Team Wei system comp A comp B comp C Every team completes customer- centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning. Work scope is broad. Component teams Feature teams www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  46. 46. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Co-ordination is in shared code Item 1 Item 2 Item 3 ... Item 8 … Item 12 Team Wei Team Shu Team Wu Component A Component B Component C With feature teams, teams can always work on the highest-value features, there is less delay for delivering value, and coordination issues shift toward the shared code rather than coordination through upfront planning, delayed work, and handoff. In the 1960s and 70s this code coordination was awkward due to weak tools and practices. Modern open-source tools and practices such as TDD and continuous integration make this coordination relatively simple. system www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  47. 47. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Feature teams are customer-centric Team has the necessary knowledge and skills to complete an end-to-end customer-centric feature. If not, the team is expected to learn or acquire the needed knowledge and skill. Feature team: - stable and long-lived - cross-functional - cross-component customer- centric feature potentially shippable product increment Product Backlog www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  48. 48. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com SAFe Batch Size Thanks to: Ran Nyman and Ari Tikka, Xp2015 Scaling Agility explored - LeSS SAFe comparison Development System Work pre-allocated to Sprints for 8-12 weeks Large batches to reduce cost due to component teams Program Increment Backlog
  49. 49. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb The trade-off Pre-allocating items to Sprints ahead of time closes off options and diminishes Sprint-to-Sprint agility.
  50. 50. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com LeSS Batch Size Thanks to Ran Nyman and Ari Tikka, Xp2015 Scaling Agility explored - LeSS SAFe comparison Development System 2 weeks Small batches that enable fast feedback Backlog Potentially Shippable Product Increment SPRINT REVIEW RETROSPECTIVE OVERALL RETROSPECTIVE SPRINT PLANNING 1PREVIOUS SPRINT NEXT SPRINT PRODUCT BACKLOG PRODUCT OWNER SPRINT BACKLOG SCRUMMASTER & FEATURE TEAM PRODUCT BACKLOG REFINEMENT DAILY SCRUM COORDINATION POTENTIALLY SHIPPABLE PRODUCT INCREMENT SPRINT PLANNING 2
  51. 51. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com to produce a Potentially Shippable Product Increment every fortnight… no matter how many teams… as long as they are feature teams integrating continuously. Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
  52. 52. Organisational Control
  53. 53. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Program Value Stream Program control abstraction Value Stream control abstraction SAFe introduces control abstractions Teams Customer focused Product Customer
  54. 54. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Control systems in organisations Market system Bureaucratic system Clan system • Prices drive very efficient decision making • Measure Input and Output • Formal rules, roles, processes, compliance • Supervision, direction and hierarchy • Specialisations enable clearer comparison with like workers • Informal value based rules • Allows innovation and collaboration • Most suitable for unique, interdependent or ambiguous work e.g. software development Reference: A Conceptual Framework for the Design of Organizational Control Mechanisms, William G. Ouchi, Management Science, Vol. 25, No. 9. 1979.
  55. 55. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Control mechanisms in SAFe Market control Bureaucratic control many roles, processes, written rules to manage execution within PI Scope & Date contract Clan control
  56. 56. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Who would like less Bureaucratic control? Market control Bureaucratic control Clan control You Ain’t Gonna Need It (YAGNI) Try… direct business - development collaboration using the simplicity of Scrum patterns for Minimum Viable Bureaucracy (MVB)
  57. 57. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Control mechanisms in LeSS Market system Bureaucratic control Clan control self-managing teams self co-ordination decisions at level of richest information PO ≪component≫ Publishing ≪component≫ Scheduling ≪component≫ Expenses ≪component≫ KPI Dashboards Direct co-ordination Communities for knowledge sharing and agreements Architecture, UX, Testing etc. 💡 $ 😀 ☸
  58. 58. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb LeSS is about Descaling… • Descaling roles and organisational hierarchy • Descaling organisational structures, policies, etc. • Descaling architectural complexity LeSS is More!
  59. 59. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com to decrease bureaucracy and increase business-development collaboration For more on this see:
  60. 60. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com The heart of Scrum Thanks to: Simon Bennett. Vision Product Inspect & Adapt People Capability Inspect & Adapt
  61. 61. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Frequency of Demos vs Sprint Reviews Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Sprint Reviews - Inspect & Adapt Whole Product (2hrs max) Team Demos Solution Demo (After all PI System demos, 1-2 hour) System Demos
  62. 62. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Frequency of overall reflection Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Value Stream Retrospective and Problem-solving workshop PI Retrospective and Problem-solving workshop Overall Retrospectives - Inspect & Adapt Organisational System
  63. 63. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Demos vs Sprint Reviews Sprint Review Purpose: “inspect the Increment and adapt the Product Backlog” Intent: “optimise value” Solution Demo Purpose: “stakeholder and customer feedback” “celebrate the accomplishments” “harbinger of near- term… decisions” Mostly Value Stream and senior ART people PI System Demo Purpose: “to test and evaluate the full system” Intent: “stay on course or take corrective action” Mostly PMs, POs and senior people One or more team members there to stage demo Team Demo Purpose: “closure” “to show” “feedback” “measure the team’s progress” Mostly teams and POs Senior people likely not interested “The Sprint Review is an opportunity for everyone to collaborate about the product.” - less.works 😃 $
  64. 64. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Business and development collaborate face- to-face on the direction of the product… every Sprint. To focus everyone on the Whole Product. To “turn on a time, for a time” 📖
  65. 65. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Owner: Team or Product focused? Team Business Owner Customer Product Manager 2..4 Product Owner 1..2 The Product Owner The Product Owner is responsible for maximizing the value of the product The person with the external (market) contract problem steers directly PO ☸
  66. 66. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Product Owner can work with up to 8 teams when clarification is delegated PO Requesters Users Market / domain experts Decisions Content and order of Product Backlog Detail Clarification - splitting, acceptance criteria etc. 💡 $ 😀 “Yes” “No” “A little now, rest later” “Sooner” “Later” ☸
  67. 67. 💡Insight… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum facilitates direct interaction between business people and development teams… …and not just with the Product Owner.
  68. 68. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com www.nature.com/scientificreports Hierarchy is Detrimental for Human Cooperation KatherineA.Cronin1,2 , Daniel J.Acheson3 , Penélope Hernández4 &Angel Sánchez5,6 Studies of animal behavior consistently demonstrate that the social environment impacts cooperation, yet the effect of social dynamics has been largely excluded from studies of human cooperation. Here, we introduce a novel approach inspired by nonhuman primate research to address how social hierarchies impact human cooperation. Participants competed to earn hierarchy positions and then could cooperate with another individual in the hierarchy by investing in a common effort.Cooperation was achieved if the combined investments exceeded a threshold, and the higher ranked individual distributed the spoils unless control was contested by the partner.Compared to a condition lacking hierarchy, cooperation declined in the presence of a hierarchy due to a decrease in investment by lower ranked individuals. Furthermore, hierarchy was detrimental to cooperation regardless of whether it was earned or arbitrary.These findings mirror results from nonhuman primates and demonstrate that hierarchies are detrimental to cooperation. However, these results deviate from nonhuman primate findings by demonstrating that human behavior is responsive to changing hierarchical structures and suggests partnership dynamics that may improve cooperation.This work introduces a controlled way to investigate the social influences on human behavior, and demonstrates the evolutionary continuity of human behavior with other primate species. recei e : 30 a 015 accepte : 0 o em er 015 Pu is e : Decem er 015 OPEN
  69. 69. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com CPJ inspired by Jeff Bezos' most recent annual letter. https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c Which is Scrum enabling?
  70. 70. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb The responsive organisation “The future of work is... an organisation — a decision system — built to break down big decisions and jobs into smaller pieces that can be processed much more rapidly, replacing the illusion of top-down control over the future with realtime, active control over the present. It’s an organisation where very few decisions are made for others, but many more decisions are being made in the open.” From CPJ inspired by Jeff Bezos' most recent annual letter. https://medium.com/21st-century-organizational-development/type-2-organizations-df3f1f53c66c Who would prefer something like this?
  71. 71. Co-ordination
  72. 72. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum of Scrums: ScrumMaster vs Team representative “The ScrumMaster is typically the representative in the Scrum of Scrums meeting, and he passes information from that meeting back to the team.” “ScrumMasters… meet to update their progress toward Milestones, program PI objectives and internal dependencies…” “A healthy Scrum of Scrums meeting is attended by team members who do actual development work and not ScrumMasters or the Product Owner.” Intermediation Point-to-point connection
  73. 73. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Co-ordination overheads can be reduced Source: less.works/resources/graphics.html
  74. 74. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Co-ordination mechanisms Centralised mechanisms Scheduled meetings Disadvantages: • bottlenecks • handoffs • delays • inhibit emergent behaviour • teams owning these processes • inhibit empirical process control Decentralised mechanisms Networks of people interacting Disadvantages: • more difficult to get an overview • less broad and consistent info
  75. 75. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Co-ordination: Centralised vs Decentralised • Just talk • Communicate in Code • Integration Continuously • Communities • Cross-Team Meetings • Multi-Team Design Workshops • Current-Architecture Workshops • Component Mentors • Open Space • Travellers • Scouts • Maybe don’t do Scrum of Scrums • Leading Team • PI Planning • Pre-PI Planning • Post-PI Planning • Scrum of Scrums • Weekly Release Management meetings Mostly Centralised mechanisms Mostly Decentralised mechanisms
  76. 76. Scrum has the potential… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com to radically simplify organisational structure without the overheads of unnecessary specification, co-ordination and reporting roles.
  77. 77. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com ScrumMaster: Part-time vs Full-time “SAFe takes a pragmatic approach and assumes, in general, that the ScrumMaster is a part-time role” Dedicated full-time role In LeSS, the ScrumMaster role is vital. We’ve seen many organizations try part-time ScrumMasters, which usually leads to no ScrumMasters at all. This then affects the LeSS adoption enormously. In LeSS the ScrumMaster is a dedicated, full-time role in the same way that being a Scrum Team member is a dedicated, full-time role. Having said that, it is possible for one full-time ScrumMaster fill the role for up to three teams, depending on any number of factors.
  78. 78. Where Scrum’s potential can be found
  79. 79. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Single-function job titles No job titles or sub-teams Individuals accountable outside of team Team is accountable as a whole Content and timing of releases decided by committee Content and timing of releases decided by Product Owner Sprint Review involves inspection Sprint Review involves collaborative adaptation Shallow Scrum as typically adopted TipoftheIceberg-ExplicitinScrum What SAFe explicitly encourages (1) (See items in black)
  80. 80. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Pseudo / Potential Team Real / Exceptional Team Undone work each Sprint Potentially Shippable Product Increment Team work focus Whole Product focus Managers decide what, how and do tracking Managers support and build capability Co-ordination mostly centralised Co-ordination mostly decentralised Contract Game Co-operative Game Single-function specialists People with T-Shaped skills Temporary Projects ✔ Long-lived Product Development Component teams Feature Teams Bureaucratic control Market + Clan control Steep hierarchy Minimum viable hierarchy Team membership changes to fill skills gaps ✔ Stable teamsCentralised specifier roles Decentralised specification Multiple localised process improvement efforts Whole of organisational system process improvement ScrumMaster focussed on team ScrumMaster focussed on organisational system DeepScrum-ImplicitinScrum Organisation as Factory Learning Organisation What SAFe explicitly encourages (2) (See items in black)
  81. 81. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Single-function job titles ✔ No job titles or sub-teams Individuals accountable outside of team ✔ Team is accountable as a whole Content and timing of releases decided by committee ✔ Content and timing of releases decided by Product Owner Sprint Review involves inspection ✔ Sprint Review involves collaborative adaptation Shallow Scrum as typically adopted TipoftheIceberg-ExplicitinScrum What LeSS explicitly encourages (1) (See items in black)
  82. 82. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Pseudo / Potential Team ✔ Real / Exceptional Team Undone work each Sprint ✔ Potentially Shippable Product Increment Team work focus ✔ Whole Product focus Managers decide what, how and do tracking ✔ Managers support and build capability Co-ordination mostly centralised ✔ Co-ordination mostly decentralised Contract Game ✔ Co-operative Game Single-function specialists ✔ People with T-Shaped skills Temporary Projects ✔ Long-lived Product Development Component teams ✔ Feature Teams Bureaucratic control ✔ Market + Clan control Steep hierarchy ✔ Minimum viable hierarchy Team membership changes to fill skills gaps ✔ Stable teamsCentralised specifier roles ✔ Decentralised specification Multiple localised process improvement efforts ✔ Whole of organisational system process improvement ScrumMaster focussed on team ✔ ScrumMaster focussed on organisational system DeepScrum-ImplicitinScrum Organisation as Factory ✔ Learning Organisation What LeSS explicitly encourages (2) (See items in black)
  83. 83. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Structure has a first-order impact on Culture Excerpt from Larman’s Laws of Organisational Behaviour… 4. Culture follows structure. Or, Culture/behavior/mindset follows system & organisational design. …systems such as Scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture — if the structural change implications of Scrum are actually realized. Source: craiglarman.com
  84. 84. 💡Insight… @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Scrum is a catalyst for meaningful structural change. Structure has a first-order impact on Culture. Process is a lower order influencer.
  85. 85. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Review 1. Scale vertically, not just horizontally to help thousands pull together as one. 2. Reduce bureaucracy and increase business-development collaboration. 3. Transform the win-lose contract game between business and IT into a win-win collaboration game. 4. Focus everyone on the end-customer and re-structure around this. 5. Produce a potentially shippable product increment every fortnight. 6. Enable the organisation to "turn on a dime, for a dime". 7. Enable resilient self-adapting of both What customer value is created and How it is created. 8. Radically simplify organisational structure without the overheads of unnecessary specification, co-ordination and reporting roles.
  86. 86. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb Conclusions • The implications of Scrum extend well beyond ‘team level’ • Few organisations have come close to realising the potential pay-offs from Scrum’s implications in the large • LeSS provides more explicit guidance on Scrum’s implications in the bigger picture • The biggest initial barriers to realising potential is understanding and buy-in
  87. 87. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com
  88. 88. @rowanb© 2016 Scrum WithStyle scrumwithstyle.com Where Scrum’s potential is articulated less.works Coming soon…
  89. 89. © 2016 Scrum WithStyle scrumwithstyle.com @rowanb We’re@rowanb au.linkedin.com/in/rowanbunning Rowan Bunning rowan@scrumwithstyle.com scrumwithstyle.com

×