Scaled Agile Survey
•Download as PPTX, PDF•
1 like•197 views
Presented at Agile New England as an Agile 101 session in July 2020. Surveys six of the most common approaches for scaling Agile: SAFe, S@S, LeSS, Nexus, DAD, and Spotify. Some models are intended to scale Agile to the entire organization, while others are intended to scale only as required for larger programs. An introduction to options beyond Scrum of Scrums or SAFe.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scaled Agile Survey
Similar to Scaled Agile Survey (20)
More from David Hanson
More from David Hanson (12)
Recently uploaded
Recently uploaded (20)
Scaled Agile Survey
- 1. ScaledAgileSurvey SAFe, S@S, LeSS, Nexus, DAD, Spotify David Hanson July 2020 Version 1.1
- 2. ScaledAgile Survey David Hanson dphanson63@yahoo.com linkedin.com/in/david-hanson/ slideshare.net/DavidHanson5 About the Presentation This presentation will survey six of the most common approaches for scalingAgile: SAFe, S@S, LeSS, Nexus, DAD, and Spotify. Some models are intended to scale Agile to the entire organization, while others are intended to scale only as required for larger programs. If you have a need to scale or an interest in scaling, and want to consider options beyond Scrum of Scrums or SAFe, this review should be a good introduction. About the Presenter David has scaledAgile on two occasions for larger multi-team, multi-year programs. His first scaled implementation in 2008 successfully leveraged a plan- build-operate model. His next “small-scaled” implementation, starting in 2014, most closely resembles LeSS, successfully scaled Scrum, and continues today.* David is an advocate of Kanban, Scrum, and XP, with scaling as required. * The Way Forward: A Scaled Agile Experience, Agile Boston, May 2020
- 19. Spotify Engineering Culture Agile > Principles > Servant > Trust > Community > Cross-pollination > Enable > People > Failure Recovery > Innovation > Impact > Value Delivery > Chaos > Scrum Practices Master Control Structure Standardization Serve * Failure Avoidance Predictability Velocity Plan Fulfillment Bureaucracy Sampling from Henrik Kniberg’s illustrated Spotify engineering culture from Jan and Apr 2014
- 21. Comparison of Scaled Models Commonalities Scaled Scrum Master Scaled Product Owner Team ofTeams Common Product Backlogs Common Planning Scrum of Scrums Common Review Common Retrospective Common Definitions Synchronized Sprints Frequent Integration Communities of Practice Differences Prescriptive vs. Principle Organizational vs.Team of Teams Scope Mapping Agile vs. Transforming Organization Scrum Specific vs. Model Agnostic Focused vs. Encyclopedic Participation Scope: Democratic vs. Representative Shared Services Terminology
- 23. Resources SAFe: https://www.scaledagileframework.com/ S@S: https://www.scrumatscale.com/scrum-at-scale-guide/ LeSS: https://less.works/ Nexus: https://www.scrum.org/resources/nexus-guide DAD: https://www.pmi.org/disciplined-agile/process or https://disciplinedagileconsortium.org/Disciplined-Agile-DAD Spotify: https://www.youtube.com/watch?v=Yvfz4HGtoPc and https://www.youtube.com/watch?v=vOt4BbWLWQw
- 24. Appendix CollabNetVersionOne Survey,Tip & Challenges My Small Scale Scrum Approach (presented Agile Boston) https://www.slideshare.net/DavidHanson5
Editor's Notes
- What’s your experience with scaling? What are you hoping to learn? Anyone participating in Scrum of Scrums? Anyone currently scaling?
- Notably absent: Scrum at Scale; CollabNet annual survey about the same. Anyone implement any of these models? Anyone considering other models? Anyone certified in any of these models? Who are our experts?
- Scrum of Scrums widely accepted as first step to scaling. Scrum Guide (2017) has two references to scaling Agile: 1) multiple teams should pull from single product backlog; 2) multiple teams working on same product must have common definition of done. (No reference to Scrum of Scrums.) Graphic from Mountain Goat. My variation: send two people from each team, one as participant and one as observer.
- Arguably first to market; maps Agile to traditional organization framework; very explicit, most comprehensive, perhaps less transformative. Might recommend for larger organizations with well established practices. Continues to evolve and keep up with latest trends (e.g. Business Agility and Design Thinking). Can use Essential with or without additional layers. C-A-L-M-R: Culture, Automation, Lean flow, Measurement, Recovery
- Seven core competencies to business agility; a recent addition in SAFe 5.0
- Program Increment or big room planning one of the more transformative and influential ideas. Highly prescriptive; questionable w/ regards to sustainable pace (day 1 10 hours). Once every 10 weeks (why not quarterly, I do not know).
- S@S seeks to transform the organization to become Agile; less prescriptive framework, potentially most transformative. Start with SM cycle focused on how from CI, then PO cycle focused on what from vision. 20 page S@S guide published 2019; arguably last to market. Aims to have “scale-free” architecture with minimum viable bureaucracy.
- Base level is same scrum; from there two parallel SoS; one for technical, process, how; one for business, priorities, what. Goal is to scale linearly with optimal sized teams and team of teams. Aims to radically reduce decision latency from months or weeks to days or hours. EAT meets daily to weekly modeled after SoS; EMS meets weekly to sprintly modeled after planning. EAT addresses impediment backlog and maintains transformation backlog.
- Entire business transforms into Scrum Teams; some virtual; EMS and EAT may have same members.
- Pragmatic and simple framework. Introduces only one additional meeting. Maintains one PO with multiple potentially shared SMs. Large Scale Scrum aims to accomplish more with less. Suggests options for additional activities, e.g. may introduce SoS or ambassador.
- Supplement with library of practices or patterns
- Perhaps simplest scaling framework; emphasizes daily integration across teams; scrum of scrums happens before daily scrum; representatives from each team form Integration Team; Nexus Guide (10 pages) supplements Scrum Guide. Adds one pre-planning event with representatives from each team to pre-select sprint backlogs; replaces sprint review with one common review; adds pre- and post- retros with representatives from each team. One PO, multiple SM, 3-9 teams, integration team may be members of individual teams and rotate over time. Nexus Daily Scrum: what was integrated, what was not; new dependencies; what needs to be shared. Retro focus: debt, integration, dependencies. Def. of Ready: add doable by single team; Def. of Done: defined by NIT.
- Four levels; comprehensive and well organized; attempts to cover and acknowledge nearly every approach and organizational practice; sponsored by PMI; unfortunately website somewhat difficult to navigate.
- Maps the interactions between groups for DevOps and the broader organization (next slide).
- https://www.pmi.org/disciplined-agile/ongoing-goals/evolve-wow process decision framework; e.g. suggests LeSS, Nexus or SAFe for scaling
- Spotify has perhaps the best terminology; Chapters and Guilds provide structure for cross team collaboration and knowledge sharing.
- Spotify, not really a model or framework; more about comprehensive engineering culture. Additional 19 culture related practices highlighted by Kniberg not shown.
- What models might be right for your needs? What models resonate with you? Which models would you want to investigate in more detail?
- 13th Agile survey; not covered here: Enterprise Scrum, Lean Management, APM, RAGE. Enterprise Scrum comprehensive by Mike Beedle w/ Structural Patterns, Collaboration Modes, and Delivery Target for scaling; RAGE adds “governance” to roles, events, artifacts, metrics with project, program, portfolio layers. Lean Management and APM don’t seem to exist as defined scaling approaches. Might APM be a reference to Jira Portfolio? 14th survey released April 2020, about same.
- Presented at Agile Boston, May 2020 Key: Bold outline: active managers or leads Blue: business, product owners, proxy product owners White or gray: Scrum masters, administrative help, Agile coach Purple: analysts Red: UI specialists with .NET skills Orange: middle-tier specialists with Java skills Yellow: database specialists with Oracle skills Green: QA most with limited automation experience Darker: generally more senior Dark blue: Boston; light blue: London Out front: onshore; in back: offshore
- https://www.youtube.com/watch?v=Yvfz4HGtoPc
- https://www.youtube.com/watch?v=vOt4BbWLWQw