Backlog Refinement

In diesem Artikel erläutere ich wie ich das Refinement interpretiere und wie ich es vom Sprint Planning 1 abgrenze.

Boris Gloger gibt in seinem Video interessante Hintergrundinformationen und erläutert die Entstehungsgeschichte des Backlog Refinement Meetings. Spannend finde ich dabei wie sich der Name über die Zeit verändert hat (Estimation Meeting => Backlog Grooming => Refinement) hat.

Ziel

Mit dem Backlog Refinement soll geklärt werden, ob das, was potentiell im nächsten Sprint umgesetzt werden soll, so weit vorbereitet ist, dass es auch umgesetzt werden kann.

Konkret klärt der Product Owner mit dem Entwicklerteam, ob

• das Sprint Goal sinnvoll ist,
• die User Stories verständlich sind,
• die User Stories anhand einer groben Schätzung in den Sprint passen könnten
• und ob die Priorisierung den besten Business Value liefern kann.

Oder anders formuliert: Der Product Owner stellt sich die die folgenden Fragen:

• Habe ich das Backlog richtig priorisiert?
• Haben die Entwickler ein Grundverständnis davon, was im nächsten Sprint auf sie zukommt?
• Sind die User Stories, von denen ich tatsächlich annehme, dass sie Teil des Sprint Plannings 1 werden, S.M.A.R.T..

Beispiele

Die folgenden zwei Szenarien kennen vermutlich die meisten aus dem Alltag und zeigen, dass ein vorheriges Refinement helfen kann.

Der Product Owner stellt im Sprint Planning 1 eine User Story vor und das Team versteht diese nicht. Es entstehen lange Diskussionen, es werden Zeichnungen am Flipchart erstellt und (Domänen-)Begriffe definiert. Statt im Planning würde im Refinement frühzeitig das Verständnisproblem entdeckt und die User Story vom Entwicklerteam an den Product Owner „zurückgegeben“ werden. Der Product Owner kriegt somit Zeit die Story klarer zu formulieren oder das Feature sogar neu zu schneiden.

Eine User Story kann im Sprint Planning 1 nicht geschätzt werden, weil die Entwickler dafür zunächst technische Fragen klären müssen. Als Ergebnis des Refinements würde das Entwicklerteam den zugehörigen Quellcode nochmal untersuchen oder eine technische Gegebenheit recherchieren. Im eigentlichen Sprint Planning 1 oder einem etwaigen zweiten Refinement stünden dann alle notwendigen Informationen zur Verfügung.

Eine User Story ist deutlich größer und komplexer als der Product Owner dies vermutet hätte. Das Entwicklerteam spiegelt ihm das im Refinement, sodass er den Inhalt im Nachgang in kleinere Stücke schneiden kann.

Durchführung

Wie oft das Refinement innerhalb eines Sprints durchgeführt wird und wer daran teilnimmt, ist Geschmackssache. Nehmt die Leute mit rein, die anwesend sein müssen, um die Fragen zu klären bzw. das Ziel des Refinements zu erreichen. Und wenn der Product Owner sich ein zweites oder drittes Meeting wünscht, weil er sonst das Sprint Planning 1 nicht adäquat vorbereiten kann, dann sollten sich das Team auch Zeit dafür nehmen. Die Zeit wird ansonsten in jedem Fall im Spring Planning 1 benötigt werden (und vermutlich sogar mehr).

Gibt es bei euch ein Refinement Meeting? Wenn ja, wie trennt ihr selbiges vom Planning? Sind bei euch immer alle Entwickler oder sogar Stakeholder dabei? Schreibt es in die Kommentare.

Werbung

Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

• Hier geht es zu Teil 1: Ab in den Tunnel mit den Entwicklern
• Hier geht es zu Teil 3: Vice versa (noch in Arbeit)

Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Product Owner lasst eure Entwickler den Tunnel

Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

• Hier geht es zu Teil 2: Product Owner optimiert eure Engpässe
• Hier geht es zu Teil 3: Vice versa (noch in Arbeit)

 

Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.

 

Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.

Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.

Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.

Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.

Aus der täglichen Retrospektive #3

Unsere Retrospektiven gehen weiter und die Teammitglieder entwickeln meiner Einschätzung nach ein immer besseres Gespür für Impediments. Das ist für mich als Scrum Master besonders erfreulich. Ich habe mir wieder einmal etwas herausgegriffen, von dem ich denke, dass es dem Leser helfen kann.

Es hat sich herausgestellt, dass ein wichtiger Prozess bisher nicht explizit gemacht wurde: Der Go Live.

Das führte unter anderem dazu, dass das Update erst mit mehreren Tagen Verzögerung und teilweise sogar mit Änderungen aus dem neuen Sprint durchgeführt wurde. Darüber hinaus war nicht gewährleistet, dass mit der Codebasis auch die Datenbasis aktualisiert wurde. Deshalb haben wir uns zusammengesetzt, den Prozess besprochen und diesen im Wiki festgehalten.

