More on Scaling Scrum

Categories Agile, Bodies Of Knowledge, Scaling, Scaling Scrum 27 Comments

I’ve been working with people who have actually made Scrum scale for large projects and product initiatives over the last twenty years. Our smallest project experience was 3 teams, average 25 teams, and largest was 80 teams.

We abstracted a framework for this scaling which we named Nexus, defined as a causal link between things, such as biological nervous systems. In our case, a Nexus is 3-9 Scrum Teams that are working on a single Product Backlog to build an integrated increment that meets a goal. A Nexus+ is more than one Nexus inter-operating to build a large product, usually integrated through a product family framework, api, or such.

We developed or reformulated new 30+ practices which cause the Nexus to operate predictably.

We call this Scaling Professional Scrum, because we agreed that you cannot Scale amateur Scrum, represented by such bad practices as lack of integration and excessive dependencies. The program consists of:

  • Development workshop, for those who will actually scale the Scrum teams into an integrated, coordinated effort. The audience is systems engineers, lead developers, development managers …. the people who will make this happen and have strong familiarity with modern development and Scrum
  • Management workshop, for those who will manage the scaled initiative.
  • Organizational workshop, for those who will establish and manage the agile organization, consisting of multiple Scrum and agile projects, providing the infrastructure and supporting functions.
  • Leadership workshop, for those who will lead the path to agility in their organization.

Scrum.org consultants and trainers are currently being trained in the Development workshop. I will co-teach the first public Scaled Professional Scrum Development workshop in Boston on March 12 and 13, with Steve Porter and Rich Hundhausen. You can register for this workshop at http://bit.ly/1DfEb1b. More will be offered starting in April, along with one day Management workshops.

BEFORE you sign up for the workshop (actually, as a test of the likelihood of your success in scaling), we have put up a free and open assessment at http://bit.ly/1BB12Ch. If you understand the questions and do reasonably well, the workshop is for you. If you are baffled by the questions and even why they were asked, the workshop is probably not appropriate.

Those of you who have invested and attempted commercial scaling methodologies such as SAFe will find this workshop may well fill the gap that you noticed when you got to actually setting up and running scaled software development.

We move forward.SPS Logo

Ken

27 thoughts on “More on Scaling Scrum”

  1. Pingback: The “Scrum Practitioner Open” assessment | Ullizee

  2. Ken, I always put effort in preparing myself for trainings. I read about LeSS, SAFe, DaD, read books, blogs, viewed videos. But somehow I can’t find much material about Scaling Proffesional Scrum. can you help me out?

  4. Hi Ken

    Is Scaling Professional Scrum the same initiative as the one you blogged about on October 25th? More specifically:
    – Is SPS the same as Jeff Sutherland’s Scrum@Scale?
    – Are these separate brand names for a shared and co-ordinated body of knowledge?

  6. Jeff, is this workshop specific to setting up and running scaled “software” development or any type of initiative?

    Thanks,
    Milan

  8. The workshop helps you learn how to use a framework to scale Scrum development, including the roles, artifacts, and events. We go into what creates more value and velocity when scaling, and what practices do the opposite. Many exercises.

  11. Nexus and Nexus+ are names that describe practices that we have used at Microsoft, Intuit, Keybank, Adobe, and other organizations that do not want to be named. We are describing something that we know from practice works.
    Ken

  13. Hello, Ken.
    I am coaching a team working on a multi-national Agile initiative with more than 100 teams and scrum masters. How about publishing some insights on your March and April Scaled Professional Scrum workshops?

  14. 100 teams.!!
    Obviously I will not be of great use to you without an understanding of the application, its current state, its architecture, etc. etc. The context and the goal.

    I do know that you need a unifying architecture that sets the rules, diminishes the dependencies, and provides something the teams can work toward. The issue will always be getting the teams to resolve dependencies and integrate the work.

    The sign of failure comes when the overall velocity drops to an unacceptable level, the defects overwhelm the work, and a sustained, horrible stability phase is needed to pull something workable together.

    I wish you the best. You need to come to a scaling workshop, or better yet have one of our scaling consultants walk you through this. I hope, of course, that you’ve read “Continuous Deployment.”

    Best wishes,
    Ken

  15. Hi Ken,
    Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focused our colleagues). Because of this we developed a SaaS tool to “automate” the daily standup meetings – with just a single email. If you like to take a look: http://www.30secondsmail.com.
    Best,
    Ajie

  16. You have turned an event where the unexpected emerges and is dealt with to a management event that can be ignored. Read some more before you continue this approach and you will find you productivity and joy of working soaring.

  17. I find a 100 Teams not so uncommon. Telco vendors(Ericsson, Huwaei, NSN…)usually have several hundred teams, that need to create&deliver a consistent portfolio of interrelated products+services. 3-9 teams per product is clearly below average there. Yet, IMO none of these companies achieved “being agile” as a holistic entity.

    • So well said. Telco and such high tech vendors as Siemens regularly employ 100 or so Scrum teams on products and product facilities. They are not scaled, however. Scaling carries with it the responsibility that ll 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).
      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 nine or so Scrum teams can build a “reified” increment. It is done. If the code is sloppier, the design worse, the ideas poorly formed … then less teams. And visa versa.
      However, when you get to twenty or so teams it doesn’t matter how optimal the work is. To take them an integrate their selected product backlog into a system that has a new working increment added to it just doesn’t happen. However, management doesn’t believe this because, duh, they aren’t software developers. So they put 100 teams on it. We can’t reify our work so we usually show they each team (or several team’s) work in a branch that functions. 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:
      1. Build architectural and platform structures (IOS, API, etc.) that defines how the functionality from each set of Scrum teams must deliver and interoperate.
      2. 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.

      If you ignore this, examples of your fate already exist in Double-click, Motorola’s cell phone operating system, and a herd of other products that can no longer compete because they are have lost their agility and flexibility.

      I’m writing the SPS/Nexus guide (similar to the Scrum Guide) that will spell out how this works in more detail. How quickly it can be reified is – of course – dependent on all the other stuff in life.

      Best,
      Ken

  18. Ken, I’m confused by this paragraph in the Nexus Guide 1.1:

    “To begin Nexus Sprint Planning, appropriate representatives from each Scrum Team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum Teams should participate to minimize communication issues.”

    The first sentence seems to imply a subset of the scrum teams participates in the Nexus Sprint Planning while the second says “All members of the Scrum teams should participate”

    Respectfully,
    Ed

  21. Just discovered Ed Newton’s post:
    Are there 3 groups of attendants at the Nexus Sprint Planning?
    a) NIT members
    b) Appropriate representatives
    c) plus all of the members of all the Scrum teams join them

    Is this correct?
    Thanks.

Leave a comment