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

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

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

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

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

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

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

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

Hört sich gut an oder?

Stell Dir das mal vor – 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

und was bedeutet das jetzt in der Praxis?

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

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

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

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

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

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

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

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

Signal Nr. 5: Nur Du arbeitest am Backlog.

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

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

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

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

Mmhhh….

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

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

Tschüß – Dein agilophiler Frank

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tschüß

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 10: Das Review-Meeting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Soweit dazu…

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

so 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NEU: Tschüß – dein agilophiler Frank

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

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

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

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

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

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

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

Dinge, die Du beim Daily vermeiden solltest:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Der Scrum-Master…

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

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

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

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

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

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

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

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

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

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

Tschüß Dein agilophiler Frank

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

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

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

Doch zunächst einmal: 

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

Das Sprint Planungsmeeting beantwortet also folgende Fragen:

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

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

Also nochmal die einzelnen Teile:

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

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

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

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

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

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

Was das Dev.-Team alles falsch machen kann…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So…

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

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

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

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

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

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

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

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

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

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

Tschüß

Dein Frank

Agilophil-Daily Podcast Episode 06: Das agile Manifest

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

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

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

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

Manifest für Agile Softwareentwicklung

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

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

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

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

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

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

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

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

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

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

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

Prinzipien hinter dem Agilen Manifest

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

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

Kommen wir zum

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Unterzeichner des Manifests waren:

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

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

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

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

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

Tschüß

Dein Frank

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

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

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

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

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

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

Grund Nummer 1: Der Realität ins Auge sehen

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

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

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

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

Grund Nummer 2: schneller sein…

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

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

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

Grund Nummer 3: Qualität bereits eingebaut:

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

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

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

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

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

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

Grund Nummer 5: Bessere Planung

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

Doch genau das Gegenteil ist der Fall:

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

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

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

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

Also hier nochmal die Planungshorizonte…

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

Fazit: Scrum oder nicht Scrum?

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

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

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

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

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

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

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

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

Soviel zu Scrum oder nicht scrum

Ich hoffe, die Folge hat dir gefallen.

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

Mach’s gut 

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 04 – Was ist Scrum?

Was ist scrum und wie entwickelt es sich weiter?

Ich habe mir überlegt, ob ich überhaupt eine Folge zur Erklärung von Scrum machen soll. Ich habe bereits in den ersten Folgen Scrum ein paar mal erwähnt und einige Begriffe daraus genannt. Ich gehe eigentlich davon aus, dass Du Scrum schon kennst, insofern sollte das, was ich jetzt erzähle nicht neu für Dich sein. Daher ist es auch nicht schlimm, wenn du die Folge hier überspringst oder auch mal vorspulst. Aber letztlich habe ich mich entschieden: ich mache es einfach trotzdem – ich erkläre jetzt Scrum:

1.Bild: 2000 Jahre zurück

Um das zu tun,  bitte ich Dich gedanklich ein Experiment zu machen – falls Du gerade nicht Auto fährst – schließe die Augen und versetze dich gedanklich in die Zeit vor 2000 Jahren. (wenn Du Auto fährst, lasse die Augen bitte offen und versetze dich trotzdem in die Zeit vor 2000 Jahren)

Es ist also Winter kurz nach Beginn unserer Zeitrechnung. Überlege, was genau hier, wo Du jetzt bist, vor 2000 Jahren war. In den allermeisten Fällen wird das Wald sein, ggf. sumpfiges Gelände – es ist wie gesagt Winter, wahrscheinlich war es auch deutlich kälter als jetzt, aber auch knapp über 0 Grad und Regenwetter ist ja nicht gerade gemütlich…Dein Smartphone gibt es nicht – selbst wenn Du es noch dabei hättest, wäre es sinnlos, denn es gibt weder ein Netz noch einen Tarifanbieter dafür…

Die Frage ist nun: was machst Du? Du bist plötzlich 2000 Jahre zurückkatapultiert worden und sitzt nun in einem winterlichen Wald und es ist kalt. Nach dem ersten Schock wirst Du anfangen zu überlegen…Du brauchst Nahrung, Wärme und Schutz. Aber in welcher Reihenfolge…

