On Lean and Agility

Donnerstag, 20. Oktober 2016

Warum zu große Backlogs regelmässig ausgemistet werden sollten habe ich bereits beschrieben, jedem Product Owner lege ich den regelmässigen Griff zur Heckenschere ans Herz. Nicht festlegen würde ich mich auf die maximale Zahl vertretbarer Backlog Items, das kann je nach Einzelfall unterschiedlich sein. Meine Faustregel ist aber, dass man sich spätestens ab dem hundertsten Eintrag Gedanken machen sollte. Konkrete Ratschläge kann ich dagegen zu etwas anderem geben, nämlich dazu nach welchen Kriterien aussortiert werden sollte. Da gibt es mehrere Möglichkeiten:

Nach Priorität

Zugegeben, ein No Brainer. Je weiter nach unten eine Anforderung priorisiert ist desto verzichtbarer ist sie, weshalb man es sich ganz einfach machen kann - weg mit den unwichtigsten 10 Prozent und das Problem ist gelöst. Aber apropos Problem: an dieser Stelle gibt es eines. Die wichtigsten Anforderungen bekommt man noch irgendwie identifiziert, aber in den meisten Backlogs folgt danach eine amorphe Masse in der alles irgendwie gleich (un)wichtig ist. Wie soll man da mit dem Sortieren weitermachen? Die häufigste Antwort darauf lautet:

Nach Business Value

Okay, noch ein No Brainer. Je geringer der erzeugte Mehrwert desto eher kann eine Anforderung weg. Benutzen wir also das als Vergleichswert und wir haben ... schon wieder Schwierigkeiten. Ein paar zentrale Faktoren für ein funktionsfähigeses MVP oder eine bessere Vermarktbarkeit lassen sich natürlich finden, aber dann - wieder Unklarheit. Ist die intuitive Hauptnavigation jetzt wertvoller als der einfache Bezahlvorgang oder der schnelle Login? Viel Spass beim Entscheiden. Aber es gibt ja weitere Priorisierungskriterien. Zum Beispiel:

Nach Alter

Hier werden die Ersten widersprechen. Denn ich würde sagen: je älter eine Anforderung ist desto eher kann sie weg. Das widerspricht für viele den Denkgewohnheiten, schließlich könnte man meinen, dass eine Umsetzung um so dringlicher wird je länger sie sich hinzieht. Ich sehe das umgekehrt - wenn eine Anwendung so lange Zeit ohne ein Feature funktioniert, dann kann das nicht wirklich wichtig gewesen sein. Aber das nächste Dilemma kommt bereits um die Ecke - gerade zu Beginn kippen üblichweise alle Stakeholder gleichzeitig ihre Wünsche ein, wodurch ihre Anforderungen alle ähnlich alt sind. Doch auch hier gibt es einen Ansatz für eine weitere Auswahl:

Nach Stakeholder

Ja, genau, nach Stakeholder. Es soll weitergehen, es soll mehr Zeit geben, mehr Budget, mehr Ressourcen? Dann hilft es, wenn man nett zu dem ist der das Geld in der Tasche hat. Du kriegst Dein Feature, ich meine Ressourcen, beide sind glücklich. Ein Kuhhandel? Ja, ist es. Opportunistisch? Vermutlich auch. Aber hey, so ist es nun mal in der Welt. Ein grosses Geben und Nehmen. Allerdings, selbst wenn wir das machen bleiben oft noch Anforderungen übrig bei denen man nicht sicher sein kann für wen sie mal wichtig sein könnten. Im Zweifel behalten? Ach was, auch da lässt sich noch reduzieren, und zwar so:

(Festhalten:) Nach Zufall

Wait, what? Nach Zufall. Jetzt kann man losen, Glücksrad drehen, blind mit dem Finger auf etwas zeigen oder einfach jede vierte verbliebene Anforderung löschen. Alles ist erlaubt. Aberwitzig? Mitnichten! Schauen wir nochmal auf die letzten Auswahlrunden. In denen haben wir nicht nur entschieden was nach unten priorisiert wird, wir haben damit gleichzeitig auch nach oben priorisiert, das eine gehört untrennbar zum anderen. Und was in keinem dieser Durchgänge für wichtig genug befunden wurde, das kann eigentlich nur verzichtbar sein. Und deshalb kann die Zufalls-Auswahl so lange weitergehen bis das Backlog auf eine vernünftige Größe eingedampft ist. Nur zu.

