Community of Practices sind ein gängiges und schon ä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 - warum?

Scrum Teams sind multidisziplinär. Das bedeutet, das die Mitglieder in den Scrum Teams 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 aber häufig die folgenden Probleme mit sich:

  • Wissensaustausch: Haben Sie in der Organisation mehrere Teams, die zum Beispiel Architekten enthalten, dann tauschen sich diese nicht mehr in ihren "Funktionen" aus, da sie nun in den Teams arbeiten.
  • Hilfe bei Problemen: Wer im Bereich von User Experiences (UX) als Mitarbeiter auf Probleme trifft, der kann diese sehr wahrscheinlich gut mit Gleichgesinnten lösen. Doch diese arbeiten nicht mehr im Team.
  • Gemeinsame Richtung. Die Gefahr von Lösungen, die nicht für alle Teams anwendbar sind, steigen bei rein teamorientierter, multidisziplinärer Aufstellung der Teams. Denn ein Austausch ist zunächst 

Eine Community of Practice hat die Möglichkeit gegen genau diese Probleme vorzubeugen.

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: Definiert den thematischen Inhalt und die Arbeit, um die sich die Community of Practice kümmert.
  • Community: Es existiert eine Gemeinschaft von Gleichgesinnten innerhalb einer Community of Practice. Dabei steht das Lernen im Mittelpunkt.
  • Practice. Innerhalb der Community of Practice werden Ergebnisse erzeugt und diese Ergebnisse sind wertvolle Praktiken, die von anderen genutzt werden können.

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. Sie können 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 erreichen Sie gar nichts. Arbeit, die zu tun ist, muss getan werden. Das erreichen Sie nur mit Transparenz und dem Bewusstsein, dass diese Arbeit auch erledigt werden muss.

Sichtbare Arbeit

Wenn Sie es nicht schaffen, die Arbeit transparent zu machen, wird es zu Problemen kommen. Die Velocity wird sinken und die Unzufriedenheit steigen.

Deswegen machen Sie die CoP Arbeit bitte immer transparent (zum Beispiel Sprint Backlog) und berücksichtigen 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

CoP ist keine Matrix

Merken Sie sich bitte, dass eine Community of Practice keine typische Matrixorganisation ist. Auch wenn es auf den ersten Blick den Anschein hat.

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

  • Verteilung von Befugnissen. In einer Community of Practice geht es nicht um die Verteilung von Befugnissen, in der Matrixstruktur in der Regel schon.
  • Koordination von Ressourcen. Matrixstrukturen versuchen Ressourcen durch die Struktur zu koordinieren, Community of Practices tun das nicht.
  • Berichtswesen. Während die Matrix neue Berichtswege etabliert, tun das Community of Practices nicht.
  • Disziplinarische Führung. Eine Community of Practice dient dem Inhalt, nicht einer disziplinarischen Führung, wie es oft eine Matrix tut.

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. 

Leave a Reply 0 comments

Leave a Reply:







>