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.

Introduction to Large-Scale Scrum LeSS


Published on

This material or a variation of this was presented at:
Monday April 20 at the Sydney Scrum User Group, Australia
Wednesday June 26 at Equinox IT breakfast event in Auckland, New Zealand
Wednesday July 1 at Equinox IT evening event in Wellington, New Zealand

The objective of this session is to introduce you to Large-Scale Scrum (LeSS) - a scaling framework based on over 10 years of experience with large-scale and multi-site Agile implementations (particularly in Asia). For an example of what large-scale can mean in practice, LeSS Huge framework (for over 8 teams) is currently being used by a product development group of 2,500 working on a single product at 10+ sites around the world.

You don't have to be working in a very large product development group for LeSS patterns to be useful however. LeSS can be useful with as few as two teams.

LeSS is particularly relevant for Scrum practitioners since LeSS is simply Scrum at Scale. The way it is designed highlight key Scrum principles and concepts, some of which are poorly understood and appreciated (even by many Agile practitioners). Examples include 'real teams', disintermediation, the core function of Product Ownership and the scope of the ScrumMaster role.

Studying LeSS may well lead you to a deeper understanding of single-team Scrum.

Published in: Leadership & Management
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website!
    Are you sure you want to  Yes  No
    Your message goes here

Introduction to Large-Scale Scrum LeSS

  1. 1. © 2015 Scrum WithStyle Introduction to A short introduction to Large-Scale Scrum April, June, July 2015 with Rowan Bunning, Certified Scrum Trainer
  2. 2. © 2015 Scrum WithStyle Credit: This slide deck includes diagrams that are © C. Larman and B. Vodde. Thanks to Craig and Bas for sharing these and other diagrams at This material or a variation of this was presented at: • Monday April 20 at the Sydney Scrum User Group, Australia • Wednesday June 26 at Equinox IT breakfast event in Auckland, New Zealand • Wednesday July 1 at Equinox IT evening event in Wellington, New Zealand Thanks to the following event sponsors Equinox IT IndustrieIT Scrum Australia Scrum WithStyle
  3. 3. © 2015 Scrum WithStyle Rowan Bunning Scrum WithStyle Pty Ltd • Background in object oriented & web dev. with vendors, enterprise product development, start-ups & consultancies • Introduced to Agile via eXtreme Programming in 2001 as: “the way good Smalltalkers develop software” • Introduced Scrum organisation-wide in 2003-4 • Agile Coach / ScrumMaster at a leading agile consultancy in the U.K. • Have trained approx. 3,000 people in Scrum & Agile • Certified ScrumMaster® • Certified Scrum Product Owner® • Effective User Stories • Agile Estimating and Planning etc. • Agile Coach in Australia since late 2008 • Organiser of Regional Scrum Gatherings® in Australia
  4. 4. © 2015 Scrum WithStyle Q: Who has more than 10 people working on the same product / project / program?
  5. 5. © 2015 Scrum WithStyle Session Outline • A Scaling Story • LeSS is Scrum at Scale • Positioning LeSS • LeSS Principles • LeSS Structure • LeSS Management • LeSS Adoption • Q&A
  6. 6. © 2015 Scrum WithStyle A Scaling Story London, England 2007-8
  7. 7. © 2015 Scrum WithStyle The problem • Multi-national operating in 43 countries • Required a globally unified CRM order management system with real time customer data • To be integrated with 34 instances of a legacy system • Business Process Re-engineering heavy • Siebel, Oracle Fusion, Mainframe, OLAP and Business objects • Had spent several years and £_____ Million on failed attempts that delivered nothing of value using waterfall-style predictive processes and traditional programme management
  8. 8. © 2015 Scrum WithStyle We succeeded using scaled-up Scrum • 25,000 hours of development and test effort • Added 1 new Scrum team per month to… • 160 people in delivery • 5 different locations (UK x2 , India x2 and Russia) • 5 different vendors • Production release cycle reduced to 7 weeks (4 of these were in Sprint) • £20m for two major functional releases and a new middleware layer infrastructure component • “the best relationship between a project and the business community I have ever seen” - senior stakeholder
  9. 9. © 2015 Scrum WithStyle Scaled-up Scrum Product Backlog • Feature A • Feature B • Feature C • Feature D • Overall PO and Product Backlog • Streams split to minimise dependency • Separate Stream Owners Team BTeam A Area 1 Backlog • Feature A • Feature C • Feature F • Feature I Area 2 Backlog •Feature B •Feature D •Feature G •Feature H Team G Area 3 Backlog •Feature E •Feature H •Feature J •Feature K Thanks to: Colin Bird. Team C Team ETeam D Team F Team H
  10. 10. © 2015 Scrum WithStyle Scaling patterns used in 2007-8 • Single overall Product Backlog • Areas split down lines of least dependency • Feature teams • Single Sprint • Simultaneous Backlog Refinement • Big room Sprint Planning • Common development standards • Multi-team continuous integration • Common Definition of Done • Whole product Sprint Review • Offshore-onshore rotation
  11. 11. © 2015 Scrum WithStyle What’s your probably of success? Reference: The Chaos Report, The Standish Group, 2013. See: The Chaos Report, The Standish Group, 2013. CHAOS Resolution by Large and Small Projects
  12. 12. © 2015 Scrum WithStyle Q: What makes scaling-up Agile difficult? A: Organisational design flaws (in comparison to Agile and Lean principles) The organisation was not designed with Agile and Lean principles in mind. Traditional organisations become more complicated over time. Large product development groups typically feature… • Functional groups • Big batches • Sequential processes • Weak feedback loops • Lots of handoffs Thanks to Craig Larman.
  13. 13. © 2015 Scrum WithStyle LeSS is Scrum at Scale
  14. 14. © 2015 Scrum WithStyle
  15. 15. © 2015 Scrum WithStyle Large-Scale Scrum (LeSS) structure PO One Product Backlog Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Item #1 Item #2 Item #3 … Up to about eight teams One Sprint Backlog per Team One dedicated ScrumMaster per 1-3 Teams One Product Owner
  16. 16. © 2015 Scrum WithStyle One Sprint, One ‘Done’, Many Teams
  17. 17. © 2015 Scrum WithStyle Sprint Backlog Product Owner Product Backlog 2-4 week Sprint Daily Scrum (15 min) 1 day Sprint Retrospective (1.5-3 h) Sprint Planning Part 2 (2-4 h) + + + (Feature) Team + ScrumMaster Sprint Planning Part 1 (2-4 h) Representatives from each team decide division of Items and identify dependencies Joint Retrospective (1.5 h) ScrumMasters and one representative from each team meet early in next Sprint Product Backlog Refinement (5-10% of Sprint) All teams in one room with own learning tools (whiteboards, projectors etc.) Potentially Shippable Product Increment Ability to ship every Sprint, rather than only when ‘train’ leaves Sprint Review (2-4 h) Using ‘science-fair’ style diverge - converge format
  18. 18. © 2015 Scrum WithStyle Potentially Shippable Product Increment Product Owner Area Product Owner Area Product Backlog Product Backlog SprintRetrospective SprintReview JointRetrospective 1 day 2-4 week Sprint Product Backlog Refinement Sprint Planning Part 2 Sprint Planning Part 1 (2-4 h) (15 min) (2-4 h) (5-10% of Sprint) (Feature) Team + ScrumMaster Sprint Backlog Daily Scrum Copyright © 2010 C.Larman & B. Vodde All rights reserved. LeSS Huge
  19. 19. © 2015 Scrum WithStyle LeSS Huge
  20. 20. © 2015 Scrum WithStyle 2-4 week Sprint Daily Scrum (15 min) 1 day SAD workshop Joint Backlog Refinement Team design Design workshop at start of each feature Big room Backlog Refinement All teams in one room with own learning tools (whiteboards, projectors etc.) Cross-team architecture Joint design workshop initiated by Community of Practice facilitator Shared understanding of existing architecture Agile System Architecture Document (SAD) workshop every few Sprints Joint design workshop Cross-team analysis and design
  21. 21. © 2015 Scrum WithStyle Collaborative modelling over specification handoff Image credit:
  22. 22. © 2015 Scrum WithStyle
  23. 23. © 2015 Scrum WithStyle Positioning LeSS Large-Scale Scrum
  24. 24. © 2015 Scrum WithStyle Experiments Guides Framework LeSS is based on 10+ years of real-world experiments Principles
  25. 25. © 2015 Scrum WithStyle Books 2008 2010 Sept 20151995 2003
  26. 26. © 2015 Scrum WithStyle Traditionally, all of this becomes part of a ‘Program’ Business Product > IT Product Business Product e.g. Transaction Banking IT ‘Products’ (often systems or components) Direct Entry system Domestic payments system Collections system International payments In LeSS, the customer- centric business product is ‘the product’ we focus on
  27. 27. © 2015 Scrum WithStyle LeSS has broad applicability LeSS LeSS Huge 2 teams 2,500+ people working on a single product >8 teams
  28. 28. © 2015 Scrum WithStyle Prescriptiveness How detailed, complicated and fully-defined a framework is Example: Rational Unified Process (RUP) 120+ roles, work products and tasks 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.) a few principles Low • Not enough that is concrete to know what to do • Easy to ‘fake-it’ Sweet-spot • Sufficient enabling structure • Plenty of freedom for Empirical Process Control & learning
  29. 29. © 2015 Scrum WithStyle LeSS Principles
  30. 30. © 2015 Scrum WithStyle LeSS Principles and Themes
  31. 31. © 2015 Scrum WithStyle • A given system has finite performance characteristics • Your organisation is optimised to produce the results is currently produces • To produce different results, you need to change the system To get from Auckland to Hamilton… To get from Auckland to Sydney… Systems Thinking
  32. 32. © 2015 Scrum WithStyle Impossible To deliver on something outside current capability, invest in expanding capability Current capability 💰 Managers
  33. 33. © 2015 Scrum WithStyle - Large-Scale Scrum: More with LeSS by Craig Larman, Bas Vodde “LeSS is ‘incomplete’; it has space for the vast situational learning. ” Transparency, Inspect, Adapt Empirical Process Control •Daily Scrum •Sprint Review •Sprint Retrospective •Joint Retrospective
  34. 34. © 2015 Scrum WithStyle Amplify learning by shortening feedback loops Image credit: sir_leif length of feedback loop causeeffect inspect adapt
  35. 35. © 2015 Scrum WithStyle 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
  36. 36. © 2015 Scrum WithStyle LeSS Structure Real Teams, Feature Teams
  37. 37. © 2015 Scrum WithStyle
  38. 38. © 2015 Scrum WithStyle Our IT organisations have been optimising around Waterfall for years
  39. 39. © 2015 Scrum WithStyle Intermediaries End User Support Subject Matter Expert Business Analyst System Analyst Solution Architect Tech Lead Developers Translators Co-ordinators Project Manager Programme Manager
  40. 40. © 2015 Scrum WithStyle Disintermediate End User Developers Facilitation PO Prioritisation Direct
  41. 41. © 2015 Scrum WithStyle 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 Copyright © 2009 C.Larman & B. Vodde All rights reserved.
  42. 42. © 2015 Scrum WithStyle Component teams lead to waterfall Backlog Item 1 Backlog Item 2 ... Comp A Team Comp B Team Comp C Team Analyst System Engineer System Testers Iteration 1 Iteration 2 (probably later) Iterations 3-5 (probably later and more) At least iteration 6 (probably later) Item 1 requirement details for Item 1 'backlog' by component not all teams start Item 1 at the same iteration; they are multitasking on multiple features system testers cannot start immediately on Item 1; they are multitasking on multiple features not available until the analyst is finished Analysis Design Implementation Test Component teams lead to a sequential life cycle with handoff, queues, and single-specialist groups and not true cross-functional teams without handoff. code Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  43. 43. © 2015 Scrum WithStyle Feature-teams 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 Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  44. 44. © 2015 Scrum WithStyle 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 Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  45. 45. © 2015 Scrum WithStyle 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 Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  46. 46. © 2015 Scrum WithStyle 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 Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  47. 47. © 2015 Scrum WithStyle LeSS Management Role of Manager and Self-Management
  48. 48. © 2015 Scrum WithStyle
  49. 49. © 2015 Scrum WithStyle Real teams Equally committed to a common purpose, goals, and working approach for which they hold themselves mutually accountable. All the characteristics of a real team, but the members are deeply committed to one another’s personal growth and development Reference: Katzenbach, J. R. and Smith, D.K. (1993), The Wisdom of Teams: Creating the High-performance Organisation, Harvard Business School, Boston. Time Performanceimpact
  50. 50. © 2015 Scrum WithStyle Types of teams Reference: J. Richard Hackman (2002) Leading Teams: Setting the Stage for Great Performances
  51. 51. © 2015 Scrum WithStyle Managers become capability builders Reference: Flow
  52. 52. © 2015 Scrum WithStyle LeSS Adoption Coaching
  53. 53. © 2015 Scrum WithStyle Organisational coaching Team coaching Technical Practice coaching Deep and narrow over broad and shallow Top-down and bottom-up Use volunteering Educate everyone Have appropriately-structured teams Define ‘done’ Only the Product Owner gives work to the teams Keep project managers away from the teams
  54. 54. © 2015 Scrum WithStyle Specialisation in the customer dimension - Large-Scale Scrum: More with LeSS by Craig Larman, Bas Vodde
  55. 55. © 2015 Scrum WithStyle - Large-Scale Scrum: More with LeSS by Craig Larman, Bas Vodde
  56. 56. © 2015 Scrum WithStyle What LeSS is not… • The ‘Contract Game’ which sets up win-lose dynamics between Business & Development • Continuing heavy dependency load and delay inherent with component teams • A relatively heavy method that needs to be tailored down to smaller groups (<50 ppl) • Scrum being ‘contained’ within something less adaptable • Requiring big batch Release Train planning with scope commitments made to executives • Product Owners from IT who are specifiers and not empowered to make commercial decisions • Prioritisation by formula • Disallowing developers and stakeholders from collaborating at the same product review • Many roles with intermediated communication up and down hierarchies • Recommending part-time, temporary ScrumMasters • Limiting retrospectives to individual teams without overall cross-team retrospectives
  57. 57. © 2015 Scrum WithStyle To learn more about LeSS…
  58. 58. © 2015 Scrum WithStyle See the website
  59. 59. © 2015 Scrum WithStyle Webinar recording Overcome common Agile problems by using Large-Scale Scrum (LeSS) See:
  60. 60. © 2015 Scrum WithStyle Questions?
  61. 61. © 2015 Scrum WithStyle @rowanb Rowan Bunning Thankyou! Keepintouch