O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Agile Organizations with Scrum@Scale

Mais Conteúdo rRelacionado

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

Audiolivros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

Agile Organizations with Scrum@Scale

  1. 1. Agile Organization Incrementally Crafting the Right Organization with Scrum@Scale Paolo Sammicheli http://paolo.sammiche.li
  2. 2. Paolo Sammicheli – Agile Business Coach http://paolo.sammiche.li
  3. 3. Agile Organization
  4. 4. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Manifesto for Agile Software DevelopmentProduct products product
  5. 5. In the old model the focus is the project, which is at the center, and people organize themselves in groups around it. The new model puts the teams at the center, and the work flows to them. Stable teams who, with appropriate coaching and time spent together, become High Performing. The Copernican Revolution of Labor
  6. 6. « An Agile Organization is one that is quick in responding to changes in the marketplace or environment » Source: https://www.mbaskool.com/business-concepts/it-and-systems/6703-agile-organization.html
  7. 7. Agile Organization Leadership #LikeABoss JAN 2, 2018 @ 07:35 AM 33,971 / / Why Agile Is Eating The World Steve Denning, CONTRIBUTOR I write about radical management, leadership, innovation & narrative. FULL BIO Opinions expressed by Forbes Contributors are their own. In 2011, Marc Andreessen wrote his famous essay, “Why Software Is Eating the World,” in The Wall Street Journal, leading to the cliché that “every company needs to become a software company.” (A useful update by Jeetu Patel on the situation in 2016 is here: “Software is still eating the world.”) In one way, Andreessen’s 2011 article was remarkably prescient. In 2011, IT firms were looked down on by Wall Street. Andreessen was telling Wall Street: “Pay attention! These companies are more valuable than you think they are.” And Wall Image Wikimedia Commons: Brocken Inaglory Great white shark at Isla Guadalupe, Mexico. Why Agile is Eating The World Jan 2, 2018 In 2011, Marc Andreessen wrote his famous essay, “Why Software Is Eating the World,” in The Wall Street Journal, leading to the cliché that “every company needs to become a software company.” In 2018, the five biggest companies in the world by market capitalization are IT firms: Amazon, Apple, Facebook, Google and Microsoft. t's not that all software is eating the world: General Electric has just proved that in a spectacular fashion: It invested heavily in software and the result. After five years, the CEO and his top lieutenants were terminated. Similar developments are under way at Intel, P&G and HP.
  8. 8. «It is Firms that are truly Agile that are eating the world, whether or not they call themselves by the label “Agile” » - Forbes, 2 Jan 2018
  9. 9. McKinsey & Company Source: https://www.mckinsey.com/business-functions/organization/our-insights/the-five-trademarks-of-agile-organizations January 2018
  10. 10. McKinsey & Company December 2015 https://www.mckinsey.com/business-functions/organization/ our-insights/agility-it-rhymes-with-stability Agility it Rhymes with Stability Companies can become more agile by designing their organizations both to drive speed and create stability.
  11. 11. McKinsey & Company December 2015 https://www.mckinsey.com/business-functions/organization/ our-insights/why-agility-pays Why Agility Pays 70% of Agile Companies rank in the top quartile of organizational health. 85% of the top healthy organizations are Agile or Startups.
  12. 12. Harvard Business Review 12 May-June 2018 https://hbr.org/2018/05/agile-at-scale Companies that successfully scale up agile see major changes in their business. Scaling up shifts the mix of work so that the business is doing more innovation relative to routine operations. The business is better able to read changing conditions and priorities, develop adaptive solutions, and avoid the constant crises that so frequently hit traditional hierarchies. By Darrell K. Rigby, Jeff Sutherland, Andy Noble
  13. 13. Scrum at Scale • Guide published by Jeff Sutherland and released under Creative Commons License in February 2018. • Extremely simple, only 18 pages. • The method clearly distinguishes the structure of the organization from the content and describe only the structure of the relations, making it universally applicable. source: https://www.scrumatscale.com ©1993-2018 Jeff Sutherland and Scrum Inc., All Rights Reserved Scrum@Scale is a registered trademark of Scrum Inc. Released under Creative Commons 4.0 Attribution-Sharealike License Version 1.0 – 10 February 2018
  14. 14. © 1983-2018 Jeff Sutherland & Scrum Inc. Components of the Scrum@Scale Framework Continuous Improvement & Impediment Removal Executive Action 
 Team Cross-Team Coordination Team-Level Process Metrics &
 Transparency Product & 
 Release Feedback Strategic
 Vision Executive Meta Scrum Deployment Backlog Prioritization Backlog
 Decomposition
 & Refinement Release
 Planning Potentially Shippable Product Increment Product Owner
 Cycle Scrum Master
 Cycle 14
  15. 15. Scale-Free Architecture • A scale-free network is a network whose degree distribution follows a power law, at least asymptotically. • The most notable characteristic in a scale-free network is the relative commonness of vertices with a degree that greatly exceeds the average. The highest-degree nodes are often called "hubs", and are thought to serve specific purposes in their networks, although this depends greatly on the domain. 15 https://en.wikipedia.org/wiki/Scale-free_network
  16. 16. © 1983-2018 Jeff Sutherland & Scrum Inc. Scale-Free Architecture • If you want to scale exponentially you need a “scale-free” architecture • Otherwise you risk introducing waste into the system and slowing the whole organization down • You will not achieve linear scalability • Scale-free architectures are pervasive in biology (ex. neural networks) • They are able to evolve to perform new functions more rapidly than an alternative network design Diagram of a scale-free network that contains components with a highly diverse level of connectivity. Some components form highly interconnected hubs, while other components have few connections, and there are many levels of interconnectivity in between. Scale-free networks are pervasive in biology. Computer simulations at the University of Chicago show that scale-free networks are able to evolve to perform new functions more rapidly than an alternative network design.Source: http://chronicle.uchicago.edu/061207/darwin.shtml Digital Darwinian world reveals architecture of evolution 16
  17. 17. © 1983-2018 Jeff Sutherland & Scrum Inc. Scaling Challenge: Bureaucracy & Hierarchy • A bureaucratic processes creates poor decision latency. • Everything we do requires so many sign-offs that nothing gets done. • We have layers upon layers of managers. • Therefore, we need a Minimum Viable Bureaucracy. 17
  18. 18. © 1983-2018 Jeff Sutherland & Scrum Inc. The Scaled Daily Scrum: The SM Role Scaled •Scrum must scale in an organic way consistent with the Scrum Guide or it will be slow •Using a Scrum of Scrums reduces communication paths but increases communication saturation •Scrum of Scrum works as a “Team of Teams” In order for the SoS to be most effective, we need a Scrum of Scrums Master (SoSM) to ensure that: • Impediments are shared and removed • Knowledge is spread and standardized • Dependencies are discussed and resolved • The SoS functions as a Team of Teams with the responsibility of Release 18
  19. 19. © 1983-2018 Jeff Sutherland & Scrum Inc. Scaled Daily Scrum (SDS) 19 SM SM SM SM SM SoS • Exists to coordinate the Scrum of 
 Scrums and remove impediments
 to the delivery of value to customers • The SDS event mirrors the Daily 
 Scrum • An opportunity to re-plan in
 order to achieve the Sprint goal
 for the SoS • Surfaces impediments • Shares learnings for continuous improvement SDS
  20. 20. © 1983-2018 Jeff Sutherland & Scrum Inc. The Executive Action Team • Accountable for the quality of Scrum in the organization • Owns the Organizational Transformation Strategy • Owns the Transformation Backlog and “eats impediments” that block it • Removes impediments not handled at the Team level due to scope, budget, or corporate political power • Executes the Transformation Strategy or delegates it to a center of expertise (often called the Agile Practice) • Measures and improves the quality of Scrum in the organization to build capability for business agility 20
  21. 21. © 1983-2018 Jeff Sutherland & Scrum Inc. Typical Impediment Escalation 21
  22. 22. © 1983-2018 Jeff Sutherland & Scrum Inc. Who should be on the EAT? • A leader who can change company policy without having to ask permission [ex. COO, CIO, CTO] • Someone who can write a check [ex. VP of Finance] • Someone who is a Scrum Star [aka. Agile Champion] • Leaders who can motivate change • Someone from People Ops [ex. HR] • Someone from Legal/Compliance 22
  23. 23. © 1983-2018 Jeff Sutherland & Scrum Inc. 23 Scaling the Product Owner Product Owner •Team •Sprints •Validated Learning Chief Product Owner •Multiple Teams •Roadmap •Coordinating teams Chief Chief Product Owner •Value Streams •Vision •Organizational Priorities PO CPO MetaScrum PO PO PO POPO Executive MetaScrum
  24. 24. © 1983-2018 Jeff Sutherland & Scrum Inc. 24 The MetaScrum: Refinement C CPO S H Stakeholders P O Product Owners Aligned Product Backlog C S HP O Sprint/Time Aligned Product Backlog C P O Aligned Product Backlog C P O M etaScrum M etaScrum M etaScrum S H S HS H S HS HP O P O P O Validated Learning Vision Validated Learning
  25. 25. © 1983-2018 Jeff Sutherland & Scrum Inc. The MetaScrum Backlog Refinement • A MetaScrum Scaled Backlog Refinement Meeting is a gathering of Key Stakeholders, Leadership, Product Owners, and Team members. • Run by Chief Product Owner • Did anything change that would change the strategy or priorities? • Aligns enterprise around single backlog • The forum for stakeholders to express preferences, remove blocks and provide resources needed (they should not try to alter product vision between MetaScrums) • Decompose upcoming backlog 25
  26. 26. © 1983-2018 Jeff Sutherland & Scrum Inc. Scaling SAAB Technologies to Hundreds of Teams
 Synchronizing 2000 People in about one hour! • 7:30 Daily Scrum • 7:45 Scaled Daily SoS • 8:00 Scaled Daily SoSoS • 8:15 Scaled Daily SoSoSoS • 8:30 Executive Action Team 26
  27. 27. Lockheed Martin F35 vs Saab Jas39e Gripen 27 © 2011 Scrum Inc.© 2011 Scrum Inc. Cumulative program cost of $15 billion • New iteration every 6 months • $43M cost1 (20% of F-35) • $4,000 Hour Flight Cost 1. According to Jane’s Aviation Weekly, the Gripen is the world’s most cost-effective military aircraft Cumulative cost 1.5 trillion dollars • $143 billion over budget • Delayed until 2022 • Cost of Navy F-35C $337 million • $31,000 Hour Flight cost DoD Waterfall vs. DoD Agile American F-35 Lightning vs. the European JAS-39 Gripen https://www.scruminc.com/scrum-military-aviation/
  28. 28. © 1983-2018 Jeff Sutherland & Scrum Inc. Scrum Master and Product Owner 
 Functions Scale Coordination Differently Scrum Master Product Owner • Share best practices • Collectively solve problems & remove impediments • Maintain clear and consistent product vision • Optimize business value • Respond decisively to changing market Team Scrum of Scrums Scrum of Scrum of Scrums T TT T TT T TT T TT T TT T TT PO CPO PO PO CPO PO CPO Product PO team Component PO team Component PO team 28
  29. 29. Scaling 125 people © Jeff Sutherland & Scrum Inc 1993 – 2018
  30. 30. Scaling 250 people © Jeff Sutherland & Scrum Inc 1993 – 2018
  31. 31. 3M - HIS © Jeff Sutherland & Scrum Inc 1993 – 2018
  32. 32. How do you Start?
  33. 33. Sprints never finish with working product Process Efficiency = 5% Sprints always finish with working product Process Efficiency = 50% © Jeff Sutherland & Scrum Inc 1993 – 2018
  34. 34. Large Defense Contractor • Top-down agile transformation motivated by perceived external market pressure • Company vision to halve the cost of projects Mid-size Software Company • Opportunistic agile implementation triggered by acquisition of a small Scrum company • Market leader Looking to stay ahead of competition Growing “Agile Native” Company • Disruptive technology innovator with successful product looking to scale to keep up with demand • Leadership are steeped in agile principles A B C Name Classified Autodesk Spotify Key Context: • Complex, integrated multi- year hardware/software projects • Each project has one customer • Reliability a key priority • Must deliver to detailed contract requirements Key Context: • Redeploying a legacy software product to cloud- based SaaS model • Goal to increase pace of innovation • Historically, releases a disruption for customers
 Key Context: • Web/app-based product • Product and company set up modularly • Allows teams to work independently with minimal coordination • Teams co-located © Jeff Sutherland & Scrum Inc 1993 – 2018
  35. 35. “Emergent” Product Design “Defined” Product Design ProcessAdaptability ProcessPredictability EP CP EA CA Adapted from Michael Cottmeyer Where is your organization on this chart? Place a dot for your organization Place an arrow for the direction Where should it be heading? Where do these go? © Jeff Sutherland & Scrum Inc 1993 – 2018
  36. 36. Case Study by Paolo Sammicheli • Form the EAT and create a Transition backlog • Form the first small set of Scrum Teams • Make them to work well, solving impediments. This iteratively will create your “operating model”. • Scale up extending this “operating model” to the rest of the company incrementally. How do you start
  37. 37. Questions?
  38. 38. SCRUM for HARDWARE AT SCALE
  39. 39. Case Study by Paolo Sammicheli • European IOT Company creating the next generation house automation platform, under NDA. • Very complex product with Software, Electronics, Mechanical parts, Engines and Plastics components with design needs. • Time pressure from the market Scrum for Hardware at Scale Challenge: Many external suppliers for SW and HW components with a tight schedule. How to manage the complex dependencies?
  40. 40. Case Study by Paolo Sammicheli The project started with a two day LiftOff (as described in Diana Larsen’s book) where we shared the Vision, formed the development teams, defined the working agreements and created the backlog with a User Story Mapping. Whole team alignment Purpose Alignme nt Context
  41. 41. Case Study by Paolo Sammicheli Organizational Structure MetaScrumScrum of Scrums CPO Chief Product Owner SSM Senior Scrum Master PO Product Owner SM Scrum Master Product Backlog
  42. 42. Case Study by Paolo Sammicheli • We tried to do our first Sprint Planning projecting the backlog on the wall from Jira. The result was a boring meeting with very low energy. • We asked the teams to behave like a real buffet: you can't take too little, because it would not be polite, but you can't take too much because you have to eat whatever you take • It resulted in a very energetic meeting where discussions took place spontaneously; a managed chaos • It takes around one hour for the three teams. At the end of the hour every team shares with the others what they selected and the CPO checks the table to see if there are high priority items still there. In that (very rare) case, teams are asked to volunteer to replace something they have with the remaining high priority item Buffet Planning
  43. 43. Case Study by Paolo Sammicheli Deployment / Review • Often during the Sprint, the Teams integrate the product and deploy it in a dedicated room, used also for the Joint Sprint Review. • The different products are installed in several movable panels. They can be taken to the team room during the Sprint for convenience. • This photo has been taken at the beginning of the development and shows the empty panels with no products.
  44. 44. Case Study by Paolo Sammicheli Results Cumulative Yesterday’s Weather 0,00 15,00 30,00 45,00 60,00 Sprint 1 Sprint 3 Sprint 5 Sprint 7 Sprint 9 Sprint 11 Sprint 13 Sprint 15 Sprint 17 Sprint 19 Sprint 21 Sprint 23 Sprint 25 Cumulative HQ Teams Yesterday’s Weather Sprint 8 = 6sp Sprint 14 = 23sp Sprint 26 = 55sp In one Year x 9.16 faster! Yesterday’s Weather is the average velocity of the last 3 Sprints

×