Pair Programming Canvas
Besseres Pairing mit dem Pair Programming Canvas?
Du bist Scrum Master, agile Coach, Entwickler oder übst eine andere Rolle in einem agilem Umfeld aus? Du interessierst dich für Pair Programming? In diesem Post zeige ich dir eine meiner Methoden, mit der nicht nur mein aktuelles Softwareentwicklungsteam sondern ebenfalls diverse Teams in meinem Umfeld eine deutliche Verbesserung in ihrer täglichen Arbeit erreicht haben. Wir sind begeistert. Ich präsentiere euch das Pair Programming Canvas.
Motivation
In den letzten Jahren durfte ich diverse Softwareentwicklungsteams begleiten. Über diese diverse Teams mit unterschiedlicher agiler Reife, unterschiedlicher Technologie oder auch ganz unterschiedlichen Softwareprodukten ist mir dennoch eine Gemeinsamkeit aufgefallen. All diese Teams standen im Kontext von Pair Programming vor fast identischen Fragen und Herausforderungen. Die Arbeitskultur bezüglich "Pairing" war noch nicht ausgereift. Ich begann diese Fragen aufzuschreiben und ein paar Jahre später wurden aus diesen Fragen ein Canvas. In diesem Artikel erkläre ich euch heute wie es funktioniert.
Pair Programming & Canvas
Zuerst ein paar Hintergründe: Beim Pair Programming arbeiten zwei Programmierer gleichzeitig an der Erstellung des Codes. Typischerweise nimmt einer die Rolle "Driver" (schreibt) und der andere die Rolle "Navigator" (beobachtet, kommentiert) ein. Die Rollen sollten regelmäßig tauschen. Die positiven Auswirkungen von Pair Programming sind inzwischen oft untersucht worden. Weniger Fehler, kleinere Programme, höhere Disziplin, besserer Code, belastbarer Flow, mehr Freude an der Arbeit bei zeitgleich weniger Risiko klingt nach etwas was du in deinem Team haben willst? (1) Dann versuch es einmal mit Pair Programming oder reflektiert in eurem Team, ob ihr die Art und Weise in der ihr Pair Programming macht noch weiter optimieren könnt.
Ebenso haben sich in der Industrie diverse Canvas durchgesetzt. Ein Canvas ist ein für eine Problemstellung strukturierte Vorlage. Agile Teams verwenden diese sehr oft da sie unter anderem die agilen Prinzipien "Einfachheit", "Informationsaustausch von Angesicht zu Angesicht" und "selbstorganisierte Teams" verkörpern.
Das bekannteste ist wohl das Business Model Canvas (2). Jedem agilem Team empfehle ich sich auch einmal mit dem Team Canvas (3) und dem Produkt Vision Canvas (4) zu beschäftigen. Der Vorteil dieser Vorlagen ist es, dass Teams dadurch schneller und oft gründlicher zu einer guten Lösung im jeweiligem relevanten Kontext kommen.
Aus diesen Hintergrund und meiner oben beschriebenen Beobachtung, dass viele agile Teams immer wieder vor sehr ähnlichen Herausforderungen im Kontext von Pair Programming stehen, schien es mir einleuchtend ein Canvas speziell für das Pair Programming zu entwicklen.
Rolle des Coaches: "nicht fordern aber fördern"
Pair Programming ist ein unglaublicher Treiber von Qualität und Effektivität. Daher kann ich jeden verstehen, der dieses Thema auch mehrmals in ein Team einbringt.
Der Coach sollte sich dabei bewusst sein, dass das Thema extrem große Auswirkungen auf den gesamten Arbeitstag der Entwickler hat. Er sollte auf keinen Fall Pair Programming fordern aber es fördern. Stellt euch hierzu einmal folgendes vor: Ihr werdet dazu "verdonnert" mit einem anderen Scrum Master aus einem anderem Team dem ganzem Tag direkt zusammenzuarbeiten? Wie fühlt ihr euch?
Ebenso ist es bei dem Thema extrem wichtig auf die Bedürfnisse aller Teammitglieder einzugehen und ggfs. auch Akzeptanz für andere Bedürfnisse zu schaffen. Der Coach sollte bereits bevor er die Methode durchführt psychologische Sicherheit im Team aufgebaut haben.
Im Idealfall kommt der Auftrag aus dem Team und der Coach kann dann zum Beispiel einen Workshop mit dem Pair Programming Canvas mit dem Team durchführen. Wir Coaches verraten an dieser Stelle einmal nicht, dass wir solche Aufträge zum Beispiel durch Fragetechniken bewusst erzeugen.
Verwendung des Pair Programming Canvas
Das Canvas ist in 15 Felder aufgeteilt. Das erste Feld kann unkompliziert als Check-In und das letzte als Check-Out verwendet werden. Dadurch reduziert sich auch der Bedarf an Erklärung bei der Durchführung. Durch die verschiedenen Felder, wird das Team durch die Fragen rund um das Thema Pair Programming geführt.
Nach dem Check-In würde ich bei der Durchführung zuerst die Methode Silent Writing (5) verwenden und danach Spalte für Spalte durch das Board moderieren. Oft gehören die Blöcke in einer Spalte thematisch zusammen. Dies kann für diverse kurze Pausen genutzt werden. Zeitlich würde ich an dieser Stelle je nach Teamgröße mindesten zweieinhalb bis drei Stunden investieren.
Über die Felder soll definitiv diskutiert werden. Der Coach sollte in der Diskussion darauf achten, dass das Ziel der Einheit "gemeinsam Pair Programming zu optimieren oder einzuführen" stets im Vordergrund steht.
Das Tool soll auf keinen Fall eine andere agile Praktik, das Working Agreement, aufweichen oder den Single-Point-of-Information dieses Konzeptes ablösen. Überlegt euch am Ende vielmehr welche Information aus dem Workshop ihr in euer zentrales Working Agreement persistieren wollt.
Ebenfalls soll das Feld Action Points auf keinen Fall ein zweites Backlog schaffen, sondern es euch leicht machen die ausgearbeiteten Maßnahmen in euer zentrales Backlog zu übertragen.
Let's grow,
Michael
Kommentare
Kommentar veröffentlichen