Darin wird klar zw. Daten- und Code- Go Live unterschieden. Damit einhergehen auch unterschiedliche Termine und Verantwortliche. Interessanterweise wurde in der Diskussion deutlich, dass der Prozess noch detailliert visualisiert und kommuniziert werden muss. In Kanban ist das fest als Regel aufgelistet:

                  Visualize Your Workflow

Einen Einblick in unser Wiki und den Prozess werde ich demnächst in Form eines Screencasts auf YouTube und auf meinen Blog stellen. Als Abonnent kriegt ihr das automatisch mit.

Mit welchem Tool verfasst bzw. persistiert ihr eure Regeln? Wer macht das? Wird das kontinuierlich erweitert oder war das nicht mehr notwendig? Ist es euch auch schon öfters passiert, dass ihr feststellen musstet, dass Regeln nicht explizit gemacht und dadurch Probleme verursacht wurden? Gerne könnt ihr mir einen Kommentar schreiben.

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Welche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

• Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
• Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

• Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
• Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
• Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
• Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
• Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
• Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
• Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
• Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

Wie besetze ich die Rolle des Product Owners

Prinzipiell ist es nie leicht die Rollen in Scrum adäquat zu besetzen. Der Product Owner (PO) ist dabei keine Ausnahme. An dieser Stelle kann ich deshalb keine generellen Empfehlung aussprechen, einfach weil dies meines Erachtens nicht möglich ist. Stattdessen beschreibe ich den Weg, den wir in der Firma heco mit Erfolg gegangen sind.

Einer unserer Administratoren in der IT sprach mich darauf an, dass er mit seinen Aufgaben zum Teil unterfordert ist und sich zum Teil auch noch mehr einbringen wolle. Beim Reflektieren darüber stachen für mich 5 wesentliche Eigenschaften hervor:

• In seiner aktuellen Aufgabe hatte unser Admin sehr engen und guten Kontakt zu allen Mitarbeitern, die das Produkt (hauseigenes ERP-System) einsetzen
• Sein Verständnis für Geschäftsprozesse war stark ausgeprägt, was auch seine akademische Karriere (Wirtschaftsgymnasium, DHBW Studium) belegte
• Seine IT-Kenntnisse machten die Kommunikation mit dem Entwickler Team einfacher
• Er betreute bereits das Produkt auf technisch administrativer Ebene
• Er war motiviert und wollte das Produkt aktiv mitgestalten

Klar war aber, dass ihm das fachliche Know How und deshalb auch die konkrete Produktvision fehlen würde. Deshalb waren die ersten zwei Schritte ihn direkt zu der Person zu setzen, die das Produkt bis ins kleinste Detail kannte: Unseren Geschäftsführer. Um den Einlernungsprozess zu beschleunigen, war die erste Aufgabe eine vollständige Dokumentation über alle Schnittstellen zu schreiben – sowohl fachlich (das WAS) als auch technisch (das WIE).

In der anschließenden Retrospektive zeigte sich, dass damit der Lernprozess nicht schnell genug voran kam. Deshalb übertrugen wir ihm die Aufgabe alle User Stories fortan selbst zu erfassen. Wir wichen also von den Empfehlungen der Standardliteratur ab, dass die Entwickler die User Stories schreiben sollen. Für mich eine der besten Entscheidungen überhaupt. Immer wenn er nicht in der Lage war die User Story zu erfassen, egal ob zu formulieren oder gemäß dem Business Value zu priorisieren, musste er mit unserem GF darüber sprechen. Zur Gänze hab ich ihn immer zusammen mit den Fachexperten die zugehörigen Informationen im Unternehmens-Wiki festhalten lassen, also z.B. die erarbeitete Domänen-Sprache (vgl. Ubiquitous Language) oder die Bedienungsanleitung. Konsequenterweise war er auch an allen Meetings anwesend. Dass Informieren der Mitarbeiter in Form von Trainings, Schulungen oder E-Mails vervollständigte die Botschaft: Er ist der PO, an den sich die Belegschaft wenden muss.

Die ersten 4 Monate agierte er als sogenannte Proxy Product Owner, der dem eigentlichen PO (in unserem Falle dem Geschäftsführer) versuchte möglichst viel Arbeit abzunehmen, v.a. wenn dieser nicht die nötige Zeit für die Ausübung seiner Rolle hatte. Der Anlernphase folgte dann das Gespräch mit unserem GF, in welchem er seine PO Position übergab. Das bedeutete in erster Linie: Benötigt das Entwickler Team sofort eine Antwort auf eine Frage, dann hat der neue PO die entsprechende Kompetenz, eine etwaig endgültige Entscheidung zu treffen. Diesen Aspekt möchte ich ganz klar hervorheben, weil er nicht unterschätzt werden darf! Zuvor hatten wir bereits eine 100%ige Verfügbarkeit des PO für das komplette Scrum Team erreicht. Diese beiden Eigenschaften zusammen lieferten einen unglaublichen Impuls für die Entwicklung.