AberAber: Was, wenn irgendwas davon doch wichtig war?

Ja, was dann? Was wenn wir versehentlich etwas rausgeworfen haben was wir doch ganz dringend brauchen? Ganz einfach - sobald das auffällt kommt es als neue Anforderung wieder rein. Und wenn auf diesem Weg so lange Anforderungen wieder zurückkommen bis das Backlog erneut ausufert? Na dann geht das Ausmisten eben von vorne los.

Montag, 17. Oktober 2016

Bild: Wikimedia Commons / Jorge Royan - CC BY-SA 3.0

Ein mitgenommenes Thema vom ersten Lean Coffee für Product Owner und Produktmanager, der letzten Freitag stattgefunden hat: wie kann man es schaffen, dass ein Backlog einen überschaubaren Umfang behält und nicht ausufert? Die einfache Antwort - regelmässig ausmisten. Von Zeit zu Zeit ist es sinnvoll sich in grossem Ausmass von bisher gesammelten Anforderungen zu trennen, selbst, bzw. gerade von solchen die noch nicht umgesetzt wurden. Und dafür gibt es auch Gründe:

Zu große Backlogs sind zu unübersichtlich

Zugegeben, eine Binsenweisheit, aber eine mit Folgen. Bei einer drei- oder vierstelligen Anzahl von Einträgen ist es nicht mehr möglich alle Inhalte im Kopf zu behalten, Duplikate, Redundanzen oder Überschneidungen fallen dann nicht mehr auf. Man kann zwar versuchen durch Kategorien, Schlagworte oder Verlinkungen die Übersicht zu behalten, allerdings ist das mit zusätzlicher Arbeit verbunden, die auch erstmal erledigt werden muss. Das bringt uns zum nächsten Punkt:

Zu große Backlogs erfordern einen unverhältnismässigen Pflegeaufwand

Ich habe Menschen gesehen, die in Vollzeit nichts anderes gemacht haben als alte User Stories und Bugs zu aktualisieren. Immer wieder überprüften sie ob das was sich in ihnen befand nicht bereits durch andere Anforderungen umgesetzt wurde, noch gewollt war oder seine Priorität geändert hatte. Nur in den seltensten Fällen führte das dazu, dass irgendetwas aus dem Backlog herausgenommen werden konnte, stattdessen kam es immer und immer wieder zurück (es war nicht ohne Grund so niedrig priorisiert). Eine unglaubliche Verschwendung von Zeit und Geld.

Zu große Backlogs veralten (auch wenn sie gepflegt werden)

Egal wieviel Mühe man sich gibt: zu große Backlogs werden immer Anforderungen enthalten die obsolet oder bereits umgesetzt sind. Alleine die Länge der Aktualisierungszyklen sorgt dafür, denn die können sehr schnell Wochen oder sogar Monate in Anspruch nehmen. Selbst wenn sie gerade erst durchlaufen wurden ist das aber keine Garantie dafür, dass alles aktuell ist. Grund dafür sind die oben erwähnte Unübersichtlichkeit und eine "im Zweifel behalten"-Einstellung die immer wieder anzutreffen ist.

Zu große Backlogs führen zu unrealistischen Erwartungshaltungen und Enttäuschungen

Für viele Stakeholder ist die Angelegenheit klar: ist meine Anforderung noch im Backlog? Klasse, dann ist es ja nur eine Frage der Zeit bis sie umgesetzt wird. Dass unwichtige Dinge immer wieder nach unten priorisiert und von neuen Anforderungen "überholt" werden wird dabei nicht bedacht. Am Ende führt das zu falschen Erwarungen, enttäuschten Hoffnungen und Frustrationen. Die entladen sich dann irgendwann. Apropos:

