Agilophil-Daily Podcast Episode 17 – Shu-Ha-Ri

Scrum, Kanban, Lean Manufacturing – diese Dinge haben ihre Wurzeln in Japan, beziehungsweise bauen auf japanischen Traditionen und Werten auf. In der Geschichte von Scrum und agilem Arbeiten hat sich daher eine sehr starke Verbindung zu Japan und zur japanischen Sichtweise ergeben. Das soll natürlich nicht heißen, dass Scrum oder agiles Arbeiten eine japanische Erfindung sei…Viele von diesen Traditionen kommen in anderen – und natürlich auch in unserem Kulturkreis genauso vor…Das Thema der heutigen Folge ist das SHU-HA-RI…

Das Shu-Ha-Ri-Konzept

Der Begriff SHU-HA-RI kommt – wie gesagt –  aus Japan und wird heute meist in Verbindung Kampfsport also AIKIDO oder KARATE gebracht, Dieses alte japanische Konzept des Lernens soll auf KAWAKAMI FUHAKU zurückgehen der im 18.Jhdt lebte (1719-1807) . Es beschreibt die drei Lernstufen zur Meisterschaft. 

Shu-ha-ri heisst übersetzt: “ erst lernen, dann loslösen und endlich übertreffen“.

Und es beschreibt den dreistufigen Prozess zur Erlangung der Meisterschaft, den wir in Deutschland so ähnlich auch als „Lehrling, Geselle, Meister“ kennen. (um mal die älteren deutschen Bezeichnungen dafür zu verwenden), wir durchlaufen also 3 Status um zum Meister zu werden

Die Begriffe selbst bedeuten hier

SHU = KOPIEREN, oder das Lernen der Form

          HA  = ABWEICHEN, oder das Überschreiten der Form

              RI  = FREIE VERWENDUNG, oder eigene Wege finden

Doch grau ist bekanntlich alle Theorie: hier mal ein paar Beispiele, was das bedeutet:

Nicht nur in Japan oder Deutschland sind diese drei Schritte bekannt – gehen wir mal gedanklich nach Westen nach Mexiko…dort gibt es eine Tradition, die sich seit den 40er Jahren zum Touristenmagnet entwickelt hat, die Clavadistas. So werden die Klippenspringer von La Quebrada in Acapulco genannt…Du hast bestimmt von ihnen gehört – der Felsen, von dem sie runterspringen ist ungefähr 35 Meter hoch und fällt nicht senkrecht ab, sondern leicht geneigt in eine Schlucht, die unten nur 7 Meter breit ist. Die Neigung bedeutet, dass der Felsen unten ca. 3,5 m vom Absprungspunkt entfernt ins Wasser geht..Das Wasser dort ist nur wenige Meter tief, so dass der richtige Moment der Brandung abgewartet werden muss um nicht auf den Boden aufzukommen. Man muss also mindestens 4 Meter weit abspringen und den richtigen Moment erwischt haben, um den Sprung zu überleben oder nicht zumindest eine schwere Verletzung zu riskieren…Warum machen die Leute das? Nun ja – wie so oft – früher – also vor den 1930er Jahren war es schlicht eine Mutprobe für die jungen Männer, die sich daraus ergeben hatte, dass früher die Fischer vom Felsen ins Wasser sprangen um verhedderte Angelschnüre zu befreien – das haben sie natürlich nicht von oben gemacht sondern von viel weiter unten – aber die Mutprobe lag ja dann nahe einfach mal zu probieren, ob das auch von weiter oben funktioniert. Heutzutage ist Klippenspringer in Mexiko ein anerkannter Beruf und die Ausbildung ist langwierig…Was meinst Du, auf welcher Höhe die jungen Klippenspringer beginnen? 10meter? 5 meter? 3 meter? – nein. Auf einem halben Meter…Wochenlang üben die Jungs den Absprung ins Wasser – man muss es im Schlaf können, die Technik muss absolut sitzen – schließlich muss man in jedem Fall die Entfernung von 4 Metern überbrücken, um zu überleben…Und lebensmüde sind die Clavadistas nicht – sie sind Meister ihres Fachs…Der Anfang ist das Fundament – der SHU-State: Stand, Sprungkraft, Haltung in der Luft, das wird über Monate trainiert. Die nächste Stufe ist bei 3metern – und das wird nochmal für mindestens 6 Monate trainiert – erst wenn die Technik perfekt sitzt, dürfen die jungen Springer höher und nach 3-5 Jahren springen sie vom obersten Punkt…sie haben dann die Stufe des Meisters erreicht…

Wenn wir also uns die Entwicklung dieser – ich nenne es mal – Kunst vorstellen, dann haben die jeweiligen Meister ihres Fachs es vollbracht immer weiter höher zu steigen, bis sie in der Lage waren vom obersten Punkt des Felsens zu springen. Und dieses Wissen haben sie dann an die nächsten Generationen weiterzugeben. Der RI-State war jeweils Voraussetzung für die Weiterentwicklung der Fähigkeit. Basis war der SHU-State.

Gehen wir mal ein paar Jahre zurück und wieder nach Europa – Wir machen eine kleine Zeitreise ins Jahr 1860 – zu einem Mann nahmens Edouard Manet. Edouard war Maler im Paris in der Mitte des 19.Jahrhunderts.  Man muss sich das mal vorstellen: in einer Zeit, in der es weder Fotografie noch Filme gab, war die Malerei ein beliebtes Mittel für Kopfkino…neben der Literatur natürlich – es wurden Bilder gemalt, die Geschichten erzählten, oder Handlungen, Dinge und Orte detailgetreu darstellten…Mitte des 19. Jahrhunderts war Paris das Zentrum der Kunstwelt und der Maler stand als Beruf auf einer Stufe mit dem Arzt oder Juristen. Die Maler durchliefen eine jahrelange Ausbildung an der Schule für bildende Künste in der sie mit dem Abmalen von alten Meistern begannen und nach vielen Jahren mit Aktmalerei abschlossen – Edouard Manet, den man heute als Wegbereiter der modernen Malerei ansieht, war einer von ihnen. Eine jährlich stattfindende Ausstellung im so genannten „Salon“ war sozusagen die Weltausstellung und Casting-Show der damaligen Kunstwelt. Die Ausstellung dauerte 6 Wochen und es kamen bis zu einer Million Besucher um sich die Werke anzusehen. Die besten Werke wurden mit Medaillen ausgezeichnet und die unerbittliche Jury entschied, welche Bilder in den erlauchten Kreis der Ausstellung aufgenommen oder welche abgelehnt wurden…Wer es in die Ausstellung schaffte war ein gemachter Mann – für die Siegerbilder schossen die Preise in die Höhe. Wer nicht vertreten war und abgelehnt wurde, konnte sich die Kugel geben…was einige Maler auch tatsächlich nach ihrer Ablehnung realisierten…Natürlich waren alle Maler hier in dem Ri State – sie hatten die Grundlagen von der Pike auf gelernt, waren mit allen Techniken vertraut und konnten sie perfekt umsetzen. Warum ich das hier erzähle? Edouard Manet, der mit einigen Freunden Meister seines Fachs war, wagte es   sich vom Mainstream abzuwenden und eine eigene Kunstausstellung zu eröffnen und einen neuen Malstil zu begründen – den Impressionismus – einen Stil, der mit grobem Pinselstrich und ohne feine Details auskam und somit die etablierte Kunst veränderte. Heute hängen die Bilder der modernen Maler in allen großen Museen und sind Millionen wert…Der Meister – im RI-State – ist in der Lage neue Wege zu gehen. Aber das auf der Basis seiner Meisterschaft. Es ist ja nicht so, dass er nicht „fein und detailliert“ malen konnte!…Pablo Picasso, der mit seinen unförmigen Portraits bekannt geworden ist, konnte „normale Bilder“ malen, die Technik hatte er drauf. Aber durch seine Meisterschaft hat er über die Grenzen der reinen Abbildung geschaut und neue Welten und Interpretationen geschaffen, die voher so nicht existierten…

Und Arien Robben – wer kennt nicht den Robben Move, den er über 10 Jahre lang ausgeführt hat, und der die gegnerischen Verteidiger bis an sein Karriereende zur Verzweiflung gebracht hat. Jahrelang hat der kleine Arien geübt und auch im Zenit seiner Karriere hat er jeden Tag 30min nach dem offiziellen Training diesen Move und Schuss trainiert. Jeden Tag über mehr als 10 Jahre hinweg…

Die Erkenntnis daraus ist…es ist noch kein Meister vom Himmel gefallen (altes deutsches Sprichwort…): Wir brauchen Zeit für die Entwicklung, wir dürfen nicht zu ungeduldig sein…

Der Shu-State: bedeutet viel Demut – ich schaue zu und ahme nach. Ich erkenne an, dass es bistimmte Dinge gibt, die ich erstmal lernen muss, bevor ich die Welt verändern kann. Und ich erkenne an, dass ich noch nicht von anfang an alles verstehen kann, manches Verständnis kommt erst mit der ständigen Wiederholung. 

Der Ha-State: bedeutet sein Selbstbewusstsein aufbauen: Ich wende an und kann es und erreiche die gleiche Qualität wie der Meister selbst. Der Bauplan kommt vom Meister aber ich habe die Fähigkeit meinen Stuhl in derselben Qualität und Güte zu bauen, wie er. Und ich erlaube mir erste Experimente etwas zu verändern – in gewissen Grenzen, die noch vom Meister vorgegeben werden. Mit der Gewissheit es zu können werde ich mutiger und kann neues Entdecken – ich steige sozusagen den Fels etwas höher…mit der Erlaubnis des Meisters, der immer noch über mich wacht..

Der Ri-Status: bedeutet Souveränität, Freiheit und Kreativität: Ich kenne den Rahmen und verändere die Regeln und finde neue Wege zum Besseren. Auf Basis meiner jahrelangen Erfahrung kann ich Dinge so einschätzen, dass die Risiken absehbar oder ein völlig neuer Nutzen geschaffen wird. Ich gebe mein Wissen weiter und gebe den Jüngeren zuerst die Wurzeln und dann die Flügel um selbst später die Meisterschaft zu erreichen.

Fazit und Schwenk zurück auf die Agilität:

SHU ist die Stufe des Anfängers, hier schaffst Du dir ein sicheres Fundament – sieh es als eine Art Lebensversicherung an. Wenn das Fundament nicht steht, wackelt das Haus ein Leben lang…Das Fundament erreichst Du durch Nachmachen des Gezeigten und Erklärten. Wenn Du oder ein Team im SHU-Status ist, ist es noch nicht reif für eigene Kreativität und es ist ratsam die Regeln einer agilen Methodik zu befolgen. Das ist kein Mangel, es ist nur ein Status. Viele Dinge werden erst durch Wiederholung klar und dahinter liegende Prinzipien erschließen sich erst mit der Zeit. Im SHU-State solltest Du dich darauf konzentrieren die Rituale, Meetings und Tools wie Backlog, Userstories, Taskboard oder Kanban-Board – Wip-Limits, Planungsmeeting, Dailies und Reviews und Retrospektiven zu etablieren und konsequent durchzuführen und zu optimieren. 

HA ist die Stufe, in der Du die Techniken beherrscht und nun beginnst die Hintergründe der Techniken und Formen zu hinterfragen und zu verstehen. Wenn Du oder Dein Team reifer in der agilen Arbeit mit Scrum oder auch Kanban ist und Du den HA-Status erreicht hast, kannst Du gewisse Regeln anpassen (brechen), um bessere Ergebnisse zu erzielen. Im HA-State geht es dann um Themen wie Struktur in der Arbeit, Kultur und Werte im Unternehmen, Verhalten untereinander und Führung/oder neudeutsch „Leadership“. 

In der RI-Stufe hast Du das Wissen Deines Lehrers vollständig aufgenommen und bist selbst zum Meister gereift. Es ist Dir nun möglich, dich von einem übergeordneten Standpunkt aus sozusagen aus der Vogelperspektive – von dem Bisherigen zu entfernen und deiner eigenen Auffassung über das agile Arbeiten zu folgen. Im RI-State ist das agile Unternehmen in der Lage neue Regeln zu definieren und beste Ergebnisse zu erziehlen. Wir betreten die Welt der lernenden Organisation. Ein Beispiel dafür ist Spotify…es wird nur oft vergessen, dass es eben die EIGENE Sicht von Spotify ist, die zum damaligen Zeitpunkt ein bester Weg war…Das heißt noch lange nicht, dass man den Spotify Weg auf andere Firmen in andern Entwicklungstufen übertragen kann…

Wenn Du in Deiner Firma den Weg zum agilen Unternehmen anstrebst, agiles Arbeiten mit Scrum oder Kanban einführen willst, dann tust Du gut daran erstmal dem Lehrbuch zu vertrauen. Erst wenn, du am eigenen Leib erfahren und gefühlt hast, wie sich Scrum oder Kanban anfühlen, welche Konsequenzen hinter dem befolgen von Regeln und Prinzipien stecken und wenn Du verstanden hast, was die zugrundeliegenden Werte wirklich bedeuten – erst dann wirst Du in der Lage sein, das System auch für Deine Firma weiterzuentwickeln. Ein „bei uns geht das nicht und wir müssen das erstmal anpassen“ ist wenig zielführend. Wenn Du ein System noch nicht verstanden hast und die Vorteile noch nicht gespürt hast, machst Du es ja kaputt, ohne den Nutzen jemals erfahren zu haben. Leider ist das ein Vorgehen, das sehr oft vorkommt und ich auch sehr oft bei meinen Kunden erlebe. Passe also die Regeln an wenn Du die Meisterschaft erreicht hast, wenn das Team viel Erfahrung gesammelt hat und ihr einen hohen agilen Reifegrad erreicht habt – dann ja – voher nicht.

Irgendwie kommt bei mir dann immer das Bild vom abgeholzten und verbrannten Regenwald hoch, den wir in unfruchtbares Ackerland verwandelt haben, ohne verstanden zu haben, dass die Heilmittel für verbreitete Zivilisationskrankheiten gebraucht hätten,  eigentlich in der Pflanzenart steckte, die wir gerade dummerweise ausgerottet haben, ohne sie vorher über haupt kennenzulernen…

Tja – dumm gelaufen…

Also – wir vermeiden das und blicken zuversichtlich in die Zukunft. Ich wünsche Dir viel Erfolg beim Erklimmen der Leiter zur Meisterschaft – ganz egal auf welcher Sprosse Du aktuell stehst.

Vielen Dank fürs zuhören 

Tschüß

dein agilophiler Frank

Agilophil-Daily Podcast Episode 15: Scrum und Disziplin

Herzlich willkommen zu einer neuen Folge von agilophil-daily – dem Podcast für agilophile Menschen – hier erfährst Du in jeder Folge interessante Dinge aus der Welt der Agilität…

Ich hole heute mal ein bisschen aus und mache einen Sprung in eine lang vergangene Zeit – 1985 und 86 war das bei mir – das Abi hatte ich gerade gemacht und es stand eine Zeit vor mir, die damals für jeden männlichen jungen Erwachsenen ein Thema war: Der 15 monatige Dienst am Vaterland…in Form von Wehrdienst oder Zivildienst…Ich muss zugeben, die Reifeprüfung hatte ich zwar abgelegt, aber so richtig „reif“ war ich zur damaligen Zeit noch nicht und daher habe ich mich wenig um das gekümmert, was so um mich herum vorging…und da man ja aktiv den Wehrdienst verweigern musste – und der Zivildienst dann auch noch 3 Monate länger ging, habe ich das nicht getan und bin halt dann zur Bundeswehr eingezogen worden…Ich landete bei der Luftwaffe in Goslar, was durchaus komfortabel war – verglichen mit dem Heer…

Damals gab es noch die deutsch-deutsche Grenze und ich wurde als „Radartiefflugmelder“ eingesetzt – bin also nicht geflogen (was bei einem Grundwehrdienst von 15 Monaten natürlich auch nicht vorgesehen war).. wir bewachten den Grenzverlauf im Harz an Stellen, wo das große Flugabwehrradar nicht hinkam – also in Tälern und landschaftlich abgeschirmten Gebieten. 

Wir hatten Schichtdienst und eines Nachts kam auch wirklich was auf meinem Radar an, was da nicht hingehörte und weder durch Vogelschwarm oder sich im Wind bewegende Bäume zu erklären war…Ich hatte eine Luftraumverletztung auf meinem Radarschirm…Ein Punkt – also ein kleines Flugzeug – flog unbeirrt vom Westen in den Osten…einfach so…

Nun lief das Prozedere ab – ich hab Meldung gemacht , den Flugverlauf mitgeplottet und aufgezeichnet und alles an die Zentrale weitergemeldet. Was die genau mit den Daten gemacht haben, war nicht wirklich wichtig…Wichtig war, dass alle Informationen von mir transparent an die übergeordnete Stelle gemeldet wurde. Das war mein Job

Was hat das Scrum oder Agliliät zu tun, fragt Du dich sicherlich?

Naja – agile war das schon – den Agil heißt nunmal nicht chaotisch. Agilität  und agile Methoden brauchen einen klaren Rahmen, innerhalb dessen sich das Team bewegt und da auch seine Kreativität ausleben kann. Agilität braucht Transparenz – alle Informationen müssen unverfälscht und möglichst in Echtzeit verfügbar sein. Und es braucht einen klaren Ablauf und eine Struktur – wie man insbesondere an Scrum gut sehen kann (aber natürlich auch in Kanban oder im Design Thinking). Es braucht auch eine schnelle Identifikation von Problemen – also Aufmerksamkeit. Der Vorfall dauerte bei mir auf meinem kleinen Radar mit der geringen Reichweite nicht mehr als ein paar Minuten…den hätte man auch leicht übersehen können, wenn man halt nicht immer auf den Bildschirm sieht…und damit bin ich beim heutigen Thema – einem Wort, was vielleicht nicht mehr so ganz in den Zeitgeist passt – der Disziplin…

Was bedeutet das? Und was bedeutet das im Zusammenhang mit Agilität?

Bei Google habe ich folgende Definition gefunden: Disziplin: das Einhalten von bestimmten Vorschriften, vorgeschriebenen Verhaltensregeln o. Ä.; das Sicheinfügen in die Ordnung einer Gruppe, einer Gemeinschaft.

