Communities of Practice

Kollaboration zwischen crossfunktionalen und selbstorganisierten Teams
Keine Kommentare

Immer mehr Organisationen wandeln sich hin zu einem Aufbau mit crossfunktionalen, selbstorganisierten Teams. Nach diesem Schritt geht es darum, wie die Experten in den einzelnen Teams vernetzt werden und wie Wissen verteilt wird. Auch übergreifende Entscheidungen und Standards müssen nun crossteam getroffen werden.

Sobald ein Unternehmen wächst, fängt es an, mehr und mehr Strukturen zu bilden. Dieses Verhalten lässt sich einfach erklären. Mit jedem weiteren Mitglied eines Teams steigen die Koordinationskosten überlinear. Die optimale Größe eines Teams liegt zwischen drei und neun Mitgliedern. Wird das Team größer, sollte es in mehrere Teams aufgeteilt werden. Der in der IT lange Zeit vorherrschende Ansatz für diese Aufteilung war, die Teams nach Funktionen zu teilen. Die Mitarbeiter, die dieselben Aufgaben ausführen, wurden in einem Team oder in einer Abteilung zusammengefasst: Backend-Entwickler, Frontend-Entwickler, Tester, DBAs oder Sysadmins.

Agile Entwicklungsmodelle wie Scrum brechen mit dieser Art der Aufteilung und fordern crossfunktionale Teams. Alle Spezialisten, die zum Liefern von Customer Value in Form eines Shippable Product Increments notwendig sind, sollen zusammen in einem Team sein und möglichst wenig Abhängigkeiten zu anderen Teams haben. Später kam die DevOps-Bewegung hinzu, zu deren zentralen Anliegen die Abschaffung der funktionalen Silos von Dev und Ops gehört. Immer mehr Unternehmen erkennen die Vorteile crossfunktionaler Teams und beginnen, ihre Organisation entsprechend umzustellen.

Durch die Umstellung einer Organisation auf crossfunktionale Teams ergibt sich für die Mitarbeiter eine neue Situation. Die Gruppe der Backend-Entwickler, Frontend-Entwickler, Tester, DBAs oder Sysadmins wird auseinandergerissen und die Mitarbeiter werden auf verschiedene crossfunktionale Teams verteilt (Abb. 1). Dabei beobachtet man nach einer Weile in der Regel drei Effekte: fehlende Hilfe bei Problemen, fehlender Wissenstransfer und Inselentscheidungen. Im crossfunktionalen Team gibt es nur wenige oder gar keine anderen Mitarbeiter mehr, die einem bei konkreten Problemen helfen können, z. B. einem Backend-Entwickler dabei, einen Bug in einer Backend-Komponente zu finden. Der Entwickler findet also weniger Hilfe und Ansprechpartner. Backend- oder Frontend-Entwickler sitzen nicht mehr eng beieinander und profitieren so nicht mehr von Erfahrungen und Fehlern der anderen. Entwickler, die neu im Unternehmen sind, kennen die anderen Kollegen noch nicht einmal von früher. Das schadet dem Wissenstransfer. Da crossfunktionale Teams in der Regel selbstorganisiert sind, z. B. in Scrum, treffen sie auch viele Technologieentscheidungen ohne Austausch mit den anderen Teams. Diese Entscheidungen sind für das einzelne Team scheinbar richtig, für die Gesamtorganisation aber möglicherweise kontraproduktiv. Es entstehen Insellösungen.

Abb. 1: Mehrere crossfunktionale Teams

Abb. 1: Mehrere crossfunktionale Teams

Vor allem in der Entwicklung von IT-Anwendungen überwiegen die Vorteile crossfunktionaler Teams. Aus diesem Grund sollten Organisationen, die die beschriebenen Beobachtungen machen, nicht einfach wieder zu funktionalen Teams zurückkehren, sondern eine Vernetzung der jeweiligen Experten untereinander ermöglichen. Diese Vernetzung geschieht in der Regel durch Communities of Practice.

