Pair Programming – die kleinste Feedbackschleife in agilen Teams

Jeder Entwickler hat es schon einmal erlebt: Man kommt morgens zur Arbeit und ein Kollege hat sich krank gemeldet und wird vielleicht sogar längere Zeit nicht mehr ins Büro kommen.

Wer kümmert sich nun um die liegenbleibenden Aufgaben? Hat jemand das notwendige Wissen und kennt den Quelltext des Programms und die darin getroffenen Designentscheidungen gut genug, um schnell übernehmen zu können?

Um so schlechter das Wissen im Team verteilt ist, um so höher ist der etwas sarkastisch benannte „Truck-Faktor“ – die Wahrscheinlichkeit, dass das Projekt scheitert, wenn ein Entwickler ausfällt.

Eine Lösung ist der regelmäßige Austausch über geschriebenen Quellcode. Während eine Version davon die bekannten Quellcodereviews darstellen, ist die aktivere Variante das so genannte Pair Programming („Programmieren in Paaren“).

In einem permanenten Wechselspiel von zwei Entwicklern vor einem Computer entsteht so Quelltext, der während der Entstehung von vier Augen gesehen wird. Der gerade entwickelnde Kollege kommentiert während er Quelltext schreibt, was er tut, denkt also quasi laut.

Wenn der Programmierer, welcher gerade nicht die Tastatur hat, Fragen, Anmerkungen oder Ideen hat, teilt er sie dem Partner mit oder bittet kurzerhand um die Tastatur und „läßt Code sprechen“. So entsteht eine Feedbackschleife direkt dort, wo die Kunst bzw. das Handwerk stattfindet.

Dies spart nicht nur anderweitigen Kommunikationsaufwand, macht häufig mehr Spaß und hilft, Teams zusammenzubringen sondern steigert auch die Qualität, denn es rutschen weniger Bugs in den Produktivcode, wie die Grafik erläutert: Nur noch die Fehler, die beide Entwickler machen würden, kommen ungesehen davon.

Der zeitliche Aufwand steigt dabei, jedoch arbeiten Paare oft etwas schneller, sodass mit leicht höheren Produktionskosten gerechnet werden muss – dies ist jedoch häufig eine sinnvolle Investition in vielen Vorhaben, die eine längere Lebensspanne überdauern sollen, berücksichtigt man die oben genannten Vorteile. Vielleicht kennen Sie ja die Kosten von Fehlern, die an Ihre Kunden ausgeliefert worden sind? Entscheiden Sie selbst, ob diese Investition interessant sein kann!

Übrigens wird dann auch die Planung einer Iteration leichter, denn mehr Entwickler können nun immer mehr Aufgaben bearbeiten, da sie das benötigte Wissen gemeinsam haben.

Meine Empfehlung: Probieren Sie es aus und sprechen Sie über die Erfahrungen in einer Retrospektive.

…und wie wäre es eigentlich mit Pair Administration, Pair Designing und Pair Management?

Teamcharta-Vortrag beim Agile Breakfast Konstanz am 24. November 2011

Wenn Projektteams zusammenfinden, treffen unterschiedliche Meinungen, Erfahrungen und Weltanschauungen aufeinander. Dies betrifft sowohl technische Aspekte als auch Organisatorisches.

Wer dies nicht hinreichend berücksichtigt, läuft Gefahr, schwelende und immer wieder neu auflodernde Konflikte zu erleben und mögliche Synergien unter Kollegen zu verhindern. Eine Teamcharta ermöglicht es, Klarheit zu schaffen, bevor Konflikte entstehen.

Um sich auf gemeinsame Konventionen einigen zu können, bedarf es jedoch auch einer guten Methodik. In einem kurzen Exkurs führe ich Sie in die Theorie der Verhandlungsführung bei gegensätzlichen Positionen ein, damit Sie auch in festgefahrenen Situationen einen Konsens finden. Ein Praxisbeispiel vertieft die Theorie des Vortrags.

Ich freue mich über die Einladung der Scrum User Group Bodensee und auf viele Freunde agiler Methoden. Die Teilnahme ist kostenfrei. Kommen Sie doch auch vorbei! Mehr Infos finden Sie hier.

Shu Ha Ri – Teamentwicklung in Etappen

Jurgen Appelo, den ich dieses Jahr persönlich bei seinem Management 3.0 Seminar in Hamburg kennenlernen durfte, hat eine für mich sehr stimmige Aussage getroffen:

Alle Modelle sind falsch, aber manche sind nützlich.

Ein Modell, dass ich für nützlich halte, ist das Shu Ha Ri – Modell, welches aus dem fernöstlichen Kampfsport stammt und von Lyssa Adkins in ihrem Buch „Coaching Agile Teams“ ausführlich dargestellt wird.