Zu große Backlogs führen zu Konflikten

"Meine User Story ist jetzt zum fünften mal nach hinten geschoben worden. Jetzt bin ich auch mal dran, wenn nicht eskaliere ich das!" Aussagen wie diese sind die fast schon zwangsläufige Folge zu großer Backlogs. Nicht nur weil ein Stakeholder das Gefühl hat, dass ihm falsche Hoffnungen gemacht wurden, sondern auch aus handfesten Gründen: es ist in vielen Unternehmen "best" practice, dass Boni und Jahresziele an die Umsetzung von Anforderungen geknüpft werden, und wenn die nicht erreicht werden stehen unangenehme Jahresgespräche bevor. In solchen Situationen ist es klar, dass die Betroffenen schnell in Krawallstimmung sind.

Also her mit der Heckenschere

Genug der guten Gründe und ans Werk. Her mit dem Backlog und raus mit allem was nicht wirklich nötig ist. Nur - wie? Wie wird entschieden was bleibt und was nicht? Nun, das wird ein Thema für einen eigenen Artikel.

Donnerstag, 13. Oktober 2016

Auch eine interessante Change Management-Geschichte: Der Stahlhändler Klöckner versucht Informationen schneller und effizienter im eigenen Unternehmen zu verteilen indem er "Hierarchiefreie Kommunikation" einführt, basierend auf einem firmeninternen sozialen Netzwerk. Hierarchiefrei bedeutet in diesem Fall horizontal, also durch direkte Ansprache des entsprechenden Kollegen und ohne Umweg über die jeweiligen Vorgesetzten.

Für viele Beschäftigte der Startup-Branchen, des Mittelstandes oder der IT-Industrie mag es zwar selbstverständlich sein direkt mit demjenigen zu reden für den man ein Anliegen hat, in Großunternehmen ist das allerdings häufig unüblich. Hier herrscht an vielen Stellen noch immer der Dienstweg, der erfordert, dass alle teamübergreifende Kommunikation über die jeweiligen Teamleiter und ggf. Unterabteilungs- und Abteilungsleiter zu erfolgen hat. Ein Vorgehen wie das von Klöckner kann in solchen Fällen dazu führen, dass sich Informationsverteilungen deutlich beschleunigen (in einem anderen Unternehmen habe ich miterlebt, dass bei einzelnen Vorgängen Monate (!) an Zeit eingespart werden konnten). Insofern eine bemerkenswerte Entwicklung.

Montag, 10. Oktober 2016

Edit: Dieser Artikel ist mittlerweile veraltet, die Zertifizierungs-Voraussetzungen haben sich geändert.

Seit letzter Woche bin ich dem (organisierten) agilen Olymp eine Stufe näher. Ich habe die Ruhephase zwischen zwei Aufträgen genutzt um mich bei der Scrum Alliance als Certified Scrum Professional (CSP) zertifizieren zu lassen, wodurch ich jetzt in der Verbandshierarchie eine Stufe oberhalb der Certified Scrum Master (CSM) oder Certified Scrum Product Owner (CSPO) stehe.

Überraschend finde ich, dass der CSP verhältnismässig einfach und billig zu bekommen ist. Man zahlt 250 $ und benötigt nur drei Jahre nachweisbare Berufserfahrung im Scrum-Umfeld sowie 70 so genannte "Education Units", die aber recht banal zu bekommen sind: ein paar Fachartikel, ab und zu bei einer User Group wie z.B. dem Bonner Scrumtisch vorbeischauen und das war es. Keine Prüfung, kein Lehrgang, keine Präsenzveranstaltung - im Grunde reicht es einfach seinen normalen Job zu machen und sich ab und zu in der Community sehen zu lassen. Angesichts dessen finde ich es erstaunlich wie wenige CSPs bisher vergeben wurden.