Nun will ich hier natürlich nicht auf die psychische Belastung dieser Situation eingehen und jeder wird abhängig von der eigenen Situation vieleicht andere Prioritäten setzen, also wir nehmen einfach mal an, du hast dich entschlossen zunächst mal einen Schutz zu bauen…

Also, was machst Du?

Erstens. 1. Du überlegst, wie dieser Schutz oder vielleicht die Hütte aussehen könnte, welches Material du dazu brauchst, und welches hier zur Verfügung steht.

Die Hütte soll zunächst möglichst schnell stehen, damit du idealerweise heute Nacht schon in ihr schlafen kannst – Also Visionen von einem komfortablen Einfamilienhaus oder einem Palast scheiden in dieser Situation schon mal aus…

Zweitens 2. Du schreitest zur Tat: suchst Dir das nötige Material und baust es zusammen, so dass es am Ende die nötige Funktion hat – also vor allem den Regen und die Kälte abhalten

Drittens 3. Du probierst es aus – d.h. Du schläfst die erste Nacht in der Hütte

Viertens 4. Am nächsten Morgen schaust Du dir das Ganze nochmal an und überlegst was Du besser machen könntest – Du stellst z.B. fest, dass es an einer Stelle noch reinregnet oder der Wind durchpfeift, Du könntest Dir vorstellen, dass es gut wäre die Tür von innen zu verriegeln und so weiter und so weiter…

fünftens 5. Du beginnst wieder einen Plan zu machen, um die Verbesserungen, die Du dir überlegst hast, umzusetzen…

Deming Circle

Das war jetzt etwas vereinfacht dargestellt, aber Du wirst mir wahrscheinlich zustimmen, dass diese Art von Arbeit eine relativ „natürliche“ und menschliche ist und dass das sich seit Anbeginn der Menschheit wahrscheinlich nicht sonderlich geändert hat. In neuerer Zeit wird dieser Zyklus gerne als „Deming Cycle“ oder PDCA-Cycle bezeichnet, nach William Edwards Deming, einem amerikanischen Physiker und „Pionier des Qualitätsmanegements“. PDCA steht dabei für Plan, Do, Check, Act, also die Planen, Umsetzen, Überprüfen und verbessern.

In Scrum ist dieser Zykluns ein wesentlicher Bestandteil und der eigentliche Kern des Ganzen, denn Scrum basiert auf Iterationen, also dem Wiederholen von genau diesem zyklischen Modell. Ein Sprint bezeichnet dabei genau eine solche Iteration und ist eigentlich eine Zeiteinheit (meistens 1-4 Wochen). 

Die im Scrum-Guide beschriebenen Scrum Events verdeutlichen sehr schön die Anwendung des Deming Cycles:

Ein Sprint beginnt mit dem Planungsmeeting (also mit dem Punkt „Plan“). Das Ergebnis des Planungsmeetings ist eine Liste der Dinge, die im Sprint getan werden sollen, das sogenannte „Sprint-Backlog“. 

Der nächste Schritt ist das „Do“, also die Realsisierung der geplanten Dinge durch das Scrum-Team. Hier wird durch das Daily Standup-Meeting die Transparenz im Team hergestellt, so dass jeder weiss, was der andere tut, und wo er steht oder ggf. Hilfe benötigt. 

Am Ende des Sprints folgt das Review-Meeting, also im Deming-Cycle das „C“ für Check. Hier wird gezeigt, was das Team realisiert hat und Feedback von den Stakeholdern oder Kunden eingeholt. 

Die Frage nach Verbesserungen in der Arbeit wird in der anschließenden Retrospektive besprochen, so dass die Informationen aus dem Reviewmeeting und der Retropektive direkt wieder in das nächste Planungsmeeting einfließen können. Damit ist der Kreis geschlossen und ein neuer Durchlauf – also ein neuer Sprint kann starten.

Doch zu Scrum gehören nicht nur festgelegte Events oder Meetings, sondern auch festgelegte Rollen, die aus einem Team oder einer Ansammlung von Leuten, ein Scrum-Team machen.