Ein Beispiel hierfür: In der Vergangenheit trauten sich die Kollegen aus den Niederlassungen nicht direkt an unseren Geschäftsführer mit Verbesserungsvorschlägen oder Fehlermeldungen heran. Oftmals wählten sie einen Umweg über mich, jedoch verwies ich immer auf den GF als Product Owner, da ich nicht priorisieren konnte bzw. wollte. Das Problem war mir bereits früher aufgefallen, doch fand ich nie eine zufriedenstellende Lösung. Inzwischen ist eine äußert produktive Feedback Kultur entstanden, bei der die Belegschaft die Umsetzung ihrer Wünsche logischerweise sehr positiv aufnimmt.

Selbstverständlich machte unser PO parallel zur Produktschulung regelmäßig Scrum Schulungen (Inhouse), las Bücher (Empfehlung hier), ging zu Scrum Stammtischen oder machte Webinare. Alternativ kann auch ein externer Berater herangezogen werden, mit dem die ersten Schritte gemeinsam gegangen werden.

 

Mich würde interessieren, wer unter den Lesern mit der unternehmenseigenen Besetzung des PO zufrieden ist. Vor allem in Hinblick auf Verfügbarkeit fürs Team!

Wo findet sich der Quality Manager in Scrum wieder?

Kürzlich sprach ich mit einer Bewerberin, die während ihres Studiums erste Erfahrungen mit Scrum in einem größeren Betrieb gemacht hat. Mit Interesse verfolgte ich ihre Antwort auf die Frage, wie die konkrete Implementierung aussah. Dabei fielen die Bezeichnungen Product Manager und Quality Manager.

Das ist insofern interessant, weil Scrum die beiden Rollen gar nicht kennt. Während der klassische Product Manager in den 3 Rollen Product Owner, Scrum Master und Developer Team aufgeht, sieht das beim Quality Manager anders aus. Wie schon beim Lean Management steckt der Gedanke hinter Scrum, dass die Qualität nicht zum Schluss durch eine Person geprüft werden, sondern dass Qualität im kompletten Entwicklungsprozess von jedem Beteiligten als eigener Anspruch etabliert werden soll. Im Falle eines Autos würde das bedeuten, dass nicht erst das fertige Auto am Ende der Fertigungsstraße auf Qualität geprüft wird. Stattdessen soll kontinuierlich vom Start bis zum Ende an jeder einzelnen Fertigungsstelle der Bearbeiter über die Standards Bescheid wissen und sie kontrollieren. Sollte währenddessen das Produkt dem Anspruch nicht genügen, würde die Fertigungsstraße pausiert und darüber beraten werden, wie es mit dem Fahrzeug weitergehen soll. Kurz gesagt: Wenn das Kind in den Brunnen gefallen ist, muss nicht mehr über die Absicherung des Brunnens gesprochen werden.

Besagter Gedanke wird in Scrum zum Einen über die Definition of Done etabliert. Eine User Story darf erst als erledigt gekennzeichnet werden, wenn der Definition entsprochen wurde. Darin stehen unter anderem Spezifikationen für die automatisierte Testabdeckung, sowie etwaige manuell durchzuführende Tests. Im Übrigen finden sich dort auch Aussagen zur Sicherheit, weil das Absichern einer Anwendung im Nachhinein genauso wenig zielführend ist wie im Falle der Produktqualität.

Darüber hinaus gehört zu einem erfolgreichen Scrum Prozess auch ein Build Server, der automatisiert alle Arten von Tests durchführt und bei jedem Check-In im Versionskontrollsystem (auch das VKS ist Teil der Qualitätssicherung) alle Produktteile integriert.

Das bedeutet, dass die Aufgaben des Quality Managers in Scrum an das Entwickler Team übergehen. Das Team soll schließlich eigenverantwortlich arbeiten und gerade hier zeigt sich, ob sich der Product Owner das richtige Team für seine Vision herausgesucht hat. Oder aber es zeigt sich, dass dem Team gar nicht erlaubt wird so zu arbeiten, wie es das für richtig hält. Hier ist dann der Scrum Master gefragt. Beispielsweise habe ich von Teams gehört, denen der Build Server und das Versionskontrollsystem vorgeschrieben wurde, obwohl die Entwickler klar kommunizierten, dass die Software nicht den Ansprüchen genügt.

Agiler Scrumtisch Heilbronn

Gestern waren mein Kollege aus der Webentwicklung und ich beim Agilen Scrumtisch in Heilbronn.

 

Die Truppe vor Ort ist ein lockerer, gut gemischter Haufen. Logischerweise wurde der Scrumtisch auch Scrum-like organisiert, d.h. jeder Teilnehmer konnte Backlog Items einreichen. Dabei profitierte ich auch prompt, da sogenannte Stattys Notes verwendet wurden, die es hier gibt. Dabei handelt es sich um eine besondere Art von PostIts. Einfach auf der Webseite nachschauen. Die Seite ist übrigens nach dem Why How What Prinzip von Simon Sinek (“People don’t buy what you do they buy why you do it”) aufgebaut. Das ist umso lustiger, als ich genau darauf gestern im Kontext von Motivation und Produktmarketing zu sprechen kam. Das entsprechende Video, welches ich jedem nur ans Herz legen kann, gibt es hier.