Im Zertifizierungs-Verzeichnis der Scrum Alliance findet man im Moment 384.800 CSMs, immerhin 84.200 CSPOs aber gerade einmal 4.600 CSPs. Lediglich ein Prozent (!) der zertifizierten Scrum Master und Product Owner nimmt die nächste Stufe, die anderen bleiben da wo sie sind. Das ist dürftig, vor allem wenn man bedenkt, dass viele große Unternehmen permanent nach irgendwelchen Zertifizierungen suchen mit denen sie ihre Weiterqualifizierungsquoten für ihre Belegschaft erfüllen können. Was könnte also der Grund für diese niedrige Zahl sein?

Eine gute Begründung hat mir ein in einem Konzern arbeitender Freund gegeben. "Klar, für Dich ist das einfach" meinte er, "aber Du machst ja auch was in dem Bereich. Für die Leute bei uns ist das viel schwerer, die sind ja nur zertifiziert." Hinter diesem "nur zertifiziert" dürfte tatsächlich ein wesentlicher Teil der Begründung liegen: bei einem sehr großen Teil der CSMs und CSPOs handelt es sich um ganz normale Team-, Abteilungs- und Bereichsleiter, die irgendwann mal aus irgendeinem Grund (siehe letzter Abschnitt) auf eine zweitägige Schulung geschickt wurden, danach aber einfach so weitergearbeitet haben wie bisher (das entspricht auch meinem Eindruck aus vielen Unternehmen). Denen dürfte bereits der Nachweis von drei Jahren Scrum-Erfahrung schwerfallen, und ohne die sind auch Fachartikel und Community-Engagement nur schwer vorstellbar.

Weiter gedacht würde das bedeuten, dass es sich bei der organisierten Scrum-Community um einen Scheinriesen handelt. Einer großen Gruppe Zertifikatsinhaber stehen nur wenige gegenüber die auch wirklich nach dieser Methode arbeiten. Schlecht für den State of Scrum, gut für mich als käuflicher Scrum Master und Scrum Coach. Vor allem da jetzt der CSP-Badge auf meinem CV meine Kompetenz noch strahlender zur Geltung bringt als ohnehin schon.

Donnerstag, 6. Oktober 2016

Bild: Public Domain Files/US Department of Energy - Public Domain

Anscheinend hat das Thema gerade Konjunktur, seit ca. zwei Wochen bekomme ich gefühlt jeden zweiten Tag von irgendjemandem erzählt, dass er ohne IT-Kenntnisse Scrum Master oder sogar Scrum Coach sein kann, bzw. werden möchte. Nun sehe ich an mir selbst (Geisteswissenschaftler), dass das geht und auch durchaus annehmbar funktioniert. Sowohl ich als auch meine Teams sind in den letzten Jahren damit erfolgreich gewesen. Aber:

Selbst wenn ein Quereinstieg möglich ist würde ich sagen, dass ein komplett technikferner Scrum Master auf Dauer in Probleme hineinlaufen wird. Das beginnt schon bei einer der Kernaufgaben, dem Beseitigen von Impediments: wenn die Entwicklerrechner zu wenig RAM haben, wenn es zu wenige Testumgebungen gibt oder wenn die Teams mit Feature Branches in eine Merge-Hölle geraten, dann muss man das nicht selbst beheben können, man sollte aber verstehen können worum es geht, damit klar ist wie eine Lösung angestoßen werden kann. Auch bei Microservices, festen und dynamischen IDs, Code Covarage, TDD und vielem mehr ist ein gewisses Verständnis mehr als hilfreich. Allerdings:

Die Bereitschaft sich in diese Bereiche einzudenken und einzulernen ist leider nicht bei jedem gleichermassen vorhanden. "Ich glaube, ich brauche das nicht. Ich coache ja nur deren soziale und methodische Skills" durfte ich mir in einem Fall gerade erst anhören. Und das ist gefährlich. Der schönste Prozess und das beste Arbeitsklima bringen nichts, wenn die Anwendung so verschachtelt gebaut und so schlecht durch Tests abgesichert ist, dass jede User Story durch eine mehrwöchige Analyse- und Bugfixing-Phase muss bevor sie auf Produktion kann. Deshalb:

