Scrum Day Europe 2015 - Scaled Professional Scrum
•
20 recomendaciones•3,739 vistas
‚Scaling' became the most hyped and at the same time the most diversely interpreted word in the context of agile. The fad and the confusion obfuscate. Despite Scrum being the most adopted framework for agile software development, scaling Scrum in a way that respects Scrum's foundations and principles is a challenge. Many don’t scale the benefits of Scrum, but organizational dysfunctions that remain unaddressed through weak implementations of Scrum. In his opening keynote of Scrum Day Europe 2015 Gunther shared the views of Scrum.org, the organization of Scrum co-creator Ken Schwaber, on Scaled Professional Scrum. Gunther shepherds the Professional Series at Scrum.org, is a partner of Ken Schwaber and represents Scrum.org in Europe.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (9)
Destacado
Destacado (15)
Similar a Scrum Day Europe 2015 - Scaled Professional Scrum
Similar a Scrum Day Europe 2015 - Scaled Professional Scrum (20)
Más de Gunther Verheyen
Más de Gunther Verheyen (20)
Último
Último (20)
Scrum Day Europe 2015 - Scaled Professional Scrum
- 1. by Scrum.org – Improving the Profession of Software Development Scaled Professional Scrum Focused. Effective. Viable. Gunther Verheyen Shepherding Professional Scrum Scrum.org July 2, 2015 Amsterdam
- 2. 2© 1993-2015 Scrum.org, All Rights Reserved MIN 3 Have you been engaged in efforts to scale Scrum? Raise your hand if your organization defines ‘scale’ as… • Multiple teams working on one product • Multiple teams working on their individual products • Multiple teams working on a suite of integrated products • One team working on several products in parallel • The complete IT organization adopting Scrum • A 360° organizational transformation toward Agile Short Survey About You
- 3. 3© 1993-2015 Scrum.org, All Rights Reserved Scaled Scrum Scaled Professional Scrum “It takes two to scale.” – Gunther Verheyen
- 4. 4© 1993-2015 Scrum.org, All Rights Reserved Focus. Transparency. ScaledScrum
- 5. 5© 1993-2015 Scrum.org, All Rights Reserved Definition of Scaled Scrum 1. Any implementation of Scrum where multiple Scrum Teams build one product or a standalone set of product features, in one or more Sprints. 2. Any implementation of Scrum where multiple Scrum Teams build multiple related products or sets of product features, in one or more Sprints.
- 6. 6© 1993-2015 Scrum.org, All Rights Reserved A system’s components interact purposefully toward a shared goal without externally exerted power. Frequent decisions of adaptation are based on knowledge gained through inspection and experience. Scrum’s DNA Self-Organization Empiricism
- 7. 7© 1993-2015 Scrum.org, All Rights Reserved Scrum 1. One team pulls work from one Product Backlog. 2. Each Sprint delivers a releasable Increment of product.
- 8. 8© 1993-2015 Scrum.org, All Rights Reserved Professional Scrum Professional Scrum Mechanical Scrum Technical Excellence Values and Principles Any Scrum instance that implements Scrum’s mechanics, its values and principles, and technical excellence.
- 9. 9© 1993-2015 Scrum.org, All Rights Reserved Technical Excellence THE MEDUSA EFFECT Poorly maintained codebases have…
- 10. 10© 1993-2015 Scrum.org, All Rights Reserved One Scrum Team Doing Work
- 11. 11© 1993-2015 Scrum.org, All Rights Reserved Three Scrum Teams Doing Work
- 12. 12© 1993-2015 Scrum.org, All Rights Reserved Nine Scrum Teams Doing Work
- 13. 13© 1993-2015 Scrum.org, All Rights Reserved • People (communication) • Business domains and requirements • Technology • Software • Infrastructure • Intra-team • Cross-team • External Dependencies Dimensions Where
- 14. 14© 1993-2015 Scrum.org, All Rights Reserved Identify and work around dependencies: – Prior to work occurring – Ongoing – Persistent – In all dimensions Reveal dependencies that remained unnoticed: – Frequent integration – Acceptance testing – Continual build and delivery – Minimize technical debt Dealing with Dependencies Proactive Reification* *Reification: Making something real, bringing something into being, or making something concrete.
- 15. 15© 1993-2015 Scrum.org, All Rights Reserved Your ability to scale depends on your ability to continuously: – Identify and remove dependencies – Integrate work across all levels – Create and inspect reified Increments
- 16. 16© 1993-2015 Scrum.org, All Rights Reserved The Nexus Scaled Professional Scrum “A man who carries a cat by the tail learns something he can learn in no other way.” - Mark Twain
- 17. 17© 1993-2015 Scrum.org, All Rights Reserved Nexus –noun ˈnek-səs : a relationship or connection between people or things http://www.merriam-webster.com/dictionary/nexus
- 18. 18© 1993-2015 Scrum.org, All Rights Reserved Scrum for Multiple Teams 1. A product has one Product Backlog. 2. Multiple Teams create integrated Increments.
- 19. 19© 1993-2015 Scrum.org, All Rights Reserved The Nexus™ – An Exoskeleton for 3-9 Scrum Teams
- 20. 20© 1993-2015 Scrum.org, All Rights Reserved MIN 3 We have heard Scrum only works for singular teams. We have heard Scrum is not enough at scale. We wonder… • Isn’t scaled Scrum through the Nexus still Scrum? • Doesn’t the Nexus efficiently scale product development with Scrum? Scrum Is Not Enough?
- 21. 21© 1993-2015 Scrum.org, All Rights Reserved The Nexus Augments Scrum Builds on Scrum principles, values, and foundations • Creates communication pathways • Widens and deepens inspect and adapt mechanisms • Fosters continued transparency • Relies on bottom-up intelligence Eschews fixed, defined solutions that add overhead.
- 22. 22© 1993-2015 Scrum.org, All Rights Reserved Nexus - Roles, Events and Artifacts Roles Events Artifacts Development Teams The Sprint Product Backlog Nexus Integration Team* Nexus Sprint Planning* Nexus Sprint Backlog* Product Owner Sprint Planning Sprint Backlog Scrum Master Nexus Daily Scrum* Integrated Increment Daily Scrum Nexus Sprint Review* Sprint Review Nexus Sprint Retrospective* *Nexus specific
- 23. 23© 1993-2015 Scrum.org, All Rights Reserved The Nexus Integration Team • A Scrum Team • Works off of Product Backlog • Members are full or part time • Composition may change between Sprints • Focus is dependencies and facilitation of integration
- 24. 24© 1993-2015 Scrum.org, All Rights Reserved The Nexus interconnects 3-9 Scrum Teams: – Exhibiting Scrum’s principles and DNA –Creating one reified Increment of product – Minimal overhead, maximized outcome
- 25. 25© 1993-2015 Scrum.org, All Rights Reserved Managing Scaled Scrum Scaled Professional Scrum “Success in management requires learning as fast as the world is changing.” – Warren Bennis
- 26. 26© 1993-2015 Scrum.org, All Rights Reserved • What must be done to integrate the work? • How frequently do you need the work integrated into releasable product? • How do you measure and manage the work and the integration? • What is the overhead of integration and delivery? • Are you balancing cost and benefits of this overhead with value produced? • Is the cost systematically being reduced? Core Questions When Managing Any Scaling Effort Process Cost
- 27. 27© 1993-2015 Scrum.org, All Rights Reserved Scaled Professional Scrum Practices Dependencies Reification Feature teams ALM artifact automation Micro-services Test-driven development Product Backlog metadata Continuous integration of all work Continuous Product Backlog refinement Frequent builds Story mapping Frequent testing Product Backlog cross-team dependency mapping Limited branching Communities of practice Descaling and Scrumble Architecture contains experimentation and A/B switches Thin sliced Product Backlog items compose Sprint backlog for ATDD
- 28. 28© 1993-2015 Scrum.org, All Rights Reserved Descaling • Scale up with caution • Add practices or tools • Reduce the overall pace by reducing the number of teams to a more sustainable number (and/or velocity) • Clean up and integrate the current software so it can be built upon in future Sprints Productivity Teams
- 29. 29© 1993-2015 Scrum.org, All Rights Reserved Scrumble • When technical debt, domain knowledge and test results overwhelm forward progress, Scrumble • Scrumble is a period of unknown duration and staffing when work is done to allow forward progress to resume • Staffing should be minimized and talent applied maximized Teams Productivity
- 30. 30© 1993-2015 Scrum.org, All Rights Reserved How To Measure the Progression of Your Scaling Effort? “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- 31. 31© 1993-2015 Scrum.org, All Rights Reserved Nexus+ Scaled Professional Scrum “Put all your eggs in one basket and then watch that basket.” – Mark Twain
- 32. 32© 1993-2015 Scrum.org, All Rights Reserved Yes, You Can Scale Beyond The Nexus Value.Dependencies.
- 33. 33© 1993-2015 Scrum.org, All Rights Reserved The Challenge of Large Scale Development • The Nexus starts to fray and create confusion at around 9 teams. Communication grinds. • Dependencies and integration issues are magnified and create chaos. • Additional engineering solutions are necessary, necessitating enabling, integrating architectures. There is no guaranteed recipe at this scale – EVERY PROJECT IS UNIQUE.
- 34. 34© 1993-2015 Scrum.org, All Rights Reserved You will need either: • A full time integration team who work above the Nexus+ helping to coordinate across each Nexus • An integration Nexus • Architecture adequate to complexity Nexus+ Integration Google runs 4,000 builds and 60 million tests every day
- 35. 35© 1993-2015 Scrum.org, All Rights Reserved Organization and Architecture Adequate to Complexity • Nexuses integrate into a horizontal platform providing stability through integration standards and facilities • An Integration Nexus • Have Nexuses within boundaries that denote collaboration and unit of purpose, like product or value chain area teams • The Microsoft Component Object Model • Build your own iOS and SDK to enable app development • Product family architecture • APIs • UI Platform • Internal Open Source • Microservices
- 36. 36© 1993-2015 Scrum.org, All Rights Reserved Closing Empirical Management Explored
- 37. 37© 1993-2015 Scrum.org, All Rights Reserved “The future state of Scrum will no longer be called ‘Scrum’. What we now call Scrum will have become the norm, and organizations have re-invented themselves around it.” Source: Gunther Verheyen, “Scrum – A Pocket Guide (A Smart Travel Companion)”, 2013
- 38. 38© 1993-2015 Scrum.org, All Rights Reserved About Gunther Verheyen • eXtreme Programming and Scrum since 2003 • Professional Scrum Trainer • Shepherding Professional Scrum at Scrum.org • Co-developing the Scaled Professional Scrum framework at Scrum.org • Author of “Scrum – A Pocket Guide (A Smart Travel Companion)” (2013) Mail gunther.verheyen@scrum.org Twitter @Ullizee Blog http://guntherverheyen.com
- 39. 39© 1993-2015 Scrum.org, All Rights Reserved Scaled Professional Scrum by Scrum.org • SPS Workshops, https://www.scrum.org/Courses/Scaled- Professional-Scrum • Nexus Guide • Nexus Assessments • Agility Index • Agility Path, http://www.ebmgt.org/agility-path- framework/agility-guide
- 40. 40© 1993-2015 Scrum.org, All Rights Reserved Scrum.org is a community. Connect. Twitter @scrumdotorg LinkedIn LinkedIn.com /company/Scrum.or g Facebook Facebook.com /Scrum.org Forums Scrum.org /Community RSS Scrum.org/RSS
- 41. 41© 1993-2015 Scrum.org, All Rights Reserved T H A N K Y O U
Notas del editor
- Abstract "Scaling" became the most hyped and at the same time the most diversely interpreted word in the context of agile. The fad and the confusion obfuscate. Despite Scrum being the most adopted framework for agile software development, scaling Scrum while respecting its foundations and principles remains a challenge. Few scaled implementations grew upon Scrum's DNA of empiricism and self-organization. Gunther introduces the “Scaled Professional Scrum” framework and the Nexus by Scrum.org. The Nexus interconnects 3-9 Scrum Teams through… Scrum. Gunther shepherds Professional Scrum at Scrum.org and is a partner of Ken Schwaber.
- A healthy Scrum foundation is the best path to success before trying to scale, otherwise you’ll scale your current dysfunctions Scrum alone isn’t enough for success. Establishing, promoting, and stewarding technical excellence as a foundation for growth.
- One team working on several products is not scaled Scrum. It is the reverse of scaling. Many teams each working on one product is a lot of Scrum, but not scaled Scrum.
- Empiricsm From Stephen Hawking’s A Brief History of Time (1988): A well-known scientist (some say it was the philosopher Bertrand Russell) once gave a public lecture on astronomy. He described how the Earth orbits around the sun and how the sun, in turn, orbits around the centre of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!” Self-organization Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property. Animal and human communities too display self organization: in every group a member emerges as the leader (who establishes order and rules) and everybody else follows him or her, usually willingly. References http://www.businessdictionary.com/definition/self-organization.html#ixzz3JG6K0gLw http://plato.stanford.edu/entries/rationalism-empiricism/ http://vserver1.cscs.lsa.umich.edu/~crshalizi/notabene/self-organization.html http://en.wikipedia.org/wiki/Self-organization http://en.wikipedia.org/wiki/Complex_system
- Scrum, ultimately can only be fully comprehended when its rules and roles are read as an expression of the values and principles of the Manifesto for Agile Software Development. is an operating system for the values and principles of the Manifesto. The kernel of the OS is the Scrum Stance. Professional Scrum: Any Scrum instance that implements Scrum’s mechanics, its values and principles, and technical excellence.
- People – someone on another Scrum Team, in my Nexus or another Nexus, but not necessarily a PBI being worked on by another team; person is on vacation, only one person with that skillset, communication paths within the team and the Nexus, etc. Domain – If you are organized around business domains, there may be features that overlap those boundaries (e.g. workflow) Technology – frameworks, DBs, messaging servers, other types of servers, tools, etc. (e.g. don’t have access to a DB to deploy your code/schema) Software/software implementation – for a single team, execution sequence; across team, architecture misaligned to team structure (e.g. the code I need to change isn’t under my team’s control) External – any of the above types of dependencies which are not solvable within the Nexus (e.g. a finance person is required to provide biz rules)
- The term “Nexus” means a connection, link; also a causal link, or a connected group or series. It’s origin is Latin (from nectere "to bind“) and was first used in 1663 (http://www.merriam-webster.com/dictionary/nexus) It’s not about the structure, it’s about the connections (i.e. collaboration and conversation)
- Consists of 3 to 9 Professional Scrum Teams: To interoperate, significant architectural components must standardize their interaction The Nexus’ foundation is Scrum and the heart of the Nexus is 3 to 9 Professional Scrum teams.
- There is no separate Nexus Integration Team Product Backlog; they work off of the same Product Backlog as everyone else They may develop utilities, scripts, etc. to help with integration
- This module is about managing the Nexus, not about managing in general. The first few topics will appeal to PMs ($) and the last few are more technical
- Adding practices/tools may initially slow you down
- Adding practices/tools may initially slow you down
- The reason a nexus is limited to 9 teams is point 1 (see Dunbar’s Number for specifics: http://en.wikipedia.org/wiki/Dunbar%27s_number) If you haven’t experienced this then you shouldn’t be teaching this Scaled Scrum teams of this size are built on the foundations of Professional Scrum at each individual single team
- 10,000 google developers check in to trunk every day. No branches. From a Google dev-op talk
- Microservices: Source: http://martinfowler.com/articles/microservices.html
- About Gunther Verheyen Gunther Verheyen (gunther.verheyen@scrum.org) is a seasoned Scrum professional. He works for Scrum.org, the home of Scrum. He represents Scrum co-creator Ken Schwaber and Scrum.org in Europe. Gunther ventured into IT and software development after graduating as Industrial Engineer in 1992. His Agile journey started with eXtreme Programming and Scrum in 2003. Years of dedication followed, of working with several teams and organizations, of using Scrum in diverse circumstances. Building on the experience gained, Gunther became the driving force behind some large-scale enterprise transformations. Gunther left consulting to partner with Ken Schwaber, Scrum co-creator, at Scrum.org in 2013. He is Professional Scrum trainer, directs the ‘Professional Scrum’ series and co-created the framework for Evidence-Based Management of Scrum.org. He shepherds classes, trainers, courseware and assessments for the programs of Professional Scrum Foundations (PSF), Professional Scrum Developer (PSD), Professional Scrum Master (PSM), and Professional Scrum Product Owner (PSPO). In 2013 Gunther published his highly appraised book “Scrum – A Pocket Guide,” a ‘smart travel companion’ to Scrum. Gunther lives in Antwerp (Belgium) with his wife Natascha, and their children Ian, Jente and Nienke. Find Gunther on Twitter as @ullizee or read more of his musings on Scrum on his personal blog, http://guntherverheyen.com/tag/scrum/.