Das Pair Programming Experiment

Vor ein paar Wochen habe ich mit meinem verteilten Team ein Pair Programming Experiment durchgeführt: 2 Entwickler auf 2 Standorten (einer in Graz, einer in Rumänien) haben vier Wochen lang ausschließlich mittels Pair Programming entwickelt – das heißt ca. 160 Stunden Remote Pair Programming!

Ausgangslage:

Mein verteiltes Team hatte sich über die letzten Monate gut weiterentwickelt und an Professionalität gewonnen. Pair Programming war jedoch bis dato noch keine etablierte Praxis im Team. Das wollte ich ändern, da es auch gute Gründe gab die Entwickler zu engerer Zusammenarbeit zu bewegen. Es wurde bis dato nämlich bevorzugt alleine an Tasks zu entwickelt und für meine Begriffe zu wenig kommuniziert. Bei einem unserer Kollegen in Rumänien (Marius) war die Kommunikations-Situation besonders schwierig. Zum einen hatte Marius an seinem Standort in Rumänien keinen lokal arbeitenden Teamkollegen mit dem er sich vor Ort austauschen konnte. Zum Anderen hatte er häufig mit Impediments zu kämpfen, von denen er das Team selten in Kenntnis setzte und stattdessen versuchte selbst Lösungen zu finden. Die folgenden Probleme galt es in dieser Situation zu lösen:

  • Marius war als Einzelkämpfer an einem externen Standort zu wenig in das Team eingebunden
  • Marius kommunizierte seinen Bedarf an Hilfe zu spät ans Team
  • Marius versuchte aufkommende Probleme (meist erfolglos) selbst zu lösen

Idee:

In einer Retro kam mir dann die Idee für das Pair Programming Experiment. Marius solle einen Sprint lang kosequent mit einem in Graz arbeitendem Senior Entwickler (Edwin) ausschließlich Pair Programming machen. Ich wollte damit erreichen, dass die Isolation von Marius beendet und die Kommunikation verbessert wurde. In Folge erhoffte ich mir einen wechselseitigen Wissensaustausch, rasche Lösung von Marius’ Problemen und in Folge eine Leistungssteigerung des Teams. Da Marius selbst merkte, dass er mehr Hilfe benötigte als er selbst anforderte war er mit der Idee einverstanden und auch Edwin fand den Versuch spannend.

Verlauf des Pair Programming Experiments:

Nach wenigen Tagen war bereits klar, dass das Pair Programming zwischen Marius und Edwin seinen Zweck erfüllte. So konnte Edwin in den ersten zwei Tagen eine Vielzahl an Verbesserungen von Marius’ Entwicklungsumgebung und Infrastruktur identifizieren und umsetzen. Es wurde auch viel Smalltalk geführt, was die soziale Isolation von Marius aufbrach und der Motivation zu Gute kam. Durch die enge Zusammenarbeit wurde laufend Wissen zwischen Edwin und Marius ausgetauscht, was einen enormen Lernfeffekt hatte. Am Ende des Sprints konnten wir ein erfreuliches Resümee ziehen: Alle waren sich einig, dass uns das Pair Programming als Team verbesserte. Daher beschlossen wir das Experiment für weitere 2 Wochen fortzusetzen, die unsere Erfahrungen aus den ersten beiden Wochen bestätigen sollten.

Retrospektive:

Nach Ende der 4 Wochen machte ich mit Marius und Edwin eine Retrospektive über das Experiment. Vor allem deren persönliche Befinden, die erzielten Lerneffekte und die Rollenverteilung wärend des Experiments waren für mich interessant zu erfahren.

Rollenverteilung:

Im klassischen Pair Programming wechseln sich die Pairing-Partner regelmässig in den Rollen des Navigators und Drivers ab. Wärend der Driver den Code schreibt, sitzt der Navigator daneben und denkt mit, ohne selbst Code zu schreiben. Edwin sollte Anfangs als der erfahrenere Entwickler vorwiegend Marius’ Arbeitsweise beobachten und ihm Hinweise für Verbesserungen geben. Dadurch war Edwin typischerweise häufiger in der Rolle des Navigators. Durch die Beobachtungen von Edwin konnten rasch Schwächen in der Arbeitsweise und am Environment von Marius identifiziert und behoben werden. Über die gesamte Dauer des Experiments zeigte sich, dass sich Marius mit der Analyse von Problemen etwas schwerer tat als Edwin – er erkannte häufig nicht die Wurzel der Probleme und betrieb damit häufig Symptombekämpfung. War jedoch einmal klar was zu tun ist, war Marius wiederrum sehr effizient beim Code umsetzen. Die persönlichen Stärken und Schwächen der beiden Entwickler haben sich durch das Pair Programming sehr gut ergänzt.

