Seit einiger Zeit geht das Konzept der Reading Group in vielen Projekten umher und wird als Allheilmittel kostengünstiger Ausbildung von Teammitgliedern in IT-Projekten gepriesen – aber ist das wirklich so?

Das Prinzip erscheint einfach – Lasse dein Team gemeinsam ein Buch lesen und rede über das gelesene. Das so angelesene Wissen setzt sich und kann vom Team direkt bei der täglichen Arbeit angewandt werden.
Die Vorteile scheinen auf der Hand zu liegen:

  • Es fallen verhältnismäßig geringe Kosten an.
    • Je Teammitglied muss ein Buch gekauft werden, dieses kann sequenziell von mehreren Teams verwendet werden.
  • Es werden weder Schulungsräume, noch teure Trainer benötigt.
  • Einmal alle zwei Wochen trifft sich das Team und spricht gemeinsam über das gelesene – Aufwand ca. 1h.
  • Das Team setzt das erlernte Wissen direkt im Projekt um.

Klingt toll, aber ist eine Reading Group wirklich so effektiv?
Schauen wir uns die Vor- und Nachteile einmal im Detail an.

Die Vorteile

Wir haben ein neues Team zusammengestellt und wollen sicherstellen das alle ein einheitliches Verständnis über die anstehende Thematik haben. Im Kick-Off wurden die Teammitglieder einander vorgestellt und die Themen der nächsten Monate vorgestellt.
Damit das Team sich mit der neuen Thematik besser auseinandersetzen und identifizieren kann wird eine Reading Group beschlossen – und das Team beginnt zu lesen.

Ein Leitbild für das Team erarbeiten:
Nehmen wir ein mal an das verschiedene Entwickler in die Architektenrolle ihres Teams eingeführt werden sollen. Das Team beschließt nun ein Buch über die Rolle der Architektur in der Softwareentwicklung zu lesen.
Dabei werden Prinzipien und Werte der Architektur im Team erarbeitet und als Leitbild festgehalten: „Als Architekt wollen wir nicht im eisernen Turm sitzen, sondern Verantwortung für die Architektur übernehmen„.

Methodiken lernen und einsetzen:
Ein weiterer Ansatz ist es Aufgaben mit dem Team direkt umzusetzen, wie die Erstellung eines „Big Pictures“ in Form von 4C Diagrammen (Context, Component, Container, Class) oder die Durchführung eines „Risk-Stormings“ mit den Entwicklerteams.
Das Team entwickelt sich so mit jedem Kapitel weiter und liefert zugleich noch einen Businessnutzen für das Projekt in Form des „Big Pictures“ oder dem „Risk-Storming“ welches wiederum Schwachstellen der Architektur offenbaren kann.

Paradigmen der Softwareentwicklung festigen:
Ein weiterer Vorteil ist das erarbeiten eines gemeinsamen Verständnisses im Team. Nimmt man einmal das Thema „Dependency Injection“ zum Ziel, so erarbeitet man sich zunächst ein Grundvokabular (Constructor Injection, Property Injection, Ambient Context, etc.), mit dem sichergestellt wird das jeder im Team weiß wovon der andere gerade redet.
Klingt trivial, aber jeder der schon einmal in einem bunt gemischtem Entwicklerteam gearbeitet hat, weiß wie breit gestreut das Wissen jedes einzelnen sein kann. 

Die Nachteile

Reicht ein gemeinsames Vokabular? Können wir wirklich davon ausgehen das das einfache Lesen eines Kapitels in einem Buch jedes Teammitglied in die Lage versetzt das gelesene auch im Projekt umzusetzen?

Das Konzept der Reading Group bringt gleich mehrere Nachteile mit sich:

  • Da sich das Team nur alle zwei Wochen trifft, um die gelesenen Kapitel zu besprechen dauert es seine Zeit bis das Wissen im Projekt genutzt werden kann.
  • Sind die Themen zu abstrakt, fehlt dem Team der Zusammenhang zum aktuellen Projekt und das Wissen kann nicht effektiv eingesetzt werden.
  • Wird das Erlernte nicht sofort eingesetzt, geht viel wissen wieder verloren. Nur selten wird das Wissen dann vom Team erneut abgerufen. Meist benötigt man dann einen kleinen Auffrischungskurs.
  • Setzt das Team das Wissen Kapitel für Kapitel direkt im Projekt um, läuft es Gefahr erst spät zu erkennen wenn es vom Weg abgekommen ist, oder es verliert sich in umständlichen Paradigmen.

Vieles hängt zudem von der Zusammensetzung des Teams ab. Handelt es sich um ein sehr junges Team mit viel Junioren, kann es sein das das Wissen nicht gleich richtig verstanden wird oder einfach falsch angewandt wird.

Erfahrungswerte

Bewegt sich das Team auf einem einigermaßen vergleichbarem Niveau, so kann eine Reading Group helfen ein gemeinsames Verständnis für ein spezielles Thema zu erlangen (Beispielsweise Domain Driven Design).
Werden die Gelesenen Kapiteln mit Beispielen aus dem aktuellen Projekt angereichert, hilft es das Wissen sofort im Projekt umzusetzen und zu vertiefen.

In unseren Reading Groups haben wir uns meist nach der ersten Viertelstunde vom Kapitel gelöst und bezogen die aktuelle Lage des Projektes in die Diskussion mit ein, um mögliche Lösungen zu erarbeiten.

Sind die Wissenslücken im Team allerdings zu groß, so ist es der bessere Ansatz spezielle Themen gezielt zu Schulen. Meist nehmen solche Maßnahmen weniger Zeit in Anspruch, als das Lesen mehrerer Kapitel über Wochen hinweg. Zudem ist eine Kontrolle, ob das erlernte auch wirklich verstanden wurde leichter zu gewährleisten.

Das Team auf einem vergleichbarem Niveau zu halten ist essenziell in einer Reading Group. Bei unerfahrenen Entwicklern ist die Gefahr zu groß, das das gelesene falsch Verstanden wird und zu mehr Verwirrung führt als es nutzen bringt. In diesen Fällen sollte die Reading Group immer von einem erfahrenen Entwickler/Coach betreut werden, der gezielt durch die einzelnen Kapitel leiten kann.

Fazit

Hält man sich an diese Regeln, so kann man über einen längeren Zeitraum eine Wissensbasis im Team aufbauen und festigen. Für das erlernen spezieller Technologien sind allerdings gezielte Schulungen besser geeignet. Zudem ist eine Reading Group nicht für jeden Lerntyp geeignet und ersetzt dadurch nicht das individuelle lernen.