Scaling, the Nexus, and Scrumbling

I will be conducting a Nexus workshop in Boston on November 17-18, with Richard Hundhausen and Rob Maher, based on the Nexus Guide. Of interest to many, SDK, API architectures, and remediation Scrumbles, and DevOps.

Many Scrum teams deliver a “done”, potentially shippable increment at the end of each Sprint.

As the number of teams rises, as the project scales, the “doneness” of the increment often decreases. The Product Backlog items that are delivered at the Sprint Review are incomplete or of poor quality.

Some projects maintain the façade of progress by having each individual team present its individual increment from its individual code base. The integration design, code, and testing into a scaled increment is left to the end of the project, to the ubiquitous “stabilization” phase.

The result of poor quality increments is a decline in velocity, Sprint by Sprint. Partially done functionality, pasted code, inadequate tests, and wobbly designs grow. The Scrum Teams either have to accept the reduced velocity from working with the degraded software and Sprint deliverables, or further reduce the quality of the deliverable.

I’ve developed a framework for scaling Scrum project to multiple teams, called Scaled Professional Scrum. Its fundamental construct is a Nexus of up to nine Scrum teams. Multiple Nexuses have their results integrated through a mechanism called a Nexus+.

To address the issues of undone increment, I’ve introduced a Scrumble. A Scrumble is an event that occurs when a Nexus cannot deliver a completed increment, one that is completely integrated, done, and ready for use.

Rather than continuing to build an unintegrated mess that become exponentially more difficult to remediate, the Scrum teams in the Nexus Scrumble. A Scrumble is an unbounded period of time where they review and evaluate:

  • Tools and practices that are being employed to continuously or frequently integrate and deliver working code;
  • Testing strategies and completeness;
  • Product Backlog decomposition and selection;
  • Sprint Backlog management;
  • The value of a software development kit that would create a common development environment for all teams (now and for future work on the system);
  • Adequacy of DevOps commitments for an increment that meets nonfunctional requirements, every Sprint; and,
  • Strategies and execution of branching and integration practices, as well as how well they are being adhered to.

Based on the reviews and evaluations, determine, in order of importance, what needs to be done to:

  • Upgrade the development environment and practices;
  • Remediate and refactor existing work into a sustainable code and test base;
  • Create a usable, reviewable integrated increment;
  • Create a development environment that supports the developers;
  • Train the developers in practices that use the development environment; and,
  • Develop system specific tools and components to reduce dependencies.

Once the Scrumble is complete, the Nexus should be better prepared to deliver usable increments. The next Sprint is started.

The length of time needed for a Scrumble varies with the skills, environment, people, and existing software. However, I would count on at least one Sprint.

One Scrumble may be enough. However, if the Nexus again finds itself with unshippable, undone increments, it may need another Scrumble.


The purpose Scrumbles is to avoid an unpleasant surprise at the end of the project or release, to sustain transparency and reduce risk, and to spot the most valuable asset – the code base – from being unacceptably degraded.

Scrum on.