Lerneffekte:

Die folgenden Lerneffekte wurden von Marius und Edwin genannt:

  • Gegenseitige Verbesserung der Programmierskills, durch engen Austausch und Beobachtung der anderen Arbeitsweise
  • Marius’ Schwächen in der Analyse konnte durch Edwins Analyse-Stärken kompensiert werden
  • Environment Probleme von Marius konnten identifiziert und gefixt werden, da mit Edwin’s System ein Vergleichsystem verfügbar war
  • Vor allem bei komplexen Tasks zeigte sich Pair Programming für beide effizienter
  • Kommunikations-Barriere minimierte sich durch den dauerhaft offenen Kommunikationskanal zwischen Graz und Rumänien

Persönliches Empfinden:

Marius und Edwin nannten folgende Punkte zu ihrem persönlichen Empfinden wärend des Experiments:

  • Sozial hat die Zusammenarbeit zwiscehn den beiden sehr gut harmoniert
  • Pair Programming half einen hohen Fokus auf die Arbeit zu halten
  • Durch die gemeinsame produktive Arbeit blieb die Motivation dauerhaft hoch
  • Für Marius wurde soziale Nähe zum Team geschaffen (Privatgespräche, Smalltalk,…)
  • Für Marius war die Identifikation mit dem Team höher
  • Das Dauer-Pair-Programming war für beide anstregend aber überzeugend

Conclusio:

Mein Resümee aus dem Experiment ist, dass Pair Programming verteilt mit den richtigen Tools genauso effizient eingesetzt werden kann, wie für lokale Teams. Voraussetzung ist allerdings die Bereitschaft des Teams, konsequent die Praktik umzusetzen sowie die soziale Verträglichkeit der Pairing Partner. Ein akuter Anlassfall bietet immer eine gute Möglichkeit für eine Veränderung, wie die Einführung einer neuen Programmier-Praktik. Tituliert man eine Veränderung als Experiment oder Versuch, so ist der Widerstand des Teams meist geringer, da der Versuch noch keine Verbindlichkeit erzeugt. Implizites Wissen (z.B. Erfahrung), das nicht durch Schulungen transportiert werden kann, lässt sich hervorragend über Pair Programming vermitteln.

Advertisements

8 Gründe warum ich Agile Entwicklung gut finde

Ich beschäftige mich nun seit etwa 5 Jahren mit agiler Softwareentwicklung und Lean Production Systems. Wie die meisten war ich auf der Uni wärend meiner Ausbildung mit dem gängigen Wasserfallmodell vertraut gemacht worden. Als ich dann zum ersten mal über Extreme Programming in einer Vorlesung von Univ.-Prof. Dipl.-Ing. Dr. Slany an der TU Graz hörte war die Verwirrung entsprechend groß über das was mir da erzählt wurde – die Verwirrung schlug jedoch in Neugierde um und wurde immer größer – und so begann ich mich nach erfolgreicher Absolvierung der Lehrveranstaltung mit Extreme Programming, Scrum, Kanban und Lean Production im Detail zu befassen.

