Scrum Team: Die ideale Teamzusammenstellung für agile Entwicklung

Skip navigation

Agile Entwicklungsprozesse mit dem idealen Scrum-Team

/ February 19, 2019
Scrum Team Blog Background Banner

In meinem vorherigen Blog-Beitrag bin ich bereits darauf eingegangen, wie Sie Scrum-Methoden in Ihrem Unternehmen am besten umsetzen können. Haben Sie erst einmal diese Grundlagen geschaffen, besteht der nächste Schritt darin, Ihr Scrum-Team zusammenzustellen. Der folgende Beitrag zeigt, wie wichtig es ist, motivierte Mitarbeiter für die optimale Teambesetzung zu haben. Dabei gehe ich nicht allzu tief auf die Beschreibung der einzelnen Rollen eines Scrum Frameworks ein, sondern konzentriere mich auf die jeweiligen Zuständigkeiten, die jede dieser Rollen mit sich bringt.

Scrum kennt drei Rollen für direkt am Prozess beteiligte Personen: den Product Owner, den Scrum Master und das eigentliche Entwicklungsteam. Neben diesen Rollen sollten Sie auch diverse Stakeholder berücksichtigen, da in größeren Unternehmen in der Regel mehrere Business-Analysten (BA) an einer Software-Implementierung beteiligt sind. Neben den genannten Rollen werden wir in diesem Artikel auch das Konzept der Subject Matter Experts (SME) behandeln – jener Personen, die der Schlüssel zum Erfolg eines Scrum-Teams sind.

Das Scrum-Team

Product Owner, Scrum Master und das Entwicklerteam verfolgen während des Entwicklungsprozesses verschiedene Aufgaben und haben unterschiedliche Verantwortungsbereiche. Dennoch arbeiten die Mitglieder als ein eigenverantwortliches und funktionsübergreifendes Team zusammen. Aber wie lässt sich ein solches Konzept in Ihrer IT-Abteilung umsetzen? Die folgenden Punkte sollten Sie idealerweise bei der Zusammenstellung Ihres Scrum-Teams berücksichtigen:

  1. Selbstorganisation und Eigenverantwortung; Jedes Scrum-Team entscheidet selbst, wie es als Gruppe zusammenarbeiten möchte. Dabei sollte es keine hierarchischen Abstufungen innerhalb des Teams geben und jedes Mitglied sollte gleichberechtigt sein, besonders in der Meinungsäußerung. Trotzdem sind die einzelnen Verantwortungsbereiche für jeden klar definiert. Zusammen können sie auf diese Weise eine Lösung finden. Der Product Owner gestaltet das Produkt mit dem Ziel der Nutzenmaximierung und hat das letzte Wort, wenn es um die Erstellung, Priorisierung und Erklärung der Anwendungs-Features geht. Alle anderen Diskussionen im Team werden vom Scrum Master geleitet und sollten zu einer Lösung führen, mit der jeder einverstanden ist.
  2. Funktionsübergreifend; Das Team sollte über alle Anforderungen informiert sein, die für die Auslieferung eines funktionierenden Produkts eingehalten werden müssen. Dies bezieht sich nicht explizit auf das Unternehmenswissen, aber auf Kenntnisse über Qualitätssicherung, User Experience (UX), Software-Integration, etc. Nicht jedes Teammitglied muss über diese speziellen Kenntnisse verfügen und ein perfekter Softwareentwickler sein, dennoch muss sich dieses Wissen auf das Entwicklerteam verteilen.
  3. Co-located; Bei Scrum dreht sich alles um enge Zusammenarbeit. Idealerweise sitzt das gesamte Team in einem Raum, so dass sämtliche Kommunikationsbarrieren möglichst klein gehalten werden. Denn es ist ganz natürlich, dass sich die Interaktion von Teammitgliedern, die in verschiedenen Räumlichkeiten, an unterschiedlichen Standorten und Zeitzonen sitzen, verzögert.
  4. Starkes Engagement; Jedes Teammitglied sollte wirklich Vollzeit dem Projekt zugewiesen werden und keine Nebenprojekte verfolgen. Schließlich arbeitet man fokussierter, wenn man auf eine Sache konzentriert ist, als ständig zwischen Aufgaben zu wechseln und seine Aufmerksamkeit auf mehrere Projekte verteilen zu müssen. Dies ist auch der beste Weg für effektives und eigenverantwortliches Arbeiten.
  5. Langlebigkeit; Versuchen Sie auch für künftige Projekte die Zusammensetzung Ihrer Teams möglichst beizubehalten. Denn neu zusammengestellte Scrum-Teams benötigen immer eine gewisse Zeit, um sich aneinander zu gewöhnen und die Zusammenarbeit zu strukturieren.

