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.

Das Ausscheiden der DFB-Elf aus Scrum-Master Sicht

6 Maßnahmen um den Teamteufel zu vertreiben

Wir sind alle enttäuscht, wir haben uns viel vorgenommen, konnten es aber nicht umsetzen…so oder so ähnlich äußerten sich die deutschen Spieler nach den letzten Spielen und dem Ausscheiden aus der Weltmeisterschaft. So oder so ähnlich geht es auch vielen Fans und mir auch, die sich 4 Jahre auf die WM gefreut hatten, darauf zusammen mit dem Team zu kämpfen, zu hoffen, zu jubeln und zu feiern.

Doch was sind die Ursachen für ein solches kollektives Versagen eines Team, welches eigentlich alle Voraussetzungen hatte, gut in dem Turnier abzuschneiden? Es waren dieselben Spieler, die entweder die letzte WM oder den Confed-Cup gewonnen hatten, es war dasselbe Betreuerteam, der Trainer, Manager und die ganze DFB-Maschinerie aus Ärzten, Physiotherapeuten usw.. Die Trainingsbedingungen waren wie immer optimal, es fehlte an nichts, nichts war zu teuer…und trotzdem – es hat nicht funktioniert.

Wir haben es hier also mit einem komplexen Problem zu tun. Wäre das Problem nur kompliziert, hätten alle getroffenen Maßnahmen zum Erfolg führen müssen, so wie in den vergangenen Jahren auch. Bei komplexen Problemen gibt es überraschende Ergebnisse, die sich eben nicht planen lassen.

Im agilen Kontext (und natürlich auch beim Fußball) ist es stets ein Ziel den Status des “hyperproduktiven Teams” zu erreichen, also jenen Status in dem das Team zu mehr fähig ist, als die Summe der Fähigkeiten der einzelnen Mitglieder vermuten lässt. Solch ein Team hatten wir in der Nationalmannschaft 2014 und auch bei den vergangenen sehr erfolgreichen WM-Teilnahmen (zumindest ab 2006).