Klingt jetzt gar nicht mal so verkehrt, denn sich einfügen in eine Gemeinschaft ist ja auch etwas, was von Agilen Teams erwartet wird und was natürlich ein wesentlicher Erfolgsfaktor von agilen Teams ist. Jedes Team hat bestimmte Regeln – seinen sie ungeschriebene Gesetze oder vielleicht auch aufgeschrieben, wie die Definition of Done…Ohne eine gewisse Grundordnung kann ein Team nicht als Team existieren. Dann sind es nur Leute, die zufälligerweise zusammen arbeiten wobei das Wort „zusammen“ dann auch nur räumlich zu verstehen ist.  Also nicht kollaborieren sondern zusammen in einem Raum sitzen. Das ist ja auch ein Unterschied. 

Kommen wir jetzt mal zu praktischen Dingen, die sich daraus ableiten lassen. 

In Scrum arbeitet das Team ja im Sprint selbstorganisiert zusammen

Eins der Dinge oder bzw. Artefakte, die ein Team zur Selbstorganisation benutzen kann, ist das Burn Down Chart. Über das Burn Down grundsätzlich habe ich ja schon in einer früheren Folge gesprochen und es ist ein durchaus gefährliches Tool, wenn man die Message falsch interpretiert oder das Burn Down falsch angewendet wird. 

Es geht um die Erkennung von Problemmustern, die uns als Team zeigen, dass wir im Begriff sind, vom rechten Weg abzuweichen. Das ist das eigentliche Ziel.

Probleme entstehen im Sprint aus verschiedenen Gründen. Vorausgesetzt die Userstories sind nicht zu groß und sowieso erst in 2 Wochen fertigzustellen, kann man am BurnDown Chart sehr gut ablesen, wie es mit der Erreichung des Sprintziels aussieht: Wenn die Kurve mehr eine Gerade ist und horizontal von links nach rechts läuft, kann man sich denken, dass wir in der aktuellen Geschwindigkeit das Ziel nicht erreichen werden. Wir habe es also mit einem Muster zu tun, das uns auf ein Problem hinweist:

Die Probleme im Sprint bestehen meisten aus:

  • Sich ausweitenden Anforderungen im Sprint (Userstories werden „größer“) 
  • Technische Probleme
  • Ausfall kritischer Personen oder Wegfall von Wissen im Team
  • Überschätzte Kapazität (wenn es z.B. nicht transparent ist, ob jemand nicht da ist (Urlaub oder wichtige Meetings ausserhalb oder Velocity nicht wirklich bekannt ist)
  • Ungeplante Unterbrechungen – also z.B. bearbeiten von so genannten „Prio 1 Tickets“, die nichts mit dem eigentlichen Sprintziel oder Produkt zu tun haben)
  • Vorherige Arbeit nicht erledigt, (Definition von erledigt verwenden)
  • Product Owner ändert das Sprint-Backlog 
  • oder – Störungen durch Management oder Stakeholder (im Sinne von „Hey Joe, kannst Du mal eben…oder Ändern der Richtung mitten im Sprint ohne Einbeziehung des Product Owners)

Sowas kannst Du als Scrum-Master oder Team Mitglied feststellen und Du solltest die richtigen Schlüsse daraus ziehen: Eure Bemühungen werden nicht rechtzeitig zum Erfolg führen, und das Sprint Burndown Chart zeigt, dass ein Scheitern so gut wie sicher ist. Wenn ihr Probleme rasch erkennt und schnell reagiert, ist das für den Geist der Agilität von grundlegender Bedeutung. Denn sonst baut Ihr eine Bugwelle vor Euch auf, die Euch immer weiter von den eigentlichen Zielen fernhält. 

Wenn ihr ein Projekt mit mehren Teams durchführt und ein Team nicht „mithalten“ kann, trefft Euch alle, um gemeinsam zu entscheiden, was zu tun ist. Vielleicht können die Anforderungen anders aufgeteilt und damit Abhängigkeiten verringert werden. Verliere nicht das Ziel aus den Augen, dass ihr alle gemeinsam ans Ziel kommen müsst – ihr habt nichts gewonnen, wenn 2 fertig sind und das dritte Team nicht – dann wird das Produkt nicht funktionieren. Das einzige, was ihr geschafft habt, ist dann einen Sündenbock zu finden. Diese Erkenntnis hilft aber im allgemeinen nicht bei der Schöpfung von Nutzen für den Kunden!

Wenn Du feststellst, dass ihr die Planung und das Sprintziel so nicht mehr erreichen könnt, ist es besser, den Umfang frühzeitig zu reduzieren, damit das Team die geplante Arbeit zu Ende bringen kann, als sehenden Auges zu scheitern. Die Organisation kann sich auf Probleme einstellen und sich darauf einstellen, anstatt überrascht zu werden. Und: es ist bekannt, dass Teams die früher fertig werden,  hinterher schneller beschleunigen.. 

Der Abbruch eines Sprints kann hier die beste Option sein, besonders dann, wenn das Team immer wieder scheitert. Nur der Product Owner kann entscheiden, ob der Sprint abgebrochen werden soll – So schwierig und unangenehm diese Entscheidung sein dürfte – der Product Owner kann und sollte beurteilen, ob sich die Aktivitäten möglicherweise nicht mehr lohnen oder ob auf der anderen Seite der Abbruch des Sprints negative Folgen für das Geschäft oder den Markt haben könnte.

Nach dem Abbruch könnt Ihr eine kurze Sprintplanung für einen verkürzten Sprint durchführen, um im Rhythmus mit den andern Teams zu bleiben (falls das notwendig ist – denn in den meisten Organisationen und Projekten gibt es schon einen abgestimmten Sprintwechsel und man sollte durch den abgebrochenen Sprint nicht alles durcheinanderbringen). Ziel ist es dann trotz des Abbruchs möglichst viel Wert zu liefern. Oder Du hältst – wenn Du Scrum Master bist, mit dem  Team eine längere Retrospektive ab, um Probleme im Umfeld oder in der Scrum-Implementierung im Team zu suchen und zu lösen – die Erkenntnisse  solltet Ihr dann gleich in der nächsten Sprintplanung berücksichtigen und mit dem nächsten Sprint gleich beginnen. 

Der Abbruch eines Sprints bedeutet nicht der Abbruch des Projekts – es ist ein Warnsignal, nicht mehr aber auch nicht weniger. Der größte Effekt eines Sprintabbruches besteht darin, öffentlich sichtbar zu machen, dass es grundlegende Hindernisse gibt, die das Team an der Ausübung seiner Arbeit hindern. Ein sichtbares und transparentes Problem ist eins, das das Team auch beheben kann. Probleme, die unter den Teppich gekehrt werden, lösen sich nicht…sie werden nur größer.

Die Beendigung eines Sprints sendet eine starke Botschaft an die gesamte Organisation, dass etwas nicht stimmt und erhöht die Fähigkeit, Hindernisse, die zum Scheitern führen, zu beseitigen. 

Wir haben in Deutschland die Tendenz Dinge immer so ernst zu sehen und zu nehmen – ein abgebrochener Sprint kann auch aus Zeichen oder als Muster gesehen werden – in USA, wo ja bekanntlich ein etwas anderer – teilweise verspielterer Ton angeschlagen wird, wird dies teilweise auch durch eine „Stop the line- Ceremony“ öffentlich gemacht. Dabei legt sich das ganze Team auf den Boden – möglichst da, wo es jeder sieht -also in der Lobby, im Engangsbereich oder so, zappelt mit Händen und Füßen und schreit oder ruft…Damit wird signalisiert, dass ihr Product Owner gerade den Sprint beendet hat. Das klingt für uns etwas fremd oder verrückt und wird sich hier bei uns sicherlich nicht durchsetzen, ich kann mir jedenfalls nicht vorstellen, dass sich jemand das bei uns traut – aber der offene Umgang mit Problemen mir dem Ziel sie danach besser beheben zu können ist etwas, was wir uns durchaus abgucken können. (sag mir gerne, ob sowas bei Euch in der Firma üblich ist…)

Die oft beschworenen „High Perfomance Teams“, also solche, die es auch mit Kaizen – also der ständigen Verbesserung – ernst nehmen, kann ein Sprint-Abbruch auch zum wiederkehrenden Muster werden – Manche Teams begeben sich mit einem hohen Risiko in den Sprint, insbesondere, wenn neue Technologien eingeführt werden oder der Stand der Technik weiter voran getrieben wird können unerwartete technische Probleme vorkommen. Hier ist es eben wieder besonders wichtig, den experimentellen Ansatz des agilen Arbeitens zu verstehen. Sicherheit gibt es woanders – hier, wo die Zukunft schon heute gemacht wird – da erleben wir Überraschungen.

Im Allgemeinen wird – und das eben angelehnt an das Lean Manufacturing – die Produktion an der Stelle angehalten, wo das Problem liegt und das Problem gleich vor Ort gelöst um dann weiterzu machen. Man kann oder sollte zumindest davon ausgehen, dass das gleiche Problem nicht wieder auftritt. 

Poka-yoke (ポカヨケ)ist ein japanischer Begriff, der „ausfallsicher“ oder „fehlersicher“ bedeutet. Ein Poka-Yoke ist jeder Mechanismus in einem schlanken Fertigungsprozess, der einem Anlagenbediener hilft, Fehler (poka) zu vermeiden (yokeru). Sein Zweck ist es, Produktfehler zu eliminieren, indem menschliche Fehler verhindert, korrigiert oder auf sie aufmerksam gemacht werden, sobald sie auftreten.  Ein gutes Beispiel für so ein Poka-Yoke Divice ist ein Geldautomat. Der Geldautomat gibt die Banknoten erst heraus, wenn der Kunde die seine EC- oder Kreditkarte aus dem Automaten gezogen hat. – Da musst Du mal drauf achten – sonst besteht das sehr hohe Risiko, dass der Kunde das Geld nimmt, geht und die Karte im Automaten vergisst. 

Probleme sichtbar zu machen ist Teil des Kaizen-Gedankens. Das Team wird lernen, schnell und diszipliniert auf Veränderungen zu reagieren und Herausforderungen zu bewältigen. In vielen Organisationen, wenn die Dinge nicht gut laufen, denken die Teams nicht klar und sind frustriert und demotiviert. Sie verstehen die Ursache ihrer Probleme und die Art und Weise, wie sie gelöst werden können, nicht. 

Die Durchführung des Notfallverfahrens Sprint-Abbruch schult das Team darin, sich auf den Erfolg zu konzentrieren und Hindernisse systematisch zu beseitigen. Große Teams werden sich selbst von ihrer Fähigkeit überraschen, Widrigkeiten zu überwinden und besser und besser zu werden. Es erhöht die Chancen, sowohl kurz- als auch langfristig erfolgreich ein potenziell lieferbares Produkt zu realisieren. Das Team wird das Gefühl haben, dass es alles tut, was es kann, wenn es das Notfallverfahren anwendet, um aus Berufsstolz (siehe Teamstolz) und Produktstolz wieder auf den richtigen Weg zu kommen.

Wenn allerdings das Team dieses Notfallverfahren zu oft anwendet -also ich sage mal mehr als alle 4 Sprints – und seine Qualität und die Velocity oder Lieferrate nicht erhöht, dann sollte das Team in den Retrospektiven darüber nachdenken, ob in der Umgebung oder bei der Anwendung von Scrum etwas grundlegend falsch ist. Insbesondere für junge Scrum Teams ist es erst einmal besser im Sprint zu scheitern (also das geplante Sprintziel nicht zu erreichen) und in ruhig geführten Retrospektiven Wege zum Lösung von Problemen zu finden. 

So jetzt komme ich mal wieder zurück zum Anfang der Geschichte – Disziplin ist das einordnen in Prinzipien der Gruppe – dazu gehört das klare Bekenntnis sich stetig zu verbessern und auf Signale zu achten…daher braucht Scrum Disziplin…

Disziplin ist also eine Eigenschaft von erfolgreichen agilen Teams.

Soweit dazu – natürlich freue ich mich über Kommentare zu meinem Podcast und zu dem Thema, zu dem Du vielleicht auch eine ganz andere Meinung hast.

Ich bedanke mich fürs Zuhören und – wie gesagt – agil beginnt bei Dir im Kopf…

Tschüß

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 14: Der “Agile Festpreis” und andere Mythen…

Herzlich willkommen zu einer neuen Folge des agilophil-daily podcast. Hier bekommst Du immer Tipps und Hinweise bunt gemischt zu allen Themen im agilen Kontext – kurz vor unserem Corona lock-Down war ich in einem Projekt bei einem noch relativ klassisch aufgestellten Energieversorger und habe dort eine Disussion mitverfolgt,  in der es um die Vertragsgestaltung mit externen Dienstleistern ging…Irgendwann wurde deutlich, dass es konkret um das Thema „agiler Festpreis“ ging und dann konnte ich mich auch nicht mehr zurückhalten und habe schließlich meinen Senf dazu gegeben. Ohne jetzt auf konkrete Einzelheiten dieser speziellen Diskussion einzugehen, nehme ich das mal zum Anlass das Thema in eine Podcastfolge zu verwandeln…und Dir meine persönlichen Gedanken und Erfahrungen darüber mitzuteilen…Warum? Ich selbst habe mich dem Thema von ein paar Jahren in einem Projekt gewidmet – wir waren voller Hoffnung, Motivation und  guter Dinge, aber es waren an dem Projekt 4 verschiedene Parteien beteiligt – Ein Dienstleister auf IT Seite und “Die IT” als interner Dienstleister selbst – dann “Der Fachbereich sowie ein Dienstleister – also ein Beratungsgesellschaft auf Seite des Fachbereichs” und das macht insgesamt summiert 4 Verträge und 4 Möglichkeiten sich gegenseitig misszuverstehen oder Dinge falsch zu interpretieren…Das Ende vom Lied war tatsächlich unangenehm und das so vielversprechend gestartete Projekt wurde nach gut einem halben Jahr eingestellt. Sicherlich ist an sowas nicht allein die Vertragsgestaltung schuld und nach Schuldigen wollen wir ja auch gar nicht suchen. Trotzdem habe ich was gelernt…und das möchte ich hier mal weitergeben:

Am Anfang stellen sich folgende Fragen:

  • Worum geht es bei Vertagsverhandlungen mit externen Dienstleistern?
  • Was ist das Ziel des Projekts?
  • Was sind die Herausforderungen?

und – was führt zu Unzufriedenheit zwischen den Vertragspartnern?

was sagt das agile Manifest dazu?

Wie sollte man also vorgehen? – eins sage ich gleich vorweg – am besten gar keine agilen Festpreisverträge machen!

Agile Projekte sind Dienstleistungsprojekte und wenn dieser Vertragstyp irgendwie nicht passt, ist eigentlich an der Grundhaltung in den beiden Unternehmen – also dem Auftraggeber und dem Auftragnehmer –  schon was nicht passend – also  zum agilen passend – ich will nicht sagen, dass hier was grundsätzlich falsch läuft – das natürlich nicht!

Aber wenn Du bzw. Deine Firma sich in eine agile Organisation verwandeln willst, fängt es eben bei den Werten und im Mindset an…und ich kann sagen, dass die Überlegung einen agilen Festpreis auszuhandeln allein schonmal ein Kennzeichen dafür ist, dass der agile Reifegrad im Unternehmen noch nicht besonders hoch ist…

Wenn es also unbedingt ein agiler Festpreis-Vertrag sein soll, dann musst Du insbesondere auf folgende 5 Punkte achten, sonst werdet ihr – und das weiß ich aus eigener, leidvoller Erfahrung – echt Probleme im Projekt bekommen:

Punkt 1: Der Geist des Vertags spiegelt die Zusammenarbeit im Team wieder. Wenn der Vertag ein „Kontrollinstrument” darstellt, von Pönalen und Strafzahlungen bei Nichterfüllung die Rede ist und der Vertag als Instrument zum Aufbau von Druck auf den Dienstleister gemeint ist, dann wird dieser Druck auf der anderen Seite auch entstehen – alte physikalische Weisheit – Druck erzeugt Gegendruck!…Die Stimmung im Projekt wird sich auf kurz oder 

lang in ein „Angriff- und Verteidigungs-Szenario“ wandeln – der Auftraggeber fordert, drückt und kontrolliert und der Dienstleister rechtfertigt sich, und will nicht schuld sein – da waren die Anforderungen nicht ausreichend spezifiziert oder zu kurzfristig gestellt oder Fachbereichstkollegen waren für Rückfragen nicht erreichbar und so weiter und so fort. Du siehst…der Fokus (- erinnere Dich an die Werte-Folge!) verschiebt sich vom Kundennutzen zu Angriff und Verteidigung…es wird also weniger und weniger an den eigentlich wichtigen Themen gearbeitet und mehr und mehr Zeit verschwendet sich zu streiten. Das ist nicht agil. 

Punkt 2: Baue Flexibilität ein, wo immer es geht! – Auf sich verändernde Backlogs und Nutzen verweisen und nicht auf ein Commitment des Teams zur Umsetzung bestimmter Anforderungen oder – noch schlimmer – auf eine bestimmte Anzahl von Storypoints. Halte die fachlichen Themen raus aus dem Vertag, sonst bist Du nicht mehr flexibel und verlierst einen wesentlichen Vorteil des agilen Vorgehens. Und der Steuerungseffekt solcher Regelungen ist fatal: Wenn der Vertrag vorsieht möglichst viele Storypoints im Sprint umzusetzen, dann werden auch Storypoints umgesetzt – es geht aber bei der Umsetzung im Projekt gar nicht darum Storypoints umzusetzen, sonder Kundennutzen zu schaffen. Wenn Du vom Team viele Storypoints willst, wirst Du sie erhalten….Wenn Du dann noch die Storypoints in Geld umrechnest – obwohl das von ihrem Wesen her gar nicht sinnvoll ist, konzentrierst Du dich darauf möglichst viel Output zu schaffen und nicht Nutzen. Du förderst Ressourcenverschwendung – und das ist in vielerlei Hinsicht nicht nachhaltig. Mit wenig Arbeit hohen Nutzen zu schaffen, ermöglicht es dem Team mit der übrig gebliebenen Zeit noch mehr Nutzen zu schaffen oder die Zeit zu haben, notwendige Prozessverbesserungen zu entwickeln. Das hast Du nicht, wenn Du dich auf Output fokussierst!

Punkt 3: Baue den Festpreis am Team auf – also Teamkapazität von x Leuten mal Sprintdauer oder Monat…Dann kostet dich das Team immer gleich viel und Du kannst mit dem Team abstimmen „WAS“ gemacht werden soll – und das auf Basis des Nutzens und der technischen Realisierbarkeit. Vermeide Bottom-up Modelle, wo einzelne Anforderungen im Preis geschätzt und zusammengezählt werden. Sowas macht viel Arbeit und ist auch nicht genauer – genauer gesagt – egal, wie du es machst, wirklich richtig schaffst Du es nie. Aber mit der Teamkapazität kommst du ziemlich nah an die Wirklichkeit heran…und das auch noch ziemlich einfach

