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

Wie mittelständische Unternehmen ihre Produktentwicklung um das 100-fache beschleunigen

Vorweg: Die Zahl 100 ist frei erfunden, aber jetzt, wo du schon mal da bist, kannst du trotzdem weiterlesen und am Ende gerne einen Kommentar hinterlassen.

Rollen bei der Softwareentwicklung

Während Konzerne ganze Teams von Business Analysten mit entsprechendem akademischem Background haben, sind kleine und mittelständische Unternehmen (KMUs) weniger breit aufgestellt. Das trifft genauso auf die Größe des Entwicklerteams zu: Dedizierte Software-Architekten und Development Leads gibt es nur selten. Das rechte Bild zeigt einige der Rollen im Entwicklungsprozess von Software (aus diesem hervorragenden Video von Pluralsight entnommen). Deshalb gilt es zu analysieren, wer im Unternehmen welche Kompetenzen besitzt und wo es zu Engpässen kommt. Die Grenzen der Rollenübergänge sind aufgrund der fehlenden dedizierten Rollenbesetzung fließend und werden deshalb häufig von mehreren Personen übernommen.

Das trifft speziell auf die Rolle des Business Analysten zu. Während Wikipedia eine lange Liste von Aufgaben für diesen definiert, will ich meine Sicht – oder besser meine Vision – darlegen, auf welchen Personenkreis die Aufgaben in KMUs aufgeteilt werden müssen. Denn wenn diese Rolle im Unternehmen sinnvoll implementiert wird, ergibt sich ein gewaltiges Optimierungspotential. Generell muss das aber unternehmensspezifisch nach Kompetenzen und Verfügbarkeiten der Mitarbeiter geregelt werden. Diese gilt es kontinuierlich weiterzuentwickeln.

Zukunft des Anwenders

Fachexperten (in der Grafik Subject Matter Expert genannt) sind die eigentlichen Anwender des jeweiligen Geschäftsprozesses. Will man also wissen, wie das Versenden eines Packstückes abläuft und wo es dabei zu Problemen kommt, dann wäre der Lagerist der richtige Ansprechpartner. Deshalb sollte er es auch sein, der den Prozess im Unternehmenswiki festhält. Ein Wiki deshalb, weil es sich einfach nutzen lässt und einige wenige Regeln genügen, um es erfolgreich mit Inhalten zu füllen. Außerdem ist es die Grundlage, um neben dem Prozess Know How weiteres Inselwissen zu erfassen.

Zukunft des Product Owners

Die Koordination, den Überblick über Domänengrenzen hinweg, die Konsolidierung der Informationen und das Überführen von Anwenderwünschen siedle ich beim Produktverantwortlichen (Product Owner bei Scrum) an. Mit steigender Kompetenz und mit steigendem Wissen der Anwender können selbige immer mehr Verantwortung und Aufgaben übernehmen, z.B. das Formulieren der eigenen Wünsche in das Issue Tracking System (Backlog in Scrum). Der Product Owner wird dann stärker zum Koordinator, der das Big Picture und die Vision vorantreibt, der eher in Innovationen statt Evolutionen denkt und der Anforderungen (Achtung: Wunsch != Anforderung) noch besser herausarbeitet. In dem Zuge sind Akzeptanzkriterien zu nennen. Eines könnte lauten:

Wenn eine Rechnung abgeschlossen wird,

• dann lässt sie sich nicht mehr verändern
• dann wird sie automatisch an die Rechnungsabteilung geschickt
• dann wird die Marge es Auftrags berechnet

Zukunft des Entwicklers