Da wäre zunächst das schon erwähnte Development-Team. Das Dev.-Team besteht aus 3-9 Mitgliedern und soll all das Wissen und alle Fähigkeiten vereinigen, die zur Umsetzung der Aufgaben im Sprint benötigt werden – es soll also interdisziplinär aufgestellt sein und aus Entwicklern (Frontend-Backend), Architekten, Tester, Anwender usw. bestehen. 

Das Scrum-Team organisiert sich selbst – innerhalb des Teams gibt es keine Hierarchie oder Teamleiter-Positionen. 

Das Dev-Team ist für das „WIE“ bei der Realsisierung zuständig, also man könnte es auch umschreiben mit: Das Team ist für die Effizienz zuständig, also dafür das das was wir benötigen richtig umgesetzt wird. ( also – “die Sache richtig machen” – also mit der richtigen Technologie, ressourcenschonend usw. ).

Dazu kommt der Product Owner, der für das „WAS“ im Projekt verantwortlich ist. Der Product Owner hat die Vision des Produktes und versetzt sich in die Lage des Kunden bzw. hält Kontakt mit ihnen –  spricht auch mit ihnen. Er ist für die Effektivität zuständig also, also dass das Richtige gemacht wird um die Ziele zu erreichen oder die Probleme der Kunden zu lösen.

Die 3. festgelegte Rolle im Scrum ist die des Scrum-Masters. Die Aufgabe des Scrum-Masters ist es dafür zu sorgen, dass das gesamte Team Scrum versteht, lebt und auf Basis der agilen Werte arbeitet. Er ist dabei nicht inhaltlich unterwegs sondern kümmert sich darum auf das Team und die Zusammearbeit zu achten und darauf, dass Scrum so echt wie möglich gelebt wird. Eine weitere Hauptaufgabe des Scrum-Masters ist die Beseitigung von sogenannten „Impediments“ also Hindernissen, die das Team bei der Arbeit behindern oder das Team von schädlichen Einflüssen von außen zu schützen.

Neben den Events und den Rollen ist der 3. große Block, den Scrum ausmacht, der der Artefakte, also der „Dinge, die man anfassen kann“. Das auffälligste Artefakt bei Scrum ist zweifelsohne das Taskboard. Ein Taskboard ist eine Visualisierung der Arbeit an einer Wand – für alle einsehbar, anfassbar und transparent. Letzendlich ist das Taskboard aus Kanban übernommen worden und stellt eine Tabelle dar, die nur aus 3 Spalten bestehen zu braucht: eines Spalte “offen” für alle im Sprint geplanten und noch nicht begonnenen Aufgaben. Eine Spalte “in Arbeit” für alle Aufgaben, die aktuell bearbeitet werden und eine Spalte “Fertig” für alle abgeschlossenen Aufgaben.

Das wichtigste Artefakt ist aber das Product Backlog. Das ist die geordnete Liste aller Anforderungen, die an das Projekt oder Produkt bestehen. Dabei ist das Product Backlog niemals vollständig, sondern umfasst nur den aktuellen Stand im hier und jetzt. Es ist inzwischen sehr verbreitet die Anforderungen als sogenannte “User-Stories” zu beschreiben, was auch einen gewissen Vorteil hat. Die Anforderung wird dazu in einer bestimmten Struktur beschrieben aus der klar wird: wer fordert das an (also die Rolle des Anfordernden)? Was wird angefordert (die eigentliche Anforderung) und warum wird das angefordert? (worin besteht der Nutzen darin). Allein, dass man über diese 3 Punkte nachdenken muss, um eine Userstory zu schreiben, hilft schon sehr dabei Unsinniges sofort von Sinnvollem unterscheiden zu können. Zum Thema Userstories wird es aber noch eine gesonderte Folge geben..

Das Product Backlog wird vom Product-Owner verantwortet. Das bedeutet nicht, dass er oder sie alle Userstories oder Anforderungen selbst schreiben muss, sondern er oder sie ist dafür verantwortlich wie sie im Produkt Backlog stehen, wie sie sortiert oder priorisiert sind, was zuerst umgesetzt werden soll und was zu einem MVP  – also zu einem minimal valuable product oder zum nächsten Release gehört und was nicht. Das Product Backlog ist sozusagen der Speicher für das “WAS” im Projekt und das Product Backlog bestimmt letztlich wie die Arbeitsleistung des Teams am besten zum Wohle des Unternehmens eingesetzt werden kann. 