Aber zurück zum Thema: Nachdem alle Backlog Items (Themen) gesammelt wurden, erhielt jeder ein 3-Punkte-Konto, aus welchem er die Items voten konnte. Daraus entstand der Business Value, nach welchem die Items priorisiert wurden. Danach zogen wir ein Item nach dem anderen heraus und diskutierten es. Dabei standen immer initial 10 Minuten zur Verfügung. Benutzt wurde eine Time Timer Uhr. Im Anschluss wurde in die Gruppe gefragt, ob das Thema weiter besprochen oder zum nächsten gewechselt werden soll. Per Handzeichen (Daumen hoch oder runter) entschied die Gruppenmajorität. Fiel die Entscheidung  zur Weiterführung der Diskussion, so gab es weitere 5 Minuten. Dies wiederholte sich dann bis ein Votum gegen das Thema fiel. An dieser Stelle sei mein vorheriger Blogbeitrag Wir arbeiten time boxed erwähnt, der den Vorteil von festen Zeitabschnitten aufgreift. Für mich eine tolle Art den Abend zu gestalten.

Die Gespräche verliefen konstruktiv und vielschichtig. Es gab unterschiedliche Betrachtungsweisen und Lösungsansätze. Einen speziellen Punkt habe ich mir herausgegriffen und in der Xing Scrum Gruppe als Frage eingestellt. Dabei geht es um sogenannte Evaluierungsstories, welche Boris Gloger in einem seiner Bücher erwähnt. Der geneigte Leser ist dazu angehalten sich an dem Gespräch zu beteiligen.

3 interessante Punkte, die ich mitgenommen habe, seien noch in aller Kürze erwähnt:

• Es gibt dedizierte Retrospektive-Trainings auf dem Markt
• Delegation Boards
• Das Buch Katzen hüten

Wir arbeiten time boxed

Es vergeht selten eine Arbeitswoche ohne eine Besprechung. Die Regel sind mehrere wöchentlich. Umso wichtiger ist es, dass ein Rahmen gefunden wird, der effektive Meetings gewährleistet. Die Chefs von Google hatten in ihrer Anfangszeit z.B. das parallele Arbeiten am Smartphone eingeführt. Diesen Schritt haben sie selbst erst kürzlich wieder rückgängig gemacht, d.h. beim Suchmaschinenriesen herrscht jetzt Handyverbot während den Sitzungen.

Ich möchte an dieser Stelle auf feste Anfangs- und Endzeiten eingehen, englisch ‘time boxed’ genannt, und erklären, warum wir inzwischen ausschließlich auf diese Art Besprechungen führen:

• Die Konzentration ist höher, da in der gegebenen Zeit der Inhalt durchgesprochen werden muss. Der Moderator (bzw. Scrum Master in entsprechenden Teams) sollte darauf achten die besonders redseligen immer wieder zurück in die Spur zu bringen. Bei massiven Problemen können Redezeiten oder Sprechbälle als Werkzeuge helfen. Bei uns klappt es allerdings recht gut, wenn die Person direkt mit dem Hinweis adressiert wird, dass uns die Zeit ausgeht. Ich habe eine deutlich stärkere Fokussierung und somit bessere Effizienz bei uns festgestellt.
• Es werden weniger unnötige Informationen ausgetauscht. Unnötig im Sinne von nicht für alle relevant. In diesem Punkt ist ebenfalls der Moderator gefragt. Einfach die Bitte an die betroffenen Teilnehmer richten sich im Anschluss zusammenzusetzen.
• Die Zeitersparnis, die mit Warten regelrecht verbraten wird, ist enorm. Je häufiger Meetings stattfinden und desto mehr Mitarbeiter daran beteiligt sind, desto höher ist die Ausbeute. Früher war es bei uns häufig der Fall, dass ein Teil der Gruppe durch ihr Warten kostbare Arbeitszeit verlor. Auf die Personalkosten möchte ich erst gar nicht eingehen.
• Pünktlich zu kommen ist auch ein Zeichen des Respekts bzw. der Höflichkeit.
• Für mich ist Pünktlichkeit auch ein Anzeichen für die Qualität des Selbstmanagements. Wenn wir externe Berater zu Gast haben und diese sich häufig oder besonders lange verspäten, dann stellt sich für mich immer die Frage wie zuverlässig sie beim Abliefern der Ergebnisse sind.
• Durch fest definierte Endzeiten wird es überhaupt erst möglich verlässlich zu planen. Wenn ich beispielsweise beim Kollegen, der mir seinen Kalender freigegeben habe, sehe, dass sein Meeting bis 15 Uhr dauert, er dann aber 30 Minuten später immer noch nicht wieder am Platz sitzt, dann ist das für mich, der um 15.30 Uhr eine Besprechung hat, gelinde gesagt ungünstig. Mir wäre es dann auch nie möglich mit ihm direkt im Anschluss einen weiteren Termin zu vereinbaren, da ich immer damit rechnen muss, dass er nicht pünktlich sein kann.
• Besprechungsräume sind bei uns wie vermutlich auch in anderen Unternehmen eine begrenzte Ressource. Wir arbeiten mit der in Outlook verfügbaren Verwaltung, um diese effektiv auszulasten. Das kann nur funktionieren, wenn time boxed vorgegangen wird.

