Wissenserzeugung und -austausch in Wissensgemeinschaften: Communities of Practice

In unserem gestrigen Meetup zu “Agile Softwareentwicklung vs. Stand der Technik” (hier die Dokumentation für Community-Mitglieder) wurde im interaktiven Teil nach agilen Praktiken gefragt, die den Stand der Technik fördern. Dabei sprachen wir auch darüber, inwieweit dies von Studien gestützt wird.

Über eine dieser Studien möchte ich hier sprechen. Nämlich wie Wissensaustausch und -erzeugung in sogenannten Communities of Practice funktionieren kann. Die Studie lässt sich via :file_folder: Econstor herunterladen. Danke an den fleissigen Meetup-Teilnehmer, der den Link zur Studie postete!

Die Studie, aus dem Jahr 2004 zwar schon etwas älter, bietet jedoch einige interessante Einblicke, wie Wissensaustausch und -erzeugung in Unternehmen funktionieren kann.

Oder besser gesagt: Was dafür notwendig ist.

In Kürze anbei ein paar Zitate aus der Studie, die ich für bemerkenswert halte.

Wertschöpfung in wissensbasierten Organisationen und über Organisationsgrenzen hinaus wird in besonderem Maße von der Fähigkeit bestimmt, verteiltes Wissen über Märkte, Kunden, Produkte, Prozesse gezielt zu mobilisieren und daraus schnell einen Wert für den Kunden zu generieren.

Insbesondere in dezentralen Organisationsformen, wie wir sie in der agilen Produktentwicklung vorfinden, ist dies umso wichtiger.

Wissen entzieht sich hartnäckig jeder trivialisierenden Steuerungspraxis.

Hier musste ich besonders schmunzeln. Wir alle kennen die YellowPage-Versuche, Wissen und Skills zu katografieren, in Datenbanken abzulegen und durchsuchbar zu machen.

Da es um Communities of Practice bzw. Wissensgemeinschaften geht, hier noch die Definition selbiger:

“Wir definieren Wissensgemeinschaften als über einen längeren Zeitraum bestehende Personengruppen, die Interesse an einem gemeinsamen Thema haben und Wissen gemeinsam aufbauen und austauschen wollen. Die Teilnahme ist freiwillig und persönlich. Wissensgemeinschaften sind um spezifische Inhalte gruppiert.”

Etienne Wenger nähert sich in seiner Definition einer CoP wie folgt den Bedingungen, die da sein müssen, damit eine CoP gut leben kann:

A CoP defines itself along three dimensions: its joint enterprise as understood and continually renegotiated by its members, the relationships of mutual engagement that bind members together into a social entity, the shared repertoire of communal ressources (routines, sensibilities, artefacts, vocabulary, styles, etc.) that members have developed over time.

Die Studie glänzt mit sehr vielem Input, der das Thema “Community of Practice” insbesondere für uns in der Agilen Welt noch einmal in ein neues Licht bringt.

Es werden drei Formen des Wissensmanagements unterschieden:

  1. Technokratisches Wissensmanagement
  2. Expertenbezogenes Wissensmanagement
  3. Wissensökologie

die in folgender Grafik veranschaulicht werden:

Es ist offensichtlich, dass die Stufe der Wissensökologie für Unternehmen erstrebenswert erscheint. Blosses Abtanken und Einfüllen von Wissen, wie sie in der ersten Stufe dargestellt werden, erscheinen hier als nicht hilfreich.

Ich habe nicht alle >200 Seiten der Studie durchgelesen, dafür war die Zeit einfach zu kurz :slight_smile:

Ich möchte mit einer Frage an Dich / Euch schließen: Was sind Eure good practices für CoPs in Euren Unternehmen, die gut funktionieren? Die langlebig sind? Deren Erkenntnisse sich im Unternehmen gut verbreiten? Und wo gibt es vielleicht Hindernisse?

Ich freue mich auf die Diskussion :smiley:

So long, Björn.

1 Like