Kein Scrum Master muss Entwickler sein (und ganz nebenbei - selbst wenn man als einer angefangen hat kann man erstaunlich schnell aus der Übung kommen). Wenn man aber nicht in unkalkulierbare Risiken hineinlaufen will sollte man Technikferne als relativen und nicht als absoluten Begriff begreifen.

Dienstag, 4. Oktober 2016

Bild: Wikimedia Commons / Fallaner - CC BY-SA 4.0

Wieder einmal ist eine großartige Agile Cologne vorbei und für mich hatte sie diesesmal den gefühlten Schwerpunkt "Scrum und Management". Während meiner Session, aber auch in vielen anderen stellte sich dabei immer wieder die Frage, warum es auf allen höheren Hierarchie-Ebenen Menschen gibt, die sich vehement gegen die agile Transition stemmen. Neben einigen (zu) einfachen Erklärungsansätzen (z.B. der Angst vor Macht- oder Statusverlust) kamen auch komplexere zur Sprache, von denen ich einen hier vorstellen möchte: die Verflechtung, bzw. die Verflechtungsfalle. Ursprünglich für die Analyse politischer Systeme gedacht lassen sich diese von Prof. Fritz Scharpf entwickelten Begriffe auch auf sonstige Organisationen anwenden und bieten eine nachvollziehbare Deutung für scheinbar irrationales Managementverhalten.

Verflechtung

Verflechtung kann entstehen, wenn verschiedene organisatorische Ebenen oder Einheiten eine gemeinsame Verantwortung für eine Organisationseinheit oder ein Ergebnis haben, für die sie sich eng abstimmen müssen. Eine typische Folge davon ist eine umfangreiche Koordinations-, Kooperations- und Kontrollbürokratie, die zum einen hemmend und dysfunktional ist, aber auf der anderen Seite immer weiter ausgebaut wird (basierend auf dem Irrglauben, damit die Dysfunktionalität auflösen zu können). Ab einem gewissen Punkt wirken die Prozesse und Vorschriften so stark verlangsamend und verkomplizierend, dass die Beteiligten nach Wegen suchen sie zu umgehen: es entstehen informelle Parallelstrukturen, in die sich immer weitere Entscheidungswege verlagern - die so genannte brauchbare Illegalität, über die ich letztes Jahr geschrieben habe. Die Überlagerung und Zunahme der formellen und informellen Strukturen ergibt in Summe das Phänomen der Verflechtung.

Die Verflechtungsfalle

Anders als man denken könnte liegt es häufig nicht im Interesse der Beteiligten die Verflechtung aufzulösen. Wer informell bestimmte Entscheidungskompetenzen gewonnen hat will sie nicht verlieren, umgekehrt wollen viele der formell zuständigen Personen sie nicht zurückhaben, da sie Überarbeitung oder Überforderung fürchten. Das obere Management will die Koordinations- und Kontrollprozesse nicht aufgeben, da sie ein Gefühl (bzw. die Illusion) von Kontrolle vermitteln, die mittleren Hierarchieebenen wiederum verdanken diesen Prozessen häufig ihre gesamte berufliche Existenzberechtigung und verteidigen sie entsprechend verbittert. Ein spezieller Fall liegt vor, wenn Teile des Managements kontraproduktive oder fehlerhafte "Verbesserungsmassnahmen" durchgeführt haben, z.B. die Einführung von Scrum nur in einigen IT-Teams bei gleichzeitiger Beibehaltung von Wasserfall im restlichen Unternehmen. Da der eigene Name und häufig die eigene Karriere mit diesen Massnahmen verbunden sind werden ihre negativen Auswirkungen oft auch dann noch abgestritten wenn sie für alle Beteiligten offensichtlich sind.

Der gordische Knoten