Bedenke immer, wenn Du Product Owner bist: die Mitglieder des Dev.Teams arbeiten (im allgemeinen) immer gleich gut, sie verdienen immer gleich viel, jeden Monat dasselbe. Du bestimmst aber welchen Wert sie für das Unternehmen darstellen und ob sie in der Zeit etwas sinnvolles machen oder nicht!

Ein weiteres Artefakt ist das Sprint Backlog – das habe ich eben schon mal erwähnt. Das Sprint-Backlog stellt eine Teilmenge des Product-Backlogs dar, nämlich der Teil der Anforderungen, der im nächsten Sprint umgesetzt werden soll.

Das Product-Increment ist ein weiterer Artefakt: Das Increment stellt ein funktionierendes kleines Produktbestandteil dar, welches nach Ende des Sprints genutzt werden kann. Hier wird Mehrwert oder Nutzen für den Kunden geschaffen – das ist immer das Ziel!

Das Burn-Down Chart wurde früher ebenfalls als Artefakt genannt, ist aber aus dem aktuellen Scrum-Guide wieder verschwunden. Das liegt daran, dass das Burn-Down-Chart zu oft zu Missverständnissen geführt hat und von Managementkreisen zu unzulässigen Bewertungen über die Teamleistung herangezogen wurde. Trotzdem ist das Burn-Down Chart nicht verboten. Es ist ein Diagramm, welches die Restarbeit im Sprint darstellt (als Anzahl von Anforderungen oder Aufwänden) und läuft im Idealfall als fallende Gerade vom Sprintstart bis zum Sprintende um am Ende die 0 zu erreichen (also keinen Rest mehr). Das große Problem beim Burn-Down-Chart ist, dass dieser ideale Verlauf nie eintritt und das oft damit verbunden wird, dem Team eine schlechte Leistung zu attestieren. Es kann aber dem Team durchaus dabei helfen, sich selbst besser zu organisieren. Hier ist der Scum-Master gefragt und seine Aufgabe wäre es, die Bedeutung des Burn-Down-Charts für das Team zu verständlich zu machen und auch dem Management die Gefahr bei Vergleichen oder Veröffentlichen von Burn-Down-Charts zu verdeutlichen. Es geht am Ende darumh das Team vor einer Mißinterpretation durch das Management zu schützen.

So weit erstmal zu den 3 Großen Bereichen in Scrum: Den Events, den  Rollen, den Artefakten.

Beschrieben wird praktischerweise alles im offiziellen Scrum-Guide (die letzte Version stammt bei Aufnahme dieses Podcasts aus dem November 2017).

Der Scrum-Guide wurde erstmals 2010 veröffentlicht und auch er unterliegt einer Evolution, wie es   bei agilen Projekten üblich ist. So ist es interessant, wie sich der Scrum-Guide im Laufe dieser Jahre verändert hat.

Der erste Scrum-Guide wurde im Februar 2010 veröffentlicht

Hier wurde noch sehr viel Wert auf die Bedeutung von Scrum als Anwendung der empirischen Prozess-Theorie gelegt und dass es ein Framework zur Entwicklung komplexer Produkte ist. Bemerkenswert ist auch, dass in der ersten Version das Release Burndown und das Sprint-Burndown als wesentliche Pflicht- Artefakte genannt werden, diese jedoch dann in den folgenden Versionen verschwinden. Zudem wird hier als 4. Säule von Scrum neben den Rollen, den Events und den Artefakten das “Timeboxen” genannt. Also der besondere Fokus auf die Einhaltung von Zeitvorgaben (z.B. beim Daily Scrum – 15min)

