Communities of Practice

Scrum tritt an, um Menschen mit unterschiedlichem Wissen, unterschiedlichen Interessen und Erfahrungen zusammen zu bringen, damit sie gemeinsam an der gleichen Werkbank arbeiten. Dafür haben wir cross-funktionale Scrum-Teams. Klassische Rollenunterschiede, etwa die zwischen Tester und Entwickler, werden im Scrum-Team aufgeweicht. Jeder, auch der absolute Spezialist, hat den einen Auftrag, an der erfolgreichen Lieferung in seinem Team mitzuwirken (selbst wenn sein Spezialwissen gerade nicht gefragt ist). Das ist ein deutlicher Unterschied zum klassischen Projektmanamagent, wo unter der Maxime größtmöglicher Auslastung Spezialisten auf verschiedenen Projekten gleichzeitig unterwegs sind.Um Menschen mit ähnlichem Wissen, Interessen und Erfahrungen zusammen zu bringen, gibt es in Scrum sogenannte Communities of Practice (CoP). Eine CoP ist zunächst eine Gruppe, die freiwillig zusammenkommt, und sich ein Thema zu eigen gemacht. So kann es beispielweise CoPs für Architektur, Testen, UX oder Scrum geben. Anders als Task Forces verfolgen CoPs nicht den Zweck, ein eng gestecktes Ziel zu erreichen. Ebensowenig haben sie die Erzeugung von Statusberichten zum Zweck. Sie sind vielmehr dazu da, Ideen zu generieren und dafür zu sorgen, dass - teamübergreifend - ein gemeinsames Bild entstehen kann. So kann sich zum Beispiel eine CoP zum Thema Testen damit beschäftigen, die Automatisierung von Testfällen in den Scrum-Teams zu platzieren und die Hindernisse auf dem Weg dorthin zu identifizieren. Mike Cohn schreibt, es sei Aufgabe von CoPs, einen gewissen Grad an Konsistenz über die Teams hinweg zu sichern.Communities of Practice sind als zusätzliche Ebene in Scrum gedacht, jedes Mitglied einer Community of Practice ist in der Regel auch Mitglied eines Scrum-Teams. Wichtig ist, dass CoPs in keinem Konkurrenz- oder Hierarchieverhältnis zu den Scrum-Teams stehen. Das, was in einer CoP anvisiert wird, sollte von den Mitgliedern in ihre jeweiligen Scrum-Teams getragen und dort umgesetzt werden.Damit heben wir die Dualität auf, die klassischerweise durch vor- oder nachgeschaltete Instanzen auftritt: Ein Team, dessen Mitglieder beispielsweise für die Qualitätssicherung verantwortlich sind, wird immer daran leiden, dass es seine Wirkungsstätte außerhalb der Scrum-Teams hat. Die Scrum-Teams werden dazu geneigt sein, das Thema Qualität an das QS-Team abgehen - und das QS-Team wird am Versuch verzweifeln, die Scrum-Teams zu mehr Qualitätsbewusstsein zu "erziehen". Selbstorganisation sieht anders aus.Etienne Wenger unterscheidet zwischen fünf Ausprägungen einer Community of Practice:

• Unrecognized. Die CoP ist für die Organisation unsichtbar, ihr Beitrag ist nicht erkennbar.
• Bootlegged. Die CoP ist nur für einen eingeweihten Kreis sichtbar - auch hier fällt es der CoP schwer, einen Unterschied zu machen.
• Legitimized. Die CoP ist offiziell anerkannt - häufig ist das mit hohen (und bisweilen unrealistischen) Erwartungen an die CoP verbunden.
• Supported. Diese CoP verfügt über genügend Ressourcen (Zeit, Mittel, Personen), um einen Unterschied zu machen und kann deshalb unter hohem Druck stehen, Ergebnisse zu liefern.
• Institutionalized. Hier sprechen wir von einer CoP, die mit offiziellem Status und Verantwortung überhäuft wird. Diese CoP leidet häufig unter Überregulierung und ihre Mitglieder werden es schwer haben, weiterhin in ihren Scrum-Teams zu wirken.

Welche CoPs gibt es in deinem Unternehmen? Wie stark sind sie ausgesprägt? Werden sie vom Rest des Unternehmens wahrgenommen? Falls nein: Was kannst du tun, um sie handlungsfähiger zu machen?CoPs brauchen zwar keinen dedizierten ScrumMaster, aber eine regelmäßige, engagierte Unterstützung (etwa zur Formulierung der gemeinsamen Mission oder zur Moderation der Arbeitstreffen) kann entscheidend sein.Literaturhttp://www.mountaingoatsoftware.com/blog/cultivate-communities-of-practicehttps://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.PDF