Scrum in Großprojekten: Wie mit dem “Community of Practice”-Konzept cross-funktionale Teams zusammenarbeiten
Agile Methoden im Allgemeinen und Scrum im Speziellen setzen auf cross-funktional zusammengesetzte Teams. Für die Entwicklung einer Webanwendung könnte ein solches cross-funktionales Team z.B. aus den Rollen Java-Entwickler, Frontend-Entwickler, Architekt, Designer und Tester zusammengestellt sein. Dieses Team ist im besten Falle in der Lage, eine User Story oder Fachanforderung komplett eigenständig umzusetzen. Sämtliches dafür erforderliche Know-how befindet sich im Team. Wenn in einem größeren Projekt mehrere cross-funktionale Teams an einem Produkt oder einer Software arbeiten, ergibt sich häufig die Fragestellung, wie mit sogenannten “cross-cutting-concerns” umgegangen werden kann. Zur Adressierung dieser Fragestellung bietet sich das Konzept des Community of Practice (CoP) [1] an.
In größeren Scrum-Projekten, in denen ein Produkt mit mehreren Teams entwickelt wird, ergeben sich häufig Fragestellungen, die nicht nur ein Team, sondern die gesamte Software, bzw. das gesamte Produkt betreffen. Dies können z.B. grundsätzliche Architekturentscheidungen sein, ein gemeinsames Betriebsmodell, Coding Conventions oder das Testvorgehen. Sind im Projekt solche “cross-cutting-concerns” identifiziert, ergeben sich daraus verschiedene Implikationen. Die cross-funktionalen Teams können nicht komplett eigenständig agieren, sondern müssen sich an übergreifende Richtlinien und Entscheidungen halten. Es müssen Wege gefunden werden überhaupt zu diesen Richtlinien und Entscheidungen zu kommen. Eventuell müssen übergreifend Themen implementiert werden, die nicht in den Backlogs der einzelnen Teams geplant sind.
Für diese Situationen bietet sich das Konzept der “community of practice” (CoP) an [1]. In einer CoP finden sich zu einem spezifischen Themengebiet eine Gruppe Menschen der gleichen Disziplin zusammen, um Konzepte auszuarbeiten oder Entscheidungen zu treffen. Beispielsweise kann es eine CoP “Architektur” geben, die aus Softwarearchitekten aus allen Teams und einem Ansprechpartner aus einer zentralen Governance besteht. In der CoP ist somit jedes Umsetzungsteam vertreten, sowie weitere Stakeholder die für die inhaltliche Arbeit oder das Treffen von Entscheidungen notwendig sind. Diese CoP erarbeitet übergreifende Architekturrichtlinien und Konventionen, die in der täglichen Arbeit für alle Teams gelten und von diesen umgesetzt werden. Die Ergebnisse werden zentral dokumentiert und veröffentlicht und in die Definition of Done (DoD) der einzelnen Teams übernommen. Für die Kommunikation in die Teams hinein ist der jeweilige Vertreter aus dem Team in der CoP zuständig. Er kann z.B. beim Daily Standup täglich über den Fortschritt der Arbeit in der CoP berichten.
Ein weiteres Betätigungsfeld für eine CoP kann z.B. die Konsolidierung von bestehender Software sein, die in mehreren Teams parallel entwickelt wurde. Gibt es in einem großen Projekt beispielsweise mehrere Hilfsklassen oder -funktionen, die parallel entstanden sind, oder unterschiedliche Umsetzungen des Corporate Designs in den verschiedenen Teams, lohnt es sich eine CoP aufzusetzen, die eine Konsolidierung vornimmt. Hier könnte die Aufgabe der CoP sein, ein entsprechendes Konzept zu erarbeiten und die notwendigen Arbeitspakete zu identifizieren. Die erzielten Ergebnisse und notwendigen Aktivitäten werden über die einzelnen Vertreter wieder zurück in die Teams getragen. Da es sich in dieser Variante nicht um die Umsetzung von Richtlinien in der täglichen Arbeit, sondern um umzusetzende Arbeitspakete geht, müssen diese in die Backlogs der einzelnen Teams einpriorisiert werden.
Eine CoP kann somit mehrere Ergebnistypen hervorbringen: Ein Konzept, eine Erweiterung der DoD, eine Entscheidung, Arbeitspakete zur Umsetzung, usw. Wichtig ist, dass die CoP entsprechend befugt ist und ein Mandat hat, diese Ergebnistypen zu produzieren und zur Umsetzung zu bringen.
Die CoP besteht entweder für die Laufzeit des Projektes, dauerhaft während der gesamten Produktentwicklung, oder nur für 1-2 Sprints – je nach Bedarf. Weiterhin bietet es sich an, die Prozess- und Methodenkompetenz des Scrum-Masters zu nutzen, um z.B. Termine zu moderieren oder bei der Überführung der Ergebnisse in den Scrum-Prozess zu unterstützen. Die CoP kann auch selbst nach Scrum arbeiten, wenn über einen Zeitraum von mehreren Sprints bestimmte Aufgabenpakete erarbeitet werden müssen.
Beispiele für die Anwendung des CoP-Konzeptes in einem großen Scrum-Projekt mit mehreren Teams.
Wir setzen in einem aktuellen Entwicklungsprojekt das CoP-Konzept bereits in mehreren Bereichen erfolgreich ein und haben damit die Abstimmung zwischen den Teams untereinander wesentlich verbessert, sowie eine Möglichkeit geschaffen, über Teamgrenzen hinweg Entscheidungen zu treffen und durchzusetzen.
[1]
http://en.wikipedia.org/wiki/Community_of_practice
A community of practice (CoP) is, according to cognitive anthropologists Jean Lave and Etienne Wenger, a group of people who share a craft and/or a profession. The group can evolve naturally because of the members’ common interest in a particular domain or area, or it can be created specifically with the goal of gaining knowledge related to their field. It is through the process of sharing information and experiences with the group that the members learn from each other, and have an opportunity to develop themselves personally and professionally (Lave & Wenger 1991). CoPs can exist online, such as within discussion boards and newsgroups, or in real life, such as in a lunch room at work, in a field setting, on a factory floor, or elsewhere in the environment.
