Scaled Professional Scrum - Scrum Days Poland 2015
•
14 likes•3,251 views
Gunther Verheyen closed the first edition of the Scrum Days Poland in Warsaw by presenting Scrum.org's vision on "Scaled Professional Scrum". Gunther focused much on how the Nexus implements Scrum for 3-9 Scrum Teams. This is the full version of the presentation. Time was too short to go through it completely. Highest value was still delivered. Gunther shepherds the Professional series at Scrum.org and is Ken Schwaber's partner for Europe.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scaled Professional Scrum - Scrum Days Poland 2015
Similar to Scaled Professional Scrum - Scrum Days Poland 2015 (20)
More from Gunther Verheyen
More from Gunther Verheyen (13)
Recently uploaded
Recently uploaded (20)
Scaled Professional Scrum - Scrum Days Poland 2015
- 1. by Scrum.org – Improving the Profession of Software Development Scaled Professional Scrum Focused. Effective. Viable. Gunther Verheyen Shepherding the Professional series Scrum.org Scrum Days Poland May 29, 2015 Warsaw
- 2. 2© 1993-2015 Scrum.org, All Rights Reserved A Craze During the First Decade of Agile? scrum·pede/skrʌmˈpiːd/ 1. Sudden frenzied rush of (panic–stricken) companies to do Scrum because they want to be agile, too. 2. To flee in a headlong rush to scaling Scrum (or something that looks like it) because they need more software, now. Inspired by © Tomasz Włodarek.
- 3. 3© 1993-2015 Scrum.org, All Rights Reserved MIN 3 Have you been engaged in efforts to scale Scrum? How does your scaled implementation look like? • Multiple teams working on one product • Multiple teams each working on one product • Multiple teams working on multiple products • One team working on several products • The complete IT organization adopting Scrum • A 360° organizational transformation toward Agile Short Survey About You
- 4. 4© 1993-2015 Scrum.org, All Rights Reserved Why Organizations Want to Scale Scrum • Great results with small initiatives of 1-3 teams • A desire to gain similar benefits from larger initiatives • Looking for a straightforward approach that builds on their current knowledge and skills
- 5. 5© 1993-2015 Scrum.org, All Rights Reserved Scaling Fundamentals Scaled Professional Scrum “It takes two to scale.” – Gunther Verheyen
- 6. 6© 1993-2015 Scrum.org, All Rights Reserved Definition of Scaled Scrum 1. Any implementation of Scrum where multiple Scrum Teams build one product in one or more Sprints. 2. Any implementation of Scrum where multiple Scrum Teams build multiple products, projects, or standalone product features in one or more Sprints.
- 7. 7© 1993-2015 Scrum.org, All Rights Reserved Focus. Transparency.
- 8. 8© 1993-2015 Scrum.org, All Rights Reserved One Scrum Team Doing Work Product Backlog
- 9. 9© 1993-2015 Scrum.org, All Rights Reserved Professional Scrum Starter Scrum Values and Principles Technical Excellence Grow Your Implementation of Scrum The Scrum Framework Professional Scrum
- 10. 10© 1993-2015 Scrum.org, All Rights Reserved Three Scrum Teams Doing Work Product Backlog
- 11. 11© 1993-2015 Scrum.org, All Rights Reserved Nine Scrum Teams Doing Work Product Backlog
- 12. 12© 1993-2015 Scrum.org, All Rights Reserved Dependencies • People (communication) • Business domains and requirements • Technology • Software • Infrastructure • Internal vs. External
- 13. 13© 1993-2015 Scrum.org, All Rights Reserved Proactively identify and work around dependencies: – Ongoing – Persistent – In all dimensions – Prior to work occurring Reactively reveal undetected dependencies: – Frequent integration – Acceptance testing – Continual build and delivery – Minimize technical debt Dealing with Dependencies Dependencies Reification* *Reification: Making something real, bringing something into being, or making something concrete.
- 14. 14© 1993-2015 Scrum.org, All Rights Reserved The ability to scale is the ability to continuously: – Identify and remove dependencies – Integrate work across all levels – Create and inspect integrated increments
- 15. 15© 1993-2015 Scrum.org, All Rights Reserved Nexus Scaled Professional Scrum “A man who carries a cat by the tail learns something he can learn in no other way.” - Mark Twain
- 16. 16© 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
- 17. 17© 1993-2015 Scrum.org, All Rights Reserved Multiple Scrum Teams Doing Work 1. A product has one Product Backlog. 2. Multiple Teams create integrated Increments.
- 18. 18© 1993-2015 Scrum.org, All Rights Reserved The Nexus™ – An Exoskeleton for 3-9 Scrum Teams
- 19. 19© 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
- 20. 20© 1993-2015 Scrum.org, All Rights Reserved A 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.
- 21. 21© 1993-2015 Scrum.org, All Rights Reserved Specific Scaling Tactics in the Nexus™ • 40 Practices • New Role – Nexus Integration Team • Expands Scrum’s events to the dimension of 3-9 Scrum Teams • New Artifacts – Nexus Sprint Backlog – Integrated Increment
- 22. 22© 1993-2015 Scrum.org, All Rights Reserved Nexus - 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
- 23. 23© 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 Scaling Questions Process Cost
- 24. 24© 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
- 25. 25© 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
- 26. 26© 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
- 27. 27© 1993-2015 Scrum.org, All Rights Reserved The Nexus interconnects 3-9 Scrum Teams in creating one Increment of product with minimal overhead and maximal efficiency.
- 28. 28© 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
- 29. 29© 1993-2015 Scrum.org, All Rights Reserved Yes, You Can Scale Beyond The Nexus Value.Dependencies.
- 30. 30© 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.
- 31. 31© 1993-2015 Scrum.org, All Rights Reserved Scaling Options – Horizontal, an Architecture of Equals • Nexuses integrate into horizontal platform • Platform provides stability through integration standards and facilities • An additional Nexus manages and develops platform • Tightly integrated Nexuses – IOS/SDK • Medium integration Nexuses – Microsoft COM – Product family architecture – API • Loosely integrated Nexuses – Workflow – UI Platform
- 32. 32© 1993-2015 Scrum.org, All Rights Reserved Build your own iOS and SDK Provide the iOS and the apps will come: • Shell Oil • Apple • Google • Tesla
- 33. 33© 1993-2015 Scrum.org, All Rights Reserved Microservices • Decentralized control (of languages and data) • Organized around business capabilities • Connects to feature teams (Conway’s law) • Autonomously deployable • Focus on product, not projects Source: http://martinfowler.com/articles/microservices.html
- 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 Closing Empirical Management Explored
- 36. 36© 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
- 37. 37© 1993-2015 Scrum.org, All Rights Reserved About Gunther Verheyen • eXtreme Programming and Scrum since 2003 • Professional Scrum Trainer • Directing the Professional series 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
- 38. 38© 1993-2015 Scrum.org, All Rights Reserved Scaled Professional Scrum by Scrum.org • SPS Workshops • Nexus Guide • Nexus Assessments • Agility Index • Agility Path
- 39. 39© 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
- 40. 40© 1993-2015 Scrum.org, All Rights Reserved T H A N K Y O U
Editor's Notes
- Short Abstract Many organizations demonstrate a compelling desire to become Agile. Where the Agile movement, sprung from the Manifesto for Agile Software Development, focuses on software development, management might feel left out. But is that really the case? One of the core objectives of the agile movement was to shift the focus of software development to creating more valuable software, frequently. It can be expected that the act of managing in an agile environment therefore puts value at its heart; over holding on to old, industrial parameters like scope, budget, time. In a value-centered environment, informed management decisions to maximize value cannot be made without transparency over the question whether the software is indeed valuable; valuable to the organization, its users and the wider ecosystem. There is value in applying the Scrum Stance in the managerial domain. Indicators of value become the primary source for inspection, in order to adapt how the software is being produced. Enter a new management culture, Empirical Management, thriving on evidence-based decision-making. Gunther explores the idea of Empirical Management through the lens of Scrum’s history and the current, compelling desire of many organizations to scale Scrum. Gunther shepherds the Professional Series at Scrum.org and is a partner of Ken Schwaber. Extended Abstract Scrum has been around for almost 2 decades. During the first decade of agile, the adoption of agile and Scrum have grown incredibly. But the dependence of businesses and society on software has increased even more. Software is eating the world. The survival and prosperity of many people and organizations depend on software. Complexity and unpredictability continue to increase. Yet, many organizations are stuck with old thinking like productivity, performance and blindly pushing more requirements out to the market. The focus of managing has not shifted to optimizing the value that the software brings to the organization. The urgency to do so grows. The agile movement has left the act of managing largely unaddressed or -at least- under-focused. The agile values and spirit are more needed than ever, but it's time to include management. This can be achieved by applying the Scrum Stance in the managerial domain, hence promote Empirical Management. Gunther Verheyen directs the Professional Series at Scrum.org and is a partner of Ken Schwaber, Scrum co-creator. Gunther and Ken have developed a framework for empirical management based on the principles of Scrum, agile and Evidence-Based Management. EBM has its roots in medical practice. In his presentation Gunther look at the state of agile through the lens of EBM, and introduce how to apply its principles in a context of software. “If no evidence is collected on the value of software, informed management decisions to maximize it cannot be made. Software development deserves a professional way of managing, a way of managing that is more than mere intuition, opinion and position.” Learning Objectives Inspire by challenging some common understanding of ‘agile’ Participants will be challenged on their understanding of agile, and the purpose of agile at a business and management level. Participants will be challenged to shift their focus from how the development work is done, to the outcome of the work, and its impact on the market. Participants will get an insight into a possible future of agile, the future of agile in its next decade of existence. Audience For: Decision makers, leaders, managers looking to reground themselves in a context of 'agile'. Typical Elapse Time 1 hour
- Based on „stam·pede„ ( /stʌmˈpiːd/ ): Sudden frenzied rush of (panic–stricken) animals. To flee in a headlong rush. Followed by a rush toward scaling Scrum.
- 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.
- 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
- 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
- Need practice stamp
- 10,000 google developers check in to trunk every day. No branches. From a Google dev-op talk
- 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/.