Community of Practices sind ein gängiges und schon etwas älteres Konzept, welches auch in Scrum zur Anwendung kommen kann. Arbeiten mehrere Teams an einem Produkt, dann stellt sich immer die Frage, wie ein Austausch zwischen diesen Teams, zu neuem Wissen oder Themen, die alle betreffen, stattfindet. Dieser Artikel gibt einen Überblick und führt in das Thema der Community of Practice ein.
Community of Practice (COP )
Scrum Teams sind multidisziplinär. Das bedeutet, das die Mitglieder im Entwicklungsteam nicht mehr in Funktionen (z.B. Hardware, Architektur oder Testen) organisiert sind, sondern quer über alle Funktionen die Personen in den Teams anwesend sind.
Das ist auf der einen Seite gut für das Produkt und den Wert, der durch ein solches Team erzeugt wird. Es bringt auf der anderen Seite Herausforderungen mit sich:
Eine Community of Practice stellt für dein Business nun genau eine solche Gemeinschaft auf die Beine, die sich über diese Themen austauschen und diese weiterentwickeln kann.
Inhalt der Community of Practice
Eine Community of Practice hat bestimmte Inhalte, die typisch sind. Diese Inhalte stelle ich nun kurz vor und werde mich im Anschluss genauer damit auseinandersetzen und Ihnen diese zeigen.
Domain
Die Domain bestimmt das Thema, in dem sich die Community of Practice bewegt. Das Thema wird sich sehr nah an den typischen "Funktionen" bewegen, in denen sich im tailoristischen Umfeld Menschen organisiert haben. Warum die Community of Practice keine klassische Matrixstruktur darstellt, beleuchte ich zum Ende hin noch einmal genauer.
Community
Die Community of Practice ist eine Gemeinschaft. Diese Gemeinschaft lernt und arbeitet zusammen, teil Vorlieben und Leidenschaft.
Practice
Ganz wichtig für eine Community of Practice ist es, dass diese auch ein Ergebnis vorweisen kann. Dabei bietet sich ein Format ähnlich dem zyklischen Sprint Review an. Ergebnisorientierung ist elementar. Wenn eine Community of Practice kein Ergebnis erzeugt, wird sie sich langfristig wieder auflösen.
Aufbau von Communities of Practice
Freiwilligkeit
Community of Practices werden nicht angeordnet. Sie basieren auf Freiwilligkeit. Bei einem Workshop zur Teamfindungen kann es durchaus sein, dass Regeln für die Community of Practice gelten. Es findet aber keine Zuweisung von Personen zu Communities statt.
Kein Aufbau, sondern Entstehung
Ebenso gibt es keinen direkten "Aufbau" oder Vorgabe in der Organisation. Vielmehr ist es so, dass Community of Practices einfach entstehen, wenn der Bedarf erkannt wird. Bei so einem Prozess gehört der Glaube daran, dass es funktioniert, dazu. Die Lösung zu den CoP's liegt in der Organisation selbst und kann durch gutes Coaching an das Tageslicht gebracht werden.
Ein CoP Leiter
Eine Community of Practice hat einen Leiter. Dieser muss nicht formal bestimmt sein und kann sich herausbilden. Ebenso muss er nicht zwingend die Person sein, die alles treibt. Er sollte von seiner Verantwortung eine Rolle einnehmen, die ähnlich der des Product Owners ist. Auch wenn dieser Vergleich etwas hinkt, braucht eine Community of Practice in der Regel eine Person, die Themen in der Domain treibt. Diese Person hat keine disziplinarische Verantwortung über andere Mitglieder in der Community.
Herausforderungen in der Praxis
CoP Arbeit vs. Backlog Arbeit
Die Arbeit der Community of Practice darf kein Schattendasein fristen. Es muss transparent sein, was für Arbeit in der Community of Practice geschieht. Es ist auch klar, dass eine Arbeit in einer Community of Practice Kapazität der Teams beeinflusst. Während ein Leiter einer Community of Practice wahrscheinlich mehr Aufgaben erledigt, treibt, definiert und bei der Unterstützung hilft und schult, ist ein Gestalter innerhalb der Community of Practice aus einem Team zum Beispiel nur zu einem Drittel der Arbeit des Leiters involviert.
Dieses kostet aber Zeit. Und diese Zeit muss sichtbar sein. Du kannst diese zum Beispiel in einem Sprint Backlog sichtbar machen. Nicht selten wird Arbeit, die auftritt einfach in die Community of Practice "verschoben", wo sie aber nicht erledigt wird. Damit erreichst du gar nichts. Arbeit, die zu tun ist, muss getan werden. Das erreichst du nur mit Transparenz und dem Bewusstsein, dass diese Arbeit auch erledigt werden muss.
Sichtbare Arbeit
Wenn du es nicht schaffst, die Arbeit transparent zu machen, wird es zu Problemen kommen. Die Velocity wird sinken und die Unzufriedenheit steigen.
Deswegen mach die CoP Arbeit bitte immer transparent (zum Beispiel Sprint Backlog) und berücksichtige diese immer in einer Sprint Planung.
Synchronisation
Community of Practices können mehrere Synchronisationspunkte haben. Das bedeutet zum Beispiel Kontakt zum Team, Kontakt in die Organisation oder auch der Kontakt innerhalb der eigenen und mit anderen Community of Practices.
Auch hier habe ich persönlich die Erfahrung gemacht, dass die Teams sehr gut wissen, was sie konkret benötigen und auch wollen. Fragend und coachend ist eine Unterstützung hier sicherlich wertvoll und kann die Reflexion im Team anstoßen.
CoP und Product Owner
Der Product Owner ist in Scrum die Person, die für die Reihenfolge im Product Backlog verantwortlich ist. Damit bestimmt er die Produkteigenschaften. Eine Community of Practice löst Probleme, stimmt sich untereinander zu einer Domain ab, bietet Schulungen und baut Wissen auf, kümmert sich um Innovationen. Dieses berührt nicht das Was des Product Owners. Eine Community of Practice kann durchaus unterstützen und dem Product Owner helfen. Sie kann ihm Wissen teilen, Empfehlungen aussprechen - die letztendliche Entscheidung über das Was liegt beim Product Owner.
Beispiel Architektur
Eine gute Architektur ist nicht nur in der Softwareentwicklung wichtig. Gibt sie doch grundlegenden Inhalt für das Zusammenspiel aller verwendeten Komponenten, Austausch und Kommunikation
Wenn die Experten in den Teams sich über die Community of Practice austauschen und zum Beispiel einen neuen Standard definieren, eine Schnittstelle erneuern, sich absprechen und koordinieren, dann ist das wertvoller Inhalt für die Community selbst und das Produkt natürlich ebenso.
Die Architektur sollte grundsätzlich nicht die Produkteigenschaften beeinflussen. Der Product Owner bestimmt die fachlichen Anforderungen mit den Product Backlog Items. Die Architektur bestimmt maßgeblich das wie im Product. Dafür sind die Teams verantwortlich. Sie sind die Experten und auch die Architekten sind im Team.
Und wenn es mal rein technische Aufgaben gibt? Was machen wir dann? Am besten mit gesunden Menschenverstand arbeiten und mit dem Product Owner reden. Argumentieren, warum dieses oder jenes Product Backlog wichtig ist und zum Beispiel vor ein anderes Product Backlog Item einsortiert werden muss. Passiert das öfters, dass Sie nur technische Product Backlog Items haben? Dann liegt ein anderes Problem vor, dass nicht im Sinne der Community of Practice zu lösen ist.
Bei Ihnen ist das aber anders? Die Architektur bestimmt maßgeblich und immer führend alle andere Fachlichkeit? Dann haben Sie sich eine Restriktion auferlegt, die in unterschiedlichen Gründen liegen kann. Ich sage nicht, dass Sie das nicht machen dürfen. Fragen Sie sich bitte immer nur, welche Nachteile Sie sich dadurch einkaufen. Und vor allem: Fragen Sie sich, ob Sie eine passende agile Architektur für Ihr Produkt haben.
Beispiel UX
Wenn Sie Themen haben, die das Erlebnis der Benutzer beeinflussen, dann sind das wichtige Erkenntnisse und Wissensgebiete für die Teams und den Wert, dem Sie einen Kunden liefern können.
Wenn Sie - wie bei der Architektur - auch hier die Product Backlog Items fachlich richtig schneiden, dann ist der Bereich der User Experiences im "wie"-Bereich der Teams angesiedelt. Neue Konzepte, Erfahrungen, Tests, ... werden in der Community of Practice UX besprochen und dann in die Team getragen. Auch hier gilt, der Product Owner gibt einzig und alleine die Priorisierung des Product Backlogs vor, kann sich aber durch die Community of Practice auch beraten lassen und sollte einen engen Kontakt pflegen.
Mögliche Idee für ein gemeinschaftliches Vorgehen
Oft merke ich, dass Teams bei solchen Gesprächen schnell in "wir" gegen "ihr" verfallen. Das soll nicht sein, alle entwickeln ein gemeinsames Produkt. Es ist häufig eine Reaktion, die sich auftut.
Erarbeiten Sie sich ein gemeinschaftliches Modell. Dazu gehört aus meiner Sicht, dass Sie sich genau überlegen, wie Sie die Arbeit koordinieren und wer genau was macht, welche Verantwortung bei wem existiert. Verstehen Sie mich nicht falsch, bitte keine Zäune aufbauen, nur wenn Sie hier noch lesen, dann ist der Abschnitt wohl nicht uninteressant für Sie und Sie werden sich mit solchen Fragestellung befassen.
Deswegen stellen Sie bitte grundsätzlich das gemeinsame Verständnis in den Mittelpunkt. Wenn Sie ein motiviertes Team haben und Personen, die für die Themen brennen, dann ist der Rahmen wichtig. Und diesen schaffen Sie, in dem Sie ein gemeinsames Verständnis fokussieren und dann die Experten die Details unter sich ausmachen lassen.
Matrix Struktur und Community of Practice
Eine CoP ist keine Matrix
Merke dir bitte, dass eine Community of Practice keine typische Matrixorganisation ist. Auch wenn es auf den ersten Blick mal den Anschein haben kann, ist es etwas grundlegend anderes.
Während die Community of Practice auf der einen Seite schon eine sehr ähnliche Funktion wie eine Matrixstruktur übernimmt, so ist sie doch verschieden. Das Ziel ist überlappend, der Weg dahin jedoch unterschiedlich. Die folgenden Punkte betreffen typische, aber nicht zwingende Eigenschaften der Matrixstruktur und der Community of Practice
CoPs remote stattfinden lassen
Nicht erst seid Corona ist die Zeit der remote Durchführungen von typischen Scrum Events, Meetings und Zusammenkünften. Kannst du also auch deine CoP remote durchführen?
Ich denke lernen und Wissen aneignen kann und darf kein Thema von remote oder nicht remote sein. Ich glaube alle Agilisten lieben den Austausch von Angesicht zu Angesicht, wenn es aber nicht geht, dann sind wir alle soweit unserer Ziele bewusst, dass wir den Austausch für unser Business durchaus für die Gemeinschaft auch digital hinbekommen können.
Vorwand
Sollte bei dir im Business es häufiger vorkommen, dass ein Einwand für den Austausch von digitalen Communities of Practice herrscht, dann prüfe doch zunächst einmal andere Stellen. Oft kann das ein Vorwand sein.
Fazit und Wichtigkeit der Community of Practice
Ihr Kontext ist mehr als ein Team? Dann sollten Sie mit dem Konzept der Community of Practices übergreifende Themen zwischen den Teams und in der Organisation sicherstellen. Experimentieren Sie mit den Formaten, mit der Findung der CoP und mit einem guten Verhältnis zwischen Team und CoP-Arbeit.