Gerne würde ich noch weitere Punkte aufnehmen. Einfach in die Kommentare schreiben.

 

Als Hinweis sei noch mitgegeben, was bei der Umsetzung hilft:

• Eine gewisse Unzufriedenheit mit dem aktuellen Ablauf
• Disziplin
• Einen guten Moderator (Scrum Master)
• Eine Uhr (z.B. Time Timer wie im Bild)

Certified Scrum Product Owner Schulung

Im Zeitraum vom 18. bis 20. Juni nach ich an einer Certified Scrum Product Owner Schulung bei den Trainern Dr. Jürgen Hoffmann und Peter Beck teil. Den Kurs hatte über die wibas GmbH gebucht. Als Veranstaltungsort wählte ich die NTT DATA Ettlingen Academy.

 

Location

Das Angebot an kostenfreien Parkplätzen war optimal, sodass unnötig langes Suchen am frühen Morgen ausblieb. Die verfügbaren Räume waren schön hell mit genügend Platz für die knapp 20 Kursteilnehmer. Leider mangelte es an einer Klimaanlage, was mir bei tropischen 35°C besonders negativ auffiel. In den kleinen Pausen konnte man sich mit frischem Obst und Gebäck stärken; zur Mittagszeit gab es Essen in der Kantine, welche einen schönen Balkon mit Teich zur geistigen Erholung bot.  Bedenkt man die kurze Strecke für Karlsruher war es geradezu ideal..

 

Die Trainer

Eine kurze Recherche ergab, dass es sich um zwei etablierte, langjährige Trainer handelte, die in der Community recht arriviert sind. Deshalb bekamen die Teilnehmer das, was sie vermutlich am meisten hören wollten: Praxisberichte. Die Frage “Wie habt ihr das bei euch gemacht” kam so ziemlich jedem über die Lippen. Hierfür gibt es von mir “volle Punktzahl”. Die Aussagen waren klar, die didaktischen Methoden variierten in einem gesunden Maße und durch die Backlogs der einzelnen Gruppen konnte jeder in die Themenfokussierung eingreifen. Negativ fielen mir folgende Dinge auf:

Aufgrund meiner T-Shirt Wahl, welche meine Entwicklerwurzeln offen zeigte, wurde wohl der Eindruck bei den Trainern perpetuiert, dass man mich auch als solchen “coachen” sollte. Zumindest empfand ich dies teilweise so bei Gesprächen. Als ich mich zur Aussage, dass es gängige Praxis sei die Entwickler die Product Backlog Items schreiben zu lassen, kritisch äußerte und darüber diskutieren wollte, wurde dies einfach abgetan. Inzwischen habe ich vermehrt in der Community, unter anderem am .NET Open Space, das Thema aufgeworfen. Mein Resümee: Gängige Praxis sieht anders aus. Allerdings möchte ich fairerweise an dieser Stelle anmerken, dass selbst in der Fachliteratur (u.a. im Werk von Boris Gloger) ähnliche Aussagen stehen. Mir geht es jedoch darum, dass ich mich eine Schublade gesteckt sah, sodass eine konstruktive Diskussion in diesem konkreten Fall nicht zu Stande kam.

Ein weiterer Punkt waren ein paar wenige (!) fragwürdige Aussagen. Eine davon implizierte, dass die Definition of Done immanent unvollständig sein müsse, wenn das Produkt keine 100%ige Evolvierbarkeit aufweise.

Rein subjektiv gefielen mir die ausgewählten Planspiele nicht. Das lag vielleicht daran, dass es sich nicht um Geschäftsprozesse handelte. Vielleicht auch an den konkret gewählten Szenarien, wie das Bauen eines Lego-Parks für Kinder. Bei der zu Beginn gewählten Teambildungsmaßnahme mussten Seesterne gelegt werden. Eine gängige Praxis, wie ich von Bekannten mit selbiger Zertifizierung erfahren habe. Allerdings wurde es so umgesetzt, dass die Teams bereits blind in den Raum kommen, die Materialien finden und Position begeben mussten. Wenn aber die erste Gruppe direkt am Eingang stehen bleibt, dann ist das Resultat, dass mehrere Teams vorerst einfach rumstehen müssen, bis der erste Durchgang beendet wurde. Der Lerneffekt ist für mich genauso gegeben, wenn die Teams bereits im Raum mit den Materialien platziert wären. Sehr positiv wiederum kann ich über das Fallbeispiel zur Schätzung in Story Points im warmen Garten berichten. Die Teams sollten sich hierbei auf die Komplexität zum Entfernen von Gegenständen für den bevorstehenden Besuch von Obama (der an diesem Tag tatsächlich in Berlin war) einigen. Das fing bei Aschenbechern an, ging über Tische und hörte bei Autos auf.

 