Das macht Communities of Practice aus

Communities of Practice stammen originär nicht aus der IT und sind auch kein neues Konzept. Das erste Mal Erwähnung findet der Begriff 1991 bei Jean Lave und Etienne Wenger [1]. Etwa zehn Jahre später beschreiben Etienne Wenger, Richard McDermott und William Snyder in ihrem Buch „Cultivating Communities of Practice“ [2] das Konzept anhand vieler Beispiele im Detail. Nach ihrer Definition sind die wichtigsten Aufgaben einer solchen Community: gemeinsame Standards (Common Baseline) zu schaffen, Alltagsprobleme zu lösen, Wissen zu verteilen und Innovation voranzutreiben (Abb. 2).

Abb. 2: Aufgaben von Communities of Practice

Abb. 2: Aufgaben von Communities of Practice

Nach Meinung der drei Autoren wird eine Community of Practice über drei Elemente definiert: Domain, Community und Practice (Abb. 3). Die Domain definiert den thematischen Inhalt oder die Aufgaben einer Community, also um welche Aspekte sie sich kümmert. Der thematische Schwerpunkt soll interessierte Teilnehmer anziehen und zur Mitarbeit animieren. Er dient aber auch der Abgrenzung, damit sich die Arbeit in einer Community nicht zu einem ziellosen Diskutieren entwickelt. In einer Community of Practice soll eine Community von Gleichgesinnten zusammenkommen, die sich gegenseitig helfen, Ideen austauschen und zusammen lernen möchten. Für Emily Webber ist das gemeinsame Lernen (Social Learning) sogar einer der wichtigsten Aspekte einer Community of Practice [3]. Schon als Kinder lernen wir Menschen dadurch, dass wir andere beobachten und ihre Handlungen nachahmen. Eine Community animiert zu dieser Art des Lernens und der Wissensvermittlung. Sie ist auch der beste Weg, wie implizites Wissen zwischen den Mitarbeitern weitergegeben werden kann. Eine Community of Practice erzeugt Ergebnisse innerhalb ihrer Domain. Diese Ergebnisse sollen die tägliche Arbeit (Practice) der Mitglieder oder des Unternehmens verbessern. Dabei kann es sich um Frameworks, Werkzeuge, Leitfäden, Anleitungen, erklärende Geschichten oder Dokumente handeln [2]. Eine Community setzt nach einer gewissen Zeit einen Satz an Grundfertigkeiten bei ihren Mitgliedern voraus, die in die Common Practice übergegangen sind.

Betrachten wir als Beispiel eine Community of Practice für Backend-Entwickler. Vor zwei Jahren hat die Community die ersten Experimente mit der Entwicklung von Spring-Boot-Anwendungen gemacht und nach und nach Erkenntnisse mit diesem Framework gesammelt und dokumentiert. Von neuen Mitgliedern wird sie erwarten, dass sie sich mit den Erkenntnissen vertraut gemacht haben. Es gibt auch andere Formen von Communities, die eine sinnvoll definierte Domain haben, wie Meetups oder User Groups. Diesen Communities fehlt, dass sie keine Ergebnisse für die tägliche Arbeit erzeugen (Practice). Sie werden deshalb auch als Communities of Interest bezeichnet.

Communities of Practice müssen nicht immer bewusst entstehen. Das Buch „Cultivating Communities of Practice“ berichtet von einer Gruppe von Krankenschwestern (Community), die sich regelmäßig zum Frühstück treffen und Patientengeschichten austauschen (Domain). Ohne es zu merken oder beabsichtigt zu haben, lernen sie voneinander Details von und Handlungsweisen bei Krankheitsbildern kennen, die sie selbst zum Teil noch nie gesehen haben. Das versetzt sie in die Lage, ihre Patienten besser zu versorgen (Practice).

Abb. 3: Elemente von Communities of Practice

