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.
I’d like to make a reference to a set of principles described for “scaling”, http://scaledprinciples.org
And you’ll notice these principles are the same as 1 team Scrum. Scaling Scrum = Scrum (to quote LeSS)
I enjoyed this as it challenged current popular thinking.
However, your article implies (I think) that for a “Team of teams” scenario, what’s most important is that the Team is able to produce a product increment. I concur. It does however seem to allow for (maybe encourage) component teams – am I reading this right?
It takes away the obligation that every individual team needs to be a fully fledged feature team. The system as a whole must deliver end-to-end features.
Then perhaps you’re referring to a cross-functional system rather than individual teams. It may be possible in the right setup that this will work. I reality what I have seen over and over again is > multiple component teams crippled by their inter-team dependencies.