Sprint Cadence at scale

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.

Closed Loop Feedback

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.

Closed Loop Feedback (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.

Scaled Scrum - Singular Scrum

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.

Scaled Scrum - 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.

Scaled Scrum - Integrating Scrum Teams

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.

Scrum's DNAThe 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.

Product Owner role summary

What does a Product Owner do?

The Product Owner brings the business perspective to the software product being created and sustained into a Scrum Team. The Product Owner represents all stakeholders, internal and external, to the Development Team. Although a Product Owner is likely to have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the Development Team regularly and repeatedly.

The Product Owner assures with the Development Team that a Product Backlog exists. The Product Owner manages Product Backlog based on the product vision as a long-term view of the road ahead. A product vision captures why the product is being built.

Product Backlog shows all of the work currently envisioned for the product. This work may comprise initiatives, functional and non-functional expectations, enhancements, fixes, patches, ideas, updates and other desirements. If anybody wants to know what work is identified and planned for the product it suffices looking at the Product Backlog.

The Product Owner expresses the expectations and ideas captured in the Product Backlog to the Development Team, and orders the items in the Product Backlog to optimize the value being delivered. Lower value items are actively removed from Product Backlog (see the Tea Leaves Effect). Lower value functionality is actively removed from the product.

The Product Owner invites stakeholders to the Sprint Review to come work with the Scrum Team; what got done, what didn’t got done, what are relevant market or competition trends. The goal is to collaboratively identify what is the most valuable work to do next for the Product. This is captured in Product Backlog. Obviously.

The Product Owner manages the product budget to balance value, effort and time for the represented stakeholders. The Product Owner maximizes value. Period.

What does it take to be a Product Owner?

Being a Product Owner requires specific skills and traits. There are too many to mention, but an entrepreneurial spirit is certainly a helpful one. Being a Product Owner requires ownership of a product, implying strong organizational adoption of the role. Being a Product Owner is being a servant-leader in working with self-organizing teams. Being a Product Owner is not easy. It may take some time to get there.

Yes, We Have A Product Owner. And

My Pocket Guide to Scrum

Scrum - A Pocket Guide (front)People learn about Scrum in various ways. Some read books. Some read my book:

Scrum – A Pocket Guide (A Smart Travel Companion)

  • Read a PDF excerpt from my book. It holds the foreword by Ken Schwaber, a short note by the early reviewers, the content table and the first chapter (‘To shift or not to shift’). A taste.
  • Get the full version at Amazon, Amazon UK, Van Haren’s webshop (the publisher), Bol.com. Or use good old Google.

My book serves to help the reader make better use of the tool that Scrum is.

My book introduces the rules and roles of Scrum while emphasizing their purpose. People can more effectively employ Scrum from an understanding of the purpose, rather than from mechanically following the ‘process’.

People are more capable of using Scrum to their advantage when understanding that Scrum is a framework laying out the boundaries within which people can deal with complex problems. My book distinguishes the rules of Scrum from tactics to apply the rules. My book has some examples on tactics, and where tactical decisions within the Scrum framework are required.

My book presents no universal truths, gives no universally applicable answers on generic questions, although I get asked such questions over and over again.

How long should Sprint Planning be? And the other meetings? How much time does the Product Owner role take? Is the Scrum Master role a full-time occupation? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? What should be in the definition of Done? How many business analysts are needed in the team? What if… ?

I am extremely wary of being an ‘expert’ providing certainty where there isn’t. My book is a book for people on a journey to discover what Scrum can do for them. Hence its subtitle. My book does not map out your route. Your route is unique and distinct.

My book adds some historical perspective to Scrum, describes the roots of Scrum, how Scrum fits the Agile movement and what some future challenges of Scrum are.

My book “Scrum – A Pocket Guide” is not an expert book. It is not a book for experts. It is not a book by an expert. My book is a book by an eternal novice seeking mastery. I hope you like it. I hope it helps you seek mastery too.

Meanwhile I am in the process of creating a follow-up book. I will still not provide false precision. I might tell some stories about what worked for me, given context and time.


Agile Greece Summit – netweek interview

Yiannis Mavraganis and a crew of Agile enthusiasts organized the first Agile Greece Summit on Friday 18 September 2015 in Athens. It was an honor to be there and give a talk on Nexus and Scaled Professional Scrum. I hope attendants got many ideas and inspiration from the sessions and from sharing problems and insights. I hope it helps the Greek economy in these difficult times.

Netweek logoPreceding the event George Fetokakis published an interview with me in the Greek IT magazine netweek.

Netweek interview (Greek)The publication was in Greek. Thanks to George I can share the English version here. George published it under the header “Respect for developers”:

  1. What is Scrum?

Scrum is a lightweight framework for complex product development. Scrum has, by design, a minimal, yet sufficient, set of rules and roles. Scrum prescribes no techniques or practices to apply these rules to allow teams and organizations to devise the best possible tactics, depending on their context, to apply Scrum. 

All basic rules of Scrum are described in a lightweight document, the Scrum Guide, which is available at http://www.scrumguides.org. The Scrum Guide is maintained by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber.

  1. Do you see any challenges in the organizations which use only Scrum? What do you think are some of the big threats to Scrum adoption or growth?

In my 2013 book, “Scrum – A Pocket Guide”, I describe two future challenges of Scrum. 

The first challenge concerns the way the role of the Product Owner is fulfilled. We often see that representatives or proxies of product management are fulfilling the role. The benefits realized through Scrum would be higher if product managers would directly engage in Scrum, through the role of the Product Owner.

The second challenge is the improved understanding and adoption of Scrum by management, think about operational IT management, sales divisions, delivery managers, product departments and hierarchical CxO management.

I would add a third challenge, related to scaling. Many organizations have adopted Scrum and see the benefits at the scale of one or some teams. Organizations pursue the same benefits with many teams, but struggle in scaling Scrum while respecting the principles and foundations upon which Scrum are built.

  1. Why should a Development Team choose Scrum?

Scrum thrives on self-organization, inviting and inspiring Development Teams to plan, organize and track their own daily work. Product Owner set out a vision and goals against which Development Teams work. Stakeholders are expected to provide the Development Team with new or changing insights by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter.

Scrum fundamentally restores the respect for the creativity and intelligence of Development Teams, allows them to fully exploit their skills and insights.

  1. What is Scaled Scrum and how important is this method for big software development projects?

‘Scaled Scrum’ is any implementation of Scrum in which multiple Scrum Teams create one software system or product. The purpose of Scrum, independent of the scale at which it is used, is to create high-quality, releasable versions of product by the end of every Sprint. This allows organizations to quickly and regularly serve their customers, and to incorporate feedback into the development process fast. It is what we call ‘business agility’. It is crucial for companies to survive and prosper in today’s fast changing economy.

At a larger scale, keeping a high level of such agility is highly important. It assures companies of flexibility and responsiveness. Translated to the adoption of Scrum for product development, it holds that the big challenge of scaled Scrum holds the ability for multiple teams to produce releasable software by the end of every Sprint.

Our Nexus framework provides organizations with guidance on how to grow and scale Scrum, on how to implement Scaled Professional Scrum.

We recently published the Nexus Guide at our website, https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf

A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done):

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de Scrum.org  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.


Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.


Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.