Wenn man simple Richtlinien einhält funktionieren sie hervorragend und müssen auch nicht nur zum Wissen teilen oder lernen dienen:
_klarer Zweck / abgegrenztes Themengebiet
_Eine Person als Organisator
_Freiwilligkeit
_Wenn niemand mehr kommt, ist die Community auch nicht mehr nötig und kann wieder geschlossen werden (der Punkt fehlt im Link)
Mehr Infos hier: Communities - Large Scale Scrum (LeSS)
Alternativen / zusätzliche Tricks: Coordination & Integration - Large Scale Scrum (LeSS)
(geht alles auch ohne LeSS, ist halt nur eine super Quelle für Infos :wink:

2 Likes

Aus der Erfahrung heraus (aus vielen Communities bis zurück zu IRC/Usenet in den 90ern) hadere ich tatsächlich mit dem Vorschlag “eine Person als Organisator”.

Im IRC/Usenet hatten wir den Begriff des lurkers (iirc Hacker’s Dictionary). Es gibt immer einen größeren Teil einer Gruppe, die “rumhängt” und einen kleinen harten Kern, die intrinsisch motiviert an die Sache heran gehen. “emerges from the group because of a passion for the subject” steht ja im von dir verlinkten LeSS Guide zu Communities.

Gerade bei etwas größeren CoPs glaube ich, dass es mehrere Organisatoren benötigt - die auch implizit sein können, ohne Rolle / Hut auf - die die Runde immer wieder befeuern und mit am Leben erhalten.

Und klar, wenn der Zweck erfüllt ist oder gar keiner mehr kommt, dann braucht es die Community vielleicht nicht ODER die Rahmenbedingungen waren nicht stimmig.

Da hast du sicher Recht, ich habe keine nennenswerte Erfahrung mit größeren selbstorganisierten Communities, außer solcher, die tatsächlich eine:n Vollzeit Manager haben mit allen Vor- und Nachteilen, würde ich daher nicht als selbstorganisiert / selbst managend bezeichnen.

Eine, die ich mal ins Leben gerufen hatte (eine Agile Community natürlich) hatte auch nicht nur den Sinn Wissen zu teilen, sondern zusätzlich eine Abstimmung zwischen Scrum Mastern und Product Ownern über die (kleinere) Organisation mit 4 Teams hinweg. So konnten Praktiken etabliert werden, die allen Teams im daily business dienlich waren - ganz ohne top-down Ansagen. Und nicht zu vernachlässigen ist auch der gestärkte Zusammenhalt (auch mal gegen Entscheidungen der Geschäftsleitung) bzw. organisationsweit aufgezeigt werden welche Auswirken welche Entscheidung der GL hat und diese ggf. zu modifizieren oder auch mal etwas nötiges einzufordern (in diesem Fall eine Firmenweite Priorisierung der Kunden, die ständig im Konflikt über die Kapazitäten standen und dem Fokus schadeten - danach gab es eine unglaubliche Klarheit mit unglaublich wenig Aufwand auf allen Seiten. Hat länger gedauert, aber war es wert. Diese Priorisierung wurde dann sogar 2-wöchentlich aktuell gehalten :slight_smile:

Sind nur Beispiele, da gibt es noch viel mehr, bin gespannt auf weitere Kommentare.

@MarcoSpoerl, was hast du bisher zu CoPs erlebt?

Meine Erfahrungen mit Communities sind durchwachsen.

Als ich noch angestellt war, hatten wir eine wechselnde Anzahl CoP in der Firma. Das dürften so 5 aktive und bei meinem Exit rund 10+ inaktive gewesen sein. Der Großteil zu technischen Themen. Drei Beobachtungen habe ich gemacht:

  1. Es bilden sich interessante Formen eines “für die Community passenden Austauschs” heraus. Erstaunlich/ erschreckend viele Gruppen wollten “einen Vortrag” hören und dann drüber sprechen - das war sehr “lean back”. Mei, kann ja okay sein, nur fand ich immer schade, dass so selten der Austausch zu tagesaktuellen Themen stattfand. Da waren andere Wege (Teambüro, kurzer Dienstweg, Kaffeemaschine) anscheinend immer mächtiger.
  2. Alltag, Tagesgeschäft und Auslastung sind der Tod der Community. Es war überdeutlich zu spüren, wenn es in bestimmten Projekten brennende Probleme/ Deadlines gab bzw. die Auslastung über 80% stieg.
  3. Und hier bin ich bei Philip: ohne dedizierte Person in der Orga geht die Community mehr oder weniger schnell ein. Es gab afair genau zwei CoP, die auch ohne “Führungsmensch” funktionierten - die Frontendler und die Agilisten. Wobei es lustigeweise gerade die Letztgenannten trotzdem eher so lala schafften mit der Selbstorganisation.

Punkt 3 beobachte ich auch in anderen Communities im Netz. Ich bin bei einigen über verschiedene Themengebiete angemeldet und das Bild ist immer das gleiche: gibt es keine dedizierte Treiberin, verkümmert die Community. Grob aus dem Kopf sind das meiner Beobachtung nach 9 von 10, die diesen Tod sterben.

1 Like

Kann den Vorschreibern nur zustimmen. Ohne eine permanent treibende Person schlafen selbst die coolsten CoP sehr schnell ein.

“Treiben” sollte aber nicht heißen jedes mal selber was vorzubeten! Sondern vielmehr die Themenliste durch regelmäßiges Refinement mit der CoP aktuell zu halten und das Team in die Pflicht zu nehmen aktiv an den Themen zu arbeiten. Also ein wenig wie ein PO die Arbeit eines Scrum Teams begleitet.

5 Likes

Total spannend - ich überlege gerade das im Unternehmen einzuführen.

Erfahrung habe ich mit dem Ansatz aus dem privaten Umfeld. Aufbau einer UserGroup oder diversen Sportvereinen. Meine Erfahrung ist, dass es optimalerweise eine kleine Gruppe gibt, die gemeinsam das Thema treibt.
Im ehrenamtlichen Umfeld bestand das Problem bei nur einer Person darin, dass die irgendwann selbstherrlich wurde oder demotiviert. Als Vorstand in einem Großverein war es gut zu erkennen, dass die Sportarten die ein kleines Team als Treiber hatten, am besten funktioniert haben. Dort wo es einen Überengagierten gab, war es eine Zeitlang sehr gut, bis diesem die Energie ausging. Dann schlug die Stimmung um und es brach alles wider zusammen.
Häufige Ursache war das unterschiedliche Invest an Zeit und Herzblut. Daher denke ich, dass es förderlich ist, wenn die Kleingruppe da homogen ist. Also gleich viel Zeit und Herzblut investiert.

Für das Thema in der Organisation habe ich daraus für mich abgeleitet, dass ich vorsichtig sein muss was meine Erwartungen angeht. Und das Invest so klein halten muss, dass andere die Möglichkeit haben auf dem Niveau einzusteigen. Und gleichzeitig hoch genug, dass die CoP für andere spannend ist.

@Philip_Baier danke für den Hinweis, dass ein klarer Zweck nötig ist. Das hat mir bei einer anderen CoP die bereits läuft die Augen geöffnet. Dort hat sich der Zweck verändert und ist nicht mehr so klar - damit ist auch die Aktivität in der Gruppe eingebrochen.