Agile Transformation Toolbox

Liberating Structures sind in der agilen Szene gerade "en vogue". Aber was ist das eigentlich und wozu ist das gut? Das erzählt und Maike Goldkuhle in dieser Episode. 

Seit Oktober 2018 ist Maike Goldkuhle Mitglied des HR PioneersBeratungskollektivs. Sie beglückt Menschen durch ihre Expertise als Beraterin und Trainerin aus Personalersicht auf ihrer Reise hin zu mehr Agilität. Sie liebt es ihre Teilnehmer in Trainings und Workshops zum Selbst-lernen und -ausprobieren zu animieren und treibt ihnen dabei manchmal den Schweiß auf die Stirn. Maike lebt in Stuttgart, ist verheiratet und hat 3 Kinder.

Links:

• Liberating Structures Homepage
• Liberating Structures - IEQ Survey

Wie man schon am Titel dieses Artikels sehen kann, bin ich kein großer Fan von Story Points. Warum das so ist, erkläre ich Dir hier. 

Als "Vater der Story Points" gilt Ron Jeffries. In seinem Artikel Story Points Revisited erklärt er, wie es zu diesem Konzept gekommen ist. Er ist sich allerdings selbst nicht sicher, ob er tatsächlich der Erfinder ist. Er erklärt auch wunderbar, welche alternativen Konzepte er bevorzugt (ja, auch er ist kein Fan von Story Points).

Aber was sind Story Points eigentlich? Die ursprüngliche Idee von Story Points ist es, den Schwierigkeitsgrad oder die Komplexität eines Features zu beschreiben. Je schwieriger eine Aufgabe ist, desto mehr Story Points bekommt sie. Es ist eine bisschen wie ein Level in einem Videospiel wie z.B. Tetris. Wenn ich noch nie Tetris gespielt habe, wird mir Level 10 sehr schwer vorkommen. Mit zunehmender Erfahrung fällt mir Level 10 immer einfacher, bis ich am Ende nur noch müde darüber lächeln kann. Das ändert allerdings nichts an der Sache, das Level 10 trotzdem Level 10 bleibt. Für einen unerfahrenen Spieler ist es immer noch eine Herausforderung. 

Das gleiche gilt für Features in einem Backlog. Ein erfahrener Entwickler wird mit einem Feature mit 5 Story Points mit Leichtigkeit fertig, während ein Junior Entwickler zumindest anfangs noch seine Schwierigkeiten haben wird. Beide brauchen für die Implementierung unterschiedlich lang.

Story Points sagen also NICHTS über den Aufwand aus!

Deshalb macht es auch keinen Sinn Story Points z.B. in PTs (Personen Tage) umzurechnen. Wenn ein Team das Thema Agilität ernst nimmt, wird es immer besser im Abarbeiten der Backlog Items. Das bedeutet, dass es ein halbes Jahr später wesentlich mehr Story Points pro Sprint (auch bekannt als Velocity) abgearbeitet werden. Das Team wird immer erfahrener. 

Leider fällt es vielen Menschen schwer das Thema "Erfahrung" aus ihren Story Point Schätzungen raus zu halten. Das führt dazu, dass die beiden Dinge vermischt werden. Sobald ich das aber mache, macht es keinen Sinn mehr mit Story Points zu arbeiten.

Ich kennen Unternehmen, die haben einen Umrechnungsfaktor für Story Points, z.B. ein Story Point sind drei PTs. In diesem Fall kann man auch gleich in PTs rechnen, da es einfach nur einen weitere Zeiteinheit ist, die am Ende mehr Verwirrung stiftet, als das sie hilft. 

Heutzutage gibt es bessere Konzepte, um Projekte zu planen. Eines davon ist z.B. #NoEstimates. Mehr dazu in meinem Podcast mit Vasco Duarte. 

R.I.P Story Points...

Stell Dir vor, es ist Freitag Nachmittag, 16.00Uhr und Du läufst durch Deine Abteilung. Erst vor zwei Stunden hast Du eine kleine Rede gehalten und den Ernst der Lage geschildert. Du hattest eigentlich das Gefühl, dass Deine Mitarbeiter verstanden haben, um was es geht. Doch das Büro ist nahezu leer, fast alle sind bereits zu Hause und ins Wochenende gestartet. Vor ein paar Monaten habt ihr damit begonnen in Richtung Agilität zu starten. Doch nach anfänglicher Euphorie, ist mittlerweile totale Ernüchterung eingetreten. Keine der Versprechungen, die mit agilem Vorgehen verbunden werden, sind bis heute eingetreten. Der Druck durch den Markt steigt stetig weiter und Dein Chef wird immer ungeduldiger. Wenn Du nicht bald etwas änderst, fährt Dein Unternehmen an die Wand. So langsam bist Du mit Deinem Latein am Ende.

Dies ist keine fiktive Situation, sondern ich habe das  tatsächlich bei einem meiner Kunden erlebt. Viele Führungskräfte begehen den Fehler sich wie Superhelden zu verhalten, die die Antwort auf alle Fragen haben. Ich habe der Führungskraft folgenden Tipp mit auf den Weg gegeben: Ask the team.

Aus meiner Erfahrung gibt es die folgenden Dinge, nach denen sich die meisten Mitarbeiter sehnen:

• Psychologische Sicherheit
• Authentizität der Führungskraft
• Starke Vision
• Stärkeorientierung
• Inspiration
• Offenheit
• Neugier

In den letzten beiden Wochen hat ich zweimal den Fall, dass eine oder mehrere Führungskräfte entweder die Scrum Master Rolle im Unternehmen übernommen haben oder als Product Owner aktiv sind. Die Frage die dann in meinen Trainings aufgekommen ist war: Ist das eine gute Idee? Hier die kurze Antwort: nein.

Es sprechen mehrere Faktoren gegen dieses Vorgehen.

Keine Zeit

Die allermeisten Führungskräfte die ich kenne, sind oft schon "Land unter". Und jetzt sollen sie auch noch nebenher den Scrum Master oder Product Owner mimen? Beide Rollen sind Vollzeit Rollen und lassen sich nicht mal eben noch im Vorbeigehen wahrnehmen. Wenn ich es als Firma ernst mit meiner agilen Transformation meine, dann muss ich auch diese Rollen ernst nehmen und entsprechend besetzen.

Die Führungskraft hat die Macht

Auf den ersten Blick scheint es eine gute Idee zu sein, wenn eine Führungskraft die Scrum Master Rolle einnimmt. Schließlich hat man in seiner Rolle häufig die Macht, um Dinge auf den Weg zu bringen. Aus dem oben genannten Grund werde ich aber häufig garnicht wissen, wo ich ansetzen muss und deshalb ist dieses Argument wertlos.

Ineffiziente Retrospektiven

Gerade in deutschen Firmen herrscht immernoch eine klare Hierarchiedenke und es wird noch viel kontrolliert. Sitzt jetzt eine Führungskraft mit in der Retrospektive ist die Wahrscheinlichkeit recht hoch, dass die wahren Probleme erst garnicht angesprochen werden. Man will ja schließlich nicht schlecht vor dem eigenen Chef da stehen. Also dümpeln die Retrospektive an der Oberfläche und der Elefant im Raum wird ignoriert. So heißt es dann auch oft: Retrospektiven bringen uns nicht weiter und sind reine Zeitverschwendung.

Shorten the feedback

Ein der wichtigsten Elemente von erfolgreichem, agilen Arbeiten sind kurze Feedbackloops. Wenn ich als Führungskraft aber ständig nicht verfügbar bin, wird dieser Loop automatisch länger und die Teams kommen nicht in dem Tempo weiter, wie ich mir das vorstelle. Ein gutes, agiles Team braucht ständig und schnell Feedback von seinen PO und auch ein Scrum Master muss schnell reagieren. Das ist als Führungskraft in den aller meisten Fällen einfach nicht möglich. 

Fazit

Wenn Du es mit der agilen Transformation ernst meinst, dann verzichtest Du auf Doppelrollen. Nur so wirst du am Ende erfolgreich sein.

Es wurde aber auch Zeit. Endlich gibt es mal wieder eine Folge, die zeigt, wie Unternehmen bei Thema Agilität intern ticken.

Für diese Folge hatte ich das Vergnügen mit Klara von Carlsburg (Process Lead  OTTO (GmbH & Co KG)  IT, Business Intelligence) zu sprechen. Sie erzählt wie OTTO intern tickt und sich ständig weiterentwickelt.

Claras Lieblingszitat aus dem Podcast: "Ziele transparent machen, befördert Lernen."

Wenn Du nach der Folge Lust hast bei OTTO zu arbeiten (ja, sie suchen nach neuen Talenten), dann schau doch mal unter folgenden Links nach:

OTTO Jobs: https://www.otto.de/jobs/jobsuche/
OTTO Newsroom: https://www.otto.de/newsroom/de/
OTTO Jobbörse | Jobs in Hamburg | Jetzt bewerben
Finde deinen perfekten Job bei OTTO über die Jobsuche.
www.otto.de

In dieser Podcast Folge hatte ich das Vergnügen mit dem Product Owner Papst persönlich zu sprechen: Roman Pichler.

Roman ist ein Produktmanagementexperte spezialisiert auf digitale Produkte. Seit mehr als 15 Jahren berät er Firmen rund um das Thema Produkt und hilft ihnen dabei erfolgreiche Produktmanagement Organisationen aufzubauen. Roman ist Autor von drei Büchern zu diesem Thema, das letzte in dieser Reihe heißt "How to Lean in Product Management". Mehr zu Roman findest Du auf seiner Webseite: romanpichler.com

In dieser Episode sprechen wir über folgende Punkte:

• Was macht ein gutes Produkt aus?
• Was sind die typischen Fehler im agilen Produktmanagement?
• Welche Fähigkeiten braucht ein guter Product Owner?
• Wohin entwickelt sich die agile Produktentwicklung?

Viel Spaß beim Reinhören!

Du willst Dich als Scrum Master zertifizieren lassen und weißt nicht, zu welchem Anbieter Du gehen sollst? Dann bist Du in dieser Folge genau richtig!

In dieser Folge geht es um die Frage, welches das wichtigste, agile Prinzip ist. Aus meiner Sicht ist es eine Kombination aus mehreren Prinzipien. Welche das sind, erfährst Du in dieser Podcastfolge.