Ich habe in meiner bisherigen beruflichen Laufbahn in der Softwareentwicklung beide Paradigmen (Wasserfall und Agil) im Einsatz erlebt und habe in den meisten Fällen die agile Methodik als die zeitgemäßere empfunden. Die persönlichen Gründe dafür möchte ich hier kurz zusammenfassen:

  1. Lean: Agile Entwicklung zielt auf einen “schlanken” Produktionsprozess ab. Dadurch fallen überflüssige Tätigkeiten weitestgehend weg und der Fokus richtet sich auf das nutzenbringende Produkt. “Weniger ist mehr” unter der Voraussetzung dass das, was gemacht wird, gut gemacht wird war schon immer mein Leitspruch im Studium und Beruf. Designer haben dies ja schon lange für sich entdeckt.
  2. Value: In meiner Ausbildung zum zertifizierten Value Manager habe ich viel über eine wertbasierte Denkweise im Management gelernt. In der agilen Entwicklung wird genau diese Denkweise umgesetzt – es ist oberstes Ziel die Produktentwicklung inkrementell nach dem Wert der Produktinkremente priorisiert umzusetzen um somit den Business Value stetig zu maximieren.
  3. Kollaboration: Wissensintensive Tätigkeiten bedürfen einem hohen Maß an Kommunikation und Kollaboration. Um die Vorteile der Gruppenarbeit zu erhalten wird häufig in vielen Unternehmen in Teams gearbeitet. Jedoch ist ein Team, das nicht miteinander kollaboriert wertlos. Daher definiert das agile Manifest “Kollaboration” als einen der absolut wichtigsten Kernwerte.
  4. Motivation: Wenn ich an einem Tag produktiv war gehe ich zufrieden und mit einem guten Gefühl ins Bett – das kennt ihr doch auch, oder? Agile Methoden schaffen einen Rahmen für höchste Produktivität am Arbeitsplatz und steigern dadurch das Gefühl etwas geschafft zu haben und somit die Motivation der Mitarbeiter. Weiters bieten agile Arbeitsweisen den Beteiligten viele Freiheiten und Platz zur Selbstverwirklichung – laut Herzberg der Schlüssel zur nachhatigen Motivation der Mitarbeiter.
  5. Innovationskultur: Agile Methoden hängen meiner Meinung nach thematisch sehr stark mit Innovations- und Wissensmanagement zusammen. Es ist nur in einer Unternehmenskultur, die Innovation, Kreativität, Selbstverwirklichung und persönliche Entfaltung fördert möglich agil zu arbeiten.
  6. Kreativität: Agilität heißt auf Veränderungen rasch reagieren zu können. Dabei ist ein hohes Maß an Kreativität erforderlich. Der Schlüssel jeder Innovation, eines jeden neuem Produktes oder Dienstleistung ist letztlich Kreativität.
  7. Kontinuierliche Verbesserung: Agile Methoden sehen die kontinuierliche Verbesserung als einen festen Bestandteil der Methodik. Letztlich soll nicht nur auf Veränderungen rasch reagiert werden können sondern auch gelernt werden. Ein wesentlicher Teil des Lernens in agilen Prozessen ist “Learing by doing”.
  8. Realismus: Agiler Entwicklung haftet ein gesunder Realismus an. Vor allem in der Softwareentwicklung wurde dieser viele Jahre lang durch unrealistische Deadlines, Anforderungen, Kundenwünsche, usw untergraben. Es ist nunmal meist schwieriger als man anfangs denkt ein neues Produkt zu entwickeln.

Nicht immer läuft alles in der Praxis so glatt wie oben beschrieben. Aber selbst wenn es nicht optimal läuft ist es meist besser als wenn gar kein Bewusstsein für Agile Arbeitsweisen gegeben ist. Die oben angeführten Gründe habe ich mir mehr oder weniger frei von der Seele geschrieben. Sie widerspiegeln meine persönliche Sichtweise und müssen daher nicht immer genauen Definitionen in der Theorie entsprechen. Wer diese Sichtweise  durch eigene Gedanken ergänzen möchte oder Anderer Meinung ist, ist herzlich eingeladen Kommentare zu hinterlassen 😉

Die Werte von Scrum

Bevor ich auf die Werte von Scrum eingehe, möchte ich den Begriff “Wert” erst definieren.

Der Wertbegriff ist ja in vielen Zusammenhängen zu sehen und unterscheidet sich teils sehr stark, abhängig vom Kontext, in dem er verwendet wird.

Kent Beck definiert den Begriff “Werte” im Zusammenhang mit eXtreme Programming wie folgt:

“Values are the roots of things we like and don’t like in a situation.”

Er spricht dabei von kulturellen Werten, die in einer Organisation von den Menschen gelebt werden um eine bestimmte Kultur zu etablieren. Zugegeben eine sehr generische Definition die uns jedoch für den Anfang ausreicht um den Begriff abzugrenzen.

Nun aber zu den Werten von Scrum. Im ersten Buch über Scrum, “Agile Software Development with Scrum“, beschreiben Ken Schwaber und Mike Beedle die folgenden fünf Kern-Werte von Scrum:

  • Commitment
  • Fokus
  • Offenheit
  • Respekt
  • Mut

Ich möchte nun mit meinen eigenen Worten auf die Werte im Detail eingehen:

Commitment