Was meine ich mit funktionsübergreifend?

Idealerweise arbeitet Ihr Scrum-Team funktionsübergreifend und das gesamte benötigte Wissen für den erfolgreichen Projektabschluss ist für jedes Teammitglied zugänglich. Dazu gehören Kenntnisse über Testing (Quality Assurance), Design und User Experience, aber auch ein ausreichendes Wissen über alle notwendigen Integrationsprozesse. Natürlich ist mir klar, dass wir meistens nicht solch ideale Voraussetzungen haben und ein Scrum-Team oft keine detaillierten Informationen über die Anwendungs-Integration in weitere Systeme besitzt. In diesem Fall sollten Sie sicherstellen, dass Ihr Team Zugang zu diesem Wissen bekommt. Je nach Größe und Komplexität des Projekts kann es daher sinnvoll sein, einen Integrationsexperten, einen Experten für Qualitätssicherung und einen UX-Profi als Vollzeit-Teammitglieder mit einzubeziehen. Falls Sie mit einem kleinen Scrum-Team arbeiten, kann die Einbeziehung solcher Experten viel Aufwand bedeuten. In dem Fall sollten Sie auf einen Subject Matter Expert (SME) zurückgreifen.

Die Einführung eines SME

Wenn wir von Subject Matter Experts sprechen, meinen wir in der Regel einen erfahrenen Anwender von Business-Software, der dem Scrum-Team beratend zur Seite steht. Betrachten wir den SME von Seiten des Scrum-Teams aus, lässt er sich eher als eine Person beschreiben, die über all das Wissen verfügt, das benötigt wird, um das Produkt erfolgreich auszuliefern. Sämtliche SMEs werden als Stakeholder für das Produkt betrachtet, aber nicht alle Stakeholder müssen SMEs sein.

Subject Matter Experts können mehreren Rollen zugeordnet werden, wie zum Beispiel System-Administratoren (Infra SME) und UX-Experten (UX SME). Aber natürlich können wir auch Entwickler, Scrum Master oder Projektmanager aus anderen Teams als SMEs für ihre jeweiligen Projekte einstufen. So kann ein Teammitglied in einem Scrum-Team sogar auch SME in einem anderen Scrum-Team sein.

Aber bedenken Sie, dass ein SME nicht Teil des Scrum-Teams ist. Daher kann dieser weder für die Arbeit des Teams verantwortlich noch haftbar gemacht werden. Dies stellt natürlich eine Herausforderung dar. Aber Sie sollten einen SME nicht für seine Arbeit verantwortlich machen. Dies könnte dazu führen, dass direkte Team-Mitglieder für die Arbeit mehrerer Teams verantwortlich sind. Und dies stellt ein noch größeres Problem dar und steht im Wiederspruch zu den zuvor beschriebenen Teammerkmalen (Nummer 1, 2, 3). Besonders gut beschrieben wird diese Thematik in dem Buch „Exploring Scrum: The Fundamentals“ von Dan Rawstorne.

Das Scrum-Team mag SMEs zu ganz unterschiedlichen Zwecken und Zeiten benötigen, aber es wird von ihnen stets erwartet, dass sie Fragen beantworten und Aufgaben zur Verbesserung des Produkts übernehmen. Während der Planungsgespräche können Sie abwägen, wann Wissen oder Handlungen von SMEs benötigt werden. Anschließend können die Scrum-Teammitglieder den SME kontaktieren und ihn rechtzeitig mit einbeziehen, so dass einer fristgerechten Auslieferung des Produkts nichts im Wege steht.

Indem man dieser breiten Definition von Subject Matter Experts folgt, können wir eine klare Erwartungshaltung setzen. Wenn das Scrum-Team eine Person benötigt, die bei einer Aktivität für die Produktauslieferung unterstützend mitarbeitet, wird diese Person als SME angesehen. Gleichzeitig weiß der SME, was das Team erwartet.