Gerade in einer solch komplexen Domäne, wie der Softwareentwicklung, sind solche Abstraktionen hilfreich, um effektiv mit Gruppen arbeiten zu können und bei Teamentwicklungsprozessen bei der Selbstreflektion zu helfen.

Das Shu Ha Ri – Modell besteht aus drei Stufen:

  • Shu: Jemand, der sich in dieser Ebene bewegt, benötigt klaren Regeln. Ihm fehlt die Erfahrung, Zusammenhänge und Hintergründe bewerten zu können und er folgt den Regeln erstmal in Vertrauen auf seinen Lehrmeister.
  • Ha: Der Lernende beherrscht die grundlegenden Praktiken und Prinzipien. Jetzt entsteht Raum, das Handeln zu reflektieren und ein tieferes Verständnis zu entwickeln, warum das gelernte funktioniert oder was es im Kern ausmacht. Diese Einsichten ermöglichen es, die Regeln zu brechen und neu zu definieren, ohne die dahinterliegenden Wirkprinzipien zu verletzen.
  • Ri: Man selbst ist die Regel. In tiefer Kenntnis der Notwendigkeiten und Mechaniken des Handelns können eigene Regeln erstellt werden, die nichts mehr mit den ursprünglichen Regeln zu tun haben und diese in ihrer Wirksamkeit in Bezug auf die eigene Situation deutlich übertrumpfen.

Man kann dieses Modell auf verschiedene Bereiche eines Teams anwenden, wie auch auf die persönliche Entwicklung in Bezug auf ein Thema.

In welchem Bereich Deines Lebens oder Jobs bist Du Shu, wo Ha und wo Ri?

Reflektion des 3. Treffen der Scrum Usergroup Rhein-Neckar

Das 3. Treffen der Scrum Usergroup Rhein-Neckar stand ganz unter dem Zeichen „Agile Games“. Als Ziel für unser Treffen hatten wir uns den Austausch über solche „Spiele“ gesetzt, die zur Vermittlung agiler Werte und Prinzipien geeignet sind. Auch Teambuilding-Spiele generell haben wir mit dazugenommen.

Jeder Teilnehmer hatte die ihm bekannten Spiele vorgestellt. Es kam eine stattliche Liste zusammen:

  • Marshmallow Challenge
  • X/Y Game
  • Planning Poker
  • Magic Estimation
  • 60 Schritte Spiel
  • Ballpoint Game
  • Name Game von Hendrik Knieberg
  • Kanban Game of Ones
  • NASA Übung
  • Fearless Journey

Die NASA Übung haben wir uns dann in der Gruppe vorgenommen. Bei diesem Spiel geht es darum, zu zeigen, dass Teamarbeit bessere Ergebnisse liefert als Einzelarbeit. Besonders auch mit mehreren Teams schön, um ein wenig Wettbewerb und Vergleich zu bieten.

Freundlicherweise konnten wir die Räume der marken mehrwert – brand added value AG in Heidelberg für unser Treffen nutzen und einen Einblick in die Produktion des softwaregetriebenen Geschäftsmodells der Firma erhalten.

Das Spiel Fearless Journey haben wir für den 4. Scrumtisch Rhein-Neckar geplant. Wer Interesse daran hat, wie man jemanden für einen Change-Prozess neue Ideen mitgeben kann, ist herzlich eingeladen und jeder der mehr über Scrum erfahren möchte oder bereits viel Erfahrung hat natürlich ebenfalls.

In kleiner Runde endete der Abend dann mit einem agilen Feierabendbier bei spannenden Gesprächen mit schönen Einblicken in die Scrum-Praxis.

Für unser nächstes Treffen: Welche Spiele fehlen noch? Wer kennt noch spannende Lernerfahrungen im Agile Game Format?

Reflektion des Study Group Kickoffs

Vor dem 1. Treffen der Study Group habe ich die Dramaturgie der Kickoff Besprechung erarbeitet. Die Besprechung war für eine Stunde angesetzt, sie hat eine Stunde und 10 Minuten letzendlich gedauert. Es haben 8 Mitarbeiter teilgenommen, einige Teilnehmer waren verhindert.