Und zu guter Letzt kommen wir noch auf den Entwickler zu sprechen: Je weniger er in die Ausarbeitung von Anforderungen, fachlichen Lösungsansätzen und Modellierungen stecken muss, desto mehr Zeit kann er in gute Softwarearchitektur stecken. Und eine gute Architektur ist der Schlüssel für gute, adaptive und skalierbare Produkte. Die Grenze, wo die Aufgaben des Product Owners aufhören und die des Entwickler anfangen, ziehe ich an der Stelle, wo es einer entsprechenden Ausbildung bedarf – und sei es nur 1. Semester Informatik im Rahmen des BWL-Studiums. Ob der Datentyp Integer werden soll oder ob eine Enum die bessere Wahl für eine Auswahlliste ist, das entscheidet der Entwickler. Bei Fragen nach gültigen Wertebereichen, z.B. ob als Gewicht für einen Artikel 0 Kg zulässig sind, das kann der Produktverantwortliche mit steigender Kompetenz früher oder später gleich mitgeben. Hier bedarf es aber immer der sorgfältigen Prüfung des Entwicklers, dem sich solche Fragen naturgemäß eher erschließen. Hingegen ist der Product Owner immer für das Entwerfen der fachlichen Lösungsansätze verantwortlich, denn nur er hat den Überblick über den Geschäftsprozess und wie dieser mit anderen Prozessen interagiert. Für ein konkretes Beispiel kannst du diesen Beitrag lesen.

Fazit/Vision

Anwender sollte man in den Produktentwicklungsprozess einbinden. Mit steigender Erfahrung können sie mehr Aufgaben übernehmen und helfen, die Entwicklung zu beschleunigen und das Produkt noch besser zu machen. Transparenz, größere Akzeptanz, besseres Verständnis und die Reduzierung von Inselwissen sind nur einige wichtige Nebeneffekte. Ein Feature, sei es noch so gut, welches aufgrund von Ablehnung nicht genutzt wird, ist wertlos. Ein Prozess, egal wie gut durchdacht er ist, um den aber herumgearbeitet wird, produziert mehr Probleme als dass er löst.

Im Gegenzug kann der Produktverantwortliche mehr Zeit in Innovationen und bessere Anforderungen stecken, die zu besserer Softwarearchitektur und niedrigeren Entwicklungskosten führen. Das Ergebnis ist eine schnellere Entwicklung eines passgenaueren Produkts mit weniger Fehlern und höherer Qualität.

Der Entwickler wiederrum kann sich auf eine solide Infrastruktur konzentrieren, die zum Einen schnelle und einfache Anpassungen ermöglicht, zum Anderen entsteht Zeit für das Automatisieren von regelmäßigen Abläufen. Durch automatisierte Tests (durch gute Akzeptanzkriterien) lässt sich das Gros der Arbeit der Tester übernehmen (siehe Rolle in der Grafik oben). Ein Continuous Deployment System macht händisches Deployment überflüssig. Trainings reduzieren sich auf ein Minimum, weil die Fachabteilung von Anfang an in die Prozessumsetzung eingebunden wurde.

Wie haltet ihr das bei euch? Schreibt mir eure Erfahrungen in die Kommentare. Wie weit die Transformation bei heco fortgeschritten ist, erzähle ich in diesem Beitrag (Link folgt noch).

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.

Schlanke Prozesse sind gute Prozesse oder warum wir Kanban einführen

In unserer IT Administration führen wir regelmäßige Retrospektiven durch. Das ermöglichte es uns Kategorien von Problem zu identifizieren, wie sie auf dem Bild zu sehen sind.

• Weniger wichtige Aufgaben wurden zuerst erledigt (Priorisierung)
• Vermeintlich kurze Projekte haben sich stark in die Länge gezogen
• Aufgaben wurden nicht vollständig erledigt
• Zuständigkeiten / Ansprechpartner waren nicht klar
• Aktuelle Projektstände waren nicht transparent
• Aufgaben blieben bei Externen hängen bzw. blockierten uns
• Engpässe / Verzögerungen machten uns das Leben schwer
• Planung war schwierig
• Häufiges “auf einen Stand bringen” und mehrfaches Besprechen gleicher Punkte

