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