Auftakt: Dies ist ein Blog-Beitrag zum Modul „Agile Methoden“ des Bootcamp Product Owner der Digitale Leute School. Am Mittwoch, 25. Oktober 2023, führte Sandra Hinz n das Modul ein.
Der agile Eisberg
Als Visualisierung ist er immer wieder gut geeignet. Wenn es um agile Methoden geht, geht es dabei immer um zwei Aspekte:
- Methoden und Praktiken
- Werte und Prinzipien
Und gerade wir Deutschen neigen doch sehr dazu, uns in unserem Lernerfolg an Methoden und Praktiken zu orientieren. Warum sage ich das so? Weil ich hier an die Tanzschule denke, bei der es vielen vor allem darauf ankommt, möglichst viele Folgen zu lernen. Sprich: das technisch perfekte Tanzen. Leider ist das aber nicht alles: Es kommt auch auf die Leidenschaft und vor allem auf die positive Interaktion der Tänzer an. Das ist etwas, was man nicht mit 100 gelernten Folgen erreichen kann.
Und so ist der agile Eisberg auch zu verstehen: Um gut agil arbeiten zu können, sind dafür zu 20 Prozent die Methoden und Praktiken verantwortlich, zu 80 Prozent aber die Werte & Prinzipien (also das agile Mindset). Dazu gehören zum Beispiel:
- schnelle Fehler und schnelles Lernen
- Cross-Funktionale Arbeit
- Diversity
- Feedback
- Stakeholder- und Kundenzentrierung
- Selbstorganisation
Sandra verwendet dafür in der Session auch ein schönes Bild: „Wenn Menschen anfangen, Methoden großzuschreiben – also beispielsweise DAILY – dann geht es in eine falsche Richtung.“ Der Plan soll nicht des Plans wegen umgesetzt werden, sondern es muss immer reflektiert werden, wie eine Methode auf das Mindset einzahlt.
In der Praxis stelle ich immer wieder fest, dass das Mindset zu kurz kommt bei agilen Projekten und Workshops. Und dass es auch nicht so einfach erlernbar ist, sondern sehr viel komplexer: Eine Unternehmenskultur muss sich dafür häufig – von ehemals streng hierarchischen Strukturen – transformieren. Meine etwas pessimistische Sicht ist, dass dies nur selten am Anfang eines agilen Projekts steht und in vielen Fällen auch nahezu unmöglich ist. Aber ich möchte nicht zu pessimistisch sein: Vielleicht ist es einfach auch schon toll, neue, interessante Methoden einzusetzen und vielleicht gelingt dann mit der Zeit doch „bottom-up“ eine Transformation hin zu einem agilen Mindset?
Agile Glaubenssätze: Manifest und Cynefin
Immer wieder im Umfeld von SCRUM, Design Thinking und anderen agilen Methoden wird das agile Manifest zitiert, welches mittlerweile vor Jahrzehnten aufgesetzt wurde auf eine Reaktion auf große Unzufriedenheit damit, wie Softwareentwicklung sich bis dato entwickelte. Oft waren es jahrelange Projekte, die nach langer Laufzeit einfach nicht mehr benötigt wurden.
Die Grundsätze des agilen Manifests haben sich daraus entwickelt:
- Individuum und Interaktion
- funktionierende Software
- Reagieren auf Veränderung
- Zusammenarbeit mit dem Kunde
Das soll hier im Vordergrund stehen. Und dabei auch kein Selbstzweck sein. Wenn man das ebenfalls sehr verbreitete CYNEFIN-Modell betrachtet, dann macht SCRUM vor allem Sinn, wenn es sich bei dem zugrundeliegenden Problem mindestens um ein komplexes Problem handelt: Es gibt noch keinen erprobten Weg, dieses Problem zu lösen.
Das ist durchaus sehr herausfordernd für Organisation. Oftmals – so die Beobachtung – wird SCRUM aus Projektteams – also bottom-up – angestoßen und führt so zwangsläufig zu Konflikten mit dem Management. Nicht nur Sandra fordert deshalb auch neue Führungsprinzipien:
- Kontextorientierung
- Messbare Outcomes (und nicht Outputs!)
- Kunden- und Produktorientierung
- Enabler
Letztendlich müsse Tech als Profitcenter etabliert werden (bisher ist es vor allem Costcenter), um diesen Umbruch hinzubekommen.
Und dazu empfiehlt sie einen Blick aufs Agile Product Manifesto.
Der Scrum-Prozess
Der Einfachheit halber habe ich hier den SCRUM-Prozess mal skizziert; natürlich ist das keine Raketenwissenschaft, sondern überall im Web gibt es dazu entsprechende Versuche. Interessant ist aber wieder, wie Sandra das aufbaut und einbaut (der Prozess zeigt aber auch schon, wie David Yasli das SCRUM-Planning definiert); denn letztendlich ist das auch schon wieder eine Adaption bzw. aus Erfahrungswerten gespeist, die ja gerade das Interessante an dem Bootcamp sind: Individuelle Einschätzungen, was funktioniert und was nicht, jenseits irgendwelcher offiziellen Dokumente. Sandra hat zu den einzelnen Elementen folgendes gesagt:
- Refinement: Eigentlich findet das ständig statt. Bei neuen Terminen hat es sich aber als hilfreich herausgestellt, dies als eigenständigen Termin zu machen.
- Planning: Danach startet der Sprint. Im Planning wird das Ziel des Sprints festgelegt (aus dem Product Backlog heraus). Best Practise ist es hier, ein Planning 1 und Planning 2 zu veranstalten. In dem ersten Planning werden die Stories besprochen, im zweiten dann die Aufgaben daraus definiert.
- Print: Dieser dauert 1 bis 4 Wochen, gängig sind 2 Wochen.
- Retro: Am Ende des Sprints; es geht dabei ums Team und um die Reflektion der „Definition of Done“. Der SCRUM-Master ist hierfür zuständig.
- Daily: Nach SCRUM-Guide findet das ein Mal in der Woche statt: Wo sind die Blocker – das ist das Thema. Es sollte nicht länger als 15 Minuten dauern. „Das Daily nimmt mir auch die Last, im Planning alles perfekt zu machen“, so Sandra.
- Review: Findet oft zusammen mit den Stakeholdern statt; hier wird ein Feedback zum Ergebnis des Sprints gegeben. Im Idealfall wird hier etwas Auslieferbares präsentiert. Sandra empfiehlt, hier vorher ein internes Review zu machen, wo es auch darum geht, festzuhalten, wer was präsentiert und zu präzisieren, was erledigt und nicht erledigt ist.
„Es ist gut, das als Framework zu haben. Aber man kann auch was weglassen.“
(Sandra Hinz)
Sandra empfiehlt, die verschiedenen Dinge als Empfehlung, aber nicht als Dogma zu sehen. Sprich: Jedes Team kann das für sich adaptieren.
Die Nutzung von Kanban und Scrumban
Gerne wird in Zusammenhang mit SCRUM auch Kanban verwendet. Sie ist schon sehr alt, wurde in den 1940er-Jahren in Japan entwickelt. Und sie hat auch nur sehr wenige Regeln:
- Möglichst kleine Arbeitspakete
- Visualisierung der Arbeitsschritte
- Arbeitsbegrenzung („Work-in-Progress“-Limit
Sie ist dabei ziemlich linear: Arbeitspakete werden nach Priorisierung nacheinander abgearbeitet. Kanban ist damit auch sehr flexibel, denn ständig können Veränderungen durchgeführt werden.
Wenn Kanban und SCRUM kombiniert werden entsteht SCRUMBAN: „Man lässt dabei immer mehr von den Prozessen los“, so Sandra. Sprich: Prozesse, wie in SCRUM sind am Anfang hilfreich, aber vielleicht später nicht mehr so notwendig. Denn es geht bei agilen Methoden NICHT darum, Prozesse und Methoden als Selbstzweck umzusetzen, sondern sie sind so lange Hilfen, wie sie benötigt werden.
Abschließender Hinweis: Immer ist es eine sehr subjektive Zusammenfassung, die ich hier verfasse. Siehst Du Dinge anders, möchtest darüber diskutieren – melde Dich gerne bei mir!