20 thoughts on “Scaling, the Nexus, and Scrumbling

  1. Hi Ken

    Suppose it becomes clear part way through a Sprint that integration is too degraded for the Nexus Sprint Goal to be met. Would a “scrumble” then logically follow from a Nexus sprint cancellation?

    • I’m a bit concerned about the potential for misuse, in so far as a scrumble could become a sink for technical debt. Teams and/or the wider organization may end up planning to sweep undone work up in a scrumble. It would thus degenerate into an instance of the “hardening” antipattern.

      In other words, although we might position a scrumble as a remedy to a growing systemic problem with a particular Nexus implementation, the technique could become normalized as a planning tool.

  2. Hi Ken

    Can you clarify the following:
    1. Is the purpose scrumble to reduce the technical debt of nexus ? something most of the people mention has hardening or Stablization sprint to complete the undone work.


    2. Is it an improvement practice to review and find the improvement areas in nexus? something like overall retrospective


  3. Are we talking here about a hardening sprint ? Or an innovation & Planning Sprint as it is described in SAFe ? The timebox concept in Scrum seems to be harder and harder to maintain VS continuous discovery and delivery.

  4. The purpose is to improve the ability to work as a group of teams to create a single potentially shippable increment each Sprint. That might be relearning practices, learning how to use the tools better, learning how to decompose and share the Product Backlog better, finding out that the team(s) don’t have the skills needed and adding/removing people. What ever is needed so the team can actually build a integrated increment. If they just can’t, that certainly becomes an issue.

  5. “Rather than continuing to build an unintegrated mess that become exponentially more difficult to remediate, the Scrum teams in the Nexus Scrumble.”

    It sounds like “integration sprint” except for that it is not a sprint and it is not timeboxed (but the duration being at least one sprint).

    Unlike other approaches which have “hardening” every “N” sprints, I guess Scrumble is only applicable when multiple teams are adopting Scrum initially and when teams cannot ship a integrated product increment in the first few sprints. Is this corrrect Ken?

    • I think the critical difference is that a “hardening” sprint is expected to yield an increment for release, other sprints (fake sprints) not being held to that standard. A scrumble on the other hand, from my reading of what Ken says, does not result in an increment at all. It is a remedial event for matters of process and practice. Ken says: “Once the Scrumble is complete, the Nexus should be better prepared to deliver usable increments. The next Sprint is started.” This implies that no work is in progress during a scrumble. Rather, the induction of work is suspended until the remedial activities are complete.

  6. Thanks Ken for the reply. Scrumble seems like inspect and adapt practice to improve the process and optimize the entire nexus.

    How do you propose to start scrumble in nexus ? Can a overall retrospective with representatives from teams help here to find out the possible areas of improvement ?


  7. Ken,

    I am confused by your thought process on Scrumbling. The idea of Sprints was a predictable cadence. So now you are proposing something that is completely out of pattern with the regular cadence of Sprints. While your intentions may be good, people may read into it differently and Scrumbling may become the norm.

    As a pattern, it looks more like the erstwhile HIP – Hardening Sprint in Scaled Agile v2 from Dean or like a Release Iteration that Scott Ambler talks about in his DAD.

    Remember, what you intend and how the masses interpret what you say are completely off the rockers. To the crowds who follow your message, you need to feed ideas that are clear, concise and not misinterpreted.


    • So-called hardening sprints normalize a bad situation by pretending that undone work is OK. They try to bake in unreleasable increments as part of the normal sprinting deal, with the result that those sprints are faked. Scrumbling can be seen as the exact opposite, and as an open acknowlegment that the Scrum implementation must be fixed before new sprints can be planned. I think that’s the simple and clear message behind it.

  8. Institutionalizing Hardening sprints unfortunately normalized undone code and unresolvable technical debt.
    The insight behind Scrumblng is that many organizations will start the scaled effort without the necessary buildup and infrastructure. The Nexus will come to the Sprint Review without a done increment. What to do then.
    The norm is to accept the undone increment and move on. Scramble is a parachute the Scrum Master can pull that says: we don’t have the skills and infrastructure and architecture to develop at this scale. Let’s stop and reassess.

  9. Ken, thanks for sharing. I wasn’t in favor of the hardening sprint, but I also couldn’t think of an alternative approach to deal with accumulating technical debt. Scrumble looks like an effective intervention to fix the root cause which is a totally different approach than institutionalizing a hardening sprint. Think it has more commonalities with the “Stop the line” button from lean manufacturing, in which every employee on the assembly line has a responsibility to push a big red button that stops everything whenever they notice a defect, so they can identify and fix the root cause. I would suggest Scrumble is not only a parachute for the Scrum Master, but for every team member.

  10. Pingback: Studying for the Scrum PSM II Exam – Thoughts on Software Management and Development

  11. Pingback: Los tres vectores de la transformación - Café Ágil

  12. Pingback: 58. Lean Coffee Duesseldorf – online 04.06.2021 – Digital Mindchange

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s