Zur Schulung

Als einziges Angebot, welches ich in der näheren Umgebung finden konnte, ging dieser Kurs über 3 Tage. Die üblichen Schulungen sind in der Regel auf 2 Tage ausgelegt. Planspiele sind aber relativ zeitaufwendig und der Wunsch nach Erfahrungsberichten der Trainer führt zu starken Verzögerungen. Deshalb kann ich nur jedem empfehlen 3-tägige Seminare zu bevorzugen.

Die Kosten lagen auf gängigem Marktniveau. Bei entsprechendem Vorlauf wird Frühbucherrabatt gewährt.

Als Schulungszeiten waren 10-18 Uhr am ersten Tag und 9-17 Uhr an den darauffolgenden Tagen geplant. Diese wurden recht gut eingehalten, was nach meiner Erfahrung bei Schulungen sonst nur selten funktioniert.

Bereits vor Kursbeginn erhielt ich eine E-Mail mit Vorschlägen zur Vorbereitung. Während der Schulung wurde ein eigens dafür eingerichteter DropBox Ordner kontinuierlich aktualisiert. Darin landeten neben kostenlosen Ebooks die Fotoaufnahmen der erstellten Materialien (quasi eine Timeline der Flip Chart Blätter), sowie diverse Vorlagen und weiterführende Materialien. Ein dediziertes Dokument mit den erarbeiteten Inhalten gab es nicht.

Das klar kommunizierte Ziel war es jeden in die Lage zu versetzen, entscheiden zu können, ob Scrum mit seinen Prinzipien und Werten für das eigene Unternehmen geeignet ist und sich etablieren lässt. Der Fokus lag natürlich auf der Rolle des Product Owners, ist aber auch nach Aussagen der Trainer mit der des Scrum Master zu 80-90% deckungsgleich. Die restlichen 10-20% wurden dann aber speziell hervorgehoben bzw. ggf. auch intensiver erörtert.

Wer viele Planspiele, viel Eigenarbeit, viel Stehen und wenig PowerPoint Slides bevorzugt, kommt definitiv auf seine Kosten. Mir persönlich hätte ein wenig mehr “klassische” Schulung mit theorielastigerem Vorgehen besser zugesagt. Nach meinem Gefühl kommen dadurch mehr Fragen auf, v.a. abseits der der trivialen Oberflächenthemen. Das bestätigte sich für mich im Nachhinein beim Lesen der oben genannten Lektüre von Boris Gloger wieder. (Wenn Folien übrigens schlecht sind, dann weil der Autor Fehler gemacht hat, nicht weil diese per sé schlecht sein müssen, siehe meine Buchempfehlung.) Allerdings verhält es sich so, dass ich nach einer theorielastigen Sitzung der Einzige war,  der diese positiv bewertete. Deswegen gilt: Die Schulung muss nach der eigenen Präferenz ausgewählt werden.

 

Fazit

Auf einer Skala von 1 bis 10 gibt es von mir eine 7 mit dem klaren Hinweis, dass ich die Schulung für Menschen mit anderem Lernmodus durchaus bei 9-10 sehen würde. Darüber hinaus halte ich eine derartige Schulung für ganze Scrum Teams durchaus für förderlich, speziell wenn sich Fallbeispiele und Themen mitbestimmen lassen. Es bleibt ein positiver Rückblick mit kleinen Makeln und dem Ratschlag, dass auch das Seminar das Lesen entsprechender Fachliteratur nicht ersetzt (vice versa!).

4 Akronyme für Scrum

Diese 4 Akronyme sind hilfreiche Eselbrücken in Scrum.

 

MoSCoW

• M – Must have this requirement to meet the business needs
• S –  Should have this requirement if possible, but project success does not rely on it
• C –  Could have this requirement if it does not affect anything else in the project
• W – Would like to have this requirement later, but it won’t be delivered this time

 

Mit der MoSCoW Methode werden die Stories im Product Backlog in 4 grobe Priorisierungen aufgeteilt. Das ist v.a. bei der Initialisierung des Product Backlog und bei der Release Planung hilfreich.

Sind beispielsweise alle Product Backlog Items aus dem Bereich Must Have implementiert, könnte ggf. das Produkt einen so hohen Business Value haben, dass ein öffentlicher Release möglich ist.

Bedenkt aber, dass es sich nur um eine erste grobe Einteilung handelt und trotzdem jedes Item früher oder später eine eindeutige Priorisierung erhalten muss.

 

 

 

Deep

• D – Detailed Appropriately
• E – Estimated
• E – Emergent
• P – Prioritized

 

Das Deep Akronym ist im Kontext des Product Backlog und welche Merkmale dieses aufweisen sollte hilfreich. Die Begriffe sprechen für sich.

 

 

 

Invest

• I – Independent
• N – Negotiable and Negotiated
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

 

Mit dem Invest Akronym wird festgehalten, wann User Stories “wohlgeformt” sind. Denkt daran, dass eine User Story ein “Versprechen für eine Konversation” darstellen soll.

 