Wir sehen in der Nationalmannschaft 2018 deutlich, dass es neben dem gewünschten Status der Hyperproduktivität, auch  einen ungewünschten Status der Hemmung gibt, der sich nicht von den einzelnen Mitgliedern im Team beeinflussen lässt. Es gibt also neben dem Teamgeist, der positiv wirkt, auch einen “Teamteufel” der negativ wirkt. Wie kann man also vermeiden, dass der Teamteufel das Team befällt? Oder was kann man tun, um diesen Teufel aus dem Team zu vertreiben?

  1. Erfolg hält nicht ewig: Hat ein Team den Teamgeist bewiesen, also sehr kreativ gearbeitet, ein großes Ziel erreicht, Projekt(e) mit unerwartet positivem Ergebnis abgeschlossen und alle Beteiligen mehrfach begeistert, dann kann man sich als Scrum-Master zurücklehnen, denn es gilt ja die Regel: Never change a winning team…aber halt: Die Erfahrung zeigt, dass Sättigung einsetzt. Der Teamteufel setzt sich unbemerkt im Team fest und plötzlich wird alles, was bisher richtig war, falsch. Die Maßnahme kann daher nur sein: ändere das Team zum richtigen Zeitpunkt – und damit ist das gesamte Scrum-Team gemeint, also nicht nur das Entwicklungsteam. Tausche ggf. Scrum-Master, Product Owner oder Teammitglieder aus, wenn die ersten Anzeichen der Sättigung auftauchen. Wenn dem Scrum-Master neue Formen der Retrospektive ausgehen, er also beginnt zu wiederholen. Wenn das Team nicht mehr nach dem Warum fragt, sondern nur noch Userstories abarbeitet. Wenn der Product Owner nicht mehr begeistert die Vision erklärt, sondern Userstories zusammenhangslos ins Backlog schreibt, dann ist der Zeitpunkt nahe etwas zu ändern. Oder das Projekt zu beenden.
  2. Fehlerkultur vermeiden: “Die Lust zu Gewinnen muss größer sein, als die Angst zu verlieren”. Dieses Zitat von Jürgen Klopp trifft sehr genau auf das zu, was wir im Fernsehen gesehen haben. In den Spielen der deutschen Mannschaft war in den aller meisten Fällen die Angst zu verlieren größer als die Lust zu gewinnen. Die Angst vor Fehlern hemmt, daher ist es auch in scrum-Projekten essentiell, eine “Fehler”-kultur im Team zu vermeiden. Nicht die Suche nach dem Schuldigen bringt uns voran, sondern die Suche nach der Problemlösung.
  3. Einflüsse von außen vermeiden: Wir haben es alle miterlebt: In den Sozialen Medien wurde das Verhalten öffentlich: Medienpräsenz allgemein. Hasskommentare und “Özil-Bashing” wo man hinsieht. Weitere Einflüsse gab es über den DFB, die intensive Vermarktung des Teams, den omnipräsenten Teammanager usw.. Dass das nichts Gutes bewirkt, wurde sicht- und fast fühlbar. Für ein Scrum-Team gilt das genauso. Wenn erfolgshungrige Manager schon vorher die noch gar nicht existierenden Lösungen verkaufen (und damit das Team unter Druck setzen), wenn sofort “eskaliert” wird, sobald mal ein kleiner Konflikt im Team auftaucht und unzählige Manager aus allen Hierarchieebenen sich einmischen und Probleme wieder hochkochen, die eigentlich schon seit Wochen gelöst waren, muss der Scrum-Master alles dafür tun, um das Team zu schützen und abzuschotten. Natürlich ist hier nicht nur der Scrum-Master allein gefordert: Das Team sollte selbst dafür sorgen, dass Probleme nicht immer mit allen möglichen Leuten ausserhalb diskutiert werden, der Product Owner muss auch seinen Teil dazu beitragen, die Stakeholder ruhig zu halten.
  4. Die Aufgabe muss herausfordern (ein Level, welches man schon mal gespielt hat, macht keinen Spaß mehr). Das würde auch den Fluch des Weltmeisters erklären: Fußball-Weltmeister ist bei der weltweit beliebtesten Sportart das höchste, was ein Spieler erreichen kann. Nur wenige Menschen (also alle 4 Jahre 23, wenn man mal den ganzen Kader nimmt), können dieses Ziel überhaupt schaffen. Insofern ist es nur klar, dass alle die, die noch keine Weltmeister waren, einen viel höheren inneren Antrieb haben über sich hinauszuwachsen, als die die bereits einmal dieses Höchste der Gefühle erleben durften. In der Motivationstheorie gibt es den Korridor zwischen den unterfordernden Aufgaben (“langweilig”) und den überfordernden Aufgaben (“schaff ich sowieso nicht”), in dem man sich bewegen muss um motiviert zu sein. Product Owner und Scrum Master müssen gemeinsam dafür sorgen, dass die Aufgaben entsprechend herausfordernd bleiben, sonst leidet die Motivation.
  5. Gemeinsamer Umgang miteinander: Irgendwas war faul im DFB-Team – der Versuch, die “alten Recken von 2014” (Weltmeister) mit den “neuen Wilden von 2017” (Confed-Cup Sieger) zu verschmelzen, ist misslungen. Auch wenn alle immer betont haben, dass es keine Grüppchenbildung gab, waren schon in den Vorbereitungsspielen die “Jungen” seltsam gehemmt, wenn sie zeigen sollten, was sie können. Auch ein Team, welches bereits lange erfolgreich arbeitet, ist davor nicht geschützt: Daher gilt es, keine Cliquenbildung zuzulassen (“altes Team gegen neues Team”) und unterschwellige Macht- und Positionskämpfe zu sehen. Getreu den Stufen “Forming, Storming, Norming, Performing” der Teambildung sind diese Prozesse notwendig und laufen immer ab. Ein Unterdrücken der notwendigen Auseinandersetzungen führt dann eher dazu, dass der Teamteufel sich im Team einnistet und die Teamhemmung eintritt.
  6. Ideen gemeinsam entwickeln (jeden mit einbeziehen statt Vorgabe vom Trainerstab oder bei agilen Teams vom Product Owner/ Scrum Master ): “Der Trainer hatte keinen Matchplan” – auch diesen Kommentar habe ich immer wieder gelesen. Aber muss der Trainer immer einen Matchplan vorgeben? In der agilen Welt sollte es üblich sein, sich der “Schwarmintelligenz” des Teams zu bedienen. Das funktioniert beim Planungspoker im allgemeinen auch ganz gut. Natürlich sollte man sich mit so vielen Informationen wie möglich eindecken, um im Team eine breite Grundlage für Bewertungen von Ideen zu haben. Das Taktikteam des DFB macht hierbei sicherlich einen guten Job in dem es genau die Spielweise der Gegner analysiert. Die Auswertung dieser Informationen und vor allem die Frage, welche Konsequenzen sich daraus ergeben, ist allerdings etwas, was man durchaus dem Team überlassen kann. Merke: Es gibt keine einfachen Aufgaben, es sei denn, man überlässt es dem Team.

Das sind natürlich nur subjektive Ideen aus meiner Sicht, wie siehst Du das?