Abb. 3: Elemente von Communities of Practice

Die sieben Prinzipien einer Community of Practice

Aus crossfunktionalen Teams bestehende Organisationen wollen Communites of Practice in der Regel bewusst einführen. Dabei können diese sieben Prinzipien helfen [2]:

  1. Design for evolution
  2. Open a dialogue between inside and outside perspectives
  3. Invite different levels of participation
  4. Develop both public and private community spaces
  5. Focus on value
  6. Combine familiarity and excitement
  7. Create a rhythm for the community

Wir schauen uns die vier Punkte „Design for evolution“, „Invite different levels of participation“, „Focus on value“ und „Create a rythm for the community“ genauer an.

Design for evolution: Eine Community ist nie fertig

Eine Community ist ein Team. Damit unterliegt sie denselben Regeln wie andere Formen von Teams auch. Die gemeinsame Arbeit und das gemeinsame Lernen in einer Community erfordern ein hohes Maß an Offenheit, Respekt und Vertrauen. Wie in jedem Team wird die Zusammenarbeit aber nicht direkt von Anfang an perfekt funktionieren. Auch eine Community wird die Phasen Forming, Storming, Norming und Performing durchlaufen.

Aber nicht nur bezogen auf das Teamgefüge entwickelt sich eine Community stetig weiter. Auch der inhaltliche Schwerpunkt verändert sich (Abb. 4). Viele Communities beginnen, indem sie gemeinsam konkrete Alltagsprobleme lösen, wie einen Bug beheben, eine Architektur verbessern oder ein Deployment automatisieren. Nach einer gewissen Zeit beginnen sie damit, aus diesen Alltagsproblemen Muster, Standards und Handlungsempfehlungen abzuleiten. Wenn sie den Status quo durch dieses Common Knowledge beherrschbar gemacht haben, beginnen sie, sich mit Innovationen zu beschäftigen. Sie denken darüber nach, wie sie ihre Domäne weiterentwickeln können, mit neuen Frameworks, neuen Deployment-Verfahren oder neuen Programmiersprachen.

Abb. 4: Die übliche Entwicklung einer Community of Practice

Abb. 4: Die übliche Entwicklung einer Community of Practice

Community Leader: Einer muss

Bei der Weiterentwicklung einer Community kommt dem Community Leader, auch Community Coordinator genannt, eine zentrale Rolle zu. Zu seinen Aufgaben gehört es, die Treffen und andere Aktivitäten der Community zu organisieren und zu moderieren [2], [3]. Er bringt die Mitglieder der Community zusammen und fördert ihre Entwicklung durch Hilfestellung und Coaching. Außerdem organisiert er das Wissen der Community. Er repräsentiert die Community nach außen und achtet auf das Einhalten ihrer Grenzen. Das bedeutet z. B., dass er Eingriffen durch das Management begegnet oder Themen beendet, die nicht zur Domain gehören. Er muss kontinuierlich evaluieren, wie gesund die Zusammenarbeit der Mitglieder ist und welchen Wert die Community ihren Mitgliedern und dem Unternehmen bringt. Diese Aufgaben erinnern stark an die Aufgaben eines Scrum Masters, also eines Servant Leaders [3], dessen operative Aufgaben immer mehr auf die Mitglieder übergehen. Die Literatur [2] beschreibt auch einen anderen Typ, der als King bezeichnet wird und mit einem klassischen Manager vergleichbar ist. Meiner Meinung nach passt ein solcher Typus aber weniger gut in eine von selbstorganisierten Teams geprägte Organisation.

Different levels of participation: Mitmachen fördern

Community Leader und Scrum Master haben gemeinsam, dass sie immer mehr ihrer operativen Aufgaben an die Mitglieder der Community oder ihres Teams abgeben. Ihre wichtigste Aufgabe können beide jedoch am schlechtesten an das Team delegieren: die kontinuierliche Arbeit an einer produktiven und vor allem vertrauensvollen Kultur im Team. Diese Aufgabe ist die wichtigste, weil gegenseitiges Lernen, das Lösen kniffliger Probleme und der Aufbau von Practices nur auf der Basis von Vertrauen funktionieren.