SMART

• S –  Specific
• M – Measurable
• A – Achievable
• R – Relevant
• T – Time-boxed

SMART als Akronym gibt es in vielen Kontexten, unter anderem bei Mitarbeitergesprächen. Dabei macht es immer eine Aussage darüber, wie Ziele formuliert sein sollen. Wenn es bei Scrum also um Ziele geht, z.B. dem Sprint Goal, dann findet man in diesem Akronym Hilfe.

 

Die Sache mit den Entscheidern – Lean Management

Im ersten Teil habe ich mich mit Pair Programming beschäftigt. Auf dem .NET Open Space Süd kam natürlich auch das Dauerbrennerthema agiles Projektmanagement auf. Deshalb geht es in diesem Artikel genau darum, d.h. nicht um Scrum als eine Ausprägung davon, sondern um die Konzepte dahinter und wie sich diese den verantwortlichen Stellen verkaufen lassen.

Persönlich denke ich, dass sich die Ideen dahinter auch zum großen Teil umsetzen lassen, ohne dass der Prozess vollständig implementiert werden muss. Das könnte die Basis für eine offene Diskussion sein, denn viele Projektmanager (PMs) winken bereits ab, wenn sie Begriffe wie Agilität und Scrum hören.

Fangen wir doch mit dem Work In Progress (WIP) an: Statt an 10 Projekten gleichzeitig zu arbeiten, die erst nach 10 Monaten einsatzbereit sind, ist es betriebswirtschaftlich gesehen immer sinnvoller, ein Projekt nach dem anderen zu realisieren. Bündelt man die Arbeitskraft, wäre je ein Projekt nach einem Monat fertig (vereinfachte Rechnung…), sodass beispielsweise 3 Module nach 3 Monaten effektiv eingesetzt werden und Kosten eingespart bzw. Gewinne maximiert werden könnten. Diese Argumentation dürfte einfach zu gewinnen sein, wenn denn der PM rudimentäre Kenntnisse im Projektmanagement besitzt.

Bei der Projektplanung wird nicht über die innere Qualität diskutiert, d.h. Debatten wie ‘dann machen Sie es erst einmal Quick and Dirty, damit wir Zeit sparen’ entfallen. Mit der Fachabteilung wird lediglich der Umfang verhandelt, sprich wenn Zeit eingespart werden soll, dann nicht durch schlechteren Code, sondern durch weniger Features. Diese Diskussion könnte schon schwieriger zu gewinnen sein. Wenn der PM über längere Berufserfahrung verfügt, dürfte eine ehrliche Betrachtung der Vergangenheitswerte ihn aber ebenfalls zur Einsicht bringen. In jedem Fall – auch unabhängig von der Praxiserfahrung – können hier Beispiele aus dem privaten Leben fruchten: Wenn das Auto nur provisorisch repariert wird, dann folgt das böse Erwachen meistens früher als später.

Regelmäßige Meetings (alle 1-2 Wochen) ergeben sich allein schon aus der schnellen Entwicklung der geschäftlichen Prozesse. Wer aber auch hier Überzeugungsarbeit leisten muss, der könnte sich von dem PM bzw. der Fachabteilung das Spiel Tic Tac Toe erläutern lassen. Mir scheint es unrealistisch, selbst bei diesem einfachen Szenario, dass immer an alles gedacht wird. Was passiert, wenn ein Spieler gewonnen hat? Soll automatisch ein neues Spiel gestartet werden, soll eine Gewinnmeldung ausgegeben werden, etc.. Hierzu gibt es einen Artikel in der dotnet pro, in welchem besagtes Spiel auseinander genommen und aus diesem Kontext heraus beleuchtet wird. Viele der Fragen tauchen erst im Verlauf der Entwicklung auf, sodass ein großes Meeting, in welchem alles besprochen werden kann, zw. unrealistisch bis unmöglich schwankt.

Planungssicherheit ist ein Schlagwort, welches im Kontext des Wasserfallmodells völlig fehl am Platze ist. Welches Projekt, das auf 2, 5 oder 10 Jahre angelegt war, konnte tatsächlich die Rahmenplanung (Kosten, Zeit) einhalten. Die Zahl dürfte gegen 0 gehen. Vergangenheitsbetrachtungen dürften hier auch schnell Aufschluss geben. Es existieren keine Referenzprojekte? In der Tagesschau hört man wöchentlich von solchen, sei es nun der Bau eines neuen Flughafens oder die Einführung eines Mautsystems. Durch die kurzen Iterationen erreicht man schnell (meistens innerhalb von 8-12 Wochen) einen guten Eindruck dafür, was innerhalb von 2 Wochen erreichbar ist. Was scheint nun plausibler? Eine Planung, die auf Vergangenheitswerten beruht und die vom Kleinen ins Große rechnet oder der umgekehrte Weg, bei welchem 2 Jahre angesetzt werden und dann muss das Projekt abgeschlossen sein? Lieber den Spatz in der Hand oder die Taube auf dem Dach?

