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.

More Agile and LeSS dysfunction - may 2015

2,539 views

Published on

Whilst becoming proficient at single-team Agile is not easy, scaling to many teams and possibly many sites adds many additional challenges.


Often these challenges include...

1. Water-Scrum-Fall
2. The 'contract game' and its misalignment with "customer collaboration over contract negotiation"
3. Release rigidity - inability to adjust scope and/or release timing in order to maximise value for money
4. Limited visibility and transparency
5. Dependency hell
6. Skills bottlenecks
7. Lack of cross-team learning
8. Lack of design and architectural alignment whilst avoiding 'ivory tower' architecture
9. Inability to resolve organisational mis-alignment issues outside of delivery teams

Not all frameworks marketed as Agile are designed to address these problems.

In this session, we will introduce Large-Scaled Scrum (LeSS) as an organisational design framework and illustrate how it provides solutions to problems that commonly lead to friction, deliver challenges and difficulties realising the benefits of Agile within large programs and product development efforts.

We will outline each organisational dysfunction / scaling challenge, and connect these with the elements of LeSS that avoid the dysfunction or greatly LeSSen the problem

First presented on 7 May 2015 at
Project Management Institute (PMI) Sydney Chapter Meetup
http://www.meetup.com/PMISydneyMeetup/events/219823489/

Published in: Leadership & Management
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