Die Systemadministration ist von Natur aus ein stark vom Tagesgeschäft abhängiges Umfeld mit viel Klein-Klein-Arbeit. Der Anwender ruft an, meldet PC Probleme (Spezifisches hört man selten), der Kollege unterbricht seine eigentliche Tätigkeit wie z.B. die Vorbereitung einer größeren Umstellung und kümmert sich um die Nöten des besorgten Anrufers. Kaum zurück und wieder in die Umstellung vertieft, kommt eine E-Mail, dass die Druckertoner leer sind. Erneut gilt es die aktuelle Arbeit zu unterbrechen.

Darüber hinaus laufen natürlich immer Projekte mit anderen Abteilungen oder Externen (Telekommunikationsanbieter, Dienstleister, etc.), die voran getrieben werden müssen. Selbst der Entwickler-Kollege aus der selben Abteilung ruft an und möchte einen neuen Testserver aufgesetzt bekommen – am besten vorgestern versteht sich.

Kurzum: Ein reges Tagesgeschäft parallel zu großen Projekten und das alles im Umfeld von unterschiedlichen Stakeholdern. So wie es auch in Marketingabteilungen oder Zentralen der Fall ist.

Nüchtern betrachtet handelt es sich um eine Warteschlangensystem. Da Menschen nicht gut darin sind viele Dinge parallel zu machen, vermuten wir hierin eine der Ursachen: Zu viele Dinge werden gleichzeitig erledigt. Außerdem stehen wir Dritten skeptisch gegenüber, welche uns rein gefühlsmäßig ausbremsen. Bei den Telekommunikationsanbietern können wir indes von einer Tatsache sprechen…Darüber hinaus meinen wir diverse weitere Hindernisse erkannt zu haben, die den Arbeitsfluss immer wieder stören.

Um weil wir uns gerne verbessern möchten, eine zu große Umstellung auf einmal eher scheuen und der Evidenz der Vermutung den Vortritt geben möchten, haben wir uns entschieden Kanban einzuführen. Auf einen Nenner gebracht liegen dem 3 Prinzipien und 5 Praktiken zu Grunde.

Prinzipien:

• Starte mit dem, was du jetzt machst
• Verfolge inkrementelle, evolutionäre Veränderungen
• Respektiere initiale Prozesse, Rollen, Verantwortlichkeiten und Job-Titel

Praktiken:

• Mache Arbeit sichtbar
• Limitiere den WIP
• Manage den Arbeitsfluss
• Mach Prozess-Regeln explizit
• Führe gemeinschaftliche Verbesserungen durch (basierend auf Modellen)

Alle Regeln werden penibel eingehalten, jedoch ist die erste Regel alle Regeln abzuschaffen, die nicht mehr funktionieren.

Über die ersten Ergebnisse werde ich demnächst berichten. Falls jemand schon gute Erfahrungen primär im Administrationsumfeld gemacht hat, dann würde ich mich über Input freuen. Gerne auch aus der Softwareentwicklung.

Regelwerk und Beispiele für die eigene Retrospektive

Bei uns führt jeder IT-ler täglich seine eigene Retrospektive durch. Für neue Mitarbeiter will ich in diesem Blogbeitrag festhalten, was wir darunter verstehen. Statt die Information in unserem internen Wiki zu persistieren, wollte ich sie öffentlich machen, damit gegebenenfalls Andere davon profitieren können. Eine letzte Anmerkung für Außenstehende: Natürlich führen wir zusätzlich noch Team bzw. Sprint Retrospektiven durch, die sich zum Teil erheblich unterscheiden.

 

Regelwerk

• Die Retrospektive ist ein Werkzeug aus unserem Werkzeugkasten zur kontinuierlichen Verbesserung
• Eine Retrospektive ist eine Reflexion, bei der der Tag nochmal in Gedanken durchgegangen wird. Eine feste Dauer gibt es nicht, da jeder Tag anders ist. Aber um eine Orientierungshilfe zu nennen: 10-30 Minuten.
• Idealerweise wird die Retrospektive immer am Ende eines Tages gemacht, weil die Erinnerungen noch frisch sind. Eine feste Vorgabe gibt es jedoch nicht. Es ist genauso möglich täglich mehrmals Notizen festzuhalten oder frisch ausgeruht am Morgen des Folgetages zu reflektieren.