Punkt 4: Die wesentlich schlechtere Art Flexibilität einzubauen ist – aus meiner Sicht – das Exchange for Free Verfahren- aber immer noch besser als nichts!… Wenn eine neue Anforderung hinzu kommt,  muss eine alte – oder andere Anforderung aus dem Release verschwinden – diese Anpassung ist dann „for free“ – also nicht, wie im klassischen Projektgeschäft mit einem  Change Request verbunden. Das Schlechte daran, ist die Tatsache, dass man dann einzelne Anforderungen dabei monetär bewertet – also man ist wieder bei der bottom up Methode. Um also streitfrei festlegen zu können, dass eine Anforderung gegen eine gleichwertige andere ausgetauscht werden kann, muss klar sein, dass sie gleichwertig sind…und darin steckt schon wieder viel Potenzial für unterschiedliche Meinungen.

Punkt 5: Was ist der Abnahmegegenstand? – in Werkverträgen hat man Abnahmen – man kennt das vom Hausbau, da kommt der Begriff „Gewerk“ auch her – Der Bauherr oder Architekt oder sonst eine bevollmächtigte Person schaut sich die Leistung des Handwerkers an, prüft und nimmt sie als „ordnungsgemäß erledigt“ ab – darauf hin kann die Rechnung erstellt bzw. die Zahlung freigegeben werden. Vom Gefühl her ist das genau das, was ein Unternehmen als Sicherheit gedenkt zu brauchen, weil man die „Dienstleister“ ja kontrollieren muss, sonst machen die was sie wollen…oder man muss Druck aufbauen, sonst sind die „faul“ und arbeiten gar nicht…

Du siehst – hier schwingt eine Geisteshaltung mit, die ich unter „Command and control“ einordne – und das ist nicht wirklich agil sondern kommt aus der tayloristischen Weltsicht, die agile Unternehmen verlassen wollen…

Wie soll das also im agilen Kontext funktioinieren?

Im agilen Kontext kommt hier wieder die Wertebasis zum Tragen sowie das alt-bekannte agile Manifest: „Zusammenarbeit mit dem Kunden geht über Vertragsverhandlungen“ steht hier – und das wird durch die dazu gehörenden Prinzipien untermauert…Die für mich in diesem Kontext passendesten lauten:

  • Prinzip Nr. 4: Fachleute aus verschiedenen Bereichen müssen während des Projekts täglich zusammenarbeiten.
  • Prinzip Nr. 7: Funktionierende Dienstleistungen/Produkte sind das wichtigste Fortschrittsmaß.
  • Prinzip Nr. 8: Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, das Team und die Nutzer der Dienstleistung sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  • Prinzip Nr. 11: Die besten Arbeitsrahmen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  • Prinzip Nr. 12: In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und es passt sein Verhalten entsprechend an.

Ich übersetze das mal in den Kontext der Vertragsverhandlungen aus agiler Sicht:

Der Dienstleister ist ein Partner, der mit seinen Spezialisten mir als Auftraggeber hilft ein Problem zu lösen, welches ich ohne ihn nicht lösen kann…Der Dienstleister ist kein Gegner, gegen den ich kämpfen muss und auch kein Knecht, der mir lästige Dinge abnimmt…

In diesem Sinne ist der Dienstleister auch daran interessiert mir die passenden Lösungen und Produkte in hoher Qualität zu liefern und nicht möglichst wenig zu arbeiten und den Auftraggeber zu betrügen, wo es nur geht (was ja implizit bei einer entsprechenden Vertraggestaltung unterstellt wird). Und – aus Sicht des Dienstleisters ist es ja so: wenn man mir das schon unterstellt, dann komme ich vielleicht auch auf den Gedanken das auch so zu sehen… Währed den Anfängen kann ich da nur sagen!

Selbstorganisiert kann ein Team nur sein, wenn es keine versteckte Agenda zwischen den Teammitgliedern gibt. Ein „Knebelvertrag“ wäre Auslöser von solchen Denkeweisen, das ist ganz klar. Wenn wir gemeinsam im Vertag regeln, dass wir als Partner zusammenarbeiten und an einer ständigen Verbesserung arbeiten, dann entsteht die „Gegner-Sicht“ nicht. Und natürlich können wir das auch über im Vertag festgeschriebene Aktionen wie Retrospektiven einfordern – 

Doch wie können wir nun die gewünschte Rechtssicherheit herstellen, die sowohl dem Auftraggeber wie auch dem Auftragnehmer dient?

Wir vernachlässigen sehr oft den Kundennutzen – das was eigentlich das Ziel der Aktivitäten im Rahmen von agilen Projekten sein sollte – Anforderungen werden häufig nur nach Aufwand geschätzt und dann bepreist – eine Schätzung nach Kundennutzen erfolgt selten – dabei ist das der eigentliche Input, den wir bei der Priorisierung von Anforderungen nutzen sollten.

Wenn wir also den Kundennutzen einer Anforderung in Euro angeben können (wir müssen uns ja mal Gedanken darüber gemacht haben – sowas hat man früher „business case“ genannt), dann sollte es uns leicht fallen, ein Kriterium im Vertag zu verankern, das zur Erhöhung der Sicherheit dient.

Wir ermitteln den Nutzen, den ein Sprint haben wird – also  wir addieren die Beträge des Kundennutzens aller Anforderungen, die für einen Sprint geplant sind (und hier – kleine Nebenbemerkung –  werden wir uns genau in die Augen schauen und vertrauensvoll und wertschätzend – und vor allem ehrlich – miteinander umgehen müssen). 

Und wir ermitteln die Kosten für den Sprint (also Stundensatz/Tagessatz DL mal Anzahl Teammitglieder mal Arbeitstage im Sprint). Da ein Scrum-Team sich ja nicht ständig ändert und die Dauer des Sprints auch konstant bleibt, sollte das für jeden Monat gemittelt werden (also Feiertage rausrechnen, indem wir 20 Arbeitstage annehmen) und dann haben wir eine sehr gute und ziemlich feste und verlässliche Kostenberechnung. 

Wenn also dieser Betrag des erreichten Kundennutzens über den Kosten für den Sprint liegt, macht das Ganze Sinn. Bei einer sinnvollen Sprintplanung mit einer geeigneten Priorisierung durch den Product-Owner und einem ehrlichen Forecast durch das Team, werden wir also im Plus liegen. 

Das können wir als Abnahmekriterium im Vertrag festhalten. Wir nehmen also nicht eine Anzahl von Stories oder Storypoints als Maßstab, sondern den Kundennutzen. Wenn das Team den erstrebten Kundennutzen wiederholt nicht erreicht, können wir Pönalen im Vertrag festlegen. Das ist sowohl fair gegenüber dem Auftragnehmer, da es ein Ansporn für das Team ist, die gesetzten Ziele auch zu errreichen und sich ständig zu verbessern – und auch ein Ansporn für den Auftraggeber, nutzenorientiert vorzugehen und nicht ungebremst Output zu fördern.

Ich wiederhole es nochmal – im agilen Kontext sind Dienstleistungs-  bzw. Serviceverträge die beste Lösung. Darum die klare Empfehlung von mir – vermeide einen Werkvertrag!

Nun ist mir bekannt, dass es verschiedene Kontexte gibt, in denen eine derartig freie Vertragsgestaltung nicht anwendbar sind. Zum Beispiel müssen bei Ausschreibungen von öffentlichen Auftraggebern Festpreise angeboten und klare Gewerke festgeschrieben werden. Hier können wir allerdings mit Berücksichtigung unserer eigentlichen Intention einer partnerschaftlichen Zusammenarbeit verschiedene Mischformen anstreben – also feste Grundanforderungen (also sozusagen die Projektvision) mit einer Verankerung von Austauschmöglichkeiten über ein Exchange for Free Verfahren. 

Was auch möglich wäre, ist eine phasenweise Beauftragung von Sprints bzw. Iterationen, wodurch wir uns die Freiheit erhalten, jederzeit festlegen zu können, wann der gewünschte Nutzen erreicht ist. Wir werden damit in die Lage versetzt das Projekt auch frühzeitig zu beenden. Hier ergibt sich allerdings ein Nachteil für den Dienstleister (das ggf. veranschlagte Auftragsvolumen wird nicht ausgeschöpft). Das können wir wiederum mit einem Passus im Sinne von „wir teilen uns die Einsparung“ ausgleichen. Der Gedanke dahinter ist, den Gewinn aus dem frühzeitigen Ende gerecht aufzuteilen, was einen zusätzlichen Anreiz für den Dienstleister stellt, denn er wird belohnt, wenn er früh in bester Qualität fertig wird. Wenn wir einen Sprint zu x-1000,- € einsparen, dann erhält der DL die Hälfte des Sprintpreises als Bonus und kann sein Team bereits früher bei einem anderen Kunden einsetzen. Als Auftaggeber können wir ebenfalls die Hälfte der Sprintkosten als Kosteneinsparung verbuchen und bleiben so unter dem veranschlagten Budget. Eine klassische Win-Win Situation – niemand verliert – beide gewinnen…

Es gibt mit Sicherheit noch eine Menge weiterer Ideen für eine partnerschaftliche Vertragsgestaltung und das ist auch genau das, worauf es ankommt.  In diesem Sinne – agil beginnt hier – bei Dir – im Kopf…

Danke fürs zuhören und hinterlasse gerne einen Kommentar über meine Webseite agilophil-daily.de. Ich freue mich auch über eine Bewertung bei itunes bzw. Spotify oder Google  oder wo auch immer Du diesen Podcast hörst..

Solltest Du Wünsch zu Themen haben, über die ich mal sprechen soll, schick mir auch gerne eine PN über Linkedin oder Xing oder über mein Kontaktformular auf der Webseite.

Mach weiterhin das Beste draus…

Tschüß, dein agilophiler Frank

Agilophil-Daily Podcast Episode 12: Das Refinement oder „zeige dem Backlog, dass du es liebst“…

So etwa 2014/2015 war ich Projektleiter und Scrum-Master in einem relativ großen Projekt in Bayern. Du kennst ja den Spruch „Manchmal gewinnt man, manchmal lernt man…“ – das war definitiv ein Projekt zum Lernen. In dem Projekt gab es eine ganze Menge „Lernerfolge“ – Wir hatten zum Beispiel das Phänomen, dass die Planungsmeetings viel zu lange dauerten und sehr ermüdend waren. Wir diskutierten und diskutierten und es nahm kein Ende…Woran lag das? Wir hatten doch die Userstories alle in langen Workshops zu Beginn des Projektes besprochen und geschätzt?…

Wann hatten wir das gemacht? Zu Beginn des Projekte – Du hast richtig gehört…

Eins der wesentlichen Elemente ist ja das Lernen auf dem Weg…was wir damals in dem Projekt gemacht hatten, war allerdings ein verkapptes Wasserfallprojekt mit Scrum-Elementen zu überlagern. Wir hatten zu allem Überfluss noch verschiedene externe Partner in dem Projekt, die jeweils eine eigene Agenda hatten. Alles keine guten Voraussetzungen für ein gelungenes Projekt…

Das Verständnis, wie wir im Projekt vorgehen wollten, war fundamental anders und es äußerte sich unter anderem auch in einem besonderen Meeting – dem Refinement…und das innige Verhältnis, dass ein Product Owner zu seinem Backlog aufbauen sollte…oder in dem Falle eben nicht…

Wenn Du Product Owner oder Product Ownerin bist, bist Du diejenige Person, die für die Betreuung bzw. das Management des Product Backlogs verantwortlich ist – so steht es jedenfalls sinngemäß im Scrum Guide. Als Product Owner bis Du der – oder diejenige –  die den Wert des Produktes maximiert. Oder anders ausgedrückt: der die Arbeitszeit des Dev.-Teams zu einem lohnenden Investment für die Company macht.

Wir haben ja bereits über die im Scrum-Guide fest terminierten Events gesprochen – Am Anfang kommt das Sprint-Planungsmeeting, dann täglich die Daily Standups, am Ende dann das Sprint-Review und die Sprint Retrospektive. 

Aber ein Meeting hat keine feste Agenda und keinen angestammten Platz und wird daher gerne vergessen oder verdrängt. Das Refinement Meeting (früher auch „Grooming“ genannt). Dabei kann das Refinement Dein besonderer Freund sein: Das Refinement bewahrt Dich davor, das Team auf die falsche Strecke zu schicken. Das Refinement gibt Dir die Möglichkeit stolz auf Dein Backlog zu sein und laut auszurufen: „Seht her, was wir hier cooles bauen und welchen Nutzen wir hier für unsere Kunden schaffen!!““

Hört sich gut an oder?

Stell Dir das mal vor – 

Also reden wir in der heutigen Folge mal über das Refinement: – wozu dient das überhaupt? 

Während sich die anderen genannten Meetings auf den laufenden oder kommenden Sprint konzentrieren, blickt das Refinement über den Tellerrand hinaus auf die Dinge, die später kommen werden. 

Es dient dazu das Backlog zu sichten, zu verstehen und aufzuräumen. Denn nur, wenn Du als Product Owner und als Dev-Team auch verstanden hast, was in deinem Backlog steht, kannst du Entscheidungen treffen. 

Und Entscheidungen sind essentiell, wenn es um die Optimierung des Wertes des Produkts bzw. der Arbeitsergebnisse des Teams geht. Nur durch Entscheidungen, die das WAS und auch das WIE der Anforderungen betreffen,  ist es überhaupt möglich einen Wert zu erhöhen bzw. überhaupt einen Wert zu schaffen. Ohne solche Entscheidungen ist der Wert, den die Arbeit des Teams letztlich hat, vom Zufall abhängig und so mit Sicherheit auch nicht optimal. 

Denn es muss klar sein. Das Team arbeitet immer gleich (gut), sie kosten auch immer gleich viel… nur an was sie arbeiten, bestimmt letztlich den Wert der Arbeit (also das „outcome“ oder den Nutzen für den Kunden und damit für Deine Firma). Die oft geforderte „Performance“ eines Teams – also ein möglichst großer „output“ – ist nicht entscheidend für den Wert der Arbeit. 

Doch wie erhöht man nun den Wert der Arbeit?

Wie oft und wann sollen die Refinements durchgeführt werden?

Nun – es ist sicherlich gut, wenn es – wie in den anderen etablierten Events auch – einen festen Termin gibt, an den sich das Team gewöhnen kann. Aber es muss auch möglich sein, dass der Product Owner sozusagen zu „ad-hoc Refinements“ einladen kann, wenn etwas besonders Dringendes besprochen werden soll. Du wirst sicherlich mit deinem Team einen guten Weg finden. 

Wichtig ist, dass Refinements auf jeden Fall innerhalb des Sprints durchgeführt werden und das Du sie nutzt, um deinem Backlog zu zeigen, dass Du dich darum kümmerst…

Letztlich solltest Du als Product Owner dein Backog lieben…und das Backlog gibt dir durchaus Signale, wenn es etwas Zuwendung braucht…hier kommen ein paar:

Signal Nr. 1: Mein Backlog hat Übergewicht...Größer ist nicht besser.

Wenn Dein Backlog vollgestopft ist, wie eine Mastgans kurz vor Weihnachten, dann fühlt es sich nicht gut…lass es entschlacken und gönne ihm eine Abmagerungskur:

Das Backlog ist ein lebendes Artefakt, wir lernen aus jedem Sprint und in jedem Sprint-Review generieren wir neue Ideen, die das Produkt besser machen. Wenn im Backlog alte Ideen vor sich hin gammeln, sollten diese gelöscht werden. Denn Ideen oder Anforderungen, die eventuell seit Beginn des Projekts aus irgendeinem Stakehoder-Workshop da eingeflossen sind. 

Ideen, die wahrscheinlich von der Wirklichkeit längst überholt worden sind oder Anforderungen nach denen keiner jemals wieder nachgefragt hat…haben höchstwahrscheinlich keinen großen Wert, denn sonst würde jemand danach fragen! 

Also mache es Dir zu Regel, dass alles, was seit einem halben Jahr oder länger im Backlog liegt (und keine hohe Prio bekommen hat) gelöscht wird – oder das diese Userstories oder Anforderungen zumindest potentielle Streichkandidaten sind. (Vielleicht liegt in deinem Kontext die Schwelle auch bei drei Monaten oder darunter oder vielleicht auch darüber – die Entscheidung überlasse ich natürlich Dir…). Hier könntest du zum Beispiel im Refinement drüber sprechen. 

Wenn Ihr euch nicht sicher seid, könnt ihr vielversprechende Ideen ja nochmal ins Bewusstsein hieven, in dem ihr das nochmal vor dem jetzigen Stand des Projekts diskutiert.

Signal Nr. 2: Mein Backlog – das fremde Wesen:…Unbekannte und unklare Stories fallen durch!

Wenn Du in deinem Backlog Stories oder Anforderungen findest, und beim Durchlesen nur noch denkst: Hä? was soll das denn sein? Dann läuft was falsch…

Oft ist es so, dass du als Product Owner gar nicht selbst alle Anforderungen ins Backlog schreibst, sondern diese von allen möglichen (und unmöglichen) Seiten da rein kommen…Wenn das bei Dir so ist, achte insbesondere auf die Definition of Ready: Oft haben sich auch „Formulare“ oder Templates bewährt, die du für die verschiedenen Ticketarten gestalten kannst (wie z.B.  Userstory, Defect, Investigation): Bei einem Fehler kannst Du z.B. folgende Informationen einfordern:

  • Wie kann man den Fehler reproduzieren? (Schritt für Schritt und welche Voreinstellungen wurden gemacht, bzw. welches Systemsetting liegt beim Auftreten des Fehlers vor?)
  • Was ist das erwartete Ergebnis, wenn man die Schritte nacheinander durchführt?
  • Was ist im Gegensatz dazu das aktuelle Ergebnis?

Und bei einer Anforderung solltest Du auf das User-Story Format und die Akzeptanzkriterien achten…Nochmal zur Erinnerung…Ne Userstory enthält 3 Bestandteile – Wer braucht es? ,, was wird gebraucht? Und wozu wird es gebraucht (Nutzen)?

Signal Nr. 3: Die Unwichtigen sind die Detaillierten...

In einem guten Backlog sind die hoch priorisieren Items auch diejenigen, die am besten detailliert beschrieben sind. Diese stehen oben und sind dazu noch so klein, dass sie direkt im nächsten Sprint geplant werden können. Du kennst vielleicht die Eigenschaften eines guten Backlogs: DEEP – ein Akronym – natürlich kommt das aus dem englischen: (D: angemessen detailliert, E: = Emergent, also sich entwickelnd E: Estimated – also geschätzt  und P: Priorisiert).

und was bedeutet das jetzt in der Praxis?

Detaillieren ist schließlich Arbeit – Wenn ihr Euch mit unwichtigen Dingen beschäftigt, die in den nächsten 6 Monaten sowieso nicht umgesetzt werden, dann vergeudet ihr wertvolle Zeit, die euch bei den wichtigen Themen dann fehlt – Du kannst das mit den Opportunitätskosten vergleichen, die bei der BWL ja oft genannt werden. Wenn Du Zeit oder Geld in ein Thema investierst, fehlt dir genau diese Zeit und das Geld bei einem anderen Thema. Daher solltest Du immer darauf achten welche Themen die aktuell wichtigen sind. Diese verdienen jetzt auch die volle Aufmerksamkeit. Die anderen Probleme kannst Du dann lösen, wenn sie da sind…

Signal Nr. 4: Abgekoppelt von der Product-Vision – Habt ihr überhaupt eine Produkt Vision?

Hier kommen wir zu einem Kernthema – insbesondere wenn es bei Euch vielleicht schon zu Unzufriedenheit gekommen ist und ihr gerade Euer agiles Vorgehen mit Scrum in Frage stellt:

  • Habt ihr eigentlich eine Produktvision?
  • Baut ihr eigentlich gerade ein Produkt?
  • oder macht ihr etwas anderes?

Scrum kann seine Stärken besonders dann ausspielen, wenn es darum geht ein Produkt zu entwickeln – oder weiter zu entwickeln. Kontinuierliche Änderungen an einem bestehenden System – im Sinne von Wartung oder Fehlerbehebung – steht gegebenenfalls in Konflikt mit der eher starren Planung eines Sprints. Hier könntet ihr überlegen, ob nicht vielleicht eine Anpassung des Vorgehens in Richtung Kanban sinnvoll ist. 

Wenn ihr allerdings eine Produkt-Vision habt, dann ist ja alles ok – dann sollten allerdings die Userstories auch dazu passen…

Backlog Items, die nicht zur Produktvision passen, lenken im besten Fall nur ab. Im schlechteren Fall sorgen sie dafür, dass ihr Eure Vision nicht erfüllen könnt. Daher – und hier bist Du als PO gefragt – Behalte die Vision im Auge und lass dich nicht abbringen. Viele Wege führen nach Rom, aber wenn ihr in Warschau rauskommt, ist was falsch gelaufen…

Frage Dich, wenn du im Backlog Stories oder Anforderungen findest, einfach – bringt mich das der Produkt-Vision näher? Wenn Du die Frage mit „ja“ beantworten kannst, gehe weiter. Wenn nicht – frage Dich – „warum steht das hier?“ – Gib dem Item noch eine Chance – aber nur eine…falls Du auch nach intensivem Nachdenken nichts dazu einfällt kicke das Ticket aus dem Backlog. Wahrscheinlich fragt sowieso nie wieder jemand danach. Alle Backlog-Items, bei denen Du die Frage mit „ja“ beantwortet hast, kannst Du dann im Refinement mit dem Team diskutieren, so dass der Nutzen und die Größe der Story jedem klar ist… 

Signal Nr. 5: Nur Du arbeitest am Backlog.

Du bist zwar verantwortlich für den Wert des Produkts, das bedeutet aber nicht, dass nur Du alleine im Backlog arbeiten darfst. Nach dem Scrum-Guide ist das Backlog Refinement ein andauernder Prozess, in dem Du (als PO) zusammen mit dem Team an den Details für die Anforderungen arbeitest.  

Bitte interpretiere das nicht so, dass nur Du als PO an den Stories arbeiten darfst. Gib dem Team die Möglichkeit, selbst Ideen aufzubringen (- solltest Du Scrum – Master oder Team Mitglied sein, fordere diese Möglichkeiten für Dich oder das Team ein). Ihr verschenkt eine Menge an Kreativität im Team, wenn ihr hier zu streng seid. Oder ihr riskiert eine Überforderung des PO – was definitiv ein Risiko ist. Schütze Dich selbst und gib ab…auch wenn das hier von aussen über den Podcast leicht gesagt ist und ich weiß, dass die Umstände oft schwierig sind. Bedenke, es geht nie um den Prozess um des Prozesses willen – es geht um die Ergebnisse und den Wert der Arbeit. Wenn der Prozess hier nicht unterstützt, ist etwas am Prozess falsch und nicht an Dir!

Fazit: Denke spätestens bei Deiner Arbeit am Backlog an die Macht von Pareto! Pareto, das ist der italienische Wissenschaftler und Ökonom, der das 80:20 Prinzip entdeckt hat, welches auch nach ihm benannt wurde. Und das sagt: Du brauchst 20 % des Aufwands um 80% des Nutzens zu erreichen…Wenn Du also als Product Owner in der Lage bist, die Anforderungen, die 80% des Kundennutzens erzielen rauszufiltern, dann hast Du deinen Job richtig verstanden und super gemacht. Dann entlastest Du das Team und dich selbst von 80% wahrscheinlich unnötiger Arbeit. 

Lass Dir das mal auf der Zunge zergehen….das ist angenehm, wie ein wunderbar cremiges italienisches Eis in der Sonne….

Mmhhh….

Mit dem Bild und dem wohligen Geschmack auf der Zunge lass ich dich nun zurück…

Und wünsche Dir noch einen schönen Tag oder Abend…je nachdem, wann Du diesen Podcast hörst.

Tschüß – Dein agilophiler Frank

Diese 5 Signale sind inspiriert durch den Artikel: „5 signs your product backlog is in need of some love – published via linked-in by Dan Churchill, May 5, 2019

Agilophil-Daily Podcast Episode 11: Die Retrospektive oder wie macht man ein Team besser?

Ich habe in den letzten Folgen über die Sprintplanung, das Daily Standup und das Reviewmeeting gesprochen und daher kommt nun das abschließende Event im Sprint…Du ahnst es… – die Retrospektive. Auch wenn es das letzte Meeting im Sprint ist, hier passiert der wesentliche Teil dessen, was ein Team besser macht. Da das auch eine der wesentlichen Metaziele des Scrum-Masters ist, (Also – “Der Scrum-Master soll das Team besser machen”) muss da ja was dran sein.

Schauen wir erst mal wieder, was der Scrum-Guide dazu sagt:

Ich zitiere: “Die Retrospektive bietet dem Scrum-Team die Gelegenheit sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen”…(das klingt etwas steif, finde ich)

Ferner steht da (ich zitiere nochmal): “die Retrospektive wird durchgeführt, um

  • zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Personen, Beziehungen, Prozesse und Werkzeuge verlief
  • die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen und
  • um einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum-Teams zu erstellen”

Also – die Retro ist also für das Team und dient nicht dazu nicht fertiggestellte Userstories auseinanderzunehmen…sowas kommt im Refinement oder in der Planung dran. 

Themen sind daher eher: Anpassung der Definition of Done, Besprechung von Arbeitsweise und Kommunikation im Team, Vorschläge und Ideen dazu finden und die Selbstorganisation des Teams zu verbessern…

Am Ende der Retro ist es das Ziel mindestens einen Punkt zur Verbesserung der Arbeit zu herauszufinden und auch gleich im nächsten Sprint umzusetzen…also in das Sprintbacklog mit aufzunehmen.

Wenn Du Scrum-Master bist, schenke der Retrospektive besondere Beachtung – ich betrachte das immer als “mein” Meeting – hier kannst Du deine Kreativität ausleben und wirklichen Mehrwert schaffen. Daher auch hier wieder ein paar Tipps zu Dingen, die in einer Retro schlecht laufen können, so dass Du drauf achten kannst:

Unschön Nr. 1: keine Retro: Es gibt keine Retro, weil das Team glaubt, es gibt nichts zu verbessern…. Mal ehrlich – wenn es nichts zu verbessern gibt, ist man tot. Es ist wie das Nirvana, welches man als Normalsterblicher nicht erreichen kann – aber immer anpeilen sollte. Lass Dich als Scrum-Master auf nichts ein – die Retro gehört dazu und ist sehr wichtig! 

Unschön Nr. 2: Retro als Puffer. Wenn der Forecast bzw. die Planung nicht gehalten werden kann, wird auf die Retro verzichtet, um noch die letzten Stories abschließen zu können. Das ist genau das Gegenteil von dem, was eigentlich nötig wäre. Wenn das Team seinen Forecast nicht schafft, gibt es etwas zu verbessern und genau dafür ist die Retro da.

Unschön Nr. 3: Gehetzte Retro: Das Team ist wie immer in Eile und 10 min für die Retro müssen ja wohl genug sein. Der Scrum-Guide geht für einen einmonatigen Sprint von einer Zeit von 3h aus – also bei 2 Wochen wären dann immer noch 90 min. Das gesamte Team braucht eine gewisse Zeit um sich auf das Thema einstellen zu können. Wenn die Zeit nicht da ist, wird der Mehrwert des Meetings gering sein und Du musst aufpassen, dass das Meeting nicht ganz aus dem Blickwinkel des Team verschwindet. 

Unschön Nr. 4: Mangelndes Vertrauen: In der Retro ist es besonders wichtig, dass allen klar ist: Was hier im Raum mit dem Team besprochen wird, bleibt im Raum (also die Las Vegas Regel aus Hangover…) Daher ist es auch unklug Stakeholder dabei zu haben. Der Product-Owner ist allerdings ein Teil des Scrum-Teams und daher gehört er auch dazu. Aber – wenn hier gepetzt wird – dann ist die Vertrauensbasis zerstört und das ist nur schwer wieder heilbar.

Unschön Nr. 5: Das ewige Klagelied: – und ewig grüßt das Murmeltier: Das Team gefällt sich in der Rolle des Opfers und beschwert sich am Ende eines jeden Sprints über Gott und die Welt bzw. die Gesamtsituation im Unternehmen und wer alles daran Schuld ist, dass man hier nicht anständig arbeiten kann. Einmal kann man das vieleicht machen – aber letztlich macht es doch nur Sinn über die Dinge nachzudenken, die auch im Einflußbereich des Teams liegen. Getreu dem bekannten Spruch oder Gebet der Antialkoholiker: “Gib mir die Kraft zu Ändern, was ich ändern kann, gib mir die Gelassenheit hinzunehmen, was ich nicht ändern kann und die Weisheit beides voneinander zu unterscheiden.”

Unschön Nr. 6: Die Ergebnisse der Retro sind keine Ziele: Es gibt mehrere Varianten Ziele zu beschreiben – eins der bekanntesten ist SMART (also Spezifisch, Messbar, Archievable also Erreichbar, Relevant und Time-Boxed) – egal für welche Zieldefinition man sich entscheidet – Ziele sollten es schon sein, damit wir auch sehen können, ob wir – als Team – diese auch erreichen.

Unschön Nr. 7: Keine Zuständigen: Wenn sich jeder auf den anderen verlässst, wird es wahrscheinlich so kommen, dass das Action-Item aus der letzten Retro gar nicht angegangen wird. Gut ist es (und so steht es auch im Scrum-Guide) die Ergebnisse aus der Retro direkt mit ins Sprint-Backlog des nächsten Sprints zu schreiben und auch genauso wie eine Userstory zu behandeln. Dann ist es am Taskboard sichtbar und fällt auf, dass sich vielleicht gerade keiner drum kümmmert.

Unschön Nr.- 8: Was war da noch? Wir sollten uns auch daran erinnern, was wir in den letzten Retros als Action Items beschlossen haben. Also – wie schon gesagt – bitte mit am Taskboard lassen und ggf. auch in die Impediment-Liste aufnehmen…

Unschön Nr. 9: der unerwünschte Product Owner: Es hält sich oft noch die Meinung, dass der Product Owner nicht zum Team gehört und damit nichts in der Retro verloren hat. Das stimmt nicht, denn das Scrum-Team besteht aus allen 3 Rollen. Gemeinsam gewinnt man und gemeinsam verliert man – das schließt den Product Owner mit ein.

Unschön Nr. 10: Zeitverschwendung…Wenn das Team die Retro für Zeitverschwendung hält, kannst Du mal drüber nachdenken, die Retro interessanter zu machen (ich halte das für ein sehr konstruktives Feedback vom Team und das geht direkt an dich als Scrum Master).

Wenn das Team keinen Mehrwert in der Retro sieht, dann sorge als Scrum Master dafür, dass die Retro interessant wird und Mehrwert entsteht. Dazu sag ich gleich noch was…

Unschön Nr. 11: Murmeltier, die zweite: Wenn die Retro immer gleich abläuft, so nach dem Motto: Jetzt nehmt mal die Post-Its und schreibt auf, was euch nicht gefallen hat und was wir besser machen können, wird auch irgendwann nichts mehr bei raus kommen. Wahrscheinlich wird dann auch sowieso immer das Gleiche aufgeschrieben. Auch hier gilt: Wenn Du Scrum Master bist, betrachte die Retro als Dein wichtigstes Meeting in dem Du dafür sorgst, dass es immer wieder anders und Neu für das Team ist.

Unschön Nr. 12: Retro am Anfang des Sprints: Bitte verstehe die Retro als Schlusspunkt, da das auch mental Auswirkungen hat. Es geht darum, kurz innezuhalten und das vergangene zu reflektieren. Daraus wollen wir dann für die Zukunft lernen. 

Unschön Nr. 13: Keine Doku – Auch wenn das wie ein Relikt aus überkommen Wasserfall-Zeiten erscheint – Wir sollten wissen, was wir in den vergangenen Retros besprochen haben. Daher mach bitte eine Kurze Fotodoku oder Tabelle (gerne auch als ppt) – das tut gar nicht weh…ABER: Achte darauf, dass das nur die Ergebnisse dokumentiert werden und schreibe kein vollständiges Besprechungsprotokoll im Sinne von “dann hat Klaus das und das gesagt und Willi hat darauf geantwortet, dass…., denn die Doku darf nicht in fremde Hände geraten und ist nur für das Team bestimmt. 

Unschön Nr. 14: Retro als Ort der Schuldzuweisungen. Wir haben ja schon mal im Rahmen der Werte drüber gesprochen: Die Suche nach dem Schuldigen bringt uns nicht weiter, wir wollen schließlich Lösungen…Deshalb offenbart eine reine Schuldzuweisungsveranstaltung eine Schwäche des Scrum Masters und auch des Teams in der Kommunikation. Wenn Du Scrum Master bist, achte darauf, dass Du sowas im Keim erstickst – sonst könnte es Dich überrollen und es wird später schwer sich davon zu befreien.

Noch unschöner: Mobbing – wenn das Ganze aus dem Ruder läuft und die Leute sich unter der Gürtellinie tummeln, hole dir externe Unterstützung, da das als Teil des Teams wahrscheinlich kaum noch zu kitten ist.

Unschön Nr. 15: Stakeholder in der Retro: Die Stakeholder sind überall gerne gesehen aber die Retro ist nur für das Scrum-Team – keine Ausnahme…genauso verhält es sich übrigens mit Linien-Vorgesetzten. Das verwandelt die Retro in einen unsicheren Platz – in dem Umfeld traut sich keiner die Wahrheit zu sagen und der Sinn des Ganzen geht verloren.

Unschön Nr. 16: Die Team-Mitglieder sind zwar da, machen aber nicht mit. Versuche hier Vertrauen zu schaffen. Oft passiert das mit Teams aus unterschiedlichen Kulturkreisen. Achte als Scrum Master auch darauf, dass Du die kulturellen Unterschiede in den Teams verstehst und darauf eingehst. Sei aber auch nicht zu ungeduldig oder überfahrend, gerade mit asiatischen oder indischen Kollegen kann das nach hinten losgehen.

Unschön Nr. 17: Veröffentlichte Meeting-Protokolle: Der Verlauf der Retro ist streng vertraulich und nur für das Scrum-Team relevant. Natürlich kann und sollte man die daraus abgeleiteten Action Items nicht auf dem Taskboard verstecken, aber was im Raum abging, geht niemanden etwas an… so lehne freundlich aber bestimmt ab, wenn ein Linienvorgesetzter um die Übergabe von Protokollen bittet….

So – jetzt habe ich wieder länger darüber gesprochen, was man alles nicht machen sollte. Auch hier gilt wieder: Bitte nicht dogmatisch sein. Die Dinge, die ich eben angesprochen habe, sollen Dir – egal welche Rolle Du im Projekt hast  – helfen zu erkennen, dass etwas nicht ganz optimal laufen könnte. Natürlich kann es immer mal vorkommen, dass eine Retro nicht optimal läuft. Das ist auch nicht schlimm. Ich möchte nur, dass Du erkennst, wo vielleicht Probleme hochkommen könnten…

…daher komme ich nun zu den Dingen, auf die ich achte, wenn ich eine Retro machen will…

  1. Das Wichtigste aus meiner Erfahrung: Denk Dir immer wieder was Neues aus. Ich vermeide Wiederholungen, denn sonst wird es schnell langweilig. Mit kleinen Spielen zur Auflockerung oder immer wieder unterschiedlichen Abfragen für ein Brainstorming bzw. zum Sammeln von Ideen macht es allen Teilnehmern – und letztlich auch mir – mehr Spaß. Und wenn es Spaß macht, habe ich meist auch ein besseres Gefühl und Ergebnis.

2. Ich versuche auf die Situation im Team einzugehen und nehme konkrete Dinge zum Anlass darüber zu sprechen, was man besser machen kann

die Lösung liegt immer im Team und nicht bei mir (als Scrum Master). Bitte nichts vorgeben

3 Ich habe mir auch eine Sammlung an von Retrospektiven angelegt, die ich gemacht habe. Du findest im Internet eine Menge Vorschläge (z.B. bei tastycupcakes.org) oder retromat.org

Für mich ist die Retrospektive ist das wichtigste Meeting um das Team besser zu machen. Nicht mehr und nicht weniger…

So dabei will ich es jetzt mal belassen – ich Danke dir fürs zuhören und freue ich über eine positive Bewertung oder vielleicht kannst Du ja auch einer Kollegin oder einem Kollegen den Podcast einfach empfehlen…

Tschüß

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 10: Das Review-Meeting

Tja – Corona hat uns fest im Griff aber keine Sorge – ich mach nicht noch eine Sonderfolge zu Corona…In den Folgen davor sind wir ja schon ein paar Scrum-Meetings durchgegangen und so liegt es nahe in dieser Folge nun mit dem nächsten Meeting weiterzumachen – dem Meeting mit dem sich ein Sprint dem Ende nähert – Dem Review Meeting

Was ist das Review-Meeting? Im Review wird gezeigt, was im Sprint realisiert worden ist, es wird also das geplante Produkt-Inkrement demonstriert.

Nach dem Scrum-Guide ist der Zweck des Meetings, das während des Sprints realisierte Ergebnis zu überprüfen und das Product-Backlog bei Bedarf anzupassen. Es ist also nicht so zu verstehen, dass hier nur gecheckt wird, ob auch alle Userstories erledigt worden sind – der wesentliche Teil des Meetings ist die Diskussion von Ideen und Änderungen, die den Wert des Produktes weiter steigern können und diese dann ins Product Backlog aufzunehmen. Das Review-Meeting hat also nichts mit einem Projekt-Status-Meeting oder einem Abnahmeprozess zu tun. Wichtig ist es auch zu verstehen, „wessen“ Meeting das eigentlich ist: Es ist ein Meeting des Product Owners – Er lädt zum Beispiel wichtige Stakeholder ein und erklärt, welche Features oder Funktionen fertig geworden sind. Er kann auch selbst die Dinge vorführen, im allgemeinen wird das aber dem Dev.-Team überlassen. Dazu bietet es sich an, das Review – ähnlich wie das Planungsmeeting – in 2 Teile aufzuspalten: der erste Teil dient der Präsentation des Erreichten und der zweite Teil ist eine Diskussion über das Feedback, die Dinge, die sich daraus ergeben und als nächstes zu tun sind, die Überprüfung von Auslieferterminen, Erwartungen, Budget usw. 

Das Ergebnis des Reviewmeetings ist daher nicht eine Liste von abgenommenen Userstories sondern ein überarbeitetes Product Backlog, in das die Erkenntnisse des beendeten Sprints eingeflossen sind.

Von dieser Beschreibung des Reviews aus dem Scrum-Guide weicht das richtige Leben – wie sollte es anders sein – mal wieder an der ein oder anderen Stelle ab und das wirkt sich meistens negativ auf den Projektverlauf aus (auch wenn man das nicht wahr haben möchte).

Daher kommen jetzt ein paar Abweichungen, vor denen ich Dich warnen möchte: Nicht weil ich es besser weiß, sondern weil diese Abweichungen Deinem Projekt schaden werden…

Abweichung Nr. 1: Es gibt gar kein Sprint-Review: Der Product Owner ist ja eng mit dem Team verbunden und kennt ja sowieso durch die Daily-Standups schon, was die Leute gemacht haben. Ein Review wäre dann ja nur Zeitverschwendung…Und was ist mit den Stakeholdern? Wie können neue Ideen entstehen, wenn man das Erreichte nicht nochmal klar vor sich sieht? Und vielleicht auch mal ausprobiert? Denke daran, dass das Reviewmeeting den Zweck hat Feedback zu bekommen und neue Userstories – also Verbesserungen – anzuregen. Ohne den offiziellen Rahmen eines Reviewmeetings findet das nicht statt und du beraubst Dich eines der wesentlichen Vorzüge von Scrum.

Abweichung Nr. 2: Das Sprint-Review als Projekt-Statusreport: wir haben geliefert: 10 Userstories mit 42 Tasks, 2 Bugfixes – prio 1, 3 Bugsfixes Prio 2 und 3 andere. Insgesamt wurden 53 Storypoints erreicht, das macht eine Steigerung von 5% gegenüber dem letzten Srint…So vorzugehen zeigt auch, dass der Sinn des Reviews und womöglich sogar der Sinn des ganzen Projektes vom Scrum-Team gar nicht verstanden wurde. Es sollte immer um Inhalte gehen und nicht um KPI‘s.

Abweichung Nr. 3: Die Powerpoint-Schlacht: Hochglanzfolien zeigen dem Management, was das Team alles Tolles erreicht hat. Nur: Hätte das Team sich nicht den halben Sprint mit der Erstellung und Abstimmung von Folien für das geneigte hochrangige Publikum aufgehalten, wäre viel mehr Nutzen für das Unternehmen möglich gewesen…Die Transparenz kommt durch die Live-Demo, nicht durch aufgehübschte Folien, die womöglich noch geschönt sind und von Problemen ablenken…Ausserdem schlafen alle ein, wenn das Reviewmeeting in einen Vortrag mit 83 Folien mutiert. Also heißt die Devise: zeigen statt erzählen!

Abweichung Nr. 4: Buchhalterei: Jeder präsentiert für sich genau die Userstories, die er umgesetzt hat. Die anderen hören gar nicht mehr zu. Es geht nur um das Abhaken der Story durch den Product Owner, nicht um eine integrierte Lösung oder ein gemeinsames Produktinkrement, die Stakeholder verstehen im schlimmsten Falle gar nicht, was das überhaupt mit ihrem Produkt zu tun hat… Wichtiger wäre es am Anfang des Meetings klar das Sprintziel herauszustellen und welchen Nutzen die Stakeholder mit den realisierten Features haben. Es geht nicht darum im Review zu beweisen, dass jeder Task umgesetzt wurde, sondern welcher Nutzen für den User erreicht wurde. Dinge, die für den Stakeholder nicht relevant sind, brauchen auch gar nicht gezeigt zu werden. Das Team sollte sowieso darauf achten, keine technischen Schulden aufzubauen oder Tests und Doku’s zu unterschlagen. Das rächt sich später und das sollte das Team auch verstanden haben.

Abweichung Nr. 5: Nebenschauplätze im Sprint.   Blöd ist auch, wenn das Team Dinge macht, die gar nicht im Planungsmeeting besprochen wurden und der Product Owner dann im Reviewmeeting das erste Mal damit konfrontiert wird. Schließlich bestimmt der Product Owner ja WAS gemacht wird und das Dev.Team bestimmt WIE es gemacht wird und nicht anders herum. Wenn Du das als Scrum-Master merkst, gehe dazwischen und sorge für Transparenz: entweder der Product Owner muss involviert werden oder es laufen irgendwelche Linenmanager durch die Gegend, die in den Teams Arbeit am Product Owner vorbei verteilen. Das musst Du als Scrum Master dann unterbinden…

Abweichung Nr. 6: Das Dev-Team ist nicht anwesend: „Die anderen müssen noch ein wichtiges Update einspielen, ich bin heute alleine da“…Autsch – Im Review wird das Inspect and Adapt durchgeführt, also hier kommen die wichtigen Infos – also das Feedback – hoch und dieses Feedback muss vom Dev.-Team auch verstanden werden, damit der Sinn der Arbeit deutlich wird und die Anwendungsfälle oder die Bedienung durch die Kollegen vom Fachbereich klar wird. Nur so kann gemeinsam eine weitere Verbesserung erreicht werden. Wenn nicht alle dabei sind, fällt dieser entscheidende Punkt weg und über kurz oder lang leidet die Motivation der Dev.-Team Mitglieder und das Projekt gerät aus dem Fokus…

Abweichung Nr. 7: Keine Stakeholder anwesend: Das Review lebt vom Feedback. Wenn keiner da ist, der Feedback geben kann, gibt es keinen Fortschritt und keine kontinuierliche Verbesserung. Ausserdem kann das auch ein Gefühl von Desinteresse verursachen und wäre somit ein Demotivator für das Team.

Abweichung Nr. 8: Besprechung von nicht fertigen Stories: Unfertige Userstories haben im Review nichts zu suchen. Erstens ziehen sie das Meeting in die Länge, weil man sich um Dinge kümmert, die noch gar keinen Nutzen bringen weil sie noch gar nicht funktionieren und zweites läuft man natürlich in die Gefahr Schuldige zu suchen und darüber zu diskutieren, warum was nicht fertig geworden ist.

Abweichung Nr. 9: Der selbstsüchtige Product Owner: Der Product Owner präsentiert im Review den Stakeholdern, was ER umgesetzt oder was ER erreicht hat. Sowas kommt beim Dev.-Team nicht gut an –  Es geht hier immer um eine Teamleistung – der Product Owner ist nichts ohne das Team und das Team ist nichts ohne den Product Owner. Solltest Du also Product Owner sein, denke bitte daran, hier nicht zu übertreiben…

Abweichung Nr. 10: Der feedbackresistente Product Owner: Wenn Du als Product Owner der Meinung bist, Du weißt was für die Stakeholder oder Kunden besser ist als sie selbst, dann wird es schwierig. Auch hier gilt: es geht immer um die Sache und nicht um Deine persönliche Profilierungen. Keine Angst – die kommt automatisch, wenn du deine Stakeholder einbeziehst.

Abweichung Nr. 11: Schwindeln….ich will es nicht betrügen nennen, aber wenn das Dev.-Team Dinge vorführt, die eigentlich noch voller Bugs stecken und somit die DoD nicht erfüllen, macht man sich was vor. Alle müssen ehrlich miteinander umgehen – sonst seid ihr nicht transparent und es wird was verheimlicht…und das fällt euch später auf die Füße (alte Regel!)

Abweichung Nr. 12: Verfolgen eines Projektplans…Im Review wird heimlich ein schon vorher verabschiedeter Projektplan umgesetzt und die erreichten Arbeitspakete abgehakt. Es wird nicht über den aktuellen Status des Projekts oder des Produkts gesprochen und es wird kein Feedback eingeholt und vor allem, es wird nichts am Backlog geändert um den Ergebnissen der Diskussion Rechnung zu tragen… dann sind wie wieder im Wasserfall gelandet…und das Team wird keine Verbesserung erreichen können…

Abweichung Nr. 13: keine Kunden anwesend: Das wird wahrscheinlich nicht immer die Regel sein können, aber denke mal darüber nach, auch zahlende Kunden für dein Produkt zum Review einzuladen um das WIRKLICHE Feedback einzuholen. Das bringt mehr als immer nur dem eigenen Fachbereich zuzuhören, der oft genug selbst in einem Elfenbeinturm sitzt und gar nicht weiß, worauf es dem zahlenden Kunden wirklich ankommt.

Abweichung Nr. 14: Alles immer neu erklären…Wenn die Stakeholder immer wieder wechseln und immer wieder neue Leute auftauchen, denen man in jedem Review das Projekt erstmal von Grund auf erklären muss, dann hält das auf der einen Seite nur auf, auf der anderen Seite ist es nicht möglich ein fundiertes Feedback zu erhalten, was essentiell für das Review-meeting ist. Hier wäre wieder ein Ansatzpunkt für Dich als Product Owner oder Scrum Master in einer Retro drüber zu sprechen und dafür zu sorgen, dass Stakeholder auch für längere Zeit oder über das ganze Projekt eine Verantwortung dafür übernehmen und sich ihrer Bedeutung für das Projekt auch bewusst werden.

Abweichung Nr. 15: Passive Stakeholder. Wenn die Stakeholder passiv und unengagiert sind, ist nur noch nicht das Feuer in ihnen entfacht. Du kannst zum Beispiel als Scrum Master dann dafür sogen, dass die Stakeholder selbst das Review moderieren oder organisiere das Review als Messe mit verschiedenen Ständen, in denen die neuen Funktionen gezeigt werden. Natürlich nicht immer aber es kann eine gute Initialzündung sein, um die Stakeholder zu aktivieren.

Abweichung Nr. 16: Review als Tachometer: Wenn der einzige Zweck des Review ist, zu zählen wieviele Userstories oder Backlogitems umgesetzt worden ist um letztlich die Velocity des Teams zu ermitteln, dann läuft auch was falsch.. Es geht nicht um KPI-Ermittlung – es geht um Feedback und Optimierung des Produkts…

Da komme ich doch gleich nochmal zur Velocity – was ist das eigentlich: also die Velocity ist die Summe aller Storypoints, die das Team wirklich erreicht hat (also gezählt werden nur die Stories, die „done“ sind, angefangene und nicht abgeschlossene Stories werden nicht gezählt!). Die Velocity wird oft als Maß für die Teamperformance verwendet und es wird viel zu viel Bedeutung darein gelegt. 

Die Performance eines Teams misst sich nicht in der Velocity, sondern am Wert, den das Team für das Unternehmen schafft, in dem es Dinge umsetzt, die nützlich sind. Die Velocity ist nur eine Hilfsgröße um es dem Team im Planungsmeeting leichter zu machen, den Umfang des Sprint-Backlogs möglichst realistisch abzuschätzen. Dabei ist es natürlich sinnvoll zu wissen, was man als Team in der Vergangenheit so geschafft hat…Für mehr sollte die Velocity nicht verwendet werden – erst recht nicht dazu, mehrere Team miteinander zu vergleichen. Jedes Team entwickelt eine eigene Metrik im Umgang mit den Storypoints, daher macht es gar keinen Sinn die Teams zu höheren Zahlen zu treiben. Das fördert höchstens Output, also die Produktion von Fehlern und Waste und hat nichts mit Motivation zu tun…

Soweit dazu…

Aber -Es ist wie überall – und daran möchte ich nochmal erinnern: Gehe nicht zu dogmatisch vor! Wenn gute Gründe vorliegen, mal von den eigentlichen Idealen des Scrum abzuweichen, dann ist das nicht verboten. Du musst nur wissen, dass das dann tendenziell dazu führt, dass ihr weniger effizient im Projekt arbeitet, als es möglich gewesen wäre…

so 

Nachdem ich jetzt die ganze Zeit mehr oder weniger darüber geredet habe, was man alles NICHT machen soll, hier noch ein paar Fragen, die Du stellen kannst, um ein geeignetes Feedback von Deinen Stakeholdern zu bekommen: Die Teilnehmer können die Antwort jeweils auf ein Post-It schreiben und ihr könnt das dann im Anschluss auswerten…

Hilfreich ist es zum Beispiel nach Skalen zu fragen – also sowas wie: Wie wahrscheinlich ist es, dass Du das Produkt einem Freund oder Kollegen empfehlen würdest (auf einer Skale von 0 = unwahrscheinlich bis 10= auf jeden Fall)

oder Wie perfekt ist das Produkt auf einer Skala von 0 bis 10 – wenn Du keine 10 gibst, was fehlt dem Produkt um eine 10 zu erreichen?

Eine andere Frage wäre:  Wie würdest Du das Produkt benutzen? Würdest Du das Produkt selbst- persönlich auch benutzen? – Warum? oder Warum nicht?

Oder als Demo: bitte benutze das Produkt für die nächsten 5 Minuten und erzähle uns alles was dir dazu einfällt.-

Oder eine Story: Erzähle uns bitte mal, wie du das Produkt zu hause oder bei der Arbeit benutzen würdest. 

Oder das „Bauchgefühl“ – das finde ich auch immer sehr gut: Wenn Du nur ein Wort hättest: Was fällt Dir zu dem Produkt ein?

oder – Dinge wie: wenn dieses Produkt einen Geruch hätte, welcher Geruch fällt dir dazu ein, oder wenn dieses Produkt ein Auto – oder ein Tier wäre: welches fällt Dir dazu ein? (hier kommt gut raus, ob es zum Beispiel ein „Ferrari“ oder eine lahme Ente ist oder wie auch immer…

Konkret kannst Du auch fragen: Wenn Du eine Sache hinzufügen könntest, was würde das sein?

oder – wenn Du eine Sache weglassen müsstest, was würde das sein?

Oder natürlich die starken Gefühle wie Liebe und Hass: was liebst Du am meinsten an dem Produkt – oder was kannst DU am wenigsten leiden?

Du kannst das Ganze natürlich auch von der anderen Seite aufziehen…wie können wir das Produkt richtig schlecht machen, sozusagen, was wäre der absolute Albtraum von einem Produkt? – um hinterher die Sichtweise umzudrehen und darüber nachzudenken, wie man sowas vermeiden kann…

So Ich denke, du hast nun einen Überblick davon, worum es in einem Sprint-Review eigentlich geht. 

Ich danke Dir fürs zuhören und würde mich über eine Bewertung in iTunes sehr freuen. Bitte Teile auch den Link zum agilophil-daily podcast, so das wir eine immer größere Gruppe von agilophilen Menschen werden…sharing is caring…

NEU: Tschüß – dein agilophiler Frank

Agilophil-Daily Podcast Episode 08: Das Daily Standup und was ein Scrum Master den ganzen Tag so macht…

Die Frage kommt öfters – ich habe mal bei einem Barcamp bei Siemens eine kleine Session über Scrum gegeben. Das ist ja immer sehr interessant, denn Scrum ist zwar in der Info-Blase, in der ich mich bewege ein alter Hut, aber es gibt da draussen ja noch große Bereiche, in denen das überhaupt kein Thema ist und man sich bisher noch gar nicht damit beschäftigt hat.  Und so kam auch hier wieder beim Scrum Master – als ich kurz die Rollen erklärt habe – die Frage: Was macht so ein Scrum Master eigentlich den ganzen Tag? Der hat ja eigentlich nicht viel zu tun, muss nur die paar Scrum-Events moderieren (also am Anfang das Planungsmeeting, dann jeden Tag ne viertel Stunde ein Daily Standup und dann noch das Review und die Retro, also ist er bei einem Zwei Wochen-Sprint nur 2 Tag ausgelastet und sonst nur eine viertel Stunde täglich beschäftigt…

Es liegt also nahe, dass Scrum-Master ein Job ist, den man so neben der Linien oder Dev.-Teamrolle so mitmachen kann. Es braucht also eigentlich keine eigene Person dafür…

Nun muss ich als Scrum Master mich natürlich rechtfertigen und sagen; NEIN, so einfach ist das nicht, der Scrum Master hat VIEL zu tun und ist unheimlich WICHTIG….ich will jetzt mal von dieser Frage etwas abschweifen und Dir später die Möglichkeit geben, die Frage selbst für Dich zu beantworten…

Kommen wir erstmal zu Daily Scrum oder auch Daily Standup genannt:

Nach dem Sprint-Planungsmeeting geht ja die Arbeit im Sprint los. Um während des Sprints die Transparenz im Team sicherzustellen, also dafür zu sorgen, dass jeder weiß was jeder andere im Team macht, woran er gerade arbeitet und was aktuell bremst, gibt es jeden Tag ein kleines Meeting, in dem maximal 15min lang darüber gesprochen wird: das Daily Standup oder kurz “Daily”. Standup wird es deshalb genannt, weil es am besten ist, das Meeting stehend vor dem physikalischen Taskboard durchzuführen – also nicht vor einem virtuellen Taskboard in einem Tool wie Jira oder Trello, sondern tatsächlich mit Zetteln an der Wand.

Nun ist das ein sehr kleines Meeting aber auch ein sehr wichtiges. Daher auch hier wieder ein paar Punkte, die Du vermeiden solltest, wenn Du als Scrum-Master unterwegs bist aber natürlich auch, wenn Du als Mitglied des Dev.-Teams oder als Product Owner dabei mitmachst.

Dinge, die Du beim Daily vermeiden solltest:

Nr. 1: Keine Routine: Wenn das Daily nicht an jedem Tag zum selben Zeitpunkt stattfindet, ist die Gefahr groß, dass es vergessen wird oder nur wenige Leute teilnehmen. Lass den Tag am besten mit dem Daily beginnen oder setze einen festen Termin kurz vor dem Mittag: Das hat dann auch den Nebeneffekt, dass alle gleich zum Essen wollen und deshalb das Meeting nicht zu lange dauert…

Nr. 2: Daily als Statusmeeting: Bitte achte darauf, dass das Daily kein Statusmeeting ist, in dem jeder kurz dem Product-Owner oder dem Scrum-Master berichtet, wie der Fortschritt ist. Das Daily dient dem Team. Damit jeder weiß, woran der andere arbeitet, wo vielleicht Hilfe benötigt wird oder gerade nichts zu tun ist. Und damit jeder weiß, ob gerade Probleme auftauchen und welche das sind.

Nr. 3:  Daily nur als Aufzählung von Ticketnummern: Bitte kein lustloses: Gestern habe ich an Ticket 4711 gearbeitet und heute mache ich 4712. Probleme habe ich keine…Damit erreichst Du keine Transparenz. Bitte erzähle was Du gemacht hast und erzähle was Du heute bzw. gleich machen willst. Dokumentiere das, indem du die entsprechenden Zettel an der Wand bewegst. Und bitte verschweige keine Dinge, die dich an irgendwas hindern…Der Überbringer von schlechten Nachrichten wird hier nicht geköpft (Du sollest das, falls Du Scrum-Master bist, jedenfalls strengstens vermeiden)

Nr.4: Probleme gleich im Daily lösen: Bitte nicht ->Das Daily ist dazu da in kurzer Zeit Transparenz zu schaffen. Wenn Ihr gleich alle Probleme hier lösen wollt, wird das Meeting täglich Stunden dauern. Nein: Wenn Problem hochkommen, dann vertagt Euch mit der Besprechung auf später. Und nur die Betroffenen machen dann einen Termin aus um das Thema zu klären und nicht das gesamte Team!

Nr. 5: Verstecktes Planungsmeeting. Ähnlich wie Nr. 4: Hier werden keine neuen Anforderungen besprochen, hier werden keine Userstories angepasst oder geändert oder neue geplant. Dazu gibt es die entsprechenden Meetings wie Planung oder Refinement. Beim Daily geht es nur und das, was ihr jetzt macht -hier und jetzt – Um das geht es und um nichts anderes.

Nr. 6: nicht zuhören…Wenn ein Team-Mitglied über mehrere Tage Schwierigkeiten bei der Lösung einer Aufgabe hat und keiner Hilfe anbietet…kann das daran liegen, dass die Auslastung im Team zu hoch ist (es sind keine Zeitpuffer mehr vorhanden) oder dass man sich untereinander nicht vertraut…Bitte achte hierauf, falls Du Scrum-Master bist und gebe mal geeignete Trigger…

Nr. 7: Monologe: Die Leute kommen nicht zum Punkt und missachten das Timeboxing. Sorge als Scrum-Master dafür, dass die Leute in der Zeit bleiben und dass ihr nals Team die 15min einhaltet (Aber auch hier gilt natürlich wieder – nicht zu dogmatisch sein. Bitte nicht das Meeting nach 15min abbrechen, wenn nicht jeder was gesagt hat. Aber gibt deutliche Hinweise. Falls Du im Dev.-Team bist, denke einfach daran, dich kurz zu fassen. Jeder soll dran kommen und Du möchtest ja auch wissen, was die anderen tun…)

Nr. 8: Wir kennen das vielleicht noch aus der Muppet Show: Statler and Waldorf. Wenn ein paar Team-Mitglieder jeden Punkt kommentieren ist das nicht nur Zeitverschwendung sondern auch respektlos und nervig.

Nr. 9: Respektlosigkeit II: Ebenso ist es respektlos, wenn sich Team-Mitglieder unterhalten, während jemand anderes gerade dran ist und über seine Arbeit spricht. 

Nr. 10: Aufgabenverteilung durch PO oder Scrum-Master: Das Dev.-Team entscheidet grundsätzlich wer was macht um das gemeinsame Zeil zu erreichen. Aufgaben werden nicht von oben delegiert.

Nr. 11: Ahnungslosigkeit: “Ich kann mich nicht mehr erinnern, was ich gestern gemacht habe”- Sowas geht natürlich gar nicht. Man kann auch mal nichts für das Projekt gemacht haben, weil vielleicht eine wichtige Linienaufgabe dran war. Aber dann sollte das auch offen kommuniziert sein und das wäre dann auch eher ein Hindernis…

12.: Respektlosigkeit III: Die Leute kommen zu spät zum Daily. Wenn Du Scrum-Master bist, erziehe die Leute zu einer gewissen Disziplin…Oft hat dabei schon ein kleines Sparschwein geholfen…Jede Minute zu spät = 1 Euro…(das gesammelte Geld dann natürlich nur für Teamevents zu nutzen…)

Nr. 13: Feedback-Stress: Wenn Team-Mitglieder andere Team-Mitglieder gleich im Daily kritisieren und Diskussionen vom Zaun brechen, solltest Du als Scrum-Master einschreiten. Kritik muss offen besprochen und geklärt werden, aber nicht im Daily, sondern danach. 

Nr. 14: zu viele Teilnehmer: Ein Scrum-Team hat bekanntlich zwischen 3 und 9 Mitglieder. Wenn sich 20 Leute im Daily tummeln und jeder was zu sagen hat, haltet Ihr die 15min niemals ein…

Nr. 15: Unbeteiligte reden mit: Das Daily ist für das Entwicklungsteam. Es dient nicht dazu, das Stakeholder Kommentare abgeben oder aktiv teilnehmen. Sicherlich kann man mal ne Frage zulassen aber achte auf dem eigentlichen Zweck des Dailies.

Nr. 16: Linienvorgesetzte wollen im Daily die Performance von einzelnen Mitarbeitern beurteilen. Das ist nicht agil und zeigt einen sehr geringen agilen Reifegrad des Unternehmens. Es geht um die Selbstorganisation des Teams und nicht um Performance jedes einzelnen.

Soweit erstmal zu den Dingen, die ein Daily torpedieren können. Vielleicht fallen Dir auch noch ein paar Dinge ein, die in einem Daily schief laufen können. Falls ja, kannst Du dich gerne melden – z.B. über das Kontaktformular auf meiner Webseite agilophil.de

Aber kommen wir nun mal zurück zu der Frage, was ein Scrum-Master eigentlich den ganzen Tag so macht…

Im Scrum-Guide steht folgendes zu den Aufgaben eines Scrum-Masters:

Der Scrum-Master…

  • Ist ein Servant Leader für das Scrum-Team
  • schützt das Scrum-Team vor unnötigen Einflüssen von außen
  • moderiert bei Bedarf oder Notwendigkeit die Meetings 
  • hilft in methodischen Fragen dem Product Owner
  • coacht das Entwicklungsteam in Selbstorganisation und Cross-Funktionalität
  • beseitigt Impediments oder Hindernisse
  • hilft der Organisation bei der Scrum-Einführung
  • hilft anderen, Scrum zu verstehen
  • arbeitet an Organisationsveränderungen, die dem Team helfen, produktiver zu sein
  • arbeitet mit anderen Scrum Mastern zusammen, um die Effektivität von Scrum in der Organisation zu verbessern

Das klingt jetzt ein bisschen statisch, aber letztlich ist der Scrum-Master das Mädchen für alles, was es braucht, damit das Team besser arbeiten kann. Du darfst Dir dabei nicht zu schade sein, auch mal durch das Büro zu laufen und neue Stifte für das Whiteboard zu besorgen oder mal den Kaffee aufzusetzen. Aber lass Dich als Scrum Master oder Scrum Masterin nicht darauf reduzieren nur die Sekretärinnen-Arbeiten zu übernehmen. Du hast immer 3 Hüte auf: einen des Trainers oder der Trainerin, die allen, die es wissen müssen, Scrum beibringt. Dann den Hut des Beraters oder der Beraterin, die Hinweise gibt, wie man sich in machen Situationen verhalten sollte oder was man bei Problemen tun kann. Und letztlich noch die Mütze des Coaches, der bei Problemen im Team Lösungen durch geeignetes Fragen finden kann (Merke: ein Coach hat nie selbst die Lösung, sondern lässt den Coachee die Lösung selbst finden in dem er geschickt Fragen stellt.) 

Hier also noch ein paar Beispiele für Dinge, die ein Scrum-Master so macht. Was ich jetzt aufzähle, ist aber kein “Must Do” oder irgendwo festgeschrieben, sondern das sind alles Vorschläge und Ideen – Vieles von dem kann auch vom Product Owner oder vom Team übernommen werden, je nachdem wer Zeit dafür hat oder es am besten und schnellsten kann. Denke an den Teamgedanken. Wenn Du dich zurücklehnst und sagst, “das muss der Scrum-Master machen” und dich heimlich darüber freust, wenn kein Raum zur Verfügung steht und Du somit die Inkompetenz des Scrum-Masters deutlich machen kannst, hat das nichts mit Teamarbeit und Fokus auf ein gemeinsames Ziel zu tun. Das ist dann weit entfernt vom so oft beschworenen “agilen Mindset”.

Am sichtbarsten ist der Scrum Master natürlich bei allen Scrum-Meetings. Insbesondere sorgt er oder sie dafür, dass die Meetings regelmäßig stattfinden und die gewünschten Ergebnisse erreicht werden. Hier gilt es also eine Terminserie einzustellen, damit frühzeitig klar ist, wann die Sprints beginnen und enden, Räume zu buchen und sonstige Vorbereitungen zu treffen (wie z. B. ein paar Kekse oder Snacks zu besorgen). Beim Planungsmeeting kann – zumindest am Anfang – aber auch der Product Owner die Moderation übernehmen und beim Review das Team. Es ist auch durchaus sinnvoll das mal wechseln zu lassen, damit keine Langeweile im Sprint 34 aufkommt…

Die Retrospektive hingegen ist DAS Meeting des Scrum-Masters. Hier ist es wichtig, möglichst keine Routine aufkommen zu lassen und sich immer etwas Neues einfallen zu lassen. Kleine Spielchen, die die Teamsituation betreffen, oder unterschiedliche Abfragen, auf die ein Brainstorming folgen kann oder oder oder…Das Ergebnis der Retro ist mindestens eine Maßnahme, die direkt im nächsten Sprint umgesetzt werden sollte und die dazu dient, die Teamarbeit zu verbessern. Und das ist auch das Ziel des Scrum-Masters…

Zwischen den Meetings liegt die Haupttätigkeit des Scrum Masters in der Arbeit mit dem Team. Dazu gehört zu einem großen Bestandteil auch das reine Beobachten und Kennenlernen – Das Team sollte – besonders am Anfang- keinen Grund haben, dem Scrum Master zu misstrauen, aber ist es wichtig alle Mitglieder des Teams auch kennenzulernen und mit ihnen zu sprechen und anzusehen, wie alle miteinander im Team interagieren. Dazu gehört es auch, mal ein Teamevent zu organisieren, also gemeinsam zum Abendessen zu gehen oder mal Bowling zu spielen oder Kart zu fahren oder die sonstigen Dinge, die Spaß machen – oder einfach nach Feierabend mal mit den Teamkollegen ein Bierchen zu trinken. Das schmeckt auch alkoholfrei…

Das nächste große Thema des Scrum Masters sind die Impediments. 

Der Scrum Master ist für die Beseitigung von Hindernissen zuständig. Dazu müssen diese erstmal aufgedeckt und gelistet werden. Hierzu bietet sich eine klassische to-do Liste an, wie sie ja gerne in Excel gepflegt wird aber natürlich sollte alles möglichst transparent sein, also auch irgendwie neben dem Taskboard auftauchen. Es geht darum, die Impediments zu beseitigen, das heißt aber nicht, dass der Scrum Master alleine alles lösen muss. Wenn Du Scrum-Master bist, dann sammle die Punkte und adressiere sie oder leite sie weiter und zwar so lange, bis sie gelöst sind. Hier kommt auch das unschöne Wort “Eskalation” ins Spiel – scheue Dich nicht davor, Langläufer bei oberen Hierarchiestufe bekannt zu machen, damit dann was passiert. In diesem Punkt ist die Arbeit des Scrum Master der des klassischen Projektmanagers am ähnlichsten – mit der Ausnahme, das der Scrum Master nicht wie der klassische Projektmanager automatisch an allem Schuld ist…

Es gibt noch eine ganze Menge mehr Dinge, die ein Scrum Master den ganzen Tag so macht und wenn Du Scrum Master bist, frage Dich einfach nur:  „Was kann ich tun, damit es allen besser geht oder alle besser zusammenarbeiten können?“ Dann fällt Dir bestimmt noch viel ein…

Damit möchte ich die 6.Folge beenden und danke Dir fürs Zuhören. 

Tschüß Dein agilophiler Frank

Für die Shownotes: weitere Tipps, was ein Scrummaster den ganzen Tag so macht, findest Du in einem viel beachteten Beitrag von “IT-agile”: 

Agilophil-Daily Podcast Episode 07: Dinge, die im Sprint-Planungsmeeting falsch laufen können…

Der Sprint beginnt mit dem Planungsmeeting und wenn man mal voraussetzt, dass Du vorher das Backlog im Refinement in Ordnung gebracht hast, dann kann eigentlich gar nicht viel schief gehen. Leider passieren oft – auch bei mir – im Planungsmeeting Dinge, die dafür sorgen, dass das Meeting oder eben der Sprint hinterher nicht optimal läuft. 

Doch zunächst einmal: 

Wozu dient das Planungsmeeting überhaupt? Sinn des Planungsmeetings ist es, dass sich Team und Product-Owner auf das nächste auslieferbare Produktbestandteil – also das sogenannte Produkt-Inkrement einigen. 

Das Sprint Planungsmeeting beantwortet also folgende Fragen:

  1. Was ist in dem Produktinkrement des kommenden Sprints enthalten?
  2. Wie wird die für die Lieferung des Produktinkrements erforderliche Arbeit erledigt?

Sehr oft teilt man das Planungsmeeting daher auch in 2 Teile ein: Das Planungsmeeting 1, in dem gemeinsam mit dem Product Owner das Ziel und die Aufgaben oder Userstories für den nächsten Sprint festgelegt werden und das Planungsmeeting 2, in dem das Team zur Detailplanung übergeht und die einzelnen Teilaufgaben, die so genannten “SubTasks” bespricht und festlegt. Das Ergebnis des Planungsmeetings ist das Sprint-Backlog als Sammlung aller Aufgaben inklusive der SubTasks, die vom Team im anstehenden Sprint umgesetzt werden. Dieses Sprint-Backlog stellt also den Forecast – also die Prognose dar. Das Dev.-Team ist der Meinung, dass es den gewünschten und besprochenen Nutzen erreichen kann. Dabei hat das Team natürlich auch berücksichtigt, dass vielleicht ein Kollege 2 Tage im Urlaub ist und eine Kollegin eine ganze Woche auf einer Schulung…Der Begriff Commitment oder Selbstverpflichtung ist hier gefährlich, da es damit oft zu Fehlinterpretationen kommen kann (also wenn ein Team sich verpflichtet, wird wahrscheinlich hinterher die Suche nach Schuldigen losgehen, falls nicht alle Stories geschafft werden. Das wollen wir hier aber nicht…). Daher übersetze ich Commitment lieber mit  “Bekenntnis”, denn das ist etwas, was aus dem Herzen kommt und keine Pflicht!

Also nochmal die einzelnen Teile:

Im Planungsmeeting 1 beschreibt der PO das Ziel – also genauer den Nutzen – den er gemeinsam mit dem Team im Sprint erreichen will – man diskutiert das gemeinsam und man einigt sich darauf, was man erreichen kann.  Das Team zieht sich die Userstories raus, mit denen das Ziel am besten erreicht werden kann. Notfalls werden noch neue Userstories geschrieben um neuen Erkenntnissen (z.B. aus dem letzten Sprint oder Kundenfeedback) zu berücksichtigen. Großartige Inhaltliche Diskussionen um die Stories sollten nicht mehr vorkommen, denn das wurde bereits im Refinement besprochen. Auch die Schätzung der Aufgaben ist für die meisten Stories schon im Refinement geschehen und sollte nur noch überprüft werden. Am Ende des Planungsmeetings 1 haben wir dann die Liste der Userstories und das Sprintziel. Der PO kann jetzt eigentlich das Meeting verlassen und das Team macht (ggf. noch zusammen mit dem Scrum-Master) alleine weiter. 

Also nochmal, um es zu betonen: der Product Owner beschreibt das Ziel, welches er erreichen möchte aber nicht er, sondern ausschließlich das Dev.-Team bestimmt die Anzahl der Product-Backlog-Einträge für den kommenden Sprint! Denn das Team entscheidet, was machbar ist!

Im Planungsmeeting 2 werden die Userstories vom Team einzeln besprochen und es werden die Arbeitsschritte und Details geklärt, die notwendig sind um den gewünschten Nutzen zu erreichen. Das betrifft insbesondere die technische Umsetzung, die vom Team designed wird und nicht vom PO vorgegeben. Sollten nicht noch gravierende Zeifel aufkommen und man den PO nochmal zur Abstimmung braucht, kann danach der Sprint gleich gestartet werden.

Auch hier nochmal: Die Betonung liegt darauf, dass das Team entscheidet, wie umgesetzt wird und wer was macht. Der Product Owner gibt keine Designvorgaben und niemand ausser dem Dev.-Team selbst entscheidet, wer was macht.

Noch ein kleines Wort zum Sprintziel: Das Sprintziel gibt dem Dev.-Team Orientierung und beantwortet die Frage warum wir das aktuelle Produktinkrement bauen. Es bietet aber auch eine gewisse Flexibilität bei der Umsetzung muss also aus einer gewissen Flughöhe formuliert sein. Bei der Arbeit im Sprint behält das Team das Ziel immer vor Augen. Wenn Du also Scrum-Master bist, solltest Du das Ziel auch ausdrucken bzw. groß und für jeden Sichtbar aufschreiben und am Task-Board aufhängen.

Soweit so einfach…jetzt komme ich mal zum richtigen Leben:

Was das Dev.-Team alles falsch machen kann…

Sind alle im Meeting da? Schlecht ist es, wenn im Planungsmeetings die Leute, die etwas machen sollen oder wollen nicht da sind. Fasse das Planungsmeeting als Pflichtveranstaltung auf! Nur wenn Du dabei bist, kannst du auch gestalten! Es gibt also keine Entschuldigung nicht dabei zu sein, ausser vielleicht Familie, Kinder, Krankheit…

Sind alle während des Sprints verfügbar? Überlege selbst und sage es offen, wenn Du im Sprint nicht voll zur Verfügung stehst, Urlaubstage hast oder auf Schulungen gehst oder zu Messen gehst…Sonst passiert es leicht, dass ihr Euch als Team überschätzt und Euch damit selbst unnötig unter Druck setzt.

Beachte die technischen Schulden: plane immer ein Viertel der Zeit für Bugfixing ein!! Keine Software wird ungestestet ausgeliefert und das ist ein ehernes Gesetz! Daran gibt es nichts zu rütteln!

Keine “Slack-Time” / “Zeitpuffer” – plane immer einen Zeitpuffer für das Tagesgeschäft ein! Es passiert aber immer irgendwas, was nicht planbar ist, es ruft jemand an, man sitzt zusammen, weil ein Teammitglied eine Frage hat, man spricht am Kaffeeautomaten über wichtige Themen usw…Diese Dinge gibt es, es ist Realität und daher muss das im Sprint auch vorgesehen werden. Wird das nicht berücksichtigt, hechelt das Team die ganze Zeit den Aufgaben hinterher und fokussiert sich auf Output. Wenn sich alle nur auf Output konzentrieren, bleibt die Zusammenarbeit und der gemeinsame Austausch auf der Strecke. Fataler Weise leidet damit dann die Nutzenorientierung – also das, was in englisch gerne mit Outcome – also als Auswirkung – bezeichnet wird.

Plane nicht zu detailliert!: im Planungsmeeting wird zwar “feingeplant” aber sei dabei nicht zu granular oder detailverliebt. Wenn du 2/3. der Subtasks planst ist das völlig ausreichend. Es muss nicht alle “minutiös” in Einzelschritte zerlegt werden. Während der Arbeit bist Du als Teammitglied ja auch in der Lage die Tasks, die sich beim “tun” ergeben, neu hinzuzufügen.

Zu detaillierte Schätzungen: Schätze nicht jeden einzelnen Subtask, Du brauchst nur ein Bauchgefühl für die Größe der Dinge und Deine Erfahrung, was Du so schaffst…Schätze nicht um des Schätzens willen, wir wollen hier keine Bürokratie aufbauen – und ein Zeit-Tracking ist auch eher hinderlich (es sei denn, du machst es nur für Dich persönlich, um besser zu werden)

Zu wenig Planung: Führe das Sprintplanungsmeeting 2 mit dem Team in jedem Fall durch. Wenn ihr das weglasst, leidet die Transparenz,  denn hier wird viel Wissen im Team geteilt. Wenn man gemeinsam bespricht, wie man sich die Arbeit aufteilt, haben alle was davon. Wenn nicht – arbeitet ihr nicht als Team, sondern seid Einzelkämpfer in der Gruppe.

Teamleiter…Es gibt keine Teamleiter. Bitte verlass Dich nicht auf einen ggf. auch selbst ernannten Chefprogrammierer, der die Aufgaben schätzt und verteilt. Macht das zusammen, nur so lernst Du besser zusammenzuarbeiten und lernst auch Verantwortung zu übernehmen. du musst selbst Erfahrungen zu sammeln und dann gewinnst Du letzlich auch an Selbstbewusstsein und Standing im Team. Also Raus aus der Komfortzone…mach es selbst!

soweit zum Dev.-Team…nun noch ein paar Worte zum Product Owner im Planungsmeeting, da gibt es auch ein paar Themen, die Du beachten solltest wenn Du diese Rolle einnimmst…:

Was wollen wir eigentlich? Denke als PO immer an das Sprintziel! Ein gutes Sprintziel beantwortet die Frage “Was wollen wir in diesem Sprint erreichen?” Und – es ist nicht ein Befehl von Deiner Seite als Product Owner sondern es wird im Planungsmeeting mit dem Dev.-Team gemeinsam diskutiert und vereinbart. Verstehe das Sprintziel als “Kalibrierung der Erwartungshaltungen von Product Owner und Dev.-Team”.

Macht ihr nicht eigentlich Kanban? Überlege mal, was Du wirklich machst…macht ihr ein Projekt, bei dem es darauf ankommt in einer bestimmten Zeit etwas Neues zu schaffen? Oder arbeitet ihr an unzusammenhängenden Anforderungen, bei denen verschiedene Themen, Systeme oder Bereiche parallel bearbeitet werden? Wenn Du also kein geordnetes, auf ein Ziel ausgerichtetes Backlog hast, sondern eine bunte Liste von Anforderungen, die sich auf unterschiedliche Ziele und Systeme beziehen, ist vielleicht Kanban die bessere Wahl. Mach nicht Scrum, nur weil Dir einer sagt, das machen ja alle!

Akzeptiere keine unfertigen Stories aus dem letzten Sprint, sondern diskutiere mit dem Team, warum etwas nicht fertig geworden ist. Es geht nicht um die Suche nach Schuldigen, sondern darum, dass Du zusammen mit dem Team lernst realistisch zu die Arbeit einzuschätzen. Das braucht Erfahrung und daher ist es nicht schlimm, wenn nicht alle Userstories geschafft werden. Wenn es aber zur Regel wird, dass einfach alle nicht fertigen Stories in den nächsten Sprint geschoben werden, dann plant ihr kontinuierlich falsch. 

Änderungen in letzter Minute, die nicht klar sind und die DoR nicht erfüllen…

Wenn Du als Product Owner in letzter Minute Userstories in das Backlog für den nächsten Sprint schreibst, dann überlege Dir genau, ob das eine gute Idee ist. Warum ist das jetzt so wichtig? – Weil Du dahinter stehst oder weil gerade Dein Boss angerufen hat? Beachte, dass Du das ganze Planungsmeeting sprengen kannst, denn das Team erwartet von Dir Klarheit. Und Du musst in der Lage sein, die Story auf ein Level zu bringen, das die DoR erfüllt. Wenn Du die Anforderung selber nicht verstanden hast, dann besprich das zusammen lieber nochmal mit Stakeholdern und dem Team z.b. im Refinement. Zu dem Begriff DoR komme ich gleich noch…

Fokus auf Output: Drücke nicht zu viele Stories in den Sprint, es geht nicht darum möglichst viele Stories oder Subtasks umzusetzen, es geht darum einen nachhaltigen Nutzen zu schaffen. Also der Fokus liegt auf Outcome!

So…

Generell gibt es dann noch ein paar Themen, die alle – also das gesamt Scrum-Team – betreffen:

Variable Sprint-Längen: Ändere nicht die Sprintlänge, wenn ihr nicht mit allen Stories fertig werdet. Das hat dann nichts mehr mit Scrum zu tun: Legt den Fokus auf das richtige Schneiden der Userstory, so dass die Story in den Sprint passt und passe nicht die Sprintlänge einer unrealistischen Planung an.

Überladene Sprints: bitte, auch wenn es Druck von aussen gibt und es Leute gibt, die wollen, dass ihr in Anführungsstrichen “schneller” werdet. Gib dem Druck nicht nach und überplane den Sprint nicht. (wenn mal ein oder zwei Punkte in den nächsten Sprint fallen ist das nicht schlimm, wenn ihr aber jedes mal 30-40% der Stories quasi automatisch in den nächsten Sprint fallen lasst, dann ist das was faul. Falls Du Scrum-Master bist, wäre das auch ein Zeitpunkt das Vorgehen mal generell zu hinterfragen. Vielleicht wäre hier auch KANBAN die bessere Wahl?…

Dogma: Zum Beispiel beim Thema “DoR”: Die “Definition of Ready” ist eine gemeinsam von Euch besprochene Liste von Eigenschaften, die eine Userstory erfüllen muss und sie stellt quasi das Eingangstor für die Sprintplanung dar. Was die DoR nicht erfüllt, kann normalerweise nicht für den Sprint geplant werden und muss erstmal im Refinement zurechtgeschnitten und geklärt werden…Aber seid nicht zu streng, betreibt hier keine Erbsenzählerei. Die DoR darf kein Freigabeprozess werden (sowas gibt es im klassischen Projektmanagement, gehört hier aber nicht rein!).

DoR ignorieren: DoR haben ihren Sinn. Wenn das Team keine DoR berücksichtigt, kauft es die Katze im Sack. Die Stories sind nicht wirklich klein genug, wurden nicht verstanden – wie soll man dann abschätzen, ob man das im nächsten Sprint schafft oder nicht? Ihr handelt Euch damit nur Probleme ein. Wenn Du Mitglied des Dev.-Teams bis, dränge darauf, dass ihr DoR aufschreibt und auch berücksichtigt.

Planung wird nicht vom ganzen Team durchgeführt. Bitte nichts für “andere Leute” planen. Agiles Arbeiten lebt von der Zusammenarbeit, Transparenz und Gleichberechtigung. Wenn ihr zum Beispiel nur 2 Repräsentanten des Teams die Arbeit für das gesamt Team planen lasst, dann driften wir in alte Zeiten ab, wo es Leute gab, die für andere dachten. (Wenn ihr Scaled Scrum – wie zum Beispiel LeSS einsetzt, ist das natürlich was anderes, aber das ist eine andere Geschichte und eine eigene Podcastfolge wert)

So weit zum Planungsmeeting und was da alles schief laufen oder missverstanden werden kann.. Wenn Du einige Dinge und Verhaltensweisen, die ich hier besprochen habe, in Deinem Projekt wiederfindest, prüfe, ob Du das nicht in den nächsten Retrospektiven abstellen kannst – egal ob Du jetzt PO oder ScM bist. Schaue auch noch mal in den Scrum-Guide, denn da stehen die wichtigsten Sachen drin…

Scrum ist keine evolutionäre Methode, wie Kanban, es ist ziemlich streng. Wenn Ihr Scrum macht, dann müsst ihr euch auch an die Regeln halten, sonst ist es nicht Scrum.

Und damit möchte ich diese Folge abschließen und bedanke mich fürs Zuhören. Ich würde mich sehr freuen, wenn Du über iTunes eine Bewertung abgeben könntest und mir auch gerne Feedback über das Kontaktformular auf meiner Webseite agilophil.de oder direkt in der Podcastsite “agilophil-daily.de” geben könntest.

Und jetzt wünsche ich Dir viel Erfolg bei Deinem nächsten Planungsmeeting 

Tschüß

Dein Frank

Agilophil-Daily Podcast Episode 06: Das agile Manifest

Ich kann mich noch gut erinnern – Ich habe letztes Jahr in einer Diskussion mit einem meiner Studenten von der Beuth-Hochschule in Berlin, bei der ich eine Lehrveranstaltung betreue, folgendes Statement gehört:

“Scrum wurde doch nur vom Management entwickelt, damit die Teams stärker unter Druck gesetzt werden können.” Der Student, der das gesagt hat, arbeitet neben seinem Studium als Entwickler in einer Firma. Obwohl das agile Manifest doch schon so alt ist und eigentlich bekannt sein sollte, scheint diese Firma sich bisher nicht darum gekümmert zu haben. Schade für den Studenten, ich bin sicher und hoffe natürlich, dass er in seinen weiteren Jobs bei Firmen arbeiten kann, die ein agileres Mindset an den Tag legen…und er damit den Frust, den das Thema “agil” bei ihm ausgelöst hat, wieder abbauen kann.

Ich nehme das mal zum Anlass um eine Folge über das agile Manifest zu machen – obwohl ich auch hier denke, dass Dir das höchstwahrscheinlich bereits bestens bekannt ist. Trotzdem ist bekanntlich Wiederholung die Mutter des Studierens und ich lade Dich ein einfach nochmal ein,  ganz entspannt zuzuhören. Falls Dir das agile Manifest noch nichts sagt, wird es hoffentlich um so spannender:

Am 11.-13. Februar 2001 also fast vor 20 Jahren,  trafen sich in der Cliff-Lodge im Snowbird-Skigebiet in Utah, USA, siebzehn Menschen –  Vertreter verschiedener damals existierender agiler Strömungen, wie „XP-Extreme Programming“, SCRUM, DSDM (Driving Strategy Delivering More), Adaptive Software Entwicklung, Crystal, Feature-Driven Development, Pragmatic Programming und andere. Sie waren sich einig eine Alternative zu den vorherrschenden dokumentationsgetriebenen, schwergewichtigen Software-Entwicklungsprozessen zu finden. Was entstand, war das Agile ‚Software Development‘ Manifest mit folgendem gemeinsam unterzeichneten Wortlaut:

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Das agile Manifest besteht nur aus 4 Sätzen und die besagen also folgendes:

  1. Wir wollen lieber miteinander sprechen und interagieren als stur den vorgegebenen Prozessen zu folgen und alte Werkzeuge zu benutzen, weil wir das schon immer so gemacht haben.
  2. Wir wollen uns lieber darum kümmern die Software fehlerfrei auszuliefern als eine umfassende Dokumentation anzulegen, die erstens sowieso niemand vollständig liest und die zweitens ab dem nächsten Release schon wieder veraltet sein wird.
  3. Wir wollen lieber mit dem Kunden zusammenarbeiten und auf seine Wünsche eingehen, als misstrauisch alles in einem von Rechtsanwälten verfassten Vertragsdokument festzuhalten und später vor Gericht über unterschiedliche Auslegungen zu streiten.
  4. Wir wollen lieber aus den erreichten Zwischenständen lernen und neue Erkenntnisse und Erfahrungen in die Produktentwicklung einfließen lassen als am Anfang alles Festzuschrieben und dann den Plan ohne Rücksicht auf unsere sich verändernde Umwelt umzusetzen.

Wichtig ist aber noch der letzte Satz, denn das relativiert das Ganze wieder: Nicht alles, was wir bisher gemacht haben, ist schlecht. Jede Organisation, die den Stand eines 2 Leute Garagenstartups verlassen hat und wächst, braucht Prozesse und Tools. Ohne gewisse Ablaufregeln der Arbeit – nichts anderes stellen Prozesse dar – können größere Gruppen von Leuten nicht zusammenarbeiten. Wir müssen nur aufpassen, dass wir die Prozesse nicht zu wichtig nehmen und dass wir nicht Gefahr laufen, unser Hirn an Eingang in die Firma auszuschalten. Wir müssen immer hinterfragen, ob das, was wir hier machen sinnvoll und notwendig ist – und dies müssen wir gemeinsam, also interaktiv tun…

Ferner braucht jede Software eine Dokumentation oder eine Userhilfe. Auch wenn es ein großes Ziel ist, eine Software für den Anwender selbsterklärend zu designen, es wird immer Fälle geben, wo man mal schnell eine “how to?-Frage” nachschlagen will – eine Software ohne eine Hilfe wäre also nicht Nutzerfreundlich. Genauso ist eine Dokumentation für die Wartbarkeit der Software unabdinglich: wie sollen Kollegen, die nach ein paar Monaten oder Jahren Fehler suchen oder die Software weiterentwickeln, sich schnell zurecht finden? (Mit einer Doku kann man also wertvolle Zeit zur Einarbeit sparen).

Dann kommen wir noch zu der Vertragsfrage: Auch hier werden wir wahrscheinlich nicht ohne eine kleine schriftliche Vereinbarung auskommen – entscheidend ist aber doch das gegenseitige Vertrauen, welches sich in der Zusammenarbeit aufbauen sollte. Daher ist es extrem wichtig das Ziel und die Probleme des Kunden zu verstehen und letztlich gemeinsam an einer Lösung zu arbeiten. Alles andere ergibt sich dann von selbst.

Planung ist essentiell, der Plan selbst danach aber wertlos, das sagte schon General Eisenhower. Natürlich müssen wir planen – wir haben in scrum ja auch die 5 Planungshorizonte, über die ich ja schon mal gesprochen. Aber wir müssen flexibel bleiben und in der Lage sein den Plan stets anzupassen. Änderung ist nichts Schlechtes, sondern es ist eine notwendige Justierung auf dem Weg zum richtigen Ergebnis. Du fährst ja auch nicht Auto ohne das Lenkrad zu bedienen und Du hast hoffentlich auch kein schlechtes Gefühl dabei…

Das agile Manifest besteht aber nicht nur aus diesen 4 Kernsätzen, es stehen auch 12 Prinzipien dahinter, die Dir bei der Umsetzung helfen und die die Bedeutung des Manifests unterstreichen. 

Ich lese diese jetzt einfach mal vor, so wie Du sie auch im Internet finden kannst (und wahrscheinlich auch kennst):

Prinzipien hinter dem Agilen Manifest

Prinzip Nr. 1: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.  – Dahinter steckt die Idee der Iteration und der Entwicklung von funktionierenden kleinen Einheiten, die dem Kunden schnell nutzen bringen.

Prinzip Nr. 2: Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen.  Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Das bedeutet: Änderungen sind nie schlecht – bleib flexibel und siehe Änderungen als notwendige Aktionen um der Lösung des Problem noch näher zu kommen. Der Kunde hat also etwas davon, wenn wir schnell auf Änderungen reagieren – es ist für ihn von Vorteil! – Umgekehrt sind festgeschriebenen Anforderungen und starre Change-Request-Verfahren ein Nachteil für den Kunden! -> Und damit letztlich auch für uns…

Kommen wir zum

Prinzip Nr. 3: Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Schneller ist besser – denke daran, wenn Du dir überlegst, wie lange zum Beispiel ein Sprint sein soll…in 2-Wochensprints beispielsweise hast du doppelt so viele Feedback und Anpassungsmöglichkeiten, wie in einem 4-Wochen-Sprint. Die Lernkurve ist viel steiler.

Prinzip Nr. 4: Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Jeder muss sich in die Lage des Anderen versetzen können um eine bestmögliche Lösung für Probleme oder Wünsche finden zu können. Es macht also wenig Sinn sich abzugrenzen und gegenseitig nur Aufgaben und Lösungen über den Zaun zu werfen…

Prinzip Nr. 5: Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Motivation entsteht durch Sinnstiftung und Handlungsfreiheit und das Streben nach Meisterschaft…wie heißt es so schön: Wenn du ein Schiff bauen willst, dann trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer. (bitte das Zitat von Antoine de Saint Exupéry hier jetzt nicht zu wörtlich nehmen, nur die Sehnsucht alleine wird einen auch nicht weiterbringen…). Also, falls du Product Owner oder Manager bist – lass los und vertrau dem Team. – das gilt natürlich auch für Scrum-Master!

Prinzip Nr. 6: Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. vergiss Mails, setz dich zusammen mit den Leuten und unterhalte Dich. Finde aber Möglichkeiten mitzuteilen, wenn Du nicht gestört werden möchtest (z.B. setz einen Kopfhörer auf oder denkt Euch im Team entsprechende Signale aus, damit auch vermieden wird, dass man sich nicht mehr konzentrieren kann vor lauter Unterhaltung…)

Prinzip Nr. 7: Funktionierende Software ist das wichtigste Fortschrittsmaß. Outcome über Output. Es ist nicht wichtig, wieviel Du arbeitest, sondern was dabei rauskommt. Das Maß ist dabei nicht die eingesetzte Arbeitszeit, sondern das Ergebnis.

Prinzip Nr. 8: Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Auch wenn ein Sprint “Sprint” heißt und diese Bezeichnung ist in diesem Zusammenhang auch etwas unglücklich: Wir laufen hier eigentlich einen Marathon, d.h. wir müssen unsere Arbeitsleistungen auf lange Zeit durchhalten können. Ein Sprintplanungsmeeting hat also nicht das Ziel dem Team noch ein paar zusätzliche Userstories aufzudrücken oder ständig im Notfallmodus einer unrealistischen Planung hinterherzuhecheln. Wenn Du Product Owner bist, beachte das, wenn Du Scrum-Master bist, sorge dafür. Und—das Prinzip gilt natürlich auch, wenn Du nicht “Scrum” machst!

Prinzip Nr. 9: Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Kaizen – die ständige Verbesserung – greift nicht nur in der Retrospektive und im Team. Durch schnelle Zyklen ergeben sich mehr Möglichkeiten Dinge zu verbessern. Mehr Feedback bringt zugleich bessere Ideen.

Prinzip Nr. 10: Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell. Da muss man erstmal drüber nachdenken…das hat nichts mit Faulheit zu tun, sondern mit Vermeidung von Waste – also Verschwendung. Wir wollen keine Arbeit verschwenden, indem wir sinnlose Dinge umsetzen, die niemand braucht oder verwenden kann.

Prinzip Nr. 11: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. 

Nur in selbstorganisieren Teams kann sich die Kreativität eines jeden Einzelnen voll entfalten. Jeder hat seine Stärken und die Menschen haben verschiedene Charaktere. Von alleine sind wir relativ einfach in der Lage uns in einem Team zurechtzufinden und uns einzuordnen. Wenn das von aussen passiert, geht es meist schief.

Prinzip Nr. 12: In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. 

Dieses Prinzip wird beispielsweise in den Scrum-Retrospektiven direkt umgesetzt. Aber auch in Kanban oder anderen agilen Methoden ist es sinnvoll und teilweise verankert die Teamarbeit stets zu überprüfen und Wege zu einer ständigen Verbesserung zu suchen.

Letztlich finden wir all diese Prinzipien also in den agilen Methoden, wie Scrum oder auch Kanban wieder. (wobei Kanban in der heute oft verwendeten Form des “Lean-Kanban” für Software oder IT-Vorhaben durchaus etwas jünger als Scrum ist).

Die Unterzeichner des Manifests waren:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Einige der 17 Namen der Unterzeichner und auch die meisten der agilen Methoden, die ich vorhin genannt hatte,  sind aktuell vielleicht ein wenig in Vergessenheit geraten.

Andere, wie Alistair Cockburn, Ken Schwaber oder Jeff Sutherland sind wiederum durch die inzwischen herausragende Stellung von Scrum noch sehr präsent.

Soviel zum agilen Manifest – eine der Grundlagen des agilen Arbeitens und natürlich auch nicht nur im Softwarebereich gültig. Inzwischen sind  20 Jahre vergangen und agile Arbeitsweisen haben sich in vielen Bereichen durchgesetzt oder sind gerade dabei, in Bereiche wie Industrie oder in Schulen vorzudringen. Es ist also nicht heute nicht mehr gerechtfertigt, das agile Manifest nur auf die Softwareherstellung zu beziehen, auch wenn es ursprünglich im IT-Umfeld entstanden ist.

So – das wars für heute – Vielen Dank fürs Zuhören…Wenn Dir der Podcast gefallen hat, bitte ich Dich ihn zu abonnieren und mir eine Bewertung zu geben. Falls Du Kritik oder Anregungen hast, gerne auch über das Kontaktformular auf meiner Webseite oder als PN in Linked-IN oder Xing.

Tschüß

Dein Frank

Agilophil-Daily Podcast Episode 05: 5 Gründe, warum Scrum gut ist! Ein Plädoyer für Scrum

Scrum ist nicht neu. Die Ursprünge von Scrum reichen weit in die 80er Jahre hinein, als Toyota mit seinem „Toyota Production System“ neue Wege ging und das später so genannte „Lean-Manufacturing“ begründete. Viele agile Strömungen und Methoden sind seit dem entwickelt worden, wobei Scrum, welches eigentlich auch nur eine Zusammenfassung von „Best practices“ darstellt, aktuell die bei weitem am meisten verwendete ist.

Alle agilen Methoden basieren auf denselben Werten und bedeuten im allgemeinen tiefgreifende Änderung der Unternehmenskultur, was bei der Einführung auch eigentlich die Schwierigkeit darstellt.

Der „PDCA-Kreislauf“, worüber wir schon gesprochen haben, basiert letztlich auf einer bereits 1620 von Francis Bacon beschriebenen wissenschaftlichen Methode, die man als „Hypothese, Experiment, Evaluation“ zusammenfassen kann (Francis Bacon: Novum Organum).

Man kann also wirklich nicht behaupten, dass Scrum nur „neumodisches Zeug“ ist…

Nun reden alle über Scrum, aber warum wollen es viele machen (oder meinen es machen zu müssen)? Also starten wir mit einem Vergleich: 5 Gründe, warum Scrum besser als Wasserfall ist:

Grund Nummer 1: Der Realität ins Auge sehen

Projekte starten im Allgemeinen in einem Flow des Optimismus. Wir glauben, dass alles funktionieren wird  – wenn wir einmal alle Anforderungen aufgenommen und spezifiziert haben – und das auch im Vertrag geregelt ist, dann wird schon alles funktionieren…

Die Realität sieht leider meistens anders aus. Wenn das Projekt fortschreitet, stellen wir gewöhnlich fest, dass Anforderungen missverstanden werden oder Lösungen komplexer sind, als zunächst angenommen. Das Festpreisangebot für den festgeschriebenen Scope ist daher nicht mehr erreichbar, ohne Kompromisse bei der Qualität zu machen…was natürlich niemand will…

Die Praxis in hunderten von Projekten hat gezeigt und ich kann das bei meine Projekten, die ich als Projektmanager gemacht habe, bestätigen: Es ist naiv zu glauben, dass das, was der Kunde am Anfang an Anforderungen und Vorstellungen in seinem Kopf hat, auch genauso vom Dienstleister oder Entwickler verstanden wird.…daher kommt es bei der Präsentation der Ergebnisse nach einem langen Zeitraum (also klassisch nach der Konzept- und Realisierungsphase) oft zu unangenehmen Überraschungen…Und es kommt noch schlimmer: selbst wenn die Kommunikation im Projekt außergewöhnlich gut läuft und alles genau so realisiert wird, wie der Kunde es verstanden hat, kann man nicht davon ausgehen, dass der Kunde am Anfang des Produkts überhaupt in der Lage war zu beschreiben, was er am Ende des Projekt wirklich braucht. Das liegt nicht an der Dummheit des Kunden, sondern an der Tatsache, dass wir auf dem Weg lernen und Erfahrungen machen, die wir nunmal am Anfang nicht haben. Das hat sich ja auch in einem Sprichwort manifestiert, dass wir alle kennen: “Hinterher ist man immer klüger”…nur warum glauben wir das im Projektmanagement nicht?

Die Tatsache ist, dass Änderungen unvermeidlich sind. Fataler Weise gehen klassische Projektmanagement-Methoden davon aus, dass wir alle Eventualitäten im Voraus festlegen können (wenn wir nur intensiv genug darüber nachdenken) und dass wir Verständnis und Kundenbedürfnisse mit Dokumenten kommunizieren können und dass wir das auch noch mit einem Abnahmeprozess festschreiben und fest kalkulieren können.  Da das eigentlich noch nie wirklich funktioniert hat, müssen wir anerkennen, dass wir hier anders vorgehen müssen.

Grund Nummer 2: schneller sein…

Probleme bauen sich typischerweise in einem traditionellen Projekt über die Laufzeit auf und treten dann in der Testphase zu Tage. Die Testphase startet sehr spät, wenn alle Teilentwicklungen integriert sind. Der Nutzen kann also erst am Ende des Projekts generiert werden.

Scrum-Teams sammeln die Anforderungen nur so lange, bis verwertbare Bestandteile entwickelt werden können und setzen sie dann um. Dabei sollen die wichtigsten, fundamentalsten aber auch einfachsten Anforderungen zuerst umgesetzt werden. Ein Nutzen wird dann bereits mit dem ersten Sprint erreicht.

Die „Time to Market“ wird radikal gesenkt und es können sofort erste Kundenfeedbacks eingeholt werden. Die weiteren Entwicklungen können auf das Feedback reagieren, so dass der Kunde genau die Funktionen oder Features bekommt, die er wirklich benötigt.

Grund Nummer 3: Qualität bereits eingebaut:

Das klingt etwas provozierend, doch es ist ja so: Wenn Entwicklungs- und Testphasen zeitlich sehr weit auseinander liegen, dann dauert der Fehlerfindungsprozess auch sehr viel länger. Wenn die Tests in einem 2 Wochensprint integriert sind, bist Du als Entwickler gedanklich ja noch voll im Thema und findest den Fehler auch viel schneller. 

Aber Scrum-Teams gehen natürlich noch viel weiter: Automatische Regressionstests stellen sicher, dass die Weiterentwicklung auf Basis des bestehenden Codes funktioniert. Falls Du Product-Owner bist, solltest du aber auch darauf achten, dass genügend Zeit für die Erstellung solcher Testfälle besteht und das auch geplant wird (also auch Userstories dafür geschrieben werden). Schaffe also Dir selbst den Freiraum, die Säge zu schärfen, damit du den Baum schneller fällen kannst…

Scrum-Teams lassen nichts ungetestet. Der Code ist immer zu 100% getestet. Im Zweifel werden eher Funktionen weggelassen als Funktionen ungetestet auszuliefern. Daher gibt es am Ende keine „technologischen Schulden“, da der Fokus auf Qualität liegt.

Grund Nummer 4: Wir können jederzeit aufhören!

Im klassischen Umfeld quasi undenkbar, in Scrum sollte es jedoch Alltag sein: da wir kontinuierlich Nutzen liefern, steht uns jederzeit die Entscheidung offen, das Projekt zu beenden – nämlich dann, wenn der Nutzen für den Kunden erreicht worden ist…Was bedeutet das? Die Anwendung des Pareto-Prinzips: Du kennst das wahrscheinlich aus Deiner eigenen Erfahrung auch: um 80% des Nutzens zu errreichen brauchst Du eigentlich nur 20% des Aufwandes reinzustecken. Der Teufel liegt im Detail, die nächsten 20% bis zur 100% Umsetzung verschlingen dann 80% des Aufwandes. Nun muss man das nicht wörtlich nehmen, doch Du solltest immer bedenken: Brauchen wir das Feature wirklich im neuen Release oder kann das auch noch später kommen – vielleicht stellt sich heraus, dass wir es gar nicht mehr benötigen. 

Immerhin – nach einer Studie der Standish Group enthält Software wie Excel zu 64% Funktionen, die von den meisten Menschen selten oder gar nicht benötigt werden. Und etwas zu entwickeln, was hinterher niemand braucht, ist Verschwendung  – und die wollen wir vermeiden!

Grund Nummer 5: Bessere Planung

Es gibt eine Menge Fehlinformationen zu agilen Projekten. Wenn man das erste Mal davon hört, könnte man leicht denken, dass agil gleich planlos ist.

Doch genau das Gegenteil ist der Fall:

Die traditionelle Projektplanung an Hand von Gantt-Diagrammen und Statusreports reflektiert nicht den wirklichen Nutzen des Projekts, sondern macht nur den Fortschritt gegenüber dem Plan deutlich. So bleibt es sehr lange völlig intransparent, ob ein geplanter Nutzen auch wirklich erreicht wird. Im schlimmsten Falle wird ein Projekt komplett „grün“– also in Time, in der gewünschten Qualität und im Budget umgesetzt um dann zu merken, dass das, was da umgesetzt worden ist, gar nicht das ist, was wirklich gebraucht wird.

Um es mal zu verdeutlichen: im klassischen Projektmanagement gibt es zu Beginn des Projekts eine Planungsphase und dann wird dazu übergegangen, diesen Plan zu verfolgen. Erst wenn es erkennbare und nicht mehr zu leugnende Abweichungen vom Plan gibt, wird der Plan angepasst. Die Plananpassung gilt hierbei als etwas schlechtes.

Im agilen Projektmanagement gibt es hingegen 5 Planungshorizonte, die eine große Transparenz und Flexibilität erzeugen – diese Horizonte reichen von täglich bis zu mehreren Monaten oder Jahren:

  1. Daily-Standup
  2. Sprintplanung 
  3. Product Backlog 
  4. Releaseplan 
  5. Vision

Also hier nochmal die Planungshorizonte…

  • täglicher Horizont: Im Daily-Standup oder DailyScrum wird jede einzelne Aktivität täglich vom Team geplant und aktualisiert. So ist im gesamten Team Transparenz über den Stand der Arbeit gewährleistet.
  • wöchentlicher Horizont 1Sprintplanungsmeeting: In der Sprintplanung planen Product Owner und Dev.-Team die Arbeitspakete für die kommende Iteration. Die Betroffenen planen also selbst, so kann man immer besser lernen und Planabweichungen werden mit der Zeit immer selterner.
  • wöchentlicher Horizont 2Backlog Refinement: Die weitere Gestaltung des aktuellen Produkts planst Du als Product Owner im Refinement Meeting zusammen mit dem Team, so dass auch später kommende Aufgaben schon mit vorbereitet werden können.
  • Horizont über mehrere MonateReleaseplan: Die weitere Releaseplanung wird vom Product-Owner zusammen mit Stakeholdern, Produktmanagern über die nächsten Monate vorgenommen.
  • Horizont über mehrere Monate oder auch JahreVision: In der Vision kannst Du das endgültige Potenzial des Produkts planen. Der zeitliche Horizont kann hier über die nächsten Jahre gehen. Wichtig ist, dass ein gemeinsames Bild entsteht, was man zukünftig erreichen will.

Fazit: Scrum oder nicht Scrum?

Die Frage, ob Du nun Scrum anwenden sollst oder lieber nicht, solltest Du nicht einfach nur aus dem Bauch oder nur entsprechend aktueller „Modeerscheinungen“ beantworten. Bei bestimmten Aufgabenstellungen hat die klassische Projektmethode „Wasserfall“ durchaus ihre Vorteile und Existenzberechtigung. Um eine Einschätzung auf die eigene Situation zu vereinfachen, kannst Du dir einen „Schieberegler“ vorstellen, der dort hingeschoben werden kann, wo er in der aktuellen Situation in deiner Firma oder im Projekt am besten die reale Welt beschreibt. Die beiden Enden des Schiebereglers sind natürlich immer die Maximalwerte – in der Realität wird alles irgendwo dazwischen liegen.

Stell Dir also einen Equalizer vor, der 5 Schieberegler zu folgenden Themen hat:

•    Schieberegler Kultur: Ist es zum Beispiel bei Euch üblich in partnerschaftlichem Verhältnis zusammen mit Kunden oder Auftraggebern Anforderungen umzusetzen, regelmäßig Feedback zu geben und sich gegenseitig zu engagieren   ODER  herrscht ein Arbeitsklima der Abgrenzung, der Skepsis gegenüber der Leistungsfähigkeit des Partners und der Kontrolle bzw. Beschuldigung?

•     Schieberegler Time-To-Market: Sind die Aufgabenstellungen durch schnelle technische Weiterentwicklungen im Markt ständigen Schwankungen ausgesetzt ODER haben wir es mit (z.B. gesetzlichen) Anforderungen zu tun, die sich überJahrzehnte nicht grundsätzlich ändern werden?

•     Schieberegler Organisation: Wie ist Deine Firma organisiert? Wird in traditionellen Hierarchien gearbeitet, in denen Abteilungsleiter ihre Teams nach fachlichen Funktionen gruppieren und eine Zusammenarbeit zwischen verschiedenen Abteilungen eher selten vorkommt ODER wird bereits eine Form von „Soziokratie“ gelebt, in der kleine übergreifende Teams in selbstorganisierten Inseln ihre Aufgaben bearbeiten?

•    Schieberegler Technologie:  Haben wir es mit technologischen Rahmenbedingen zu tun, die schnelle Änderungen an den Systemen verhindern – wie z.B.monolithische Systeme, in denen Änderungen über bürokratische ChangeRequest-Verfahren langwierig beantragt werden müssen und vielfältigen Sicherungs- und Kontrollmechanismen unterliegen ODER arbeiten wir mit schnellen, kleinen, komponentenbasierten Systemen, die quasi „am offenenHerzen“ – also im laufenden Betrieb geändert werden können?

•  Schieberegler Markt:   Wie ist die aktuelle Marktsituation in Deiner Firma? Ist es überlebenswichtig schnell neue Produkte am Markt zu platzieren ODER ist die Produktpalette eher auf „commodities“ ausgerichtet, die sich nicht wirklich ändern (wie z.B. In der Versorgungsindustrie)?

Je nachdem, wo bei Dir der Schieberegler steht, wird die Scrum-Einführung schwerer oder leichter fallen. Die Entscheidung sollte sich aber nicht nur stoisch an der gegebenen Situation ausrichten, sondern in die Zukunft gerichtet sein. Grundsätzlich gilt aus meiner eigenen Erfahrung: je unbekannter das Produkt oder zu erreichende Ergebnis, und je unsicherer die Gesamtsituation und je größer der Druck der Konkurrenz am Markt, desto eher eignet sich Scrum zur Umsetzung von Projekten und dementsprechend zur Lösung der dringendsten Probleme in Deinem Unternehmen.

Soviel zu Scrum oder nicht scrum

Ich hoffe, die Folge hat dir gefallen.

Falls Ja – bitte ich Dich mir eine Rezension bei Itunes zu geben.

Mach’s gut 

Dein agilophiler Frank