More Agile and LeSS dysfunction - may 2015

  1. 1. © 2015 Scrum WithStyle scrumwithstyle.com Overcome common Agile problems by using Large-Scale Scrum (LeSS) Real-world scaling problems and solutions from Large-Scale Scrum May, July 2015 with Rowan Bunning, CST
  2. 2. © 2015 Scrum WithStyle scrumwithstyle.com 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 less.works This material or a variation of this was presented at: • May 7 at Project Management Institute (PMI) Sydney, Sydney Australia • May 19 at Agile @ Scale meetup, Sydney Australia • July 1 at Equinox IT webinar. View the recording at: equinox.co.nz/resources Thanks to the following event sponsors Equinox IT equinox.co.nz Sirius Technology siriustechnology.com.au Suncorp suncorp.com.au
  3. 3. © 2015 Scrum WithStyle scrumwithstyle.com Our IT organisations have been optimising around Waterfall for years
  4. 4. © 2015 Scrum WithStyle scrumwithstyle.com Was your project / product organisation designed with this in mind?
  5. 5. © 2015 Scrum WithStyle scrumwithstyle.com How many of these principles is your organisation based on? Image credit: less.works
  6. 6. © 2015 Scrum WithStyle scrumwithstyle.com Q: What challenges are there? 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
  7. 7. © 2015 Scrum WithStyle scrumwithstyle.com Session Outline • Why is Agility at scale difficult? • A thought on Systems Thinking • Quick Intro to LeSS • Water-Scrum-Fall • Dependency Hell • Release Rigidity • The Contract Game • Lack of Cross-team Learning • Lack of Design and Architectural Alignment
  8. 8. © 2015 Scrum WithStyle scrumwithstyle.com A thought on Systems Thinking
  9. 9. © 2015 Scrum WithStyle scrumwithstyle.com • 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 Wellington to Palmerston North… To get from Wellington to Sydney… Systems Thinking
  10. 10. © 2015 Scrum WithStyle scrumwithstyle.com Impossible To deliver on something outside current capability, invest in expanding capability Current capability 💰 Managers
  11. 11. © 2015 Scrum WithStyle scrumwithstyle.com Quick Intro to LeSS
  12. 12. © 2015 Scrum WithStyle scrumwithstyle.com Experiments Guides Framework LeSS is based on 10+ years of real-world experiments Principles
  13. 13. © 2015 Scrum WithStyle scrumwithstyle.com Books 2008 2010 Sept 20151995 2003
  14. 14. © 2015 Scrum WithStyle scrumwithstyle.com 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
  15. 15. © 2015 Scrum WithStyle scrumwithstyle.com 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 scrumwithstyle.com One Sprint, One ‘Done’, Many Teams
  17. 17. © 2015 Scrum WithStyle scrumwithstyle.com LeSS Huge - multiple Requirement Areas
  18. 18. © 2015 Scrum WithStyle scrumwithstyle.com Water-Scrum-Fall
  19. 19. © 2015 Scrum WithStyle scrumwithstyle.com Is Agile being ‘contained’ within something quite different? Image credit: andrejkoelewijn.com
  20. 20. © 2015 Scrum WithStyle scrumwithstyle.com 😃😞 Water - Scrum - Fall 💡 $ ArchitectsBusiness AnalystsProject Control Board User Reps Operations SIT UAT System Testers Deployment Benefits Realisation begins Envisioning Big Batch Specification Big Batch Project Scope Product Backlog Users Released 2 weeks each Sprint Many months Many months Limited Coverage Agile Team Programmers & Testers only Dependent on other functional groups to get things specified or released. The other groups are using a big-batch model.
  21. 21. © 2015 Scrum WithStyle scrumwithstyle.com 😞😃 Scrum $ Flow of Value Benefits Realisation begins Vision & Business Goals Product Backlog Users Feature Team that is fully cross-functional 2 weeks each Sprint Released💡 Feedback re Product and Process quality OperationsSystem Testers The Agile Team has the skills and authority to create Potentially Shippable Product Increments each Sprint Architect Business Analysts Broadening of skills
  22. 22. © 2015 Scrum WithStyle scrumwithstyle.com
  23. 23. © 2015 Scrum WithStyle scrumwithstyle.com Dependency Hell
  24. 24. © 2015 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.
  25. 25. © 2015 Scrum WithStyle scrumwithstyle.com Image credit: boost.co.nz
  26. 26. © 2015 Scrum WithStyle scrumwithstyle.com 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 www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  27. 27. © 2015 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.
  28. 28. © 2015 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.
  29. 29. © 2015 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.
  30. 30. © 2015 Scrum WithStyle scrumwithstyle.com Traditional Component Team Feature Teams Ideal state! Problem Whole System Whole Product Sub System Component File / Class Nothing Code + Design and Unit Test + Analysis and System Test + Co-creation Extended Component Teams Conflight in scope in the team leading to duplication or additional coordination work Functional over specification Degree of cross-functionality Potential Technology work scope inside the team Feature team adoption path Source: C. Larman & B. Vodde.
  31. 31. © 2015 Scrum WithStyle scrumwithstyle.com Release Rigidity
  32. 32. © 2015 Scrum WithStyle scrumwithstyle.com 4 releases/year using release train and component teams Month 11 Internal contract 2 3 5 74 6 8 9 10 121 Internal contract Internal contract Internal contract Release Release Release Release
  33. 33. © 2015 Scrum WithStyle scrumwithstyle.com 25 releases/year with Potentially Shippable Product Increments Month 11 Internal contract 2 3 5 74 6 8 9 10 121 Internal contract Internal contract Internal contract ReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleaseRelease
  34. 34. © 2015 Scrum WithStyle scrumwithstyle.com Smaller releases earlier = increased benefits realised $1M $800K $600K $400K $200K Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 Month 1 2 3 4 5 6 $1M $800K $600K $400K $200K Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 Month 1 2 3 4 5 6
  35. 35. © 2015 Scrum WithStyle scrumwithstyle.com Potentially Shippable Product Increment every Sprint gives the business… • early realisation of business value • flexible decision about when/what to deploy • flexible re-prioritisation each short cycle based on changes in business conditions, learning etc. • improved quality and fitness for purpose • improved estimates • increased visibility of something meaningful • early full-cycle feedback (documents don’t crash!) • early learning
  36. 36. © 2015 Scrum WithStyle scrumwithstyle.com Reality > Abstractions
  37. 37. © 2015 Scrum WithStyle scrumwithstyle.com The Contract Game
  38. 38. © 2015 Scrum WithStyle scrumwithstyle.com External contracts spawn internal contracts Business External customers I.T. External contract Internal contract
  39. 39. © 2015 Scrum WithStyle scrumwithstyle.com Product Management R&Dstart end (release) www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Business I.T.
  40. 40. © 2015 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 Date & Scope sign-off I.T.
  41. 41. © 2015 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 commitment Responsibility low control low flexibility low transparency big batches cannot release early not “done” until the end Business have completed date and scope move I.T.
  42. 42. © 2015 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 true status of progress. I.T.
  43. 43. © 2015 Scrum WithStyle scrumwithstyle.com Incentives & hierarchy encourage opacity Business stakeholders “Everything is going really well.”Program manager “Things are basically on track, we’re doing some minor risk management to head off issues arising.” Second level manager “Things are kind of rough but we’re managing the problems.”First level manager Developer “It’s a big mess. I have no idea how we’re going to get this done.”
  44. 44. © 2015 Scrum WithStyle scrumwithstyle.com Opacity
  45. 45. © 2015 Scrum WithStyle scrumwithstyle.com Incentives are around being ‘on plan’ ….rather than responding to change
  46. 46. © 2015 Scrum WithStyle scrumwithstyle.com
  47. 47. © 2015 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 I.T.
  48. 48. © 2015 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 I.T. The date and scope contract point represents the time that both parties have maximised the ability to shift blame when something goes wrong.
  49. 49. © 2015 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. I.T.Business There’s been a surprise! But you committed!
  50. 50. © 2015 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 I.T.
  51. 51. © 2015 Scrum WithStyle scrumwithstyle.com Now development pulls out the ‘Secret Toolbox’ • Crappy code • No longer thinking about the design • No longer taking time to learn • Stopping testing • Not fixing weakness in organisation • Overtime leading to attrition of the best people
  52. 52. © 2015 Scrum WithStyle scrumwithstyle.com Secret toolbox dynamics Goal: conform to original schedule actual variance to original schedule pressure to try actions to conform to original schedule QF QF % use of “secret toolbox”— hacking to generate bad code quickly exhortations, bribes, and threats to developers to meet schedule duration and effort to add new featuresO the key dynamic under discussion: short-term improvement but long- term degradation of the same variable long term short term management belief: exhortations, bribes, and threats make things faster management belief: estimates are not estimates, but commitments management belief: managers should not be looking at the code www.craiglarman.com www.odd-e.com Copyright © 2009 C.Larman & B. Vodde All rights reserved.
  53. 53. © 2015 Scrum WithStyle scrumwithstyle.com Internal contracts create a competitive game Consequences: • Distrust. • Increased technical debt. • Rewrite • Increased improvement debt. • Outsourcing of the problem.
  54. 54. © 2015 Scrum WithStyle scrumwithstyle.com Agile is meant to be a cooperative game
  55. 55. © 2015 Scrum WithStyle scrumwithstyle.com
  56. 56. © 2015 Scrum WithStyle scrumwithstyle.com With good Scrum… • Contracts between the Business and I.T / Program management are eliminated. • Instead, there is a Product Owner from the business. • The “more, more, more” person with the external contract / business profitability problem is given the steering wheel. • The Product Owner can change the content and date of release at a fidelity of each Sprint. • Product Owner typically Head of Business Line or Head of Product Management
  57. 57. © 2015 Scrum WithStyle scrumwithstyle.com I.T. Before adopting LeSS Business Stakeholders Program Management Business Analysis team Architecture team Development team Testing team Functional teams Business
  58. 58. © 2015 Scrum WithStyle scrumwithstyle.com After adopting Less Implications: • Program / development management are no longer responsible for hitting release dates or milestones. • Good Scrum involves elimination of the contract game. Direct collaboration Cross-functional teams I.T. Business facilitated by…
  59. 59. © 2015 Scrum WithStyle scrumwithstyle.com Reality > Abstractions
  60. 60. © 2015 Scrum WithStyle scrumwithstyle.com Skills Bottlenecks
  61. 61. © 2015 Scrum WithStyle scrumwithstyle.com Team skills E F G Learning allows us to keep whole feature with single team Product Backlog D E F skills required Team skills A B CA B C skills required Team skills C D E d Will slow down as they learn a bit of d. Principles: • Whenever we can use specialisation to maximum advantage, we use it. • Whenever specialisation becomes a constraint, we break the constraint. • Better to do a high value thing slower than a low value thing fast. •Expanding skills capability is valuable.
  62. 62. © 2015 Scrum WithStyle scrumwithstyle.com Lack of Cross-team Learning
  63. 63. © 2015 Scrum WithStyle scrumwithstyle.com 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) Joint Retrospective (1.5 h) ScrumMasters and one representative from each team meet early in next Sprint to deal with systemic issues Product Backlog Refinement (5-10% of Sprint) Potentially Shippable Product Increment Sprint Review (2-4 h) Using ‘science-fair’ style diverge - converge format Product Backlog Refinement (5-10% of Sprint) Big Room Refinement All teams in one room with own learning tools (whiteboards, projectors etc.)
  64. 64. © 2015 Scrum WithStyle scrumwithstyle.com The regular teams do the Undone Release work • This creates opportunities for cross-functional learning • May start with pairing specialist group with regular teams • Perfection vision: no release Sprint necessary Undone Work actual release Product Owner wants to release Release Sprint: teams only do Undone Work . . . www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  65. 65. © 2015 Scrum WithStyle scrumwithstyle.com Lack of Design and Architectural Alignment
  66. 66. © 2015 Scrum WithStyle scrumwithstyle.com 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 www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved.
  67. 67. © 2015 Scrum WithStyle scrumwithstyle.com 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
  68. 68. © 2015 Scrum WithStyle scrumwithstyle.com Collaborative modelling over specification Image credit: less.works
  69. 69. © 2015 Scrum WithStyle scrumwithstyle.com 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
  70. 70. © 2015 Scrum WithStyle scrumwithstyle.com Learn more about LeSS at less.works
  71. 71. © 2015 Scrum WithStyle scrumwithstyle.com @rowanb au.linkedin.com/in/rowanbunning Rowan Bunning rowan@scrumwithstyle.com scrumwithstyle.com Thankyou! Keepintouch

×