Die Version vom Juli 2011 kommt schon sehr Nahe an die heutige Version heran, vor allem im Aufbau: Die Definition von Scrum geht ab von der Entwicklung von komplexen Produkten hin zur Behandlung von komplexen Problemen (was natürlich eine viel breitere Anwendung von Scrum zulässt.) Ferner werden die Rollen klarer beschrieben – insbesondere der Scrum-Master als Service für den Product-Owner, das Team und die gesamte Organisation. Außerdem wird das Backlog Grooming als notwendig eingeführt – Das Backlog Grooming ist ein sehr wichtiges Meeting, welches den Blick über den Tellerrand ermöglicht. Hier wird die Vision und die später kommenden Aufgaben betrachtet und das Project Backlog überprüft und “ausgemistet”. Ein wichtiges Detail ist ferner, dass das Ergebnis der Sprintplanung nicht als commitment bezeichnet wird (was dann auch gerne als Selbstverpflichtung übersetzt wird), sondern als Forecast (also Vorhersage – die ja nicht unbedingt eintreten muss.).

Es gab noch eine weitere Version aus dem Oktober 2011, die aber keine relevanten Änderungen aufwies.

In der Version von 2013 wird der vorher verwendete Begriff Grooming geändert in Refinement, was den Sinn des Ganzen besser trifft. Das Product-Backlog soll nicht nur ausgemistet, sondern es soll den neuen Erkenntnissen angepasste werden Es soll schließlich aus dem bisherigen Projektverlauf gelernt werden.

Außerdem werden die 3 Fragen im Daily-Standup-Meeting präzisiert: es heiß nun nicht mehr: was habe ich gestern getan?- was werde ich heute tun? und was behindert mich? – sondern es geht mehr um den Teamaspekt: es heißt nun: 

  • was habe ich gestern getan um dem Team zu helfen das Sprintziel zu erreichen?
  • was will ich heute tun um dem Team zu helfen das Sprintziel zu erreichen?
  • was hindert mich daran, dem Team zu helfen das Sprintziel zu erreichen?

Ferner entsteht nun der Gedanke, dass ein Product-Backlog Eintrag nach einem Refinement “ready for Sprint” sein soll, also soweit fertig beschrieben – also verständlich, mit Akzeptanzkriterien und vor allem klein genug, so dass es im Sprint umgesetzt werden kann.

In der nächsten Version aus dem Juli 2016 wird nun erstmals auf die Scrum-Werte eingegangen – diese Werte über die ich in der ersten Folge schon gesprochen habe, gab es zwar schon früher, aber sie waren im Scrum Guide nicht explizit erwähnt, was dazu führte, dass man das nicht als Bestandteil von Scrum interpretiert hatte. Das ist seit 2016 anders.

In der aktuellen Version von 2017 geht es vor allem darum, zu starre Formulierungen so zu lockern, dass die Teams mehr Gestaltungsfreiheit bekommen. Es wird verstärkt Wert auf den Aspekt des Wissenstransfers im Team gelegt, die 3 Fragen aus dem Daily-Scrum werden bezeichnet als nur eine Möglichkeit das Meeting zu strukturieren. Die Rolle des Scrum-Masters wird von einem Scrum-Polizisten mehr in Richtung Scrum-Coach gelenkt, der dem Team hilft Scrum zu verstehen und nicht nur die Regeln durchsetzt. Ebenfalls den Scrum-Master betrifft die Vorgabe für eine Retrospektive mindestens eine konkrete Maßnahme zu benennen, die im nächsten Sprint direkt umgesetzt werden soll um die Teamarbeit zu verbessern.

Links zur Folge:

Der Scrumguide in der aktuellen Version ist zu finden auf:
https://www.scrumguides.org

Die Weiterentwicklung des Scrumguides basiert auf einem Blog-Beitrag von Paddy Corry auf „medium.com“ („The evolution of the Scrum-Guide ‘10-‘19)
https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide-10-to-19-f3ac4d82cfcb

Agilophil-Daily Podcast Episode 03: Agile Werte

Doppelte Arbeit in der Hälfte der Zeit!

Wenn Sie agil werden (bzw. Scrum einsetzen), schaffen Sie die doppelte Arbeit in der Hälfte der Zeit…das klingt doch gut, oder?

