Posted on 4 Comments

Start optimizing your Scrum (stop filling positions)

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.

Posted on 7 Comments

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.

Posted on Leave a comment

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 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,

Posted on 2 Comments

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de  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 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.

Posted on 4 Comments

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 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 website.

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

Posted on 3 Comments

The “Scrum Practitioner Open” assessment

People and organizations regularly ask us at (1) for our ideas on scaling Scrum. They are keen to learn from Ken Schwaber‘s and our community‘s experience in scaling product development done through Scrum.
At the same time (2) we frequently get asked for an assessment that tests a person’s ability to join a Scrum Team, often in a scaled context, and be productive in terms of having practiced Scrum.

They are satisfied with our existing Professional series, offering rigorous help and insights to adopt, implement and grow Scrum and Scrum Teams. Additionally however they look for (1) help and inspiration in their scaling efforts and (2) courses and assessments for Professional Scrum Practitioners. As part of our on-going mission to improve the profession of software development and guide the maturing of Scrum, we have taken action. We are in the process of (1) launching a practitioner course to scale Professional Scrum and (2) we are revisiting our assessments accordingly:

  1. The “Scaled Professional Scrum for Practitioners” workshop introduces our framework for scaled Scrum. It introduces techniques and practices for horizontal scaling, amongst which defining and growing a Nexus, a networked structure of 3-9 Scrum Teams developing a product. Find the next planned session here.
  2. We have also created and made the “Scrum Practitioner Open” assessment available, free to anyone taking it. The Scrum Practitioner Open assessment provides anyone with the ability to assess their skill to productively participate in a Scrum Team that is developing increments of software. This assessment is particularly useful for people on one of multiple teams engaged in a scaled development initiative.

Scrum Practitioner OpenTry the Scrum Practitioner Open assessment. Our industry will benefit from an assessment testing the ability to develop software effectively in a Scrum Team, in a scaled context, and optimize common development issues based on the values of Scrum and the basis of empiricism and transparency.

Thank you for your participation.