Stephan schreibt auf…

Theorie in Praxis

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.

CoP

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

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.

Skaliertes Sprint Review in Scrum: Die Messe

Im Scrum-Prozess wird das Sprint Review genutzt um die Arbeit des vergangenen Sprints in Form von potentiell auslieferbarer Software zu präsentieren. Neben der Möglichkeit, die Software auszuprobieren, ist das wichtigste Ziel im Sprint Review Feedback zum Produkt zu erhalten: Wie fühlt sich das Produkt an und können wir es besser machen? In einem kleinen Projekt bestehend aus einem Team ist das Sprint Review relativ einfach umsetzbar. Doch wie sieht es aus, wenn das Produkt von mehreren Teams erstellt wird und es eine Vielzahl Stakeholder gibt, die zur Verbesserung des Produktes beitragen können? Im folgenden Artikel möchte ich ein Konzept vorstellen, wie das Sprint Review skaliert werden kann – Die Messe.

In einem aktuellen Entwicklungsprojekt arbeiten wir mit sechs Scrum-Teams an der Entwicklung einer Webanwendung. Die Teams sind mit einem Product Owner, einem Scrum Master, 5 – 6 Entwicklern, Qualitätssicherung, Design und User Experience Experten ausgestattet. Ein Team kommt somit auf ca. 10 Personen. Zu jedem Team kommen noch diverse Stakeholder aus verschiedenen Bereichen, z.B. Marketing, Category Management, usw., hinzu. Bei einem Sprint Review können somit gerne 60 – 80 Personen anwesend sein. Allen möchten wir die Chance geben, den aktuellen Stand des Produktes auszuprobieren und Feedback oder Anregungen für die Verbesserung desselben einzubringen. Und das alles in unter zwei Stunden!

Zu Beginn des Projektes haben wir in den Sprint Reviews die einzelnen Teams ihre Umsetzungen präsentieren lassen und um Feedback gebeten. Das Projekt war zu diesem Zeitpunkt noch etwas kleiner und am Sprint Review nahmen ca. 30 Personen teil. Unsere Beobachtung war jedoch, dass bei einer so großen Teilnehmerzahl die Zurückhaltung groß ist und wir insgesamt maximal 3 – 5 wertvolle Feedbacks erhalten haben. Die Scheu während einer Präsentation Fragen zu stellen oder Vorschläge einzubringen ist groß. Weiterhin hatten die Teilnehmer des Sprint Reviews nicht die Möglichkeit die erstellte Software selbst auszuprobieren. Diese Vorgehensweise stellte sich für die Größenordnung unseres Projektes somit als ungünstig heraus.

Nach einigen Sprints haben wir uns deshalb ein neues Konzept überlegt. Wir wollten mehr Interaktion mit den Teilnehmern des Sprint Reviews. Mehr Feedback. Mehr ausprobieren. Herausgekommen ist ein Konzept, welches an eine Messe angelehnt ist und unsere Erwartungen übertroffen hat!

Wir treffen uns zu jedem Sprint Review in einem entsprechend großen Raum. Jedes Scrum-Team hat einen Messestand aufgebaut, in dem die fertig gestellten User Stories des letzten Sprints präsentiert werden. Auf großen Metaplanwänden werden die User Stories zum Nachlesen aufgehängt, angereichert mit Grafiken und Screenshots zur Erläuterung. An jedem Messestand stehen mehrere Laptops bereit, an denen die Software ausprobiert werden kann. Eines der Laptops ist an einen Beamer angeschlossen, so dass umstehende Teilnehmer das Geschehen verfolgen können. Es liegen überall Stifte und Feedback-Karten aus.

Das Sprint Review wird von einem der Scrum Master moderiert. Er leitet das Review ein, in dem er die Messe und das Setup kurz erklärt und dann an die Product Owner der einzelnen Teams übergibt. Diese stellen in wenigen Minuten das Motto des vergangenen Sprints und die umgesetzten Stories allen Teilnehmern vor. Nachdem sich so alle einen Überblick verschaffen konnten, wird die Messe eröffnet, jedoch nicht ohne auf eines der Ziele des Sprint-Reviews hinzuweisen: Feedback geben! Alle Teilnehmer werden ermuntert über die Messe zu schlendern, die Software auszuprobieren und auf den Feedback-Karten Kommentare und Vorschläge zur Verbesserung des Produktes zu hinterlassen. Um dies zu incentivieren, werden am Ende der Messe alle abgegebenen  Feedback-Karten einer großen Tombola zugeführt und per Los ein Gewinner ermittelt, der einen kleinen Preis erhält.

Präsentation der umgesetzten User Stories zum Beginn der Messe

Präsentation der umgesetzten User Stories zum Beginn der Messe

Die Messe beginnt. Die Teilnehmer gehen zu den einzelnen Messeständen. An jedem Stand stehen einige Vertreter des jeweiligen Teams und nehmen ihre Besucher in Empfang. Die umgesetzten User Stories werden in Einzelgesprächen den Besuchern des Standes detaillierter erklärt. An den bereit stehenden Laptops können die Besucher die Software ausprobieren. Die Vertreter des jeweiligen Teams geben hierbei Hilfestellung, wie die User Story begutachtet werden kann und fragen nach den Meinungen und Vorschlägen der Besucher. Diese werden auf den Feedback-Karten festgehalten und können dann von dem Product Owner gesichtet und ggf. als neue User Stories in das Backlog aufgenommen werden.

Interaktion an einem Messestand

Interaktion an einem Messestand

Nach ca. 45 Minuten wird die Messe vom moderierenden Scrum Master für beendet erklärt. Das Feedback wird gesammelt und der Gewinner der Tombola gezogen.

Mit diesem Konzept gelingt es uns in jedem Sprint Review die zwei wichtigsten Ziele zu erreichen: Neue Funktionalitäten können ausprobiert werden und wir erhalten wertvolles Feedback zur Verbesserung des Produktes. In etwas mehr als einer Stunde, von 60 – 80 Personen. An den Messeständen bekommt praktisch jeder Teilnehmer die Möglichkeit die Software selbst auszuprobieren und wir erhalten ca. die zehnfache Anzahl ausgefüllter Feedback-Karten, im Vergleich zu vorher. Und ganz nebenbei fördern wir den Austausch aller Teilnehmer untereinander und erzeugen ein tolles Gemeinschaftsgefühl.

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.