Scaling, the Nexus, and Scrumbling

September 28, 2015 Categories Agile, Nexus, Scaling, Scaling Scrum, Scrum, Scrumble 21 Comments Tags continuous improvement, quality

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.