Donnerstag, 17. November 2016
Survivor Bias
 |
| Bild: Pexels / Oliver Sjöström - Lizenz |
Der Blick auf Spotify, Google, Netflix und Zalando verzerrt die Wahrnehmung, denn sie haben eine Gemeinsamkeit die so offensichtlich ist, dass sie schon wieder übersehen wird: sie haben überlebt und sind erfolgreich. Die dahinterliegende Bedeutung wird klar wenn man sich andere Unternehmen ansieht die nicht so glücklich waren, geschlossen wurden oder vor sich hinkrebsen - in ihnen findet man mitunter genau die gleichen Teamaufteilungen, Organisationsprinzipien und Skalierungsansätze wieder. Man sieht: nur an denen allein kann der Erfolg nicht liegen.
In mehreren Einsätzen in großen Projekten/Abteilungen (5 - 30 Teams) habe ich die Erfahrung gemacht, dass gerade im skalierten Umfeld viel "historisch gewachsen" ist. Firmenstrukturen oder Firmenkulturen sorgen dafür, dass ein und die selbe Lösung in einem Fall hervorragend funktionieren, in einem anderen aber zu Stillstand oder Chaos führen kann. Gute Ansätze können durch eine ungeschickte Einführung so diskreditiert sein, dass sie nicht mehr einsetzbar sind, andere, eher suboptimale können in bestimmten Konstellationen gute Ergebnisse bringen. All das kann man von aussen nicht sehen.
Für ein differenziertes Bild sollte man aus diesem Grund nicht nur fragen "Welche Methoden von erfolgreichen Unternehmen können wir auch bei uns einsetzen?", man sollte auch fragen in welchen Kontexten diese Methoden eingebettet waren und ob es andere Situationen gab in denen sie nicht funktioniert haben. Unterlässt man das und konzentriert sich nur auf die Erfolgsfälle ist die Wahrnehmung verzerrt - und basierend auf verzerrten Wahrnehmungen sollte man besser keine Methoden, Prozesse oder Frameworks einführen.
Montag, 14. November 2016
Agilität, dort wo man sie nicht vermutet
 |
| Bild: Wikimedia Commons/Alter Fritz - CC BY-SA 3.0 |
Obwohl es natürlich Computer und Telefone an jedem Platz gab wurden wichtige Informationen nach wie vor über Laufmappen verteilt, Papierumschläge auf denen der nächste, der übernächste und z.T. weitere Empfänger bereits vermerkt waren. Beim jeweils nächsten Empfänger angekommen landeten sie auf einem Aktenstapel und wurden nach und nach abgearbeitet, was dauern konnte. Ich erinnere mich an einen Vermerk der nach Monaten zurückkam, mit nichts weiterem als der Notiz "Veraltet, bitte aktualisieren".
Inmitten dieser klischeehaften Vorgänge gab es aber auch Lichtblicke. Sachbearbeiter die einfach alle Beteiligten an einem Vorhaben in ihr Büro einluden um die Angelegenheit direkt zu besprechen, Vorgesetzte die bis zum Praktikanten alle Untergebenen gleich behandelten, Kollegen die sich regelmässig darüber austauschten wie man besser zusammenarbeiten könnte. Ich hatte das große Glück vor allem mit solchen Menschen zusammenarbeiten zu dürfen.
Niemand hätte damals von flachen Hierarchien, von Retrospektiven oder Iterationen gesprochen, letztendlich war das was wir gemacht haben aber nichts anderes. Natürlich, vieles hätte man besser machen können, aber verglichen mit anderen Behörden und Großunternehmen die ich seitdem kennenlernen durfte war das was ich dort miterlebt habe schon sehr gut.
Ich versuche mir diese Phase meiner Vergangenheit von Zeit zu Zeit ins Gedächtnis zu rufen, da sie mich an zwei wichtige Dinge erinnert. Erstens: Agilität kann auch dort vorhanden sein wo man sie nicht vermutet, und Zweitens: sie kann auch existieren ohne dass die standardisierten Begriffe der englischsprachigen Frameworks genutzt werden. Wer das berücksichtigt kann agile Transitionen wesentlich schneller vorantreiben als jemand der puristisch auf der reinen Lehre beharren will.
Donnerstag, 10. November 2016
Change Fatigue
 |
| Bild: Wikimedia Commons/Arthur Goss - Public Domain |
Die häufigste Ursache sind in relativ kurzen Abständen vorkommende Strategie- oder Methodenwechsel. Wenn etwa in den letzten fünfzehn Jahren nacheinander Lean Management, Six Sigma, PMP, Kanban und Projektbasierte Matrix-Organisation eingeführt wurden, kann man sicher sein, dass z.B. eine Scrum-Einführung für die Mitarbeiter nur wie die nächste Sau erscheint, die durch das Dorf getrieben wird. Möglicherweise ist die neu einzuführende Methode in der jüngeren Vergangenheit auch schon eingeführt und wieder durch eine andere ersetzt worden, wodurch sie bereits als "verbrannt" gilt.
Selbst wenn dieser ständige Methodenwechsel an sich schon kontraproduktiv und ermüdend ist - eine Steigerung ist möglich. Dann nämlich, wenn er jedes mal mit Erwartungen und künstlich erzeugten Emotionen überladen wird. Gunther Dueck hat es in der Überschrift eines seiner Artikel auf den Punkt gebracht: Grundlose Begeisterung ist Pflicht. Nicht nur der häufig überzogene Pathos der Kickoff-Veranstaltungen ist dabei ein Problem, sondern vor allem die dadurch erzeugte Fallhöhe. Je euphorischer die Ankündigung, dass diesesmal wirklich alles besser wird, desto größer die darauf folgende Enttäuschung, wenn alles beim Alten bleibt.
Noch schlimmer ist es, wenn die Methoden nicht nur bereits "durch das Dorf getrieben" sondern ausserdem missbraucht worden sind, um die Angestellten zu gängeln. Scrum bietet durch seine Transparenz die Möglichkeit zu Micromanagement und Blaming, Lean Startup kann in wahllosen Aktionismus ausarten und Kanban in Akkordarbeit. Wer derartige Erfahrungen bereits hinter sich hat, wird zurecht misstrauisch sein, wenn die Methodenkiste ein weiteres mal aufgemacht wird.
Ich rate in solchen Fällen zu einem mehrstufigen Vorgehen. Als erster Schritt sollten die gescheiterten Methodeneinführungen der Vergangenheit analysiert und die dabei gemachten Fehler festgehalten werden. Das ist für die Beteiligten ein schmerzhafter und unangenehmer Prozess, allerdings meistens der einzige Weg um den Mitarbeitern zu zeigen, dass man aus der Vergangenheit gelernt hat. Aufbauend darauf kann man versichern (und regelmässig überprüfen), dass sich diese Fehler nicht wiederholen.
Der darauf aufbauende zweite Schritt besteht aus dem Verzicht auf eine pompöse Einführungsveranstaltung zugunsten vieler kleiner Schritte. Wer in kurzen Abständen erreichbare Verbesserungen ankündigt und transparent macht ob und wann sie erreicht wurden, erzeugt damit mehr Vertrauen als mit einer weiteren Tschakka!-Veranstaltung. Das heisst nicht, dass es keine langfristigen Visionen geben sollte, es bedeutet aber, dass nicht mehr behauptet wird sie in kurzer Zeit erreichen zu können, wenn man sich denn nur anstrengt.
Als dritter Schritt sollte regelmässig (z.B. monatlich) das Feedback der betroffenen Mitarbeiter eingeholt werden. Haben sie das Gefühl, dass sich die Lage tatsächlich verbessert? Wie zufrieden sind sie mit ihrer Situation? Haben sie das Gefühl, ernstgenommen und mitgenommen zu werden? Im Normalfall ergibt sich aus diesem Feedback, dass die Neuerungen auf den unteren Ebenen zu Unsicherheit, Mehrarbeit und gegebenenfalls sogar Verschlechterungen führen, also dem Gegenteil dessen was eigentlich erreicht werden sollte.
Der vierte Schritt muss jetzt darin bestehen, den ersten Reflexen zu wiederstehen. Diese sind entweder ein frustriertes Zurückrollen aller Veränderungen ("hat ja nichts gebracht"), oder ein weitgehendes Ignorieren der Mitarbeiter-Stimmen ("weil die undankbar sind und ihnen nicht klar ist, dass man doch alles nur zu ihrem Besten tut"). Stattdessen sollte mit den vier Schritten von vorne begonnen werden: Fehleranalyse, kleine Verbesserungsmassnahmen, Feedback einholen und Vorgehen anpassen. Das bedeutet zwar kurzfristige Mehrarbeit, ist aber die beste Möglichkeit um Vertrauen aufzubauen und dem Change Fatigue-Phänomen zu entkommen.
Montag, 7. November 2016
Wie man Teams leistungsfähig macht
Zur Abwechselung mal wieder ein Video. Dieses hier ist besonders empfehlenswert für jeden der irgendeine Art von Weisungsbefugnis oder Personalverantwortung hat, es fasst gut zusammen was man tun oder lassen sollte wenn man ein leistungsfähiges Team haben will. Spoiler: es geht um Offenheit, Transparenz, Toleranz und Menschlichkeit.Donnerstag, 3. November 2016
Montag, 31. Oktober 2016
Kommentierte Links (XVIII)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Jason Little: Is Your Organization Ready for Agile Change? (Edit: Link ist mittlerweile tot)
Ich bin mittlerweile ein Fan von Jason Littles Blog, so ziemlich alles was er schreibt könnte ich unterschreiben. Wenn er darüber hinaus noch sinnvolle Werkzeuge vorstellt - umso besser. Die in diesem Beitrag vorgestellten Umfragen habe ich in ähnlicher Form bereits an anderer Stelle gesehen, was ich noch nicht eingesetzt habe sind die Perspective Maps, für die es dort zwei schöne Beispiele gibt. Die Idee dahinter ist, die Sichtweisen verschiedener Gruppen (Teams, Management, Stakeholder, etc) zu erheben und festzuhalten wo sie voneinander abweichen oder sogar gegenläufig sind. Das visualisierte Ergebnis kann dann an einer zentralen Stelle aufgehängt werden, an der es nicht mehr übersehen werden kann. Das ist Transparenz!
Melissa Perri: Stop Blaming the User
Was Melissa Perry da schreibt ist leider eine viel zu häufige Realität. Software (und Hardware) ist oft so benutzerunfreundlich, dass es ohne Vorwissen oder Hilfe nicht mehr möglich ist sie korrekt zu bedienen. Das hat fast nie mit Bosheit oder Unfähigkeit zu tun, sondern fast immer mit "Sachzwängen". Um Geld und Zeit zu sparen werden neue Funktionen nicht richtig entwickelt sondern notdürftig irgendwo an bestehende Prozesse und Oberflächen drangeklemmt, mit den entsprechenden negativen Folgen für Usability und User Experience. Richtig bedenklich wird das aber erst, wenn Unternehmen oder Entwicklungsteams die Schuld für die daraus entstehenden Akzeptanzprobleme auf den Benutzer schieben wollen. Mit Perris Worten: "If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful." Bei der Entwicklung von Anwendungen für die eigenen Mitarbeiter kann dieses User Blaming dazu führen, dass die Betroffenen in die innere Kündigung abtauchen, bei externen Anwendungen können schlechte Presse und Verluste von Marktanteilen die Folge sein. Das Abstellen dieser (vermeintlichen) Sachzwänge sollte daher immer höchste Priorität haben. Apropos:
Tom Bartel: Refactoring For Non-Coders
Einfache Erklärungen wie diese hier von Tom Bartels sind extrem wichtig, und zwar aus einem banalen Grund: zu den technikfernen "Non-Coders" gehört in vielen Unternehmen auch das Management, das die Refactoring-Aufwände verstehen, genehmigen und einplanen muss. Für jemanden der von einer Anwendung nur die Benutzeroberfläche kennt können Refactorings leicht den Eindruck erwecken, hier würde nur "der Code hübscher gemacht". Wenn nur begrenzte Ressourcen verfügbar sind gehört das dann zum Ersten was gestrichen wird (das sind die "Sachzwänge" aus dem letzten Abschnitt). Die Folge: schlecht wartbare, bedienbare und erweiterbare Anwendungen. Mit plastischen Methaphern wie dieser hier können die Auswirkungen von fehlendem Refactoring vermittelt werden.
Mike Perrow: 5 tough questions about scaled agile you'll need answers for
SAFe ist vermutlich das umstrittenste unter den großen agilen Frameworks, für viele ist es sogar ein Antipattern, das durch die Hintertür Wasserfall-Elemente wiedereinführt. Sein Erfinder Dean Leffingwell hat allerdings einen Punkt wenn er festhält, dass Scrum oder Agile in großen Firmen Fragen aufwerfen, die man beantworten können sollte:
Ob SAFe die richtigen Antworten auf diese Fragen liefert ist umstritten, zumindest sind sie aber für klassische Management verständlich. Und in einem Punkt hat Leffingwell definitiv recht: wer diese Fragen nicht beantworten kann wird schnell als unseriös gelten und nicht mehr ernstgenommen werden.- Wie kann sichergestellt werden, dass alle Teams das gleiche Ziel im Blick haben und darauf hinarbeiten?
- Wie kann verhindert werden, dass die Teams unterschiedliche (schlimmstenfalls inkompatible) Wege in Architektur, Benutzerführung und Design gehen?
- Wie funktioniert langfristige (Budget)Planung in einem skalierten agilen Umfeld?
- Wie lässt sich berechnen, welchen Geschäftswert die getätigten Ausgaben einbringen werden?
- Warum ist eine permanente Anpassung von Anwendung und Anforderungen billiger als das schnelle Fertigstellen und Abliefern klarer Aufträge?
Harald Schlüter: Eine Fallstudie zur Einführung von Kanban
Diese Fallstudie von Harald Schlüter ist gleich in zweifacher Weise interessant: zum einen aufgrund ihres Inhalts, zum anderen aber aufgrund der visuellen Aufbereitung. Auch wenn man bei der Veranstaltung nicht dabei war geben die Flipchart-Blätter einen sehr guten Einblick darüber wie die Einführung strukturiert und durchgeführt wurde..
Donnerstag, 27. Oktober 2016
Digitalisierung
 |
| Grafik: Pixabay / Geralt - Lizenz |
Wenn meine Kunden mich nach den Voraussetzungen für eine gelungene Einführung von Scrum/Agile fragen nenne ich (neben anderen) immer die Digitalisierung von Daten und Prozessen. Das überrascht dann den einen oder anderen (was wiederum mich überrascht1). Bei genauerer Betrachtung stellt sich oft heraus, dass noch weite Teile des Unternehmens in der Welt der physischen Datenhaltung verblieben sind. Aber warum ist das ein Problem? Aus mehreren Gründen.
Zunächst sind nicht digitalisierte Informationen nur schwer verfügbar. Wenn man sich nicht gerade am Standort des physischen Archivs befindet muss man den Archivar oder die Sekretärin anrufen, sie auf die Suche schicken und hoffen, dass sie das Richtige finden. Und selbst wenn das gelungen ist gehen die Probleme weiter. Entweder man muss auf die Zustellung warten oder man lässt alles einscannen und hat dann ein riesiges, nicht durchsuchbares PDF (oder noch schlimmer: einen Ordner voll JPGs). Handelt es sich bei derartig schwer zugänglichen Dokumenten um wichtige Informationen (Lizenzverträge, Zuständigkeitsabgrenzungen, Stakeholderverzeichnisse, etc.) kann es sein, dass ihre späte Verfügbarkeit den Beginn der Arbeiten stark verzögert, bzw. bereits getane Arbeit obsolet werden lässt.
Dazu kommt, dass physische Daten oft nur mit Mühe zu aktualisieren sind. In einem Unternehmen habe ich erlebt, dass die Mitarbeiter ihr Feedback zu einer neuen Software auf Papier schreiben und in BVW-Briefkästen einwerfen mussten. Alleine das Entziffern und Abtippen dauerte ewig. In einem anderen Fall druckte der Kundendienst die Feedback-Emails der Kunden aus und heftete sie in Aktenordnern ab (!). Infolgedessen traten wieder die im letzten Abschnitt beschriebenen Probleme auf. Mit einem solchen Vorgehen ist es nahezu unmöglich die Rückmeldungen der Benutzer zeitnah in die Weiterentwicklung einfließen zu lassen.
Einen Sonderfall bilden halbherzige oder Teil-Digitalisierungen. Auch hier Beispiele aus der Praxis: In einer Behörde lag der von einer Agentur erstellte Corporate Identity-Leitfaden zwar digital vor, allerdings nur gebrannt auf CDs, die (natürlich) in Aktenordnern im Archiv lagen. In einem anderen Unternehmen waren Produktdaten zwar in einer Access-Datenbank erfasst, die allerdings keine Schnittstelle zu den Webanwendungen hatte, die diese Daten benötigten. Eine Gruppe von Werkstudenten machte nichts anderes als die beiden Systeme manuell zu synchronisieren, was jedesmal mehrere Wochen dauerte.
Wenn solche Daten von Anfang an in miteinander vernetzten CMS oder CRM-Systemen aufgenommen werden können Vorgänge auf eine im Vergleich atemberaubende Geschwindigkeit beschleunigt werden. Auf wichtige Dokumente oder aktuelle Nutzerstatistiken lässt sich innerhalb von Minuten zugreifen, und die entnommenen Informationen und Erkenntnisse können sofort in die Weiterführung der Arbeit übernommen werden. Schöne neue Welt. Erst so lässt sich wirklich agil arbeiten.
Das Problem an dieser Stelle ist natürlich, dass eine Digitalisierung und Vernetzung größerer Aktenbestände Zeit und Geld erfordert. Der mittel- und langfristige Effizienzgewinn ist allerdings so groß, dass diese Investition sich absolut lohnt.
1Okay, mittlerweile nicht mehr.
Montag, 24. Oktober 2016
D-A-CH Chapter der Scrum Alliance ist im Aufbau
 |
| Bild: Pixabay/Lusign - Lizenz |
Beim ersten Arbeitstreffen ging es um u.a. Themen wie gegenseitiges Coaching oder die Erarbeitung von Standards für Unternehmen, die Gruppe an der ich teilgenommen habe war aber die, die sich mit der Vernetzung, bzw. dem Aufbau der lokalen Events und User Groups beschäftigt hat. Ein Engagement in diesem Bereich halte ich grundsätzlich für wichtig, schließlich gehören Agilität und Subsidiarität für mich zusammen. Darüber hinaus scheint es in manchen Orten noch Nachholbedarf zu geben - selbst in großen Städten wie Frankfurt oder Wien finden dem Vernehmen nach nur unregelmässig Veranstaltungen statt.
Der bescheidene Beitrag den ich an dieser Stelle leisten kann ist das Weitergeben von Erfahrungen und best practices, schließlich bin ich recht intensiv in der Community in Köln/Bonn unterwegs und trage mit dem Scrumtisch Bonn auch zu ihr bei. Und vielleicht profitiere ich irgendwann auch selbst davon - wenn ich mal wieder ausserhalb des Rheinlandes unterwegs sein sollte wäre eine lokale Veranstaltung eine willkommene Alternative zur Hotelbar.
