„Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt.“ Wie schaffe ich es, Wissenstransfer im Team zu fördern? Welche Konzepte bietet Scrum? Was haben wir konkret im Team implementiert und ausprobiert?
Wissenstransfer ist gerade in der Softwareentwicklung essentiell. Bei den vielen komplexen Problemen mit denen wir uns tagtäglich beschäftigen, ist es wichtig, immer mehrere Wissensträger zu haben, die sich gegenseitig unterstützen und ergänzen können. Nur, wie schafft man es denn, dass das Wissen im Team geteilt wird? Diese Frage hat mich kurz nachdem ich als Scrum Master zu meinem aktuellen Team gekommen bin sehr beschäftigt. Gleich zu Beginn hat uns ein wichtiger Know-How-Träger verlassen und mit ihm auch sein Wissen. Eins unserer Ziele ist es jetzt, Wissensinseln im Team abzuschaffen und alle Teammitglieder an allen Themen zu beteiligen.
Für die Entwicklung verwenden wir Scrum. Mit Scrum werden schon viele Elemente und Konzepte eingeführt, die dabei helfen, Wissen im Team zu verteilen. Sprint Planning, Review, Retrospektive, Daily Scrum – all diese Meetings nutzen Synergieeffekte des Teams, fördern gemeinsame Diskussionen und binden alle Teammitglieder ein. Sie bieten eine Plattform um Probleme, Ideen und Erkenntnisse zu teilen und weiterzuentwickeln.
Uns war das nicht genug. Gemeinsam haben wir in Retrospektiven folgende Praktiken eingeführt:
Pair Programming
Beim Pair Programming arbeiten zwei Entwickler an einer Programmieraufgabe. Vorteile dieser Agile Engineering Praktik sind, dass immer vier Augen den Code betrachten. Kritische Fragen werden schon während der Implementierung gestellt und können sofort bearbeitet werden. Bei uns hat das zu höherer Qualität des Codes und des Produktes geführt und uns dadurch insgesamt schneller gemacht. Zusätzlich gibt es danach mehrere Experten für das bearbeitete Thema und verkürzt darüber hinaus auch die Einarbeitungszeit neuer Teammitglieder.
Mit Pair-Programming habe ich auch schon in meinen früheren Teams gearbeitet. Eins der Teams nutzte eine Pair-Programming Matrix, um sicherzustellen, dass die Paare jeden Sprint, später dann jeden Tag, wechseln.
WIP Limit
Das WIP (Work in Progess) Limit kommt aus der Lean Welt. Grundsätzlich begrenzt das WIP Limit die parallele Arbeit im System. Bei uns definiert es, wieviele User Stories in einem Sprint in Bearbeitung sein dürfen. Wir haben aktuell ein WIP Limit von 3 User Stories für 9 Entwickler. Diese Bedingung kann das Team nur einhalten, wenn alle eng zusammenarbeiten und mehrere Entwickler gemeinsam eine User Story umsetzen. Die Einführung eines WIP Limits hat bei uns zu einem starken Fokus auf die aktuellen User Stories und schnellen Ergebnissen geführt. Das erhöht die Transparenz und verringert das Risiko, weil man viel genauer weiß, welche Features tatsächlich fertig sind. Ein weiterer positiver Nebeneffekt ist auch, dass durch diese intensive Zusammenarbeit erst gar nicht die Möglichkeit entsteht, dass sich Wissensinseln bilden.
Lightning Talks
Um noch bestehende Wissensinseln aufzulösen nutzen wir das Format des Lightning Talks: 15 – 30 minütige Talks, die 1x pro Woche in einem der Entwicklerräume stattfinden. Bis jetzt gab es Talks zu Coding Conventions, produktrelevanten Themen, Konferenzbeiträgen, theoretische Hintergründe zu Konstrukten in Ruby, Besonderheiten von Rails und vielem mehr.
Außerdem nutzen wir die Lightning Talks, um uns auf große, neue Themenkomplexe vorzubereiten. Das Ergebnis einer Recherche zu einem neuen Thema wird dann im Rahmen eines Lightning Talks vorgestellt.
