Small development teams or single developers work on several products at the same time. How can you do Scrum in such a situation?
"My development team consists of 6 people, almost all of them work in different projects. These projects stand for different systems or I would say products. My problem is that the development teams responsible for one product consist of only one or two persons and thus are actually too small, so we could use Scrum usefully. Regarding all developers as a team and creating a common backlog for all the requirements would mean that there would be several Product Owners, namely one for each product. How does that coincide with the rule, the Product Owner is one person, not a committee?"
You are describing a classic problem. There are many people who say, exactly because of this organizational feature we cannot do Scrum. The opposite is the case. The role model of Scrum with the requirement that there is only one Product Owner for a team is built that way precisely because of this problem.
Why is it like that? We know that a team of 7 + / -2 people can extremely well continuously improve their processes and thus achieve a very high efficiency in what it does. Unfortunately, it is not enough. Because we can efficiently provide the wrong thing and be anything but effective in fact. Specifically for your situation you should ask yourself the following questions:
- Which product is the most important?
- What should be done before we can focus on a different product?
- What would happen, if our assumption were wrong and we should correct the direction?
- Do we need so many products at all?
- What new products will we need?
- What do the users really need?
- What is our profit trend line?
- Summarized: how does the strategy for our products look like and how does it fit together with the corporate strategy?
Can the current product managers (referred to as „several Product Owners“ in your question) answer these questions immediately? Do they have the necessary expertise? Are their target agreements defined that way? Or is it just the budget, we have left for this year, that should be spent? Unfortunately, as consultants we often get an immediate „yes“ only in the latest issue (usually said only in private).
This does not mean that the product managers will not work on the answers and affect them significantly as important stakeholders. But if the team asks these questions there should be an immediate response so that it can proceed further. Is there anyone who can give the answer in your organization? Will someone brave step forward? He or she is the product owner for the team.
Even if the products are no longer developed but only supported by the team, if only few new changes are to be implemented for each product and the technical complexity is very low: this kind of simplicity should make it possible for the team to easily maintain the products and to establish new improvements together. Why shouldn't we use it?
But the above questions still remain frequently unanswered. In this case, it might help you and the Product Owner if you will make the work on the products transparent with the help of a Kanban board. That way the decisions that have to be made are easier to understand for the product managers. The responsibility of the Product Owners is to not only to make decisions at the right time, but also to continuously and in time integrate the stakeholders.
About the author
Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.
- Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
- Served as ScrumMaster in internationally distributed Scrum Teams
- Co-founder and Product Owner at DasScrumTeam AG
- Key interests: Agile companies and Scrum beyond Software
Immer informiert mit dem DasScrumTeam Newsletter
Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.