Dieses Versprechen von Jeff Sutherland, einem der Erfinder von Scrum, verleitet viele Vorstände oder Manager zu einem Trugschluss: Es gibt da ein Tool, und wenn ich das einführe, dann werde ich so erfolgreich, dass die nächste Beförderung nicht mehr zu verhindern ist. 

Denn- ich- als Manager-  muss mich ja um nichts kümmern, ich habe ja das neue Wundertool – und dazu kaufe ich mir einfach so einen neuen, teuren Agile-Coach oder externen Scrum-Master und so kann ich mich ruhig in meinem Chefsessel zurücklehnen und meinem Vorstand zeigen: Tja – in meiner Abteilung läuft alles super, denn ich habe die richtigen Entscheidungen getroffen. Alle Projekte werden plötzlich schneller fertig, die Kosten laufen nicht mehr aus dem Ruder und meine Abteilungskennzahlen sind alle so grün, dass ich der neue Star des Unternehmens werde…und am Ende des Jahres kaufe ich mir dann den neuen Porsche Cayenne und den Pool, mit dem ich schon immer bei meinen Grillparties angeben wollte….

Stopp Stopp Stopp – aufwachen – raus aus den Träumen!!!

Das ist natürlich nicht so einfach, denn die Einlösung des Versprechens hat eine Kehrseite der Medaille: Das Ganze funktioniert nur, wenn die Einstellung zur Arbeit im gesamten Unternehmen überprüft (und in den meisten Fällen) auch geändert wird!

Hierarchien sind da eher hinderlich und – wenn das mit der Agilität wirklich um sich greift, dann säge ich ja an meinem eigenen Stuhl…oh…

Also suche ich lieber nach einem Weg, nach aussen agil zu sein und in der eigentlichen Unternehmenskultur und Struktur möglichst alles so zu lassen wie es ist…

Wir kommen langsam zu Kern des Ganzen: Man kann sich nicht waschen, ohne sich nass zu machen…Wenn Du agil sein möchtest, musst du die agilen Werte leben. Und wenn die Kultur und die Werte in Deinem Unternehmen anders sind, dann wird “agil” nicht funktionieren… denn die Werte sind die Basis:

Im Scrumguide wird zum Beispiel von folgenden Werten gesprochen:

  • Respekt
  • Mut
  • Offenheit
  • Commitment
  • Fokus

und jetzt vergleiche ich das mal mit den Werten, die Patrick Lencioni in seiner Pyramide zu den 5 Dysfunktionen eines Teams beschreibt:

das wären von unten nach oben gesehen

1. Vertrauen, 2. Konfliktbereitschaft, 3. Selbstverpflichtung, 4. gegenseitige Verantwortlichkeit und 5. Zielorientierung, 

Du stellst sicherlich fest, dass das sehr ähnlich klingt:

  • Vertrauen ist die Basis auf der ein Team zusammenarbeiten muss, und Vertrauen gelingt nur mit Respekt. 
  • Die Konfliktbereitschaft ist der nächste Punkt, denn nur mit ausgetragenen Konflikten findet das Team zusammen und dazu gehört der Mut unangenehme Dinge anzusprechen. 
  • Die Selbstverpflichtung wird im Scrum-Guid “Commitment” genannt ist sozusagen die Bekenntnis zu dem eigenen Wert der Arbeit und der eigenen Pflicht, diesen Wert zum Wohle des Team einzusetzen, 
  • Die gegenseitige Verantwortlichkeit gelingt nur mit dem Respekt vor anderen Fähigkeiten und Meinungen der anderen und bedeutet auch ein Loslassen von eigener Verantwortung
  • Und letztlich müssen wir uns alle im Team auf ein gemeinsames Ziel fokussieren, damit wir auch alle in eine Richtung denken und arbeiten und alles, was wir tun, nach diesem Ziel ausrichten.

Du sieht, hier sind die Regeln für die gute Zusammenarbeit im Team in den Scrumguide aufgenommen worden und diese sind Bestandteil von Scrum. Ohne diese Werte ist das, was Du  machst kein Scrum!

Scrum besteht also nicht nur aus den Meetings, den Sprints und aus Userstories sondern es steht auf dem Fundament der Werte.

