Theoretische Grundlagen erarbeiten und diese in Praxis umsetzen ist seit Jahren eine meiner Leidenschaften. Noch mehr Spass macht es mir, wenn ich mich dabei mit Gleichgesinnten über das Erlebte austauschen kann. Was funktioniert? Was funktioniert nicht? Und warum nicht? Welche Erkenntnisse haben die Beteiligten gewonnen?

Warum brauchen Firmen CoPs?

DevOps erfordert agile Methoden und funktionsübergreifende Teams, deren Mitglieder eine durchmischte Expertise und T-Shaped Skills aufweisen, damit sie besser zusammenarbeiten. In diesem Setting machen die Experten ihre neuen Erfahrungen.

Wie kann dieses Wissen nun in die anderen Teams getragen werden? Du vermutest richtig: In einer CoP!

Über den Austausch von Wissen und Erfahrungen (Demos & Successes) hinaus bietet eine CoP weitere Zugewinne. Sie ermöglicht teamübergreifende Falldiskussionen bei Problemen (Problems) und Beschlüsse für gemeinsame Normen und Werkzeuge (Decisions) an der Front und nicht in der Hierarchie.

Gerade der letzte Punkt ist nicht zu unterschätzen. Kultur ist in einer Firma sehr schwierig zu ändern, und die praktische Verschiebung der Entscheidungsgewalt aus der hierarchischen Linie in die DevOps-Teams und damit in die Hände der einzelnen Mitarbeitenden macht die CoP zu einem potentiell mächtigen Werkzeug für den gewünschten Kulturwandel.

Meine CoP

Im Rahmen von DevOps wurde unser Kompetenzcenter für Simulationen aufgelöst und unsere Teammitglieder in agile Delivery Teams umgeteilt. Was schreit lauter nach einer CoP als diese Ausganglage? Ich habe die Gelegenheit beim Schopf gepackt und im Frühling 2019 die CoP Service Virtualization auf die Beine gestellt.

Das erste Meeting – Wir starten

Agenda

Das erste Meeting sollte eine Stunde dauern und hatte folgende Agendapunkte:

• Hallo & Was/Wo/Wie/Warum? (5’)
• Notieren auf Zetteln (10’)
  • Wer bin ich? Name, Abteilung, Erfahrung in der Domain
  • Was kann ich beitragen? Mögliche Demonstrationen aus der Praxis für die CoP
  • Was sind meine grössten Probleme? Biggest Pain im Alltag zu Simulationen (Nur Tonspur)
  • Was möchte ich an der bestehenden Lösung ändern? Feature Request
• Besprechen und Auslegen der Zettel (30’)
• Nächstes Meeting organisieren (10’)
• Meeting evaluieren (5’)

Prinzip – Face to Face

Aus der persönlichen Erfahrung, dass Communities viel besser funktionieren, wenn man sich persönlich kennt (und nicht unwissend im Gang aneinander vorbei geht), habe ich auf Präsenz vor Ort bestanden.

Methode – Bodenanker als gemeinsames Bild

Ich habe für die Besprechung die Methode Bodenanker verwendet: Physisch und damit auch mental nahmen alle Teilnehmenden für die Präsentation ihrer Zettel eine andere Position ein.  

Auf diese Art entstand ein erstes gemeinsames Verständnis und für die CoP das erste Backlog für Demos, Falldiskussionen und mögliche Epics inkl. Priorisierung.

Evaluation – Fist of Five

Für ein unmittelbares Feedback führten wir ein Fist of Five durch. Alle Votes waren höher als vier :).

Fazit

Für ein Fazit ist es zu früh. Der Start war vielversprechend, die Teilnehmenden motiviert und aktiv. Das nächste Treffen wurde für in einem Monat abgemacht.

Mir persönlich hat es viel Spass gemacht diese Community zu starten. Wichtig ist das die Community den Inhalt bestimmt. Dabei frage ich mich, ob in einem per Definition selbstorganisierenden Gefäss überhaupt ein Leader nötig ist. Wenn überhaupt, dann setzt der Community Leader meiner Ansicht nach nur den Rahmen und nimmt eine Coaching Rolle ein.

Was meinst du zur gewählten Methode? Und wie stehst du zur Frage nach dem Leader in einer CoP? Ich freue mich über Kommentare!

Viel Spass in deiner Community of Practice