Tag: Scaled Scrum

Scrum is a minimal, yet sufficient framework for self-governing product eco-systems to create, evolve and maintain complex products.

Scrum defines the in and the out of the system:

• The system works on ideas, suggestions and options that are converted into Product Backlog for reasons of transparency and manageability.
• The system produces a valuable Increment of product, a release candidate, no later than by the end of a Sprint.

Scrum defines 3 complementary, peer accountabilities to balance all activities required for modern, Agile product development:

• A Development Team converts the desirements ordered via the Product Backlog into valuable Increments of product in no more than a Sprint’s time, where a Sprint is no more than 4 weeks and often shorter.
• A Product Owner optimises the flow of value, balancing innovative, novel ideas against desires, wishes, suggestions and needs stated by the user base, the stakeholders, the organisation, the teams.
• A Scrum Master fosters an environment in which the Product Owner, the Development Team, and the organisation get the most out of Scrum, using many possible management techniques.

The system called Scrum might consist of multiple teams creating, evolving and maintaining one product. It shouldn’t supersede the minimalism of Scrum. The system works off of one Product Backlog and creates valuable product Increments through the accountabilities foreseen by Scrum.

The context of multiple teams creating one product is often interpreted as an obligation for every team to be a Scrum Team, and every team to be a complete and full-time feature team.

Scrum doesn’t define accountabilities as an excuse to fill positions. Scrum thrives on understanding the accountabilities rather than on blindly filling positions and claiming titles. Scrum doesn’t instruct a uniform, detailed layout of the internals of your system.

Use Scrum to optimise the whole. Optimise your Scrum. Employ Scrum to build a product with multiple teams. Your system is expected to be a feature system, a system capable of producing valuable Increments of product, no later than by the end of a Sprint, regardless the setup of the teams. The accountabilities are expected to be fulfilled, regardless the number of people it takes throughout your system.

Minimally, for n teams working on one and the same product:

• There are n Development Teams, where the composition of each team is likely to depend on your context. Ultimately, the combined teams need to be able to produce valuable Increments while maintaining the integrity of the product. They self-organise to optimise.
• There is 1 Product Owner, and most likely a distribution of product ownership. The form of the distribution depends on your context. Ultimately, the flow of product value needs to be unhampered, frequent and targeted.
• There are 1-n Scrum Master(s), depending on your context. Ultimately, the eco-system and the environment in which it operates need sufficient and sufficiently provocative support, guidance, protection and coaching.

Frameworks like LeSS, Nexus and Scrum@Scale offer diverse strategies at scale that might help in your situation if you are unable to keep your system minimal. Consider your specific needs and opportunities to optimise carefully.

A system called ‘Scrum’

Scrum is founded on empirical process theory. Scrum implements regular inspections and adaptations in a closed-loop feedback system to deal with unpredictable events, changes and circumstances. The output of the system is used to be compared against new or updated input in order to update the output.

The input to the system of ‘Scrum’ is Product Backlog. The output generated defines the core purpose of the system, i.e. the availability of a Done Increment. The time of one cycle to create such a Done Increment, which can be used as input for a new cycle, is limited to 30 days, and often less. Such a cycle is called ‘Sprint’ in Scrum.

Technically Scrum has 2 elements of feedback being fed into the next cycle, i.e. the results of the inspection of the product at the Sprint Review (the Increment) but also the inspection of the process at the Sprint Retrospective. The system internally implements an additional, daily inspection and adaptation at the Daily Scrum to assure the best possible progress toward creation of a Done Increment.

Done (of an Increment) reflects releasable. Every Increment has all the qualities that make it fit for use. Whether it is actually released is a separate decision, but it has no impact on what defines “Done.”

One Scrum Team

When one team develops and sustains a product through Scrum, their ability to create releasable Increments might depend on the availability of skills within the team, access to tools and infrastructure, and dependencies within their one-team system. They self-organize around the inner-team dependencies, their Scrum Master works hard to (help) remove the other.

Sprint length is set to the right frequency to enable learning (and incorporating new insights in the next Sprint) about:

• How valuable the product actually is,
• The fitness of the applied technology,
• Current market changes.

A few, or more, Scrum Teams

When a few teams are developing and sustaining a product though Scrum, additional complexity comes into play. Additionally the teams face cross-team dependencies to produce releasable Increments, where releasable includes integration. This results in the need for additional communication and alignment. It explains why velocity, the measure of producing releasable software, of a team working stand-alone is always higher than the velocity of that same team in a construct of multiple Scrum Teams.

Often Scrum Teams find it easier to work on the same Sprint length to have a shared Sprint Review and thereby reduce complexity. Within the Sprint work is synchronized via a Scrum-of-Scrums, a Daily Scrum across the teams.

When many Scrum Teams need to co-develop one product, dependencies become huge. There are not only the inner-team dependencies that every single team faces, but also an exponentially growing number of dependencies in Product Backlog and in the codebase.

The goal of a system called ‘Scrum’ however remains to create releasable Increments by the end of every Sprint, where a Sprint takes no more than 30 days, preferably less. If such Increment is not created, the closed feedback loop is broken, and the opportunity to adapt is lost.

A solution that up to some level circumvents this, is to align Sprint lengths of the involved Scrum Teams. The goal of such enforced cadence has the purpose of ultimately synchronizing at joint Sprint Reviews, the ultimate way to create and review integrated software. At the slowest pace of the involved team(s) a fully integrated Increment is available.

It is however still a limitation of autonomy, and autonomy is the best possible weapon against dependencies.

Cultivating Your Green Tree

The autonomy of teams is reflected in their ability to autonomously set their own, proper Sprint length. Such autonomy can be largely increased by keeping all code of the product integrated. At all times.

The state of integration of the work is a source of inspection that might lead to adaptations that get priority over all other work to be performed. Integration needs to be fixed first before -upon a green integration light- new work can be added to the system. Work on your trunk only, and keep your trunk green at all times. Cultivate your green tree.

When work is kept integrated at such a rigorous rate, the need or necessity of shared Sprint Review meetings, as the way to ultimately synchronize results across multiple teams, dissipates. When work is rigorously kept integrated, all the time, each and every one of the involved Scrum Teams can derive a reviewable Increment from the integrated codebase autonomously and independently. The work performed during their Sprint can be reviewed with the Product Owner and specific stakeholders, allowing focus on a specific part of the system alone.

Complexity is suddenly hugely reduced, while the ability to release integrated software is retained as well as the advantages of time-boxing the creation of output. No heated debates over big enough rooms for all shared meetings. No heated debates over the exact time-boxes across teams. Autonomy, and ultimately… self-organization.

The system exhibits all core characteristics of Scrum as a closed-loop feedback system, the same characteristics that one team would exhibit; empiricism and self-organization. As a whole the system exhibits flow and continuity. The system operates at scale, yet is back to being… Scrum. The benefits of Scrum are scaled. Individuality, bottom-up energy, collaboration, self-respect are framed, not overruled, imposed or dictated, leading to autonomous teams creating cohesive product.