Scrum, wie auch XP sieht es vor, dass sich Entwickerteams zu einem gewissen Arbeitspensum commiten – d.h. dass die Teams in einer definierten Zeit (Sprint, Iteration,…) eine definierte Funktionalität entwickeln werden. Der Wille und der Mut zu commitments ist daher ein elementarer Wert in Scrum.

Fokus

Aus dem Management ist “Fokus” als strategische Erfolgsposition durch Porter bekannt. In der Softwareentwicklung ist der Fokus auf die gegenwärtige Arbeit genauso ausschlaggebend für den Erfolg eines Unternehmens. In Scrum und XP wird durch “herunterbrechen” der Anforderungen in überschaubare Tasks und durch das Arbeiten in Sprints bzw. Iterationen der Fokus auf die gegenwärtige Arbeit gelenkt. Auch tägliche Stand-up Meetings und die gegebenen Commitments führen dazu, dass alle Beteiligten immer ein Ziel vor Augen haben und dadurch fokusiert an die Arbeit herangehen.

Offenheit

Offenheit ist in Scrum in zweierlei Ausprägungen präsent. Einerseits ist die Offenheit eines jeden Einzelnen gegenüber neuen Praktiken, Techniken, Denkweisen, usw. gemeint. Auf der Anderen Seite ist damit Transparenz mit Konflikten, Anforderungen, Informationen, usw. umzugehen gemeint.

Respekt

Scrum bedeutet Teamarbeit und das geht nicht ohne gegenseitigen Respekt. Ein respektvoller Umgang beinhaltet für mich unterschiedliche Meinungen zuzulassen, eigene Schwächen und jene Anderer zu honorieren und einen entsprechenden Umgang miteinander zu pflegen.

Mut

Scrum funktioniert anders als die meisten traditionellen Unternehmen gestrickt sind. Statt Hierarchien zählen Netzwerke, statt Authorität tritt Kollaboration in den Vordergrund. Um traditionell gewachsene Strukturen zu verändern braucht es viel Mut und Courage.

Kent Beck beschreibt ähnliche Werte in seinem Buch “Extreme Programming Explained“. Meiner Meinung nach sind diese Werte ebenfalls als essentiell für Scrum anzusehen:

  • Einfachheit
  • Kommunikation

In weiterer Folge möchte ich die Begriffe noch etwas weiter ausführen.

Einfachheit

Scrum und eXtreme Programming werden auch als “lean development” – also schlanke Entwicklung – bezeichnet. In diesem Wörtchen “lean” steckt schon der Drang nach Einfachheit mit drinnen. Es soll in Scrum immer der direkte Weg zum nutzenbringenden Produkt gewählt werden, anstelle von viel Zeit in langwierige Planungen zu invesiteren, die sich über die Zeit wieder x-mal ändert. “Weniger, aber dafür richtig!” ist also das Ziel in Scrum.

Kommunikation

Software wird von Menschen entwickelt. Darum ist Kommunikation ein elementarer Bestandteil der Softwareentwicklung selbst. Um ehrlich zu sein denke ich dass die mit Abstand meisten Probleme in der Softwareenwicklung Kommunikationsprobleme sind. Immer dann wenn Wissen von einer Person an eine andere Person übermittelt wird kann es, abhängig von der Art der Übermittlung, beim Wissenstransfer zu mehr oder weniger Missverständnissen kommen. Im Wissensmanagement spricht man von direktem Wissenstransfer, wenn sich zwei Personen face-to-face gegenüber stehen während diese kommunizieren, im Gegensatz zum indirektem Wissenstransfer, der über Dokumente oder technische Systeme abgewickelt wird. Besser für die “fehlerfreie” Kommunikation ist der direkte Wissenstransfer, da hier der Empfänger mit Feedback (Worten, Gestik, Mimik,…) direkt reagieren kann und so mehr Aspekte in die Kommunikation einfließen. Das ist aber ein großes Thema und ist daher einen eigenen Blogpost wert.

Zugegeben klingt das alles sehr abstrakt und vieles erscheint auf den ersten Blick als allzulogisch – doch wozu braucht es nun diese Werte für Scrum überhaupt?

Hier komme ich wieder auf die Unternehmenskultur zu sprechen. Es ist aus meiner Sicht unabdingbar für das Funktionieren von Scrum eine Kultur im Unternehmen zu schaffen, bei der die Werte von Scrum höchsten Stellenwert haben und gelebt werden.