Inhalt Dauer Ziel Methode
Willkommen 2 min Ankommen
Checkin: Was erwartest Du von dieser Study Group? (1 Satz) 8 min Erwartungen klären Speech Token
Mögliche Themen identifizieren 10 min Themenüberblick VSA
Zusammenführen am Whiteboard 10 min Gefundene Elemente zusammenführen Klumpenbildung
Prioritäten klären 5 min Top 10 zusammenstellen Mehrpunktabfrage Option/2 und max. 2 Punkte je Option
In Liste übertragen 5 min Reihenfolge festhalten Sortierte Liste
Thema wählen 3 min Thema aus der Liste akzeptieren Thumbvoting
Arbeitsmittel und Quellen für Thema 1 12 min Arbeitsmittel und Quellen identifizieren OSA
Rahmenbedingungen 3 min Einigung auf Ort, Intervall und Länge Vorschläge mit Thumbvoting
Checkout 2 min Unterlagen auf Sharepoint kommunizieren

Der Checkin war thematisch etwas unklar, hier musste ich nachsteuern, um den Fokus auf das Ergebnis auf einer höheren Ebene zu bringen, da es noch nicht um konkrete Inhalte geht. Beim nächsten Mal werde ich etwas weiter ausführen, was ich von der Gruppe möchte und ein Beispiel anbringen.

Ich habe zum ersten mal die Adhäsionsfolien als Whiteboardersatz verwendet, da kein Whiteboard mehr frei war. Die Drag & Drop Funktion ist zum Clustering wirklich praktisch, einzig der Preis der Karten schreckt mich noch ein wenig ab. Außerdem ließ sich eine Folie nicht richtig gut säubern und kein Boardcleaner war in Reichweite. Ansonsten ein wirklich tolles Werkzeug für die Moderation.

Die grundlegende Agenda hat sehr gut funktioniert, jedoch stellte sich beim Brainstorming über den am höchsten priorisierten Punkt ein großer Gesprächsbedarf heraus und die Gruppe war sich nicht einig, ob das Thema einer Study Group gerecht wird und der richtige Teilnehmerkreis anwesend sei.

Hier merkte ich schnell in mir das Spannungsfeld zwischen „der Gruppe Raum zur Diskussion geben“ und einen Zeitplan als Moderator einhalten. Mit verschiedenen Angeboten an die Gruppe konnten wir uns dann einigen, das zweitwichtigste Thema als nächsten Punkt anzugehen, damit wir für das wichtigste Thema etwas mehr Vorlaufzeit haben.

Die nächsten Treffen werden sich also um testgetriebene Entwicklung (TDD) drehen, wobei die Herausforderung sein wird, auch gewinnbringende Informationen für den Office-Entwicklungsbereich zu finden.

Als Verbesserungspotential für meine Moderation habe ich die nachstehenden Punkte heute mitgenommen:

  • Wissen Vertiefen in der Gruppendynamiksteuerung
  • Weitere Methoden zur Konsenzfindung in Gruppen
  • Gruppenergebnisse besser konservieren
  • Checkout bewußter durchführen

Ich werde die Besprechung und deren Ergebnisse, die ich zwischenzeitlich fotografiert habe, im Nachgang noch aufbereiten und der Gruppe zur Verfügung stellen.

Study Group: Gemeinsam lernen

Mein Kunde Softwarekontor hat mich beauftragt, eine Study Group zu initiieren. Bei diesem Format geht es um gemeinsame Weiterbildung und Austausch zu definierten Themen.

Das ganze funktioniert so:

  • Auswahl eines Lernbereichs
  • Auswahl von passenden Quellen (Webseiten, Bücher, Demos, Quellcode, Webcasts)
  • Definition, wie das Wissen erschlossen werden soll (Lesen in Vorbereitung oder vor Ort, Buchtausch alle 15 Minuten, Durchstöbern…)
  • Ermittlung des passenden Intervalls und der Länge eines Treffens
  • Erstellen einer Roadmap für alle Treffen zu dem Thema (optional)
  • Einigung auf eine Agenda für das nächste Treffen

Einen weiteren Tipp gab mir Deborah hierzu: Hat man mehrere Bücher zu einem Thema bietet sich an, diese erstmal gemeinsam zu sichten:

  • Jeder nimmt sich ein Buch für 15 Minuten, liest darin, was er möchte. Das kann ein Kapitelanfang sein, das Inhaltsverzeichnis, Skimmen einiger Seiten
  • Danach stellt jeder das gelesene den anderen aus seiner Sicht dar
  • Danach tauscht man die Bücher untereinander nochmal aus und wiederholt die obigen Schritte

Als Ergebnis hat jeder einen Überblick über das Lernmaterial, kann es grob beurteilen und per Konsenz kann entschieden werden, welches Material verwendet wird.

Entschließt sich das Unternehmen kostenfrei Getränke und ein paar Snacks oder direkt einige Pizzen zu ordern, wird aus einer Study Group schnell eine tolle Plattform des innerbetrieblichen Austauschs und der Teamentwicklung.