Im Gegensatz zu den Mitgliedern eines Scrum-Teams verbringen die Mitglieder einer Community aber nicht viele Stunden pro Tag im selben Raum, lernen sich besser kennen und verstehen und bauen so Vertrauen auf. Deshalb ist es wichtig, dass sich die Mitglieder einer Community regelmäßig sehen und auch treffen, vor allem kurz nach der Gründung der Community. Verteilte Communities sollten regelmäßige Videocalls durchführen und sich an einem Ort treffen (Kasten: „Mögliche Aktivitäten einer Community of Practice“). Wichtig ist, dass diese Aktivitäten zu einem regelmäßigen Ritual werden. Sonst gehen sie im Zweifel im Tagesgeschäft unter.

Mögliche Aktivitäten einer Community of Practice

  • Vor-Ort-Treffen in einem Besprechungsraum oder zum gemeinsamen Mittagessen oder Frühstück
  • Telefon- oder Videokonferenzen
  • Inhousekonferenzen (z. B. als Open Space)
  • Vorträge externer Experten
  • Pflege von Wiki-Einträgen
  • Retrospektiven
  • Community Value Reviews
  • Infoveranstaltungen für die übrige Organisation

Nicht jeder Interessent im Unternehmen wird unbedingt an allen Aktivitäten einer Community teilnehmen wollen (Abb. 5). Es kann sein, dass sich der Mitarbeiter noch nicht reif fühlt, um inhaltlich mitzuarbeiten, z. B. Wiki-Einträge zu erstellen, aber gerne als Zuhörer an Aktivitäten teilnehmen möchte (Peripheral). Oder aber eine Gruppe von Mitarbeitern interessiert sich nur für einzelne Themen, aber nicht für alles, was in der Community diskutiert und beschlossen wird. Unter den aktiven Mitgliedern einer Community (Active) bildet sich außerdem oft ein Kreis von Personen heraus, die bevorzugt Aufgaben des Community Leaders übernehmen und z. B. Meetings organisieren (Core Group). Eine Gruppe von aktiven Mitgliedern in einer Community gibt es aber nur, wenn jeder einzelne etwas davon hat und die Ergebnisse ihm einen gewissen Nutzen bieten. Die Teilnahme an einer Community ist freiwillig. Und es gibt vermutlich wenige Organisationen, in denen die Mitglieder der crossfunktionalen Teams zu viel Zeit haben und sie freiwillig in nutzlosen Communities verbringen.

Abb. 5: Es gibt verschiedene Arten der Teilnahme an einer Community of Practice

Abb. 5: Es gibt verschiedene Arten der Teilnahme an einer Community of Practice

Focus on Value: Kontinuierlich Wert schaffen

Folgendes Beispiel veranschaulicht, wie schwierig es sein kann, eine Community für alle Mitglieder dauerhaft wertvoll zu erhalten (angelehnt an [2]): In einer Organisation haben sich die erfahrenen Entwickler zu einer Community zusammengetan, um sich über knifflige Programmierprobleme auszutauschen. Einige Hochschulabsolventen erfahren von der Community, sind begeistert von der Idee, von den alten Hasen etwas zu lernen, und nehmen fortan an den Treffen teil. Nach einigen Monaten beginnen sie, eigene Problemstellungen mit in die Diskussionen einzubringen. Als Reaktion darauf verlassen die alten Hasen die Community und gründen eine neue. Natürlich ist das für das Unternehmen nicht sinnvoll, weil die Jungen von den Erfahrenen nichts mehr lernen und diese umgekehrt keine neuen Impulse mehr bekommen. In dieser Situation ist der Community Leader gefragt. Er muss gemeinsam mit beiden Parteien eine Community entwerfen, die beiden etwas bringt.