Zusammenfassend lässt sich sagen, dass es vielleicht langfristig mehr von Erfolg gekrönt ist, wenn sukzessive einzelne Punkte aus dem agilen Projektmanagement integriert werden, ohne diese vor dem PM als agil zu deklarieren. Wenn dann sowieso bereits zu 50% nach der entsprechenden Ideologie gehandelt wird, wäre ein Scrum Buch vielleicht das passende Geburtstagsgeschenk für den PM. Beim Lesen sollte es ihm/ihr dann wie Schuppen aus den Haaren fallen. Idealerweise hält der PM dann eure Idee noch für seine eigene…

Die Sache mit den Entscheidern – Pair Programming

Vergangenes Wochenende war wieder .NET Open Space Süd in Karlsruhe. Es zeichnete sich das gleiche Bild ab wie bereits in Leipzig 2011: Ein steigender Teil der Entwickler ist unzufrieden. Als Hauptursache meine ich folgende Punkte identifiziert zu haben:

• Innovationen werden durch den CIO/CTO gänzlich abgelehnt
• Neue Wege werden von der GL nur halb mitgegangen, solange sie noch “angenehm” zu gehen sind
• Frische Ansätze werden vorsätzlich sabotiert, z.T. durch das Team

Dementsprechend trifft das dann die sogenannten “schöpferischen Zerstörer” (Buchreferenz fehlt mir aktuell), d.h. kreative, innovative Menschen, die den Status Quo und all seine negativen Mitbringsel aufbrechen wollen.

Betrachtet man die letzten Jahre, so hat sich vieles getan. Zum einen im Prozess- und Projektmanagement, als auch in den dazu passenden Werkzeugen. Zu nennen wäre die Ausrichtung am Lean Management, z.B. in Form von Scrum, oder Continuous Integration (bzw. Continuous Deployment) durch einen Build Server. Clean Code – heutzutage in aller Munde – besagt nicht viel mehr, als dass man sich ständig weiterbilden und Softwareentwicklung als Handwerkskunst verstehen muss.

Stand heute stehen viele Vorgesetzte respektive Entscheider – sei es nun der IT Abteilungsleiter oder Geschäftsführer -  dieser Bewegung entweder skeptisch oder gänzlich ablehnend gegenüber. Warum auch CIOs eine derartige Haltung einnehmen, ist für mich bis dato nicht nachzuvollziehen. Schließlich sind die Stellenanforderungen an diese Position primär Kreativität, innovatives und prozessorientiertes Denken, sowie ausgeprägtes Business Alignment.

Deshalb möchte ich in den nächsten Wochen hin und wieder Punkte aufgreifen, welche typischerweise von Entscheidern mit in der Regel altbackenen Argumenten abgelehnt werden. Heute befasse ich mich mit Pair Programming:

Hier ist natürlich als Gegenargument zu hören, dass es betriebswirtschaftlich keinen Sinn macht, wenn zwei Personen an der gleichen Aufgabe arbeiten. Genauer gesagt würde ja nur einer arbeiten und der andere schaut dabei zu. Aber gerade Pair Programming ist ein Musterbeispiel dafür, wie falsch solche Aussagen von entsprechenden Stellen sein können!

Inselwissen ist sicherlich in jeder Firma ein Problem – teilweise vielleicht so groß, dass die Geschäftsleitung gar keine Vorstellung davon hat! Wenn immer zwei Personen an einem Stück Code schreiben, ist dem von Anfang an Einhalt geboten. Wird beim Pair Programming auch noch regelmäßig durchgewechselt, was sich für Teams ab einer Größe von 4 Personen immer anbietet, so ergeben sich weitere Synergieeffekte, da z.B. das Gesamtverständnis für das System gefördert und Doppelentwicklungen vermieden werden.

Als nächster Punkt wäre anzumerken, dass dadurch quasi eine kostenfreie Schulung stattfindet. Nach meiner Erfahrung bietet selbst der einfachste Code Gelegenheit für neues Detailwissen. Als Beispiel diene das Schlüsselwort checked für die Addition zweier Integer-Werte. Darüber hinaus hat jeder Developer sein Spezialgebiet, in welchem er dem Kollegen Wissen vermitteln kann.

Und noch ein Argument darf aus betriebswirtschaftlicher Sicht nicht fehlen: Der Code wird “besser”, d.h. Arbeitszeit für Refactoring, Neuprogrammierung und Nachbesserung wird eingespart. Fehler die früh aufgedeckt werden, sparen bare Münze! Ein toller Spruch hierzu kam am Open Space ebenfalls: Für das Programmieren wird eine Gehirnhälfte im Menschen beansprucht, d.h. wenn zwei Entwickler am selben Problem arbeiten, hat man ein vollständiges Gehirn, welches sich dem Problem annimmt.

All about Scrum

 

Hier ein paar gute Scrum Artikel:

• http://goo.gl/3Ddnu
• http://goo.gl/hy1LG
• http://goo.gl/Lgwdl
• http://goo.gl/x5qT