Teamziele erreichen – Wissensinseln auflösen
11. Oktober 2010
Scrum funktioniert dann optimal, wenn ein Team von Generalisten zusammen arbeitet. In einem solchen Team kann jedes Teammitglied alle anstehenden Aufgaben übernehmen, so dass eine User Story nach der anderen vom Team abgearbeitet werden kann. Dabei gilt: es befindet sich immer nur genau eine User Story in Bearbeitung. Am Ende der Iteration steht dann ein implementiertes, dokumentiertes und getestetes Produktinkrement bereit.
In der Realität werden Teams jedoch häufig aus Spezialisten zusammen gestellt. Im Team ist dann ein GUI-Spezialist, ein Datenbankspezialist, ein Tester usw. Der GUI-Spezialist wird also reflexartig alle GUI-Tasks auf dem Taskboard bearbeiten, der Datenbankspezialist stürzt sich auf die Erstellung der SQL-Statements. Am Ende des Sprints kann es dann passieren, dass viele User Stories begonnen wurden – und längst nicht alles fertig geworden ist.
Welche Vermeidungsstrategien gibt es hier? Zunächst einmal empfiehlt es sich eine Teamregel zu etablieren, die die Anzahl der gleichzeitig in Bearbeitung befindlichen User Stories begrenzt. Anstatt also die GUI-Task einer noch nicht begonnenen User Story in Bearbeitung zu nehmen, wäre nun also der GUI-Spezialist dazu gezwungen, eine Task einer noch nicht fertig gestellten Anforderung auf dem Taskboard umzusetzen. Sollte dies eine Datenbankabfrage sein, müsste er sich also einarbeiten. Ich kann mir gut vorstellen, was jetzt manch einer denkt: „Das geht doch gar nicht; der Kollege hat doch auf diesem Gebiet gar kein Know-how!“. Es stellt sich also die Frage, wie Wissensinseln vermieden und das Know-how im Team verbreitert werden kann. Eine mögliche Technik ist das Pair Programming, wo ein Experte mit einem Neuling zusammenarbeiten könnte. Das erhöht vielleicht zunächst den Aufwand, zahlt sich aber in späteren Sprints aus. Eine weitere Technik zu Erweiterung der Wissensbasis ist der Knowledge Sharing Process, kurz KSP. Im KSP, der wöchentlich stattfinden könnte, stellt ein Spezialist ein Thema vor, damit andere Entwickler von ihm lernen können.
Auch wenn es viele Techniken gibt, das Wissen im Team auszubauen, so ist das Unterfangen nur dann von Erfolg gekrönt, wenn die Mitarbeiter ein eigenes Interesse daran haben, die Wissensinseln aufzulösen. Anders formuliert: Wenn die Mitarbeiter keinen Vorteil darin sehen, zu einem Team von Generalisten zu werden, bleibt es trotz der Wissensvermittlung beim jeweiligen Spezialistentum.
Meiner Meinung nach muss der Wille zur Abschaffung von Wissensinseln durch Product Owner und Scrum Master wieder und wieder motiviert werden. Insbesondere muss den Teammitgliedern das Risiko vor Augen geführt werden, dass der Ausfall von Experten den Projekterfolg gefährdet und Wissensteilung ein Instrument zur Risikominimierung bei gleichzeitiger Erhöhung der Produktivität ist. Wenn es Product Owner und Scrum Master gelingt, aus der Produktvision eine Teamvision zu machen, wird das Team von sich aus alle Hebel in Bewegung setzen, ein Scheitern des Projekts aufgrund von Wissensinseln zu vermeiden.
Welche Techniken setzen Sie zum Abbau von Wissensinseln ein? Austausch erwünscht!
Quelle Foto: © Maksim Samasiuk – Fotolia.com
| 2 Kommentare