Und so verhält es sich auch mit allen anderen Methoden und Techniken, die dem agilen Umfeld zugeordnet werden – wie z. B. Kanban: auch in Kanban müssen die Werte wirklich gelebt werden, damit es funktioniert – ebenso bei den agilen Organisationsformen wie es Jürgen Appello in Management 3.0 beschreibt oder OKR oder oder oder…

…und dieses ist das aktuell so oft genannte “agile Mindset” um das es geht.

Aber mit diesem Mindset verhält es sich so wie mit dem Autofahren…

Du erinnerst Dich bestimmt noch daran, wie es war, als Du gerade deinen Führerschein bestanden hattest und die ersten Kilometer alleine mit dem Auto unterwegs warst. Alles war neu und aufregend, Du hast über jeden Handgriff nachgedacht und dich gefragt, wann Du nun schalten sollst, mit welcher Geschwindigkeit du durch die Kurve fahren sollst und Du hattest bestimmt auch Schweißperlen auf der Stirn, als Du das erste mal in einem engen Parkhaus am Berg anfahren solltest, weil die Schranke vor Dir geschlossen war…und rückwärts einparken – oje, passe ich in diese kleine Parklücke?    

und heute? 

Denkst Du noch darüber nach, wann du schalten sollst oder tust Du es einfach, wenn du merkst, dass der Motor untertourig läuft oder zu hoch dreht? 

Und einparken? Ich komme aus Berlin und wenn Du da mal abends nach 23:00 nach hause gekommen bist – da fährt keiner mehr weg und alle Parkplätze in der Umgebung sind vergeben…und Du fährst 3 mal um den Block und muss langsam pinkeln…da lässt Du keine Lücke aus, auch wenn vorn und hinten nur noch eine Postkarte dazwischen passt…da weißt du genau, wie groß Dein Auto ist…

Es ist Dir in Fleisch und Blut übergegangen, wie man so schön sagt. Du denkst nicht darüber nach, du machst es, es ist für dich das natürlichste von der Welt.

…nach einen Scrum- oder Kanban-Training ist das genauso: Du hast gelernt, welche Werte von Bedeutung sind- und über die haben wir ja eben schon gesprochen –

Aber du denkst noch darüber nach, wie die zu leben sind, was bedeutet Mut – wann soll ich mutig sein und was ist der Unterschied zwischen Mut und Übermut? Wenn Du irgendwann nicht mehr über eine Fehlerkultur nachdenkst, sondern vermeintliche “Fehler” ganz natürlich aus Dir raus als wichtige Informationen interpretierst und du dir eine Frage nach einem “Schuldigen” gar nicht stellst sondern ganz automatisch nach einem Weg zur Prozessverbesserung nachdenkst, dann bist du auf dem richtigen Weg, dann hast Du die Werte verinnerlicht – und dann beginnt eine agile Methode – welche es immer auch ist – zu funktionieren…

Um das weiter zu verdeutlichen, möchte ich nochmal auf das “Commitment” eingehen, weil es hier öfters zu einem Mißverständnis kommt. 

Das englische “commitment” wird oft mit Selbstverpflichtung übersetzt und eine Art Selbstverpflichtung steckt in dem Begriff auch drin, wie ich das vorhin schon angedeutet habe…Aber diese Verpflichtung wird aktuell oft mißinterpretiert.

Es besteht gerade nicht in einem Eid oder Schwur, den ein Team im Scrum-Planungsmeeting leistet, dass all das, was es gerade geplant hat auch am Ende des Sprints genauso umsetzt werden muss. Oder eine Aufforderung an den Product Owner als eine Art Selbstgeisselung bildlich gesehen mit der Peitsche zuschlagen dazu dürfen, sollten einige Userstories nicht zu seiner vollständigen Zufriedenheit realisiert worden zu sein.

Nein: die Selbstverpflichtung ist ein Bekenntnis, sich einzubringen. Daher übersetze ich das “Commitment” auch lieber mit Bekenntnis und Du solltest das lieber für Dich folgendermassen verstehen: Ich bekenne mich zum Team, Ich bekenne mich dazu, all mein Wissen dem Team zur Verfügung zu stellen, Ich bekenne und verpflichte mich alles zu tun, was ich kann, damit das Team das selbst gewählte Sprintziel auch erreichten kann. Ich suche die Schuld nicht bei anderen sondern bekenne mich dazu selbst nach Lösungen zu streben und Dinge voran zu bringen.