Das Entwickler-Team

Scrum Team
Betrachten wir nun die gerade beschriebenen Scrum-Merkmale und das Konzept der SMEs genauer, vor allem die funktionsübergreifenden Anforderungen, so verstehen wir besser, welche Situationen einen SME statt eines zusätzlichen vollen Team-Mitglieds erfordern.

Die funktionsübergreifenden Eigenschaften scheinen immer wieder für Verwirrung zu sorgen. Idealerweise weiß jedes Teammitglied alles über jeden einzelnen Entwicklungsaspekt. Dies würde allerdings bedeuten, dass jede notwendige Rolle Teil des Entwicklerteams ist. Wenn spezialisierte Skill-Sets (QA, UX) benötigt werden, sollte es einen Experten mit diesen Fähigkeiten im Scrum-Team geben.

Vermeiden Sie es, diese Experten in mehreren Teams einzusetzen. Halten Sie sich immer daran, jedem Teammitglied nur eine bestimmte Funktion zuzuordnen. Wenn der Experte aus verschiedenen Gründen kein Vollzeit-Mitglied des Teams werden kann, sollten Sie die Person als SME betrachten und ihn oder sie auch als solchen während des ganzen Projekts einsetzen.

Machen Sie es sich einfach und bleiben Sie konsequent: Erfinden Sie bei ihrem ersten Projekt keine neuen Rollen wie temporäre Teammitglieder oder ähnliches. Dies schafft nur Verwirrung bezüglich der Zuständigkeiten und Erwartungen und bringt Risiken mit sich.

Ein optimales Scrum-Team (Product Owner und Scrum Master mitgezählt) sollte nie aus mehr als neun Leuten bestehen. Meiner Erfahrung nach liegt die optimale Teamgröße für große Unternehmensprojekte bei sieben Personen (PO + SM + Dev Team). Für kleinere Projekte empfehle ich eine Mindestgröße von vier Teammitgliedern (PO + SM + 2 Dev Team). Mit einem noch kleineren Team würden Sie keine Scrum-Methodik mehr verfolgen und den Teammitgliedern einen erheblichen Mehraufwand zumuten. Wenn Sie gerne mit kleineren Teams arbeiten möchten, dann sollten Sie einen Blick auf andere Arten der agilen Entwicklung werfen, beispielsweise Kanban.

Was ist mit meinen Business-Analysten?

Viele Unternehmen arbeiten mit Business-Analysten, um ihre Geschäftsherausforderungen zu identifizieren und zu lösen. Business-Analysten verfügen über umfangreiche Erfahrungen und detailliertes Wissen, das für ein Entwicklungsprojekt sehr nützlich sein kann. Da es bei Scrum aber um eine enge Zusammenarbeit zwischen dem Scrum-Team und den Geschäftsbereichen geht, würde die Einbeziehung eines Business-Analysten diesen Arbeitsprozess nur erschweren. Wie kann ein Business-Analyst dennoch effektiv in einem Scrum-Team arbeiten? Zuerst müssen wir die Rolle und Zuständigkeiten des Product Owners verstehen. In meinem nächsten Beitrag werde ich auf die Rolle des Product Owners näher eingehen und erklären, wie ein BA den Product Owner und den Rest des Scrum-Teams unterstützen kann.

Also, halten Sie Ihr Scrum-Team klein und übersichtlich. Wenn Sie das Team durch mehr Rollen erweitern, die nicht von Scrum als Methode vorgegeben sind, schaffen Sie nur unnötige Herausforderungen für Ihr Team und sich selbst. Mit Scrum kann man am einfachsten arbeiten, wenn auch wirklich alle Projektbeteiligten den Scrum-Regeln folgen. Dies kann zu tiefgreifenden Veränderungen führen, aber es schafft auch die größtmögliche Transparenz für alle Beteiligten. Gleich am ersten Tag Änderungen vorzunehmen, ist keine gute Idee. Veränderungen sollten immer auf der Grundlage gewonnener Erkenntnisse angetrieben werden, nicht einfach so. Die Mehrheit der Unternehmen arbeitet gut mit Scrum, warum also nicht auch Sie? Probieren Sie es aus und verbessern Sie Ihre Entwicklungsprozesse.