Ist ein Unternehmen in eine Verflechtungsfalle getappt kann es sich aus den genannten Gründen nur sehr schwer aus ihr befreien. Ähnlich wie im Fall des gordischen Knotens ist die Situation in vielen Fällen so verworren, dass eine Entwirrung einen Komplexitätsgrad am Rand der Unlösbarkeit erreicht. Als einzige Lösung bleibt dann die Zerschlagung des Knotens, was in diesem Fall ein komplettes Zurücksetzen aller Prozesse auf Null und einen sauberen Neustart bedeutet. Das ist eine radikale und nicht immer machbare Methode, allerdings eine die die verschiedenen Widerstände abschwächen kann. Da das Gesamtsystem zurückgesetzt wird kommt es nicht zu individuellen Schuldzuweisungen oder Karriereknicks von Einzelpersonen, zudem bietet der Neustart allen Beteiligten die gleichen Möglichkeiten die umstrittenen Zuständigkeiten und Verantwortlichkeiten zu bekommen, zu behalten oder abzuwehren. Natürlich ist auch das mit Risiken verbunden, weshalb es auch hier zu Abwehrreaktionen kommen kann. Durch die Loslösung von Einzelfällen, bzw. Einzelpersonen gibt es allerdings weniger Anreize diese bis zur letzten Konsequenz durchzuziehen.

Donnerstag, 29. September 2016

Grafik: Pixabay / Geralt - Lizenz

Ron Jeffries: Dark Scrum

mit den Füssen abstimmen

Jobspotting.com: Warum ein Kicker noch keine Unternehmenskultur macht (Edit: Link ist mittlerweile tot)
Wenn wir schon bei neuen Begrifflichkeiten sind - ich würde hier von potemkinscher Agilität sprechen. Offene Räume, Teamevents, Kickertische und Lounge-Bereiche machen das Arbeiten vielleicht bequemer, sorgen aber nicht von sich aus für Selbstorganisation und effektives Arbeiten. Ich kann mich an lichtdurchflutete Großraumbüros erinnern in denen übles Dark Scrum gelebt wurde (siehe oben) und an Abteilungen mit Loft-Atmosphäre in denen die (Pseudo)Scrumteams nur die Detailvorgaben der Anforderungsmanager und Architekten abarbeiten durften. Eine agile Transition ohne Kulturwandel funktioniert eben nicht.

Rob Lambert: A Blazingly Simple Guide To Turning Around a Team
Ob ich diesen Weg als "berauschend einfach" bezeichnen würde weiß ich nicht, schließlich sind auch hier sechs Monate Arbeit notwendig um ein dysfunktionales Team "umzudrehen". Grundsätzlich macht das Vorgehen allerdings Sinn - ein Monat zur Einarbeitung, ein Monat für die Erarbeitung von Metriken und Benchmarks, ein Monat für das Anstoßen größerer Veränderungen, zwei Monate für die Umsetzung, einen Monat für Retrospektiven und Stabilisierungen. Mein empfohlenes Vorgehen dauert ähnlich lang. Interessant ist in solchen Fällen die Reaktion des Managements wenn ab dem zweiten Monat die Leistung des Team (vorübergehend) sinkt. Das ist der klassische Zeitpunkt an dem irgendjemand die Nerven verlieren und alles abbrechen kann.

Victor Savkin: Is Taking Small Steps Always a Good Idea?
In vielen Teams ist es eine wiederkehrende Diskussion, die in fast jedem Planning II geführt wird: wie granular müssen Tasks geschnitten werden? Dieser Artikel versucht die Diskussion auf wissenschaftliche Füße zu stellen indem er den Bekanntheitsgrad der Aufgabe mit den Verarbeitungskapazitäten des Gehirns in Verbindung setzt. Verkürzt gesagt entsteht dabei folgende Faustregel: hoher Bekanntheitsgrad = große Tasks, geringer Bekanntheitsgrad = kleine Tasks. Voraussetzung ist aber, dass auch diese größeren Tasks noch innerhalb eines Tages zu bewältigen sein müssen. Vor allem die Visualisierungen finde ich sehr ansprechend, sie sollten sich gut in Workshops integrieren lassen.

Scott Belsky: Avoiding Organizational Debt

bisher darunter verstanden

Montag, 26. September 2016

Ein Kalauer für die Oktoberfest-Zeit.

#BilligeWortspieleFür200 pic.twitter.com/2c2e3n6TKC
— L'Eclat c'est moi! (@blog2de) 14. September 2016