Wenn Du das so interpretierst, dann wird da ein Schuh draus. Achte also darauf, dass insbesondere dass Thema Commitment in deiner Firma oder deinem Team nicht falsch verstanden wird und damit nur nochmehr äußerer Druck auf das Team ausgeübt wird.

Soweit erstmal zum Thema Werte generell. Ich werde zu den agilen Werten in absehbarer Zeit noch gesonderte Folgen bringen.

Ein letzen Hinweis habe ich noch: Der am Anfang zitierte Satz „Doppelte Arbeit in der Hälfte der Zeit“ bezieht sich auf das Buch von Jeff Sutherland: „The Art of Doing Twice the Work in Half the Time“. Als deutsche Entsprechung dazu gibt es „Die Scrum-Revolution“ von Jeff Sutherland als Hörbuch. Ich kann beides empfehlen als kurzweilige Werbung für Scrum, auch das englische Original ist einfach geschrieben und man kann es quasi nebenbei so weglesen. Das gilt auch für das Hörbuch in deutsch.

Dein agilophiler Frank

Scrumkuchen – Wie backe ich einen agilen Scrumkuchen?

Zutaten für das Grundrezept:

  • 1-3 Programmierer
  • 1-2 Tester
  • 1-2 Anwender
  • mit je 0,5cl Architekt, Business Analyst und Linienvorgesetzte abschmecken
  • 1x Product Owner Hefeextrakt
  • 2 Prisen Stakeholder Gewürzsalz

sowie

  • 1% “nur über meine Leiche”
  • 40% “nö, wolln wa nich”
  • 50% “is mir egal”
  • 9% “watten hier los?”

Dazu empfehlen wir den Rührbesen “Scrum-Master” zum sanften oder kraftvollen Durchrühren der Masse. (je nach Bedarf)

Zubereitung:

Man nehme das aktuelle Projekt (hier Namen einsetzen), 3-7 frische Programmierer, Tester und Anwender, wahlweise digitale Pioniere oder nerdige Tüftler. Dann verrühren. Scrum-Masse abdecken, bis alles hochkommt. Jetzt aufdecken.
Unverhoffte Zutaten, wie “nö, wolln wa nich” oder “is mir egal” mit der Hand versuchen, einzukneten.
Setzen sich bestimmte Zutaten ab und lassen sich nicht unterbuttern – vorsichtig mit einem Teelöffel abschöpfen. Bei hartnäckigen Geschmacksstörungen Grundrezept verändern, mehr Product-Owner-Extrakt einstreuen und mit dem Scrum-Master Rührbesen auf höchster Stufe glatt rühren. 
Neue Masse vorsichtig mit Stake-holder Gewürzsalz abschmecken (Achtung, scharf). Alles glatt streichen und an einem warmen Ort aufgehen lassen.
Bei 170 Grad goldbraun backen, sollte der Kuchen oben zu dunkel und kantig werden, mit Alufolie abdecken. Bei zu großer Hitze können flüchtige Zutaten (wie Architekt oder Linienvorgesetzte) verdampfen.

Tipp: Servieren Sie, nachdem alles abgekühlt ist!
Tipp Nr. 2.: Sollte die Masse beim Backen vollständig in sich zusammenfallen, probieren sie das Grundrezept für Kanban-Strudel…

Quelle: Dieses Rezept ist angelehnt an den Beitrag “Google-Hupf” von Jörg Richert aus der Obdachlosenzeitung “Karuna Kompass” Ausgabe 5, Berlin. Die Verwendung des Ursprungsrezepts wurde mit dem Autor abgestimmt und erfolgt mit freundlicher Genehmigung von ihm. Wenn Du Interesse an einer Unterstützung dieser sehr lesenswerten Zeitung hast, informiere Dich bitte unter www.karuna-kompass.de oder kaufe dem mobilen Vertriebspersonal eine Ausgabe ab.