Introducing Scaled Professional Scrum – Nexus

Scrum is a framework for complex systems development.

  • Professional ScrumScaled Scrum is any instance of Scrum involving more than one team creating and sustaining a product or system.
  • Scaled Professional Scrum is any instance of scaled Scrum that thrives on Scrum’s formal rules and roles, complemented by software development professionalism, and Scrum’s values and principles.

The Scaled Professional Scrum framework of Scrum.org provides guidance to organizations engaging in efforts to scale their product development done through Scrum. The framework cohesively integrates practices, experience and insights gained from efforts to scale Scrum worldwide, including the substantial efforts that involved Ken Schwaber and Jeff Sutherland, co-creators of Scrum.

At the heart of Scaled Professional Scrum is a Nexus, an ‘exo-skeleton’ for Scrum. A Nexus employs the Scrum process to inter-connect 3-9 Scrum Teams building one product.


The Scaled Professional Scrum framework holds 40+ practices. Each of these practices, if chosen and used against context, augments the operation of the Nexus.

The whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF) is now available through the Scrum.org website.

At the “Scrum Day Europe” event of July 2 in Amsterdam I introduced the Scaled Professional Scrum framework of Scrum.org and the Nexus in my opening keynote. Find the presentation at SlideShare. The recording of the session is available at YouTube.