Was ist festzuhalten?

• Sowohl das Gute, als auch den Verbesserungsbedarf. Jedoch nicht nur das Problem an sich, sondern möglichst gleich eine entsprechende Lösung.
• Wenn ich selbst etwas Neues probiert habe und es gut funktioniert hat, dann könnte eine Schlussfolgerung lauten, die Vorgehensweise meinen Kollegen zu empfehlen. Eine weitere könnte lauten, dass es sich lohnt noch mehr Zeit in die Optimierung bzw. das Testen zu stecken, um noch mehr herauskitzeln zu können
• Bei negativen Punkten ist zu unterscheiden, ob es sich um regelmäßig benutze Ansätze respektive auftretende Verhaltensweise handelt oder ob es ein einmaliges Problem war
• Wenn es regelmäßig auftritt, sollte es in jedem Fall festgehalten und über eine Lösung nachgedacht werden. Im Zweifel kann es in die Team Retrospektive eingebracht werden, um Hilfestellung zu bekommen. Oder es könnte sich um das Verhalten des Kollegen handeln, welches negative Konsequenzen für die eigene Arbeit mitbringt. Dann könnte eine Schlussfolgerung sein dies zunächst unter 4 Augen zu klären.
• Bei einmalig aufgetretenen Problemen sollte jeder selbst entscheiden, ob es sich ein Eintrag lohnt. Bei einem menschlichen Fehler, der einmalig und unter einer einmaligen Konstellation auftrat, ist das vermutlich wenig zielführend. Allerdings hängt es auch ein wenig von den Konsequenzen ab. Vergesse ich beispielsweise beim Gehen das Abschließen und Sichern des Firmengebäudes, so kann ich – oder eben nicht – selbiges notieren und z.B. darüber nachdenken eine kleine Checkliste am Monitor zu befestigen. Auf der könnte übrigens dann auch stehen, dass die abendliche Retrospektive durchzuführen ist.

Beispiele

• Vergesse ich als Schüler, der ich ca. 1x in der Woche bei einem Betrieb jobbe, mehrfach meine meine Retrospektive durchzuführen oder mir meine Arbeitszeit per Unterschrift bestätigen zu lassen, dann kann ich mir die oben erwähnte Checkliste an meinem Arbeitsplatz (am besten auf Augenhöhe) befestigen.
• Verstoße ich als Entwickler gegen das Don’t Repeat Yourself-Prinzip, dann notiere ich das. Stelle ich nach einem Monat fest, dass das häufig vorkommt, überlege ich mir, woran es liegt. Arbeite ich z.B. viel mit Copy & Paste, so könnte ich z.B. für 1-2 Wochen in meiner IDE die Tastenkombination STRG+C umstellen.
• Vergesse ich als Administrator regelmäßig E-Mails an Externe, weil der Empfänger sich nicht von alleine meldet, so kann ich mir in Outlook auf die gesendete E-Mail einen Reminder setzen.
• Verbringe ich als Vorgesetzter den Großteil meiner Zeit in Meetings, so sollte ich selbige vielleicht analysieren. Unproduktive Meetings lassen sich mit einfachen Mitteln deutlich verbessern (vgl. meinen Artikel Wir arbeiten timeboxed). Eine weitere Möglichkeit ist es alle Meetings auf einen Tag zu legen oder an bestimmten Tagen / zu bestimmten Uhrzeiten gar keine Meetings anzusetzen.

Aus unserer täglichen Retrospektive berichte ich hier. Natürlich ist die Retrospektive ein sehr weites Feld und das oben genannte Regelwerk nur ein Tropfen auf den heißen Stein. Aber für den Einstieg reicht uns das. Der Rest kommt über Gespräche darüber und beim täglichen Reflektieren.

Wie hält es der Leser? Sind Retrospektiven bei euch in der Firma fest im Prozess etabliert? Nur bei Scrum oder auch in Eigenregie? Wollen die Kollegen sich überhaupt weiterentwickeln?

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.

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