Abb. 6: Strategische Ausrichtungen einer Community of Practice [4]

Abb. 6: Strategische Ausrichtungen einer Community of Practice [2]

Wenn die Mitglieder das Gefühl haben, dass ihnen die Arbeit in der Community nichts mehr bringt, verlassen sie sie im Normalfall. Der häufigste Grund dafür sind abweichende Vorstellungen über die strategische Ausrichtung (Strategic Intent) innerhalb der Community (Abb. 6). Ein Teil der Mitglieder möchte z. B. eine Plattform für gegenseitige Hilfe bei Alltagsproblemen und für den Austausch von Ideen haben (Helping Community). Andere sind schon einen Schritt weiter und möchten gerne Best Practices entwickeln, verteilen, dokumentieren und validieren (Best Practice Community) oder das vorhandene Wissen der Community für die tägliche Arbeit organisieren, aufbereiten und verteilen (Knowledge Stewarding Community). Zu guter Letzt gibt es eine Gruppe, die sich mehr mit der Zukunft ihrer Domain beschäftigen und neue Ideen und Innovationen generieren möchte (Innovation Community). Wenn die Mitglieder sich nicht einigen, wird keine der Gruppen mit der Ausrichtung der Community zufrieden sein.

Abb. 7: „Im Zentrum der Community ein Feuer am Brennen halten, das Mitglieder anlockt.“ [4]

Abb. 7: „Im Zentrum der Community ein Feuer am Brennen halten, das Mitglieder anlockt.“ [2]

Andererseits ist die Ausrichtung auch nicht in Stein gemeißelt. Die Mitglieder sollten sie regelmäßig – angeleitet durch den Community Leader – in Form einer Communityretrospektive überprüfen. Jedes einzelne Mitglied muss sich dabei fragen, ob die Community noch Wert stiftet oder, wenn nicht, wie das wieder der Fall sein könnte. Die Mitglieder einer Community müssen bildlich gesprochen ein Lagerfeuer im Zentrum der Community am Brennen halten, das neue Mitglieder anlockt und bestehende Mitglieder warmhält [2] (Abb. 7).

Der Wert einer Community für das Unternehmen muss ebenso regelmäßig überprüft werden. Die Zeit, die die Mitarbeiter während der Arbeit dort verbringen, fehlt zunächst einmal in ihren eigentlichen Teams. Wenn das Management eines Unternehmens das Gefühl hat, dass eine Community keine wertvollen Ergebnisse hervorbringt, wird es ihr wahrscheinlich nicht weiterhin Geld oder andere Ressourcen zur Verfügung stellen. Inspiriert durch die aus Scrum bekannten Sprint Reviews, lassen sich in der Community in regelmäßigen Abständen Community Value Reviews durchführen. Wenn die Mitglieder oder der Community Leader dazu noch externe Stakeholder einladen, bekommen sie wertvolles Feedback und machen den Wert ihrer Arbeitsergebnisse in der Organisation transparent.

Die Charta beschreibt die Community of Practice

Überhaupt ist es wichtig, eine Community und die Eckpunkte ihrer Arbeit im Unternehmen bekannt zu machen. Voraussetzung dafür ist, dass sich die Mitglieder auf eine Art Teamvertrag geeinigt haben, der in diesem Kontext auch oft Charta genannt wird [2]. Fragen für die Aufstellung einer solchen Charta sind z. B.:

  • Welche Domain bearbeiten wir? Jeder im Unternehmen sollte wissen, mit welchem Thema sich die Community inhaltlich beschäftigt. Das führt dazu, dass jeder grundlegend entscheiden kann, ob eine Teilnahme oder Mitarbeit für ihn wertvoll ist.
  • Mit welchen Themen beschäftigen wir uns im Moment? Zu wissen, womit sich die Community aktuell beschäftigt bzw. in nächster Zeit konkret beschäftigen wird, ist für gelegentliche Teilnehmer interessant, die dann von Fall zu Fall entscheiden können, ob eine Teilnahme für sie wertvoll ist. Außerdem weiß die übrige Organisation dadurch, welche Entscheidungen in der Community getroffen wurden.
  • Welche Kollegen arbeiten aktuell mit? Dieser Punkt ist besonders für die Kollegen interessant, die nicht Mitglied der Community sind. Sie wissen so, wen sie ansprechen können, wenn sie ein Thema interessiert, das dort behandelt wird. Für die Mitglieder ist es ebenso nützlich zu wissen, wer dazugehört – insbesondere, wenn in der Community Entscheidungen getroffen werden sollen.
  • Auf welchen Arbeitsergebnissen liegt unser Fokus und was ist die strategische Ausrichtung? Damit keine Unzufriedenheit entsteht, muss sich die Community auf eine grundlegende strategische Ausrichtung einigen. Auch diese Information ist für Außenstehende wichtig, um zu entscheiden, ob sie in der Community mitarbeiten möchten.
  • Welche Aktivitäten gibt es und wann finden sie statt? Die Community verabredet, in welchem Rhythmus sie sich treffen möchte und wie sie kontinuierlich zusammenarbeitet. Damit kann jedes Mitglied feste Termine in seinen Tages- und Wochenablauf einplanen.

Bei cosee haben wir die Charta einer Community als Board modelliert (Abb. 8). Diese Boards werden an einer Stelle aufgehängt, an der alle Mitarbeiter sie sehen können. Die Mitglieder hängen Fotos von sich ans Board und die übrigen Felder werden mit Post-its gefüllt. Im unteren Bereich des Boards befindet sich ein Bereich für die aktuellen Themen der Community. Jeder Mitarbeiter kann sich so einen Überblick verschaffen, welche Dinge im Backlog sind, gerade diskutiert werden oder schon besprochen wurden.

Abb. 8: Board für eine Community of Practice

Abb. 8: Board für eine Community of Practice

Die Boards sind vor allem auch für Mitarbeiter hilfreich, die neu ins Unternehmen kommen. Sie können sich einen Überblick über die vorhandenen Communities verschaffen. Wenn sie Interesse an einer Teilnahme oder Mitarbeit haben, wissen sie anhand der Fotos auch direkt, wen sie ansprechen können. Natürlich können sie auch einfach zu einem der am Board vermerkten Termine kommen.

Fazit

Viele Unternehmen organisieren ihre Softwareentwicklung mittlerweile in Form von crossfunktionalen Produktteams. Diese Teams haben viele Vorteile, führen aber in der Regel dazu, dass der Austausch zwischen den jeweiligen Experten schwierig wird oder ganz zum Erliegen kommt. Dadurch entstehen Insellösungen im Unternehmen und das Wissen wird nur schlecht verteilt. Communities of Practice sind ein mächtiges Werkzeug zur Vernetzung dieser Experten aus crossfunktionalen Teams. Sie ermöglichen Wissensaustausch und gemeinsames Lernen. Die Mitglieder (Community) beschäftigen sich immer mit einem klaren Thema (Domain), um ihre tägliche Arbeit zu verbessern (Practice). Bei cosee haben die verschiedenen Communities of Practice zum Wissensaustausch zwischen den verschiedenen Produktteams beigetragen und ermöglichen eine teamübergreifende Definition von Standards.

Literaturverzeichnis

  • [1] Lave, Jean; Wenger, Etienne; Situated Learning: „Legitimate peripheral participation“, Cambridge University Press, 1991
  • [2] Wenger, Etienne: McDermott, Richard; Snyder, William: „Cultivating Communities of Practice: A Guide to Managing Knowledge“, Harvard Business Review Press, 2002
  • [3] Webber, Emily: „Building Successful Communities of Practice – Discover how connecting people makes better organisations“, Blurb Inc, 2017
Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -