Donnerstag, 28. März 2019

Warum Teams nicht agil arbeiten wollen

Bild: Pixabay / Niek Verlaan - Lizenz
Manchmal ist es merkwürdig. Da will man Gutes tun für seine Mitarbeiter, zusammen mit ihnen in die neue Arbeitswelt aufbrechen, Selbstorganisation fördern, Verantwortung delegieren und Altes hinter sich lassen - und was zurück kommt sind Unverständnis, Undank und Ablehnung. Wie kann das sein, wie haben wir das verdient? Haben wir es überhaupt verdient? Die harte Antwort: Mit hoher Wahrscheinlichkeit ja. Es gibt gute Gründe für eine Ablehnung einer agilen Transformation. Hier sind einige der häufigsten:

Für die Lösung (Agilität) gibt es kein Problem

Im Grunde ist es methodenunabhängig eine Selbstverständlichkeit: bevor irgendetwas Neues eingeführt wird sollte man sich immer fragen welches Problem damit gelöst werden soll. In der Realität kommt diese Frage aber erschreckend oft nicht vor. Agilität wird eingeführt weil es gerade modern ist, weil alle es machen, weil es vom Chef befohlen wurde, etc. Dass der Ist-Zustand ausreichend sein könnte wird nicht bedacht oder bewusst ignoriert. Wer kann es verdenken wenn davon keiner begeistert ist?

Agilität ist die falsche Lösung

Ebenfalls erstaunlich häufig. Während agile Vorgehensweisen für innovationslastige, komplexe und änderungsanfällige Vorhaben gut geeignet sind passen sie in anderen Zusammenhängen eher weniger. Wenn es zum Beispiel darum geht einen Fertigungsprozess effizienter zu machen oder in einem stabilen Umfeld einen komplizierten aber gleich bleibenden Plan umzusetzen sollten auch andere Ansätze in Betracht gezogen werden. Und bei einfachen Vorhaben kann ggf. auf jegliche Methodik verzichtet werden. Wenn trotzdem aus Prinzip alles agil sein muss ist Skepsis verständlich.

Die Beteiligten wurden nicht gefragt

Der vermutlich schlechteste Weg zur Einführung von selbstorganisierten Teams ist ein Befehl von oben. Dass Agilität nur funktioniert wenn sich die Beteiligten auf allen Ebenen freiwillig einbringen sollte ein Allgemeinplatz sein, oft ist er es nicht. Wenn Einwände und Fragen dann abgebügelt oder mit fehlendem Verständnis erklärt werden braucht man sich über Ablehnung und Widerstand nicht zu wundern. Oft wird in solchen Situationen noch versucht "die Mitarbeiter mitzunehmen", "das eigene Vorgehen besser zu erklären" oder "die Menschen zu ihrem Glück zu zwingen." Erfolgreich ist das selten.

Das Framework ist nicht das Richtige

Selbst wenn Agilität die richtige Lösung für ein existierendes Problem sein sollte und das Vorgehen von den Mitarbeitern mitgetragen wird kann die Wahl des Frameworks Probleme aufwerfen. Extreme Programming passt gut zu Anwendungsentwicklung aber schlecht zu Operations, Scrum macht in regelmässigen Umsetzungszyklen mehr Sinn als in anlassgetriebenem Arbeiten, Lean Startup funktioniert in Startups (Überraschung), kann aber in grossen Organisationen zu Schwierigkeiten führen. Ein falscher Umsetzungsweg kann aus diesen Gründen schnell für wenig Akzeptanz sorgen.

Die Umsetzung ist zu esoterisch

Auch das kommt immer wieder vor. In jeder Arbeitsumgebung sollten spielerische und kreativitätsfördernde Elemente nur so lange eingesetzt werden wie sie das Gefühl von Professionalität nicht beeinträchtigen. Bunte Post-Its an die Wand hängen, in Retrospektiven Bilder malen, Bällebäder aufstellen oder Räumen lustige Namen geben kann hilfreich sein wenn Teams es wollen, wenn sie sich damit unwohl fühlen sollte man es lassen. Und wenn all das als zwingend notwendiger Erfolgsfaktor beschrieben wird werden zurecht Sinnfragen gestellt werden. Es würde nämlich auch ohne all das gehen.

Wirkliche Veränderungen sind unerwünscht

Im Grunde gehört dieser Punkt nicht in diese Liste, denn wer Veränderungen nicht will, der will auch keine Agilität. Dass trotzdem immer wieder genau das vorkommt liegt an dem Irrglauben, dass Agilität sich in abgekapselten Bereichen umsetzen liesse, ohne dass die umgebende Organisation sich ändern muss. Das wird von den Betroffenen relativ schnell als das durchschaut was es ist - als schwere Dysfunktion. Und von der will niemand ein Teil sein.

Montag, 25. März 2019

Break your Industry Standards

Immer das Gleiche zu tun wie alle anderen ist auf dauer nicht zielführend. Gesagt haben das schon viele, aber die meisten nicht so unterhaltsam wie Paul Rulkens.

Donnerstag, 21. März 2019

Agiles Change Management (II)

Bild: Max Pixel - CC0 1.0
Agiles Change Management ist anders als klassisches, und das in verschiedener Hinsicht. Schon dass es Veränderungen nicht schnell hinter sich bringen sondern dauerhaft erhalten will ist ein Paradigmenwechsel (mehr dazu hier), aber auch die Art wie der Wandel gestaltet werden soll ist neu und anders.

Um den Unterschied zu erkennen zunächst ein Blick auf das klassische Vorgehen: bei den Change-Vorhaben der Vergangenheit handelte es sich in der Regel um grosse, schwerfällige Programme. Von langer Hand geplant, von zahlreichen Gremien abgenickt, mit festen Meilensteinen versehen und von Top Down-Befehlsketten begleitet stellen sie in vieler Hinsicht Musterbeispiele für klassisches Projektmanagement dar.

Auch die flankierende Kommunikation mit den Betroffenen folgt in den meisten Fällen dem "bewährten Muster". In der Theorie wird zwar Feedback eingeholt, in der Realität wird dieses aber durch passende Fragestellungen in eine "konstruktive Richtung" gelenkt. Und wenn wirklich Unzufriedenheit ermittelt wird dann nicht um den Kurs anzupassen sondern um festzustellen wo man das bisherige Vorgehen "besser erklären" und "Mitarbeiter mitnehmen" muss.

In einem agilen Change Management ist das Vorgehen ein anderes. Genau wie in der agilen Produktentwicklung werden auch hier in kleinen Schritten überschaubare Änderungen durchgeführt und deren Wirkungsgrad und Akzeptanz schnellstmöglich gemessen. Entspricht das Ergebnis nicht den Erwartungen wird der Plan überprüft und ggf. angepasst, um schnellstmöglich die nächste überschaubare Änderung validieren zu können.

Da die Angemessenheit und Wirksamkeit der Massnahmen nicht im voraus beschlossen sondern in kurzen Abständen validiert werden sind auch Planung und Durchführung zwangsläufig variabler, schlanker und leichtgewichtiger - nur so können sie im Zweifel mit vertretbarem Aufwand angepasst werden. Auch das hat Folgen: weniger Gremienbeschlüsse, weniger Planziele, mehr Ergebnisoffenheit und mehr Experiemtierbereitschaft.

Grundlegend anders muss in diesem Zusammenhang auch kommuniziert werden. Statt lediglich fertige, unumstössliche Beschlüsse zu bewerben sollte die Forderung und Förderung von (explizit auch kritischem) Feedback im Mittelpunkt stehen. Und nicht nur das, Immer wieder muss herausgestrichen werden wo dieses Feedback zu Kursanpassungen geführt hat. Nur so kann sichergestellt werden, dass diese permanente Validierung weitergeht und zur kontinuierlichen Verbesserung beiträgt.

Natürlich bedeutet ein solches Vorgehen, dass Veränderungen nicht mehr langfristig im Detail geplant und planmässig umgesetzt werden können. Die Wahrheit ist aber auch, dass das bereits vorher nicht mehr möglich gewesen ist. Man hat in den meisten Fällen lediglich so getan als ob, dann aber am Bedarf vorbeigearbeitet. Dann doch lieber Inspect & Adapt.

Montag, 18. März 2019

Die sechs (nicht fünf) Phasen einer Retrospektive

Bild: Pixabay / Inspired Images - Lizenz
Beim Neuaufsetzen eines Scrum-, Kanban- oder XP-Teams ist es eine der immer wiederkehrenden Fragen: wie werden die Retrospektiven, KVP-Meetings oder Kaizen-Events aufgesetzt in denen das bisherige Vorgehen unter die Lupe genommen, hinterfragt und gegebenenfalls angepasst wird? Vor allem im Fall von Teams in denen der neue Scrum Master (bzw. der Facilitator, Flow Manager, etc.) selbst keine Erfahrungen in der Rolle hat kann es helfen diese Frage zu beantworten indem am Anfang auf eine bewährte Struktur zurückgegriffen wird.

Gute Erfahrungen gibt es vor allem mit einem Phasen-Modell, in dessen Rahmen in verschiedenen Arbeitsschritten verschiedene Tätigkeiten ausgeübt werden. häufig werden in diesem Zusammenhang fünf derartige Phasen genannt, zu empfehlen sind aber eine mehr, also sechs. Welche davon häufig vergessen wird wird später in diesem Text noch beleuchtet, zuerst geht es aber darum die ersten fünf kurz zu erklären. Es sind: Setting the stage, Gathering data, Generating insights, Deciding what to do, Closing (zahlreiche Beispiele für diese Phasen finden sich auf Retromat.org).

Setting the stage könnte man auch als Einleitung oder Ankommen bezeichnen. In der einfachsten Form kann das nur die Abfrage sein mit welcher Stimmung die Teilnehmer in das Meeting gehen, in komplexeren Settings kann schon ein thematischer Schwerpunkt gefunden oder ein Ventil für Frust und Freude geschaffen werden. Ein nicht zu unterschätzender sekundärer Effekt sollte es sein, symbolisch eine Unterbrechung des Arbeitsalltags vorzunehmen.

Gathering data ist als zweite Phase praktisch selbsterklärend - es geht darum die Datenbasis für das weitere Vorgehen zu schaffen. Sehr häufig ist die Unterteilung der Wand in Sektionen (z.B. start doing, keep doing, stop doing), verbunden mit der Aufforderung entsprechende Themen auf Post-Its daranzuhängen. Andere Durchführungen können Brainstormings sein, Design Thinking-Events oder Self Assessments.

Generating insights besteht fast ausschliesslich aus der Diskussion der vorher gesammelten Themen, ob in Gruppen, als Lean Coffee, Fishbowl oder in anderen Formaten. Vorgeschaltet ist oft ein Clustern zusammenhängender Themengebiete und eine Priorisierung der Themen, bzw. Themencluster. Gegebenenfalls kann es hier schon starkte Überlappungen mit der nächsten Phase geben, in der aus den Diskussionen Massnahmen abgeleitet werden.

Deciding what to do ist genau das, das Erarbeiten von Massnahmen. Welche das sind ist natürlich hochgradig Einzelfallabhängig, es gibt aber Kriterien, die bei der Formulierung hilfreich sein können: die Massnahmen sollten in nächster Zeit umsetzbar sein, sie sollten vom Team selbst umgesetzt werden können und sie sollten validierbar sein, es muss sich also überprüfen lassen ob sie erfolgreich waren.

Closing bildet gewissermassen zusammen mit dem Setting the Stage die Klammer um die Retrospektive. Auch hier wäre eine Stimmungsabfrage die einfachste Form, es ist aber auch eine "Retrospektive der Retrospektive" möglich um zu bewerten wie gut das Meeting gelaufen ist. Eine andere Form wäre das Einstimmen auf bevorstehende Herausforderungen.

Soweit die weit verbreiteten fünf Phasen. Dass die sechste relativ selten ist, ist an sich bereits bezeichnend, es handelt sich nämlich um das Inspecting the last retro's action Items, also um das Überprüfen der beim letzten mal beschlossenen Massnahmen auf Erfolg. Wie wenn nicht so soll ein Inspect and Adapt stattfinden? Und sinnigerweise sollte das auch relativ früh stattfinden. Ein zu empfehlender Ablauf einer Retrospektive wäre demnach:

Setting the stage, Inspecting last retro's action Items, Gathering data, Generating insights, Deciding what to do, Closing

Donnerstag, 14. März 2019

Deine Muda: Overproduction

Bild: Flickr / Jordi Bernabeu Farrús - CC BY 2.0
Sechster Teil der Deine Muda-Serie. Die fünfte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Überproduktion, auf englisch Overproduction. Wie bei der Lagerhaltung ist es auch hier auf den ersten Blick etwas was in Hardware und Software ähnlich erscheint, während sich auf den zweiten Blick Unterschiede zeigen.

In Bezug auf die Gemeinsamkeiten von Hardware- und Softwareproduktion gibt es zunächst eine große Überschneidung mit der gerade erwähnten Lagerhaltung. Zuviel produzierte Güter können nicht schnell genug verkauft werden und müssen gelagert werden. Da die Produktion bereits bezahlt ist, die Verkaufserlöse aber noch nicht eingegangen sind, binden die Produkte in diesem Zustand Geld, sind also totes Kapital.

Gleichzeitig bindet die Überproduktion Menschen und Maschinen die an anderer Stelle fehlen, wodurch sich dort die Arbeitsfortschritte verzögern. Im schlimmsten Fall kommt es sogar zu zusätzlichen (und eigentlich unnötigen) Neueinstellungen und Neuanschaffungen, durch die es zu einer dauerhaften Zunahme von Lohn- und Instandhaltungskosten kommt, ohne dass diese durch Gewinne refinanziert werden.

Zusätzlich zu diesen Faktoren kommt es zu Verschleisserscheinungen, und zwar sowohl bei Maschinen als auch bei Menschen. Während die ersten sich durch Gebrauch abnutzen tritt bei den Mitarbeiter nicht nur physischer sondern auch psychischer Verschleiss auf. Die Erkenntnis am Markt vorbeizuproduzieren kann deprimmierend sein und sich negativ auf Arbeitsmoral, Engagement und Sorgfalt auswirken.

Softwarespezifisch kommt ein weiterer Faktor dazu, nämlich die unnötige Aufblähung der Code Base und des Funktionsumfangs. Diese sorgen zunächst für gesteigerte Kosten bei Wartung und Instandhaltung, langfristig aber auch für erhebliche Mehraufwände in der Weiterentwicklung, da mit dem Umfang auch die Menge der nötigen Integrations- und Regressionstests, des Bugfixings und des Refactorings steigt.

Zur Behebung dieser Misstände reicht es daher in der Software (anders als im Fall der Hardware) nicht aus einfach die Produktion zu drosseln. Darüber hinaus ist auch ein Rückbau der bereits implementierten Feature-Überproduktion nötig um die negativen Effekte abzustellen. Man zahlt also doppelt, einmal für die Überproduktion selbst, einmal für den Rückbau. Ein Grund mehr, damit gar nicht erst anzufangen.

Montag, 11. März 2019

Scrum-Zertifiziert - und ratlos wie Scrum funktioniert

Bild: Pexels / Bruce Mars - Lizenz
Zertifizierungen sind ein grosses Thema. In der Wirtschaft im allgemeinen, in der IT im Speziellen, im agilen Kontext im ganz Speziellen und vor allem im Umfeld von Scrum. Alleine die grössten beiden Organisationen, die Scrum Alliance und Scrum.org haben weltweit mehr als 500.000 Zertifikate für Scrum Master und Product Owner vergeben, dazu kommt eine unklare Nummer von anderen Anbietern (von denen es wesentlich mehr gibt als man denken sollte).

Viel Expertise, sollte man denken. So viele Menschen mit bestandenen Prüfungen und (bei einigen Anbietern) regelmässigen Re-Zertifizierungen sollten eine gute Grundlage bilden, basierend auf der viele Unternehmen gekonnt an die Implementierung von Scrum gehen können. Denn wer so ein Zertifikat sein Eigen nennt hat bewiesen, dass er weiss wie man dieses Framework ein- und durchführt - richtig? Nun, leider nein.

Irritierenderweise ist keine der gängigen Zertifizierungen ausreichend um auf die Arbeit in oder mit Scrum vorzubereiten. Nicht nur weil sie lediglich Theorie vermitteln (obwohl schon das ein gewichtiger Punkt ist). Viel wichtiger ist aber ein zweiter: selbst das in den Zertifizierungskursen vermittelte und in den Prüfungen unter Beweis gestellte Wissen bildet nicht vollständig ab was nötig ist um später damit zu arbeiten. Selbst wer es vollständig verinnerlicht hat wird meistens an der Umsetzung scheitern, solange er nicht in grossem Umfang nicht prüfungsrelevanten Stoff verinnerlicht hat.

Dieser hochgradig irritierende Zustand der "zertifizierten Praxisuntauglichkeit" ist kein Zufall. Er ergibt sich zwangsläufig aus dem Zusammenspiel zweier Faktoren. Zum einen aus der Framework-Natur von Scrum und zum anderen aus der (schon vor Scrum existierenden) grundsätzlichen Arbeitsweise der Schulungsindustrie, an die die Zertifizierungsorganisationen die vorbereitenden Kurse ausgelagert haben.

Werfen wir zunächst einen Blick auf den Framework-Charakter. Mit voller Absicht erwähnt der Scrum Guide (das offizielle Regelwerk) zentrale Punkte nicht. Nirgendwo in ihm wird erwähnt wie Abnahmen stattfinden oder warum (und dass) paktisch alle Scrum-Teams Boards benutzen, kein einziges mal geht er auf DoR und User Stories ein, etc. etc. Das bedeutet nicht, dass es unklar wäre wie damit umgegangen werden kann - im letzten Vierteljahrhundert haben sich zahlreiche Best Practices und Good Practices herausgebildet. Da diese in Einzelfällen nicht passend sein könnten stehen sie aber nicht im Scrum Guide. Kennen muss man sie trotzdem.

Als nächstes zur Arbeitsweise der Schulungsindustrie. Es ist nicht so, dass diese die Good Practices und Best Practices nicht vermitteln könnte - sie will es aber nicht. Der Grund dafür ist, dass die üblichen ein- oder zweitägigen Kurse gerade ausreichend sind um die Inhalte des Scrum Guides zu vermitteln. Die umgebenden Kontextinformationen ebenfalls aufzunehmen würde dazu führen, dass aus Tagen Wochen würden. Da das kaum ein Arbeitgeber finanzieren würde bleibt es bei den besser verkaufbaren Kurzveranstaltungen. Umsatz ist hier letztendlich wichtiger als umfassende Wissensvermittlung.1

In Kombination führen der Frameworkcharakter von Scrum und die Gewinnorientierung der Schulungsindustie zur oben genannten zertifizierten Praxisuntauglichkeit. Sie ist der Grund für das Scheitern zahlloser Scrum-Einführungen und agiler Transitionen, denn da zahlreiche Unternehmen die oben genannten Hintergründe nicht kennen glauben sie, dass mit dem Zertifikat alles nötige Wissen erworben wäre. Sobald die Lücken im Framework auffallen werden diese dann reflexhaft mit Versatzstücken des alten Vorgehens gefüllt, wodurch Agilität meistens unmöglich wird.

Um mit einer positiven Note zu enden - das alles heisst nicht, dass man sich nicht mit dem Scrum Guide beschäftigen sollte. Man kann und sollte es tun. Man kann sein Wissen sogar prüfen lassen wenn man das möchte. Man sollte diese Prüfung nur nicht mit einem "theoretischen Führerschein für Scrum" verwechseln. Das ist sie nicht und das kann sie in der gegenwärtigen Konstellation auch nicht sein.


1Verständlicherweise, schliesslich sind die Schulungsanbieter private Unternehmen und müssen ihr Einkommen erwirtschaften

Freitag, 8. März 2019

Wann finden in agilen Teams Abnahmen statt?

Bild: Pixabay / Tero Vesalainen - Lizenz
Zu den vielen Dingen die in den gängigen agilen Frameworks nicht geregelt werden gehören die Abnahmen eines fertigen Produktincrements. Dass sie stattfinden sollten ist naheliegend, zumindest so lange wie es einen Product Manager, Onsite Customer oder Product Owner gibt, der die Anforderung ursprünglich verfasst hat. Wann sie stattfinden soll ist weniger klar.

Was in vielen Teams stattfindet ist scheinbar naheliegend - eine Abnahme in den Review- oder Demonstrations-Meetings, die es nicht nur in Scrum gibt sondern überall dort wo Kunden, Auftraggebern oder Benutzern die Ergebnisse umgesetzter Anforderungen vorgeführt werden. Doch so naheliegend das auch erscheinen mag, eine gute Idee ist es nicht.

Zum einen ist eine Abnahme vor den Augen von Leuten ausserhalb des Teams eine zweischneidige Angelegenheit. Bestenfalls werden sie durch intern wichtige aber für Aussenstehende irrelevante Details gelangweilt (Wurden die Regressionstests aktualisiert? Entspricht die Schriftart dem Corporate Design? Etc.), schlimmstenfalls wird die Abnahme verweigert und sie haben sich umsonst in das Meeting begeben.

Zum anderen nimmt sich ein Team das Abnahmen zu einem so späten Zeitpunkt durchführt ohne Notwendigkeit selbst einen Teil der eigenen Flexibilität. Zur Verdeutlichung: wird ein Ergebnis erst am Ende eines Sprints oder Produktionsszyklus überprüft ist es im Regelfall zu spät um einen festgestellten Änderungsbedarf ohne Planänderungen umzusetzen. Der nächste Sprint, bzw. Zyklus steht ja unmittelbar bevor und muss kurzfristig noch die Nacharbeiten aufnehmen.

Eine bessere Vorgehensweise wäre eine Abnahme sofort nach der Fertigstellung der letzten Arbeit am jeweiligen Increment. Wenn dann unmittelbar eine Vorführung und Überprüfung stattfindet bleibt auch bei entdeckten Fehlern noch genug Zeit für Korrekturmassnahmen, so dass der Zeitplan eingehalten wird und im Review, bzw. Demo-Meeting der Focus da liegen kann wo er hingehört - beim Einsammeln und Diskutieren von Feedback zum fertigen Ergebnis.

Ein häufiger Hinweis an dieser Stelle ist übrigens, dass man Abnahmen doch nicht einfach irgendwann und ohne Meeting durchführen könnte, nur weil es da gerade passt. Die Antwort darauf: doch, das geht auch ohne offizielles Meeting, und ja, gerade dann wenn es passt ist der richtige Zeitpunkt. Ganz ehrlich - wann denn sonst?

Dienstag, 5. März 2019

A lot of what managers do shouldn't be done

Wenn es um agile Vorzeigeunternehmen geht werden immer die gleichen Beispiele genannt: Google, Facebook, Amozon, Spotify. Eines der unbekannteren aber trotzdem hochinteressanten ist Semco aus Brasilien:



Dass Semco kein Startup oder IT-Unternehmen ist sondern ein IT-Konzern macht die Geschichte noch beeindruckender, denn nach allem was man hört hat sich diese Firma ihren Geist bis heute erhalten.

[Edit: das ursprüngliche Video wurde gelöscht, dass hier ist ein inhaltlich sehr ähnliches]