A System Called ‘Scrum’
Scrum implements empirical process control. Scrum mitigates risk and optimizes value through regular inspections and adaptations in a closed-loop feedback system.
Taking a step back shows that the overall input to the system called ‘Scrum’ is a stream of options, ideas, possibilities and requirements ordered into a Product Backlog. Observable working results are created as Done Increments in short cycles called 'Sprints,' where a Sprint takes no more than 4 weeks, and often less.
Sprint length is set to the right frequency to capture, and enact upon, insights about:
- How valuable the product actually is,
- The fitness of the applied technology.
- Current strategic conditions (market, company).
On the inside of the system, several additional feedback loops help a team work towards a Done Increment (Daily Scrum, delivery practices, the definition of Done).
One Scrum Team
When one team develops and sustains a product through Scrum, the team's 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 external elements that block or slow down the creation of Done versions of the product.
A Few, or More, Scrum Teams
When a few teams, or more, are developing and sustaining one product through Scrum, additional complexity comes into play. There are cross-team communication and integration needs, dependencies in Product Backlog and in the codebase. This results in the need for supplemental feedback loops, understanding that the goal of the 'Scrum' system invariably remains the creation of releasable Increments, where an Increment is for the product, not for a team.
Within the Sprint, work is often synchronized via a Scrum-of-Scrums, a Daily Scrum across the teams, enabling the teams to replan their work based on the other teams' progress.
Often Scrum Teams find it also easier to work on the same Sprint length. The goal is to ultimately synchronize realizations and expectations at joint Sprint Reviews, which is the ultimate point to review one integrated version of a product.
It is however still a limitation of autonomy, and autonomy is the most optimal strategy to eliminate dependencies.
Cultivating Your Green Tree
The autonomy of teams is partly reflected in their ability to autonomously set their own, proper Sprint length. The autonomy of teams can be hugely 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 should get priority over all other work to be performed. Why add code to a codebase if the existing code isn't integrating? Cultivate your green tree!
When work is kept integrated in a rigorous way, 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, or shared. The work performed during their Sprint can be reviewed with the Product Owner and specific stakeholders as needed, allowing focus on a specific part of the system alone.
There are good reasons to have shared Sprint Reviews, but the inability to create integrated work should not be one of them. Shared Sprint Reviews may still be organized to address the need of collective adaptation against the new market, strategic or company evolutions, and insights that get processed in an updated Product Backlog. Time for reflection is still much needed. It will enhance the cohesion of the product being created.
Complexity is suddenly hugely reduced, while the ability to release integrated software is improved. Autonomy is increased, and ultimately self-organization.