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 13: Sonderfolge zu Ostern

Was nachher alles besser wird…

Frohe Ostern! lieber agilophiler Mensch —Herzlich willkommen zur Oster-Sonderausgabe des Agilphil-Daily Podcasts

Ostern ist das Fest der Auferstehung – und insofern passt das Bild ja wunderbar – wir sind auch in einer Situation, aus der wir wieder auferstehen – aus dem Lock-Down, der Zeit der Einschränkung… –

Freuen wir uns auf die Zeit danach…und dazu werfe ich mal einen Blick auf das, was wir aus der Krise mitnehmen können um nach der Krise besser dazustehen…

Bitte nicht falsch verstehen. Ich sehe natürlich, dass die Corona-Krise eine Menge Leid über die Welt bringt – sowohl bei denen, die unmittelbar von der Krankheit betroffen sind, als auch bei allen, die mittelbar -also vor allem wirtschaftlich betroffen sind und vor unsicheren Zeiten stehen. Aber – wie immer – jedes Ding hat zwei Seiten und ich möchte mich heute mal ausschließlich mit der anderen Seite der Medaille beschäftigen. Viele Dinge werden nach der Krise anders sein, als sie vor der Krise waren und nicht alles davon ist schlecht oder negativ (wobei diese Einschätzung ja sowieso subjektiv ist von jedem Einzelnen getroffen werden muss). So überlege ich hier – in dieser Sonderfolge zu Ostern 2020, was – aus meiner rein persönlichen Sicht – vieleicht gar nicht so schlecht wäre, wenn wire es nach der Krise beibehalten würden…

Von der Krise gehen eine Menge Impulse aus, die lange nachwirken werden…ausserdem ist es ja bekannt, dass man für die Einführung von neuen Gewohnheiten eine Wiederholungszeit von ca. 4 Wochen benötigt – d.h. wenn du ein bestimmtes Verhalten einen Monat oder 4 Wochen durchhältst wird es zur Gewohnheit – ganz automatisch und quasi zwangsläufig –  und Dir fehlt dann etwas, wenn Du das nicht mehr machst (das ist letztlich auch die Eigenschaft einer Gewohnheit…)- so ist es zum Beispiel jetzt durchaus praktisch – falls Du im Homeoffice bist – mal einen Onlinekurs in Gymnastik oder Joga oder Meditation durchzuführen, nach der Corona-zeit- die ja nun schon in die 4. Woche geht –  wirst Du es vermissen und wahrscheinlich sogar weiter machen – ganz zwangsläufig wird das dann zu einer neuen Gewohnheit von Dir…und das wird Dir gut tun…

Genauso läuft es mit dem Homeoffice  – das ist natürlich von Beruf zu Beruf unterschiedlich –  aber wieso sollst Du eigentlich 5 Tage jede Woche ins Büro fahren, wenn wir uns jetzt darauf eingestellt haben, dass das auch so geht? Die technischen Gegebenheiten sind geklärt, die Hardware läuft, die Sicherheitsfragen sind besprochen und abgewogen und wir haben uns bestimmte Verhaltensweisen angewöhnt, um in Video- oder Telefonkonferenzen gut kommunizieren zu können…Da reichen doch 3 Tage im Büro und 2 Tage zuhause – das erhöht die Flexibilität und Selbstbestimmtheit von jedem Einzelnen….Ich persönlich denke solche Gedanken werden sich bei verschiedenen Menschen ausbreiten, das liegt irgendwie auf der Hand…und wie ist das bei Dir?

Das nächste Thema wären Dienstreisen…müssen denn wirklich alle Dienstreisen noch sein? Müssen wir nach der Krise wieder so reisen wie wir es vorher gemacht haben? Müssen wir für ein Meeting am Nachmittag von Berlin nach Frankfurt fliegen und abends wieder zurück, wenn wir uns 4 Wochen lang daran gewöhnt haben, dass es auch so geht? Ich kann mir sehr gut vorstellen, dass wir Dienstreisen bewusster planen und uns wirklich überlegen, welchen Nutzen es bringt persönlich anwesend zu sein. Das soll kein Pladoyer sein, auf Dienstreisen zu verzichten, denn um sich kennenzulernen müssen wir uns persönlich treffen – also Teambuilding, Networking-Events oder Verkaufsveranstaltungen und Messen wird es weiterhin geben, aber Projektstatusmeetings, Steuerungskreise oder Mitteilungen der Geschäftsführung oder ähnliches – das geht auch online – als Online-Workshop, Webinar oder einfach als Videokonferenz – und das schont das Budget und die Umwelt!…

Ich bin mal gespannt, wie die Umweltbelastung in Ballungsräumen sich entwickelt – und wie die Umwelt auf so eine 2-3 monatige Belastungspause reagiert… – gerade auch in China und Indien ist das ja schon zu sehen. Ich habe gerade letzte Woche gehört, dass es in Indien Regionen gibt, in denen man seit 30 Jahren zum ersten Mal wieder den Himalaya sehen kann…Ich denke schon, dass das ein positiver Effekt ist…

Abstand halten und gegenseitige Rücksichtnahme in Supermärkten und an sonstigen Orten…Also manche Dinge finde ich schon ganz angenehm…wir lernen wieder warten – das schult etwas, was wir in unserer heißgelaufenen Hochkonjunkturphase fast schon vergessen hatten – GEDULD… ja – wir stehen an – und drängeln nicht – wir halten Abstand und das aus Respekt (oder Angst?) – egal – ich empfinde die Situation in Supermärkten momentan irgendwie als angenehm, nicht mehr in einem hektischen Modus durch den Laden zu rennen und überall in Schlangen zu stehen und völlig gehetzt seine Sachen von der Kasse in seine Tüten stopfen zu müssen, da der nächste Kunde ja schon wartet und wir keine Zeit verlieren dürfen. Es gehen jetzt nicht alle gleichzeitig einkaufen – irgendwie haben wir das hinbekommen…OK – es gab jetzt vor Ostern schon lange Schlangen vor Supermärken aber alle haben Abstand gehalten und das geduldig abgewartet – letztlich ist es ja auch egal , wo Du wartest – ob Du nun im überfüllten Laden stehst oder davor…zeitlich macht das keinen großen Unterschied…Und wir respektieren die Menschen, die in Supermärkten arbeiten (und natürlich auch in anderen Gechäften, die noch geöffnet haben) und danken ihnen für ihren Einsatz…ich fände es schön, wenn sich diese Haltung über die Corona-zeiten hinaus beibehalten lässt..

Ganz nebenbei macht Deutschland nun eine riesigen Sprung in Sachen Digitalisierung: Kartenzahlung für kleine Beträge? Plötzlich kein Problem mehr – wird sogar gewünscht – und ist praktisch und hygienisch (der zweite Grund überwiegt momentan natürlich ) aber es geht halt auch extrem schnell und einfach für Beträge unter 50,- € – kein Kleingeld-suchen – kein aufs Wechselgeld warten – einfach Karte drauf und gut…Und warum sollten wir diese Gewohnheit wieder ablegen? Die Gewohnheit digital zu kommunizieren und das Internet vielfältiger zu nutzen ist natürlich abhängig von der zur Verfügung stehenden Bandbreite – ich hier in Berlin habe nicht wirklich ein Problem – ich kann aktuell alles streamen, was ich will, Videokonferenzen funktionieren  – in ländlichen Gebieten wird das noch anders aussehen – was vor Corona nicht funktioniert hat, ist nicht plötzlich wie aus Geisterhand da – aber ich denke die Notwendigkeit wird nochmal viel höher priorisiert und der Netzausbau wird dann wirklich mal vorankommen, denn die nächste Krise kommt bestimmt – vor allem, wenn man – wie wir jetzt – eine derartige Krise das erste Mal in sein Hirn eingebrannt bekommt…dann geht das ja nicht mehr so schnell wieder raus.

Was ich auch sehe – da ich unter anderm ja auch einen Lehrauftrag an der Beuth-Hochschule für Technik in Berlin habe – Digitales Lernen in Schulen und Universitäten wird überall normal sein…das erhöht die Flexibilität für die Lehre und für die Studierenden. Onlinekurse sprießen aus dem Boden und ermöglichen ein unabhängiges Einkommen und die Möglichkeit interessantes zu lernen, auch ohne irgendwohin gehen zu müssen. 

Höhere Bezahlung für systemrelevante Berufe: wird ja auch Zeit – es ist nicht wirklich fair und einsehbar, warum Menschen, die in sozialen Berufen arbeiten – Ärzte jetzt mal ausgeklammert- nicht monatlich locker 5000,-€ auf dem Konto haben können – selbst wenn sie extrem gut sind…In der Industrie sind solche Gehälter nicht ungewöhnlich – auch für Facharbeiter nicht. Es ist eine Frage, wo Geld verdient wird – in der Industrie z.B. gibt es Margen, die hohe Löhne möglich machen, denn es gibt Kunden, die für die Produkte das Geld bezahlen, weil es ihnen wert ist…Ein schicker Sportwagen ist teuer -aber es gibt Kunden, die das gerne bezahlen und sich einen Traum erfüllen…Eine Behandlung beim Arzt ist lästig – ich will da am liebsten gar nicht hin – und – zumindest als gesetzlich Versicherter – ist das auch noch (fast) kostenlos- ich sehe nicht, was abgerechnet wird – es ist absolut intransparent – und hat für mich daher auch keinen Wert…Da wir diese Situation nicht so schnell grundlegend ändern können, sollten wir uns in der Gesellschaft überlegen, wie wir quersubventionieren können. Von den Branchen „wo das Geld sitzt“ zu den Branchen wo kein Geld ist (ich sehe da z.B. vor allem auch Erziehung und Bildung- Wenn es der Wunsch ist, kostenlose Bildung und Kindergärtenplätze anzubieten, dann darf das nicht auf Kosten der in den Bereichen arbeitenden Menschen gehen und es sollte über ein System nachgedacht werden, sowas zu organisieren…Ich mache hier keinen Vorschlag zur Lösung, ich gebe nur einen Impuls und spreche die Problematik an. Denn letztlich profitieren wir alle davon – spätestens wenn wir weniger Altersarmut abfedern müssen, da die Menschen in den systemrelevanten Berufen dann mehr Geld in die Rentenkasse haben einzahlen können…

Bedingungsloses Grundeinkommen? Ich habe es zumindest gerüchteweise gehört – Spanien denkt als Impuls aus der Corona-Krise ernsthaft drüber nach, ein bedingungsloses Grundeinkommen einzuführen …ist das ein Schritt in die richtige Richtung? Ich denke ja – denn wie gesagt – es darf nicht von der Branche abhängen, wo Geld verdienbar ist und wo nicht – jeder sollte mit dem Beruf, den er macht einen Wohlstand aufbauen können – natürlich der eine mehr und der andere weniger – es sind ja auch nicht alle an „Wohlstand“ oder „Reichtum“ interessiert..zumindest nicht  monetär….und auch das sollten wir als Gesellschaft akzeptieren.

Am Ende komme ich doch wieder zurück zu meinem eigentlichen Thema – was hat das alles mit Agilität zu tun? Das so genannte „Empowerment“ ist ein wichtiger Bestandteil in der Zusammenarbeit von agilen Teams…und Empowerment  funktioniert nicht ohne Vertrauen! – die Vorgesetzten – ich nenne sie hier mal so – haben in den letzten 4 Wochen gelernt zu vertrauen – zu vertrauen darauf, dass ihre Mitarbeiter einen guten Job machen, auch wenn sie nicht immer dabei sind und sie kontrollieren können. Es kam die Erkenntnis hoch, das die Mitarbeiter sich sehr wohl selbst strukturieren und organisieren können. Wer Kinder hat, hat andere Arbeitszeiten als die Kollegen, die keine Kinder haben -aber die Ergebnisse stimmen – auch wenn nicht jeder exakt von 9:00 bis 17:00 am Arbeitplatz sitzt…man kann ja auch um 6:00 anfangen oder noch um 20:00 3 h arbeiten, wenn sich so der Alltag besser organisieren lässt – und der Chef muss das noch nicht einmal wissen…also er muss nicht alles wissen und kontrollieren…Daher frage Dich selbst, wenn Du in einer Vorgesetzten-Position bist – wie Du deine Situation einschätzt – Bist Du einer der immer nur den Dreck wegmacht – der immer wo er hingreift nur Mist vorfindet, den er bereinigen muss…dann wird das daran liegen, dass das einer Deiner Glaubenssätze ist…Frage Dich mal selbst…Hast Du deinen Mitarbeitern einen klaren Rahmen gegeben in dem sie kreativ arbeiten können oder nimmst Du ihnen immer die Arbeit aus der Hand und lässt ihnen daher gar keine Chance selbst Probleme zu lösen?   Du hast Dein Team erzogen – wohin auch immer…zur Unmündigkeit, das sie nicht handeln dürfen und wissen, dass Du sowieso kommst um die Kuh vom Eis zu holen oder dazu selbst zu handeln und genau zu wissen in welchem Rahmen sie die Arbeit erledigen sollen…

Ich denke, wir werden auch hier durch die Coronazeit einen Schritt in die richtige Richtung machen:  Wir vertrauen unserem Team und unseren Kollegen und setzen auf die Kreativität jedes einzelnen,  sich selbst, seine Arbeit und die Ergebnisse der Arbeit zu organisieren und dabei- ganz nebenbei „empowert“ also „ermächtigt“ zu werden wieder selbständig zu denken und zu handeln… dann sind wir wieder bei der Agiliät angekommen..

Soweit dazu – Ich danke Dir fürs Zuhören, dieser besonderen Osterfolge des Jahres 2020 – auch wenn du verspätet hörst – oder vielleicht auch erst einem Jahr diese Folge hörst oder nochmal hören wirst – es wird interessant sein zu sehen, was von der Corona-Krise übrig geblieben sein wird..ich bin zuversichtlich – am Ende wird alles gut…so wie im Film..

Wie steht es so schön in der Bibel „Alle Dinge sind möglich dem, der da glaubt.“   Markus 9, Vers 23

Ich wünsche Dir frohe Ostern in einer besonderen Zeit

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 09: Sonderfolge zu Corona…Überleben im Homeoffice als Agiler Coach, Scrum-Master, Product Owner oder Mitglied eines agilen Entwicklerteams…und sonst auch.

Wie wahrscheinlich dich und eigentlich alle, so hat auch mich die Wucht der Coronawelle getroffen und mich in ein Homeoffice-Dasein gespült, welches ich vor 2 Wochen nicht für möglich gehalten hätte…Und so habe ich die erste Woche nun hinter mir und habe auch eine Menge dabei gelernt…unter anderem habe ich an ein paar Meetups und Workshops teilgenommen und dabei festgestellt, dass es eine Reihe von Dingen gibt, die ich so noch nicht gesehen habe und das fand ich wieder ganz spannend – und das, obwohl ich schon vorher oft mit verteilten Teams gearbeitet habe und auch als Angestellter in einem international tätigen Unternehmen ein ganze Menge über Telkos und Konferenzsoftware lief…und dachte ich bin schon schlau…(scherz)

So sammle ich hier in dieser Folge einfach mal, was mir so einfällt zum Thema Homeoffice und wie Du das beste daraus machen kannst…rein subjektiv natürlich

Ich fange mal an mit Tools, also Technik und was du bei Telkos oder Videokonferenzen beachten solltest: Die Basics dürften Dir bekannt sein…Skype, Zoom, WebEx, Microsoft Teams, Skype for Business, GoToMeeting, Jitsi, Discord, Meet, Meetzippy – diese ganzen gängigen Tools für Videokonferenzen oder Onlinemeetings sind bekannt und stellen die Basis oder das Rückrad für virtuelle Teamarbeit oder Remoteoffice dar. Ich habe mal ne Reihe davon aufgezählt und ich will die hier gar nicht einzeln durchgehen oder bewerben – jedes hat seine Vorteile hier und da und irgendwie funktionieren auch alle. Es kommt natürlich darauf an, welches Tool Dein Arbeitgeber oder Deine Firma oder Kunde als Standard ausgesucht hat. Tools, die Du noch nicht kennst, kannst Du ja mal ausprobieren – das ist ja meistens kostenlos. Rein als Info: Ich persönlich finde Zoom zur Zeit das Tool mit dem besten Leistungsumfang – vor allem in der kostenlosen Version. In der kostenpflichtigen Version gibt es auch die Möglichkeit mehrere Räume zur Verfügung zu stellen und die Teilnehmer der Konferenz für Breakt-Out sessions dort zuzuordnen. Der Einladende muss dann allerdings eine Lizenz besitzen – die kostet meines Wissens jetzt so etwa 12,-€/Monat – für die Teilnehmer bleibt es weiterhin natürlich kostenlos…

Neben den reinen Konferenztools, deren Hauptfunktion die Video und Tonübertragung ist, gibt es noch eine Reihe von anderen interessanten Apps für die asynchrone Kommunikation wie Slack oder die Möglichkeiten von Office365 oder Google-Docs für die gemeinsame Bearbeitung von Dokumenten nebenbei. 

Auch sehr hilfreich sind Whiteboard Tools wie „Nexboard“, Mural oder MIRO ich sag mal als Premium-Produkte  – oder Webwhiteboard als sehr einfache Variante davon (kostenfrei nutzbar), wobei auch in Zoom und Meetzippy ist so eine Whiteboardfunktion in einfacher Form integriert ist. Wenn Du Nexboard noch nicht kennst solltest Du das mal ausprobieren- ist übrigens ein Tool aus Berlin…hierzu hatte ich letzte Woche eine nette Erkenntnis im Rahmen eines Meetups von „Agility Works“ von Klaus Schein…Klaus nutzt das Tool zur Moderation von Ganztages-Workshops und es funktioniert. Der Trick dahinter ist, dass man in Nexboard eigene Bilder, Grafiken, selbst erstellte Canvas oder auch ppt. Folien hinterlegen kann und die dann mit virtuellen Post-It’s bekleben kann (von allen Teilnehmern) – diese lassen sich dann auch per Dot-Voting bewerten. Jeder Teilnehmer kann immer alles anfassen und verschieben – wie an einem echten Board. Ein Vorteil für uns Agilisten ist die Anonymität der Post-It‘s, da man nicht sieht wer sie geschrieben hat. Daher ist das auch gut für Retrospektiven einsetzbar. (Wenn man einen Workshop macht, wo es irgendwie von Mehrwert ist, zu wissen, wer was geschrieben hat, könnt ihr Euch einen Farbcode überlegen –  jede Person kann dann die Post-its in einer bestimmten Farbe versehen…MURAL hat einen ähnlichen Funktionsumfang, nur habe ich noch nicht damit gearbeitet…und bei MIRO sieht man immer den Autor…

…soweit zur Technik – wie gesagt – ich will hier nur kurz drauf eingehen, denn wie heißt es so schön: a fool with a tool is still a fool….es geht ja darum, wie wir selbst mit der Situation besser umgehen können…

Was kannst Du beachten, wenn es um virtuelle Team-Meetings geht:

  1. Nach meiner Erfahrung – auch mit einem Team, welches verteilt in Indien und Deutschland saß  – es ist wichtig am Anfang eines Meetings einen Check-in durchzuführen – also als einfachste Form: Jeder schreibt seinen Namen auf das virtuelle Whiteboard in so einem kleinen Post-It.. – besser ist es allerdings das mit einer witzigen oder vielleicht auch sinnlosen Frage zu begleiten, um gleich ein wenig Lockerheit und Spirit ins Meeting zu bekommen. Sowas wie: „Stell dir vor, Du bis ein Auto – welches Auto wärst du im Moment? – das geht auch mit Tieren…oder Comicfiguren…Dann kann man gleich versuchen das zu zeichnen (was mit Maus natürlich schwer ist – ein iPad-oder Tablet mit Stift funktioniert mit den virtuellen Whiteboards leider noch nicht so gut – die Verzögerung beim Schreiben oder Malen ist doch ziemlich groß.) aber je blöder das aussieht, desto lustiger kann es sein. Du kannst natürlich auch reihum nachfragen, welche Erwartungen jeder an das Meeting hat.
  1. Halte Meetings kurz (am besten nicht länger als 45min) vielleicht auch mal länger so bis zu ner Stunde oder so. Ich meine hier keine Workshops dazu erzähle ich gleich noch was:
  1. Mach Pausen bzw. plane Pausen ein: am besten alle 45 min.  Zu den beiden letzten Punkten: ich finde Videokonferenzen oder auch Telefonkonferenzen irgendwie anstrengender als Live-Meetings. Ich weiß nicht, ob es Dir auch so geht…nach 45min konzentriertes Zuhören und zusehen von teilweise schlechter oder schwankender Bild oder Tonqualität- da regt sich bei mir Unmut bzw. Stress/Müdigkeit. Entweder ich schalte dann geistig ab oder ich strenge mich an, was dann irgendwann zu Kopfschmerzen, Verspannungen oder ähnlichen Symptomen führt. Also bitte ich Dich – wenn Du Meetings ansetzt – halte die kurz.
  1. Bitte auch alle Teilnehmer, sich immer zu „Muten“ also stummzuschalten, wenn sie gerade nichts sagen wollen. Das hilft ungemein, denn Nebengeräusche aus 10 Hintergründen nerven total und keiner kann mehr was verstehen…ausserdem kann es vielleicht mal peinlich sein, wenn für alle laut zu vernehmen ein „MAMA, ICH MUSS MAL PULLERN!“ kommt …
  1. Insgesamt aus meiner Sicht: ein Onlinemeeting braucht einen wachen und fairen Moderator, der immer mal wieder drauf achtet, dass die Redezeiten gleich verteilt sind, also stillere Teilnehmer auch mal anspricht und auflockert und für eine Struktur sorgt. Es braucht mehr Ansagen und Führung, da vieles, was sonst über Mimik oder Gestik kommuniziert wird, im Onlinemeeting einfach wegfällt. 

Workshops über 1 oder 2 Tage. Obwohl ich Dir gerade gesagt habe, dass Meetings kurz sein sollen: das geht schon…Nur bitte mit nicht mehr als 9 Teilnehmern (halte Dich hier an die eherne Scrum-Regel der Teamgröße) und – ich habe es vorhin schon erwähnt: Bereite den Workshop vor, in dem Du strukturierende Canvas oder „Flipcharts“ vorbereitest und ein geeignetes Whiteboard-Tool benutzt. Das geht auch wunderbar neben der eigentlichen Videokonferenz – wenn Du den Bildschirm teilst.  Bei Workshops ist es dann besonders wichtig, dass du dann zum Mitmachen animierst und da kannst Du zum Beispiel auch Elemente aus Serious Games einbauen (jeder im Team kann z.B. eine kleine Packung Legosteine nach Hause geschickt bekommen und dann baut ihr gemeinsam – oder jeder …je nachdem…) Oder Elemente der Pantomime (was natürlich nur bei ner funktionierenden Videokonferenz funktioniert. Sehr hilfreich sind auch Abstimmungen, die z.B. bei Nexboard mit Dotvoting funktionieren oder Du bereitest für den Workshop was vor über so ein Tool wie Mentimeter…Bei so langen Workshops – oder auch generell solltest du dir auch einen Co-Moderator anheuern, der nebenbei den Chat-Kanal liest und auf Fragen reagieren kann.

Der nächste Aspekt, den ich ansprechen möchte, ist – wie kannst Du dich zu Hause verhalten, so dass dir nicht die Decke auf den Kopf fällt und du produktiv bleibst bzw. aber auch nicht nur noch in Arbeit versinkst…

  1. was gut funktioniert ist: behalte Deine Rituale bei – gehe zum Beispiel raus, bevor Du anfängst zu arbeiten und mach einen kurzen Spaziergang um den Block oder so…Du kannst ja mit dem Hund rausgehen, mit Deiner Katze, dem Kanarienvogel oder deiner Schildkröte, die freuen sich dann auch (und Du hast eine Begründung, falls dich jemand fragt)
  1. Dazu gehört auch, dass Du dich so anziehen solltest, als wenn Du ins Büro gehen würdest. Wenn Du den ganzen Tag im Schlafanzug rumhängst, schlägt sich das auf Deine Psyche, das kann ich dir versprechen…
  2. Mache eine Mittagspause – am besten auch draussen bzw. nicht da, also in dem Raum, wo Du arbeitest!
  1. Und – suche Dir einen Platz zum Arbeiten der nicht derselbe Platz ist, an dem Du chillst – also runter vom Sofa und weg vom Fernseher, wenn Du arbeitest! Wenn Du kein Arbeitszimmer hast, such Dir einen Platz im Schlafzimmer oder in der Küche oder wo es sonst gut für Dich ist. Du wirst schon was finden…Falls alles nichts hilft, stell Dir einen Campingtisch ins Wohnzimmer und arbeite da. Denk Dir was aus. Es ist wichtig, dass Du die Arbeit mental von der Freizeit trennst, denn sonst verschwindet der Übergang und Du arbeitest nur noch …oder Su wirst gar nicht wirklich produktiv…das liegt jetzt ganz bei Dir, wie es dann wirklich ist (wie ohnehin alles, was ich hier sage ja nur eine Ideensammlung darstellt – alles kann – nichts muss!)
  1. Natürlich kannst Du dir jetzt auch mal Gedanken machen, was Du alles für einen „richtigen“ Homeoffice-Platz brauchst und das ggf. auch mit Deinem Arbeitgeber besprechen: ein ordentlicher Monitor gehört dazu, wenn Du länger im Homeoffice bleibst und am besten ein höhenverstellbarer Schreibtisch mit einem entsprechenden Arbeitsstuhl und genügend Licht.
  1. Was ihr im Team auch machen könnt: virtuelle Kaffeepausen – ihr „würfelt“ sozusagen die beiden aus, die dann mal ne 1/4h – jeder mit einer echten Tasse Kaffee oder Tee – dann in einem eigenen kleinen Raum (also virtuell) mal miteinander quatschen…Oder ihr richtet einen virtuellen Raum ein, den Ihr „Kaffeemaschine“ nennen könnt – oder „Launch“ oder so, in den sich dann die Leute einwählen können und einfach mal sehen, wer da noch so ist.
  1. Mach Dir durchaus auch ein Taskboard zuhause – beklebe Deine Wände mit Post-It’s – und nutze die auch privat oder mit den Kindern… Das hilft, macht Spaß und bringt was Neues rein…
  2. Biete allen Hilfe an, denen es nicht so gut geht…wenn Du alleine wohnst, schau, mal, was sich in deiner Nachbarschaft so tut – es gibt z.B. das Social Network „nebenan.de“ wo Du vielleicht Hilfe für ältere Menschen anbieten kannst (z.B.einkaufen oder mit dem Hund gehen oder so). Das kannst Du natürlich auch machen, wenn Du nicht alleine wohnst, aber wenn Du Deine sozialen Kontakte vorwiegend im Jobumfeld hast, kann das helfen auch wieder andere Menschen zu sehen als nur die Videos oder Dein Spiegelbild.
  1. Nutze die besondere Zeit, die sich jetzt bietet. Wir haben z. B. gerade Fastenzeit – nur mal so als Tipp: Wann – wenn nicht jetzt – ist die Gelegenheit für eine Fastenkur? Du wirst selten so wenige Verführungen haben, wie jetzt – Auch Sport ist wichtig. Da zur Zeit auch die Fitnessstudios geschlossen sind, bleibt vielleicht für Dich ein Hometrainer auf dem Balkon? Oder ein Trampolin im Schlafzimmer? Ein paar Hanteln auf dem Flur?. Es gibt eine Menge Onlinekurse und natürlich spriessen die Angebote derzeit, wie Pilze aus dem Boden. Nur mal so als Tipp, was es so gibt: Pure.Life- ist zum Beispiel ein Online-Fitnessstudio mit echt vielen Angeboten. Du findest bestimmt einen Anbieter oder einen Service der zu Dir passt. Du kannst auch über Babble sprachen lernen oder morgens geführt meditieren mit Seven Minds…Die Anbieter oder Tools, die ich hier nenne, sind nur Beispiele, falls Du in dem Bereich noch nichts weist und die ich oder meine Frau selber nutzen. Insofern weiß ich , dass das für mich ganz gut ist. Soll aber keine Empfehlung oder Werbung sein…sondern nur eine Inspiration. 
  1. Lass Dir helfen, wenn Du dich unwohl fühlst – damit meine ich nicht Corona-Symptome, sondern ich weiß, dass diese Zeit auch eine Zeit der Ängste sein kann…als Freiberufler sowieso, aber auch als Angestellter oder Jobber ist die Zeit von großer Unsicherheit geprägt. Suche Dir einen Coach – auch Online machen immer mehr Coaches nun Angebote – auch ich stehe dafür zur Verfügung.

So – soweit erstmal dazu. Du findest im Netz zur Zeit überall Angebote von Coaches und allen möglichen Leuten, die mal was verkaufen wollen oder auch nur helfen oder auch beides…Ich denke, die Welt wird eine andere sein, wenn der Corona-Spuk vorbei ist…Verteiltes Arbeiten, Homeoffice und Lernen im Netz wird sich etablieren und aus der vielleicht noch vorhandene Nische herauskommen. Auch dabei wird es Gewinner und Verlierer geben. Wir – Du und ich  – haben es natürlich dabei in der Hand selbst dafür zu sorgen, auf welcher Seite wir stehen. Ich wünsche Dir eine gute, möglichst coronafreie oder zumindest coronaarme Zeit für Dich und Deine Liebsten. 

Bleibe gesund

Und Tschüß –  bis zur nächsten Folge

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