Ken Schwaber

Scrum is a mindset, an approach to turning complex, chaotic problems into something that can be used. eff Sutherland and I based it on these pillars: Small, self-organizing, self-managing teams; Lean principles; and, Empiricism, using frequent inspection and adaptation to guide the work of the teams to the most successful outcome possible.

Scaled Professional Scrum is based on unit of development called a Nexus. The Nexus consists of up to 10 Scrum teams, the number depending on how well the code and design are structured, the domains understood, and the people organized. The Nexus consists of practices, roles, events, and artifacts that bind and weave the work together to produce a whole. We have found that when we get above ten Scrum teams that their ability to create usable products frays. The complexity and the dependencies that require resolution are overwhelming. The ability to create a “done” increment and not leave behind a pile of technical debt is daunting without shortcuts that reduce product viability. Some high tech vendors claim to regularly employ 100 or so Scrum teams on products and product families. They are not scaled, however. Scaling carries with it the responsibility that all of the attributes of the smallest element are found in the sum of all of the elements (100 or so teams perform like one team). This is similar to the mathematical expression that generates uniform, interlocking fractals. Let’s look Scrum’s fundamental principles: empiricism and bottom up thinking. Empiricism requires inspection of known artifacts and appropriate adaptation. Working software has no egregious unresolved dependencies. Business functions interoperate intelligently, the people with the knowledge to create them worked together to build these, the data layer, UI layer, design, and code all are woven together into something that works and can be readily added to in the future. And, when tested, they do what is expected and do it with everything else as expected. We have come to call an increment that does this “done.” Sometimes “done-done.” In Scaled Professional Scrum I refer to it as reified (reification generally refers to making something real, bringing something into being, or making something concrete). If all things are optimal, I have found that no more than ten or so Scrum teams can build a “reified” increment that is truly done, usable, and doesn’t leave technical debt. If the starting point consists of sloppy code and design, poorly formed ideas, and people that aren’t skilled or work together well, then a much smaller number of teams is the only viable approach. However, when you get to twenty or so teams it doesn’t matter how optimal the context is. To take them and integrate their selected product backlog into a system that has a new working increment added to it just doesn’t happen. The complexity of dependencies that must be resolved is too great. However, management doesn’t believe this because, duh, they aren’t software developers. So they put 100 teams on it. Since we can’t reify our integrated work at this scale, we instead demonstrate our working branch of working, partially tested functionality.. Management sees many functions working, but they aren’t integrated into a whole (reified). Then comes ship date. Whoops … we have to integrate all of the stuff. Guess what happens… the death march to make it look reified even though it is patched together. Think of IOS and the SDK, or the new Google Brillo and Weave. These are standardized structures that define how functions must work together to be part of the system.. The same is true for the IOS and SDK of the Tesla, except in spades. So you can have hundreds and hundreds of Scrum teams working on the same product area. However, when you have functionality that requires more than nine or so teams you have two choices: Build architectural and platform structures (IOS, API, etc.) that defines how the functionality from each set of Scrum teams must deliver and interoperate. and/or take longer and only do as much as the nine or so teams can do at once. Then do more. Then do more.

In this short video, I explain the challenges of scaling Scrum and how to create a Nexus™ to manage multiple Scrum teams to deliver an integrated increment every Sprint.

Find out with a short test? A single instance of Scrum has one Scrum Team that works from one Product Backlog. The team sprints against the selected Product Backlog items and creates an increment of potentially shippable, or usable, functionality by the end of the Sprint If you want to test your knowledge of scaling Scrum, I set up a little test for you. From the outside, Scaling Scrum is exactly the same. One Product Backlog provides input to a Sprint. At the end of the Sprint, an increment of potentially shippable functionality has been developed and is ready for us. However, on one of more Sprints the Product Owner has chosen to employ more than one Scrum Team. The number of Scrum Teams can be constant and their composition can remain the same, or not. Reasons for Scaling Scrum include: Desire to complete functionality more rapidly by applying more Scrum Teams to the Product Backlog. Need to apply more people to the Product Backlog for one or more Sprint than can be readily accommodated in one Scrum Team. A singularity of diverse skills applied at one time may generate this need, such as developing a user interface framework, secure architecture, and piece of functionality within one Sprint. All of the basic values, principles, artifacts, roles, and meeting of Scrum apply, whether Scrum is singular or scaled. These remain inviolate for the purposes of controlling risk, generating creativity and productivity, and creating transparency. As more Scrum Teams work together on a Product Backlog, the number of interactions, complexities, and non-linear events increase. The relationship between productivity/creativity and the number of Scrum Teams is not linear. Product Owners employing multiple Scrum teams need to carefully weigh the benefits and costs. Scaling Scrum is a program from Scrum.org to manage and operate multi-Scrum Team initiatives. Techniques for organizing and selecting Product Backlog, resolving dependencies and integrating work, and creating “done” increments are evaluated. Since every development situation is different (domain, people, technology), every set of techniques if unique and often has to change with time. Scaling Scrum is a hand-on, sleeves rolled up workshop where people figure out one instance and nuances of other instances of scaling Scrum that might work for their projects, releases, initiatives, or organizations. This is not a management overview. The people who will setup, run, coach, and optimize multi-Scrum team initiatives are the audience. We want to help you determine if this workshop is for you. To that end, we have developed a ten-question test that you can use to assess your knowledge (or desired knowledge) of techniques for scaling Scrum. You can take it at no charge. If the assessment addresses the issues you want to tackle, sign up for the workshop. We look forward to sharing our experience scaling Scrum with you. The Scaling Scrum program also provides metrics to measure the value generated by the approach selected for a multi-team Scrum Team project. As management monitors the metrics, the techniques can be adjusted to increase the value of the results. You may find it useful to read how to measure how effectively you scale your scrum effort prior to attending the workshop. Learn more.

Jeff Sutherland and I have helped hundreds of organizations scale their projects, enable their entire product development, and thread Scrum through their organizations. For sure, none of them were easy, and each had its own unique challenges. Each had its own structure, culture, goals and strategies, challenges, current practices and infrastructure, domains of competence, existing software, and people. We assert that only a systematic, emergent, managed initiative to scale succeeds. Every initiative to scale is unique. Nobody knows what your organization needs to scale Scrum. And, nobody knows what your organization will look like as you scale. To get a good feel for what scaling Scrum feels like, I refer you to Eliyahu Goldratt’s “The Goal” (or any of his later books), or Gene Kim and Kevin Behr’s “The Phoenix Project.” You will see the difficulty of teasing through symptoms to root causes, the effort to find solutions, and the possibility that solutions have undesirable side affects. Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling. Although they look familiar, the familiarity is only skin-deep. As anticipated, these cookie-cutter approaches fizzled out within months of being deployed. Scaling scrum requires concerted effort by an organization. The leaders should start thinking about answering these questions: How often does the work have to be released? What techniques are going to be used to integrate work to that frequency? What will be done to measure and manage the work and its integration? What overhead is being absorbed to achieve this integration and delivery? Are the cost and benefits of delivery frequency balanced by value returned? How is the cost going to be systematically reduced? Based on experience, we have created frameworks that provide the sinew from which scaling can proceed. Based on your current unique situation, you can progressively scale the Scrum artifacts, integration and communication techniques, domains of competence, team formation and structure, release management, practices and tools for automating them, and so forth onto them. Jeff and I cannot be everywhere, so we’ve had our teams at Scrum.org and ScrumInc develop several workshops to help you get going, to use the framework systematically and effectively. For me, Scrum.org is conducting two-day workshops that will have development leads and managers build out the framework to fit their specific situation and needs. These workshops are for people who will do the scaling, results-oriented workshops, not overviews. At the workshop, they will learn how to extend a single Scrum to large projects and organizational initiatives. The first workshop is in Boston on December 4-5, and the second in Amsterdam (Delft) on December 11-12. Others will be announced during December. If you want to successfully scale your organization’s use of Scrum, based on your own needs, experiences, and goals, we look forward to meeting with you.

Every year, organizations spend 4-10% of their revenues on their IT organizations. Value is expected in return for these expenditures. Here, value is defined as the financial benefit that an organization receives for expenditures. When measured, value can encompass an entire organization, or be constrained, such as to a single division or product line. Regardless, it must encompass those areas affected by the expenditure. Value will be a point in time measurement comprised of: revenues per employee – gross revenues per employee employee satisfaction – how satisfied are the employees? After investing in employees, they become a substantial asset and competitive advantage. customer satisfaction – are the customers more or less satisfied than in the past? Finding a new customer is much more costly than satisfying current customers. An organization can change value through: products and services that it sells and delivers. systems, both manual and automated, through which it delivers the products and services. We focus on the latter. Philips Lighting Philips Lighting, a multi-billion dollar division of Philips Corporation, recently completed a project to “accelerate” its value creation. The project spanned operations from when a quote was given to a customer until the cash was received. The project had two components: Revised business operation, integrated into a new operations flow created through value stream mapping and relentless waste elimination. New software systems, based on Salesforce products, that supported the new business operation. Each component required the other to succeed. Improved IT operations would have no impact on organizational value unless the business could effectively utilize it. Value Metric We have devised a metric that attempts to capture both aspects of an organization’s current ability to create and deliver value. It consists of: Operational metrics, measuring an organization’s efficiency. These metrics are heavily slanted toward IT, both the development of software and the deployment of it in the organization. They include flow, cycle time, stabilization, quality, utilization rate, and release cycle time. Business operational efficiency is not included in these measurements, but will be addressed in 2014 as part of the Kotter International (John Kotter) Accelerate! program. Organizational metrics, measuring the impact of that efficiency of investment on the marketplace and the value the organization accrues. These metrics are revenue per employee, customer and employee satisfaction, and product/system cost ratio. The two metrics are combined into a single metric, Agility Index. The Agility Index is a number indicating relative agility, from 1 to 100. It is heavily weighted toward organization value. That is, an organization can be incredibly competent, but if it doesn’t derive marketplace value from the efficiency, the Agility Index is low. As an organization expends funds on IT, projects, and business improvement, it should expect that this metric would increase. Traditional project measurement criteria A traditional project assesses a need and defines a complete set of requirements to satisfy the need. From these requirements, a due date and budget are established. Once these are established, any changes are fit in as possible. All metrics are accumulated against this type of project. Value does not enter the measurement. CriteriaSuccess Requirements: All requirements stated at the beginning of the project have been satisfied Budget: Budget allocated at the start of the project was not exceeded Timeline: Date for completion of the project was not exceeded Agile/Scrum project measurement criteria Agile/Scrum projects are different. A goal is established: this is the intended impact and objective. A date and funding may be estimated based on past experience, or may emerge experientially as the work progresses. All effort will be directed to achieve the best possible solution to this goal. This initiative is complete when the solution is either created, or it is determined that it cannot be reasonably created at this time. In the agile project, each Sprint or iteration is a complete project. It has requirements, budget, and due date. At the end, it has a completed set of software functionality. Based on what is completes, another project may or may not be initiated, adding more functionality to the functionality just completed. Each Sprint is measured on its own. CriteriaSuccess Confidence of investors in value: Confidence of stakeholders, product owner, and developers that the best possible solution was created for the goal of the initiative for the most reasonable amount of funding. Satisfaction of investors: Willingness of stakeholders, product owner, and developers to do this type of initiative again. Confidence in utility of software: Confidence by people using the system or product that it provides a better way of doing work than before. Satisfaction of customers: The degree to which the users look forward to the next solution to helping them do their work better.