Samstag, 31. Oktober 2015

Kommentierte Links (VI)

Grafik: Pixabay / Elisa Riva - Lizenz

C. Dierig, N. Doll, S. Fründt, O. Gersemann, G. Hegmann: Deutschlands Problem ist der deutsche Ingenieur

Was ein ganzes Autorenkollektiv da für die Welt aufgeschrieben hat, zeigt die Negativseiten jener Ressource auf, auf der praktisch die ganze deutsche Wirtschaft aufbaut: der deutschen Ingenieursmentalität. Der ihr zugrundeliegende Perfektionismus hat dazu geführt, dass unsere Autos, Maschinen und Geräte zu den besten und sichersten der Welt gehören, verringert aber mittlerweile die Erfolgschancen vieler Unternehmen - statt Wert auf möglichst frühe Marktreife zu legen werden Produkte durch kleinteiligste und nicht hinterfragbare Anforderungen "kaputtentwickelt" oder kommen erst nach der Konkurrenz auf den Markt. Erschwerend kommt dazu, dass in diesem Perfektionismus ein nicht ganz abstreitbarer Größenwahnsinn steckt, der es sehr schwierig macht dagegen anzuargumentieren. Wohin das führen kann zeigt ein zweiter Artikel aus der Süddeutschen Zeitung, der beschreibt, dass bei VW kritische Mitarbeiter einfach niedergeschrien wurden. Der vorgeschlagene Ausweg aus dieser Situation wären Entbürokratisierung und Enthierarchisierung bis zum Wegfall ganzer Managementebenen, womit auch gleich klar ist wer dagegen ankämpfen wird.

Sascha Lobo: Die lustige, bittere Wahrheit über die Vorratsdatenspeicherung

Ausgehend von einem ganz anderen Punkt (der Voratsdatenspeicherung) wird in diesem Artikel beschrieben wie der Planungsperfektionismus, an dem die (Groß)Wirtschaft leidet, überhaupt entstehen konnte. Lobo schlägt zur Erklärung den ganz großen Bogen zurück zur Epoche der Aufklärung von über 200 Jahren, in der man aufhörte an Götter und Zauber zu glauben und stattdessen die Ursachen fast aller Phänomene in Physik und Chemie entdeckte. Plötzlich ließ sich fast alles erklären, nachvollziehen und messen. Und in dieser Messbarkeit sieht Lobo die Wurzel für eine verhängnisvolle Fehlannahme: "Wenn man alles messen kann, kann man die Realität komplett erfassen und deshalb alles vorhersagen." Derartige Ansichten habe ich bei verschiedenen Managern tatsächlich bereits erleben dürfen, meistens verbunden mit einem noch verhängnisvolleren Umkehrschluss: "Wenn es sich nicht planen lässt, dann haben wir einfach noch nicht genug Daten erhoben." Diese Einstellung ist die Ursache für den Betonklotz aus Reportingpflichten, der gerade in scheiternden Projekten häufig an die Füße der Mitarbeiter gehängt wird und so auch die letzten Erfolgsaussichten vernichtet.

Sabine Bernecker-Bendixen: LaaS – Leadership as a Service

Aufzählen was alles schlecht läuft ist einfach, aber wie ginge Management heute besser? Sabine Bernecker-Bendixen macht sich die Mühe und trägt einige Gedanken zusammen. Grundlegende Ideen sind Vertrauen statt Kontrolle, Abkehr von der oben beschriebenen Zahlengläubigkeit, die Verlagerung von Verantwortung nach unten zu den Mitarbeitern, Förderung von deren Kompetenzen, die Entwicklung einer Teamkultur, Coaching statt Befehle geben, Bereitschaft zur Selbstkritik, Bereitschaft sich kritisieren zu lassen, Bereitschaft eigene Schwächen und Fehler einzugestehen und sie zu korrigieren sowie Abschaffung von Flaschenhälsen und Herrschaftswissen. Im Großen und Ganzen soll am Ende genau das entstehen was die Überschrift besagt: Leadership as a Service. Wer die klassische Unternehmenswelt kennt weiß - die Frau spricht von einer Revolution.

Steve Denning: Can The 21st Century Corporation Operate Without Agile?

Apropos Revolution. Steve Denning von Forbes hat einen sehr, sehr langen Fortune-Artikel von Geoff Colvin gelesen und darauf aufbauend einen sehr langen eigenen geschrieben. Wer beide liest bekommt erklärt, wie die (Business)Agilität zum Erfolg der "21st-century corporations" beiträgt, die im Augenblick die Märkte revolutionieren: Skype, Apple, Tesla, Uber, AirBnB, etc. Zu ihren Erfolgsfaktoren zählt er neben einer neuen Art der Personalführung (siehe oben) auch die Bereitschaft, die Beziehungen zum Kunden neu zu definieren - statt ihn durch Werbung, Preise, etc. so zu manipulieren, dass er die angebotenen Produkte kauft, wird ergründet was er will und ihm dann das angeboten. Da Kunden aber häufig ihre Meinung über das was sie brauchen ändern, erfordert das hohe Reaktionsgeschwindigkeiten, also Agilität.

Der Fruehlix: Ich habe den Scrum-Master besiegt!

Mit erwartbarem Ergebnis.

Dienstag, 27. Oktober 2015

Management was killed by Complexity

Es scheint ja gerade die Zeit der agilen Konferenzen am Rhein zu sein. Neben der Agile Cologne und der kommenden Scrum Deutschland muss wohl auch vor Kurzem die agile Inhouse-Konferenz der Telekom stattgefunden haben, von der auch diese launige Keynote stammt:



Bei allem Amüsement muss ich aber auch ein bisschen Kritik üben: Zum einen ist das Halten eines frontalen Vortrages eher unagil, zum anderen wird hier thematisch lediglich eine "Grundlagen-Einführung" gehalten - das alles sollte eigentlich jedem der sich ein bisschen mit dem Thema beschäftigt schon klar sein. Vielleicht wollte aber auch einfach jemand ein bisschen Geld dafür ausgeben, dass sein Unternehmen als "dummer Mist" bezeichnet wird. Das wäre dann gelungen.

Montag, 26. Oktober 2015

Agile wird in Vergessenheit geraten

Bild: Flickr/Wandering Soul - CC BY 2.0
Zugegeben, ein etwas reisserischer Titel, aber die Essenz meiner Ideen die ich am Wochenende auf der Agile Cologne in eine Session mit dem Dauerbrennerthema Die Zukunft agiler Methoden eingebracht habe. Und falls das angesichts meiner bisherigen Aussagen verwirren sollte kann ich das sogar noch verstärken: Agile wird in Vergessenheit geraten - und das ist eine gute und wünschenswerte Entwicklung.

Um das zu erklären möchte ich Agilität mit zwei anderen, älteren Ansätzen vergleichen, die die Wirtschaft in ähnlicher Art und Weise revolutioniert haben wie die Agilität es gerade tut: mit Standardisierung und Fordismus. Die Standardisierung war eine um 1800 einsetzende Bewegung deren Ziel es war, Maße und Einheiten, aber auch Produkte, so zu vereinheitlichen, dass sie universal anwendbar wurden. Erst durch die Standardisierung wurde es beispielsweise möglich, dass sich Schrauben und Muttern oder Knöpfe und Knopflöcher1 unabhängig voneinander herstellen lassen und trotzdem zueinander passen. Der Fordismus baute etwa 100 Jahre später darauf auf und optimierte (und verbilligte damit) die Fertigung der standardisierten Gegenstände in arbeitsteiligen Fertigungsstrassen, in denen beispielsweise Marmeladengläser erst auf ein Fließband gestellt, dann gefüllt, dann verschlossen und dann verpackt werden. Es ist ersichtlich: ohne die beiden Konzepte der Standardisierung und des Fordismus wären weder Industrielle Revolution noch Konsumgesellschaft möglich gewesen. Unser gesamtes modernes Wirtschaftssystem beruht darauf. Trotzdem kennt kaum noch jemand diese Begriffe.2

Dass diese Ansätze heute nahezu unbekannt sind liegt allerdings nicht daran, dass sie nicht mehr genutzt werden, ganz im Gegenteil. Sie sind nach wie vor allgegenwärtig. Zumindest die (Hardware)produzierende Industrie wäre ohne sie überhaupt nicht vorstellbar. Sie sind sogar derartig selbstverständlich geworden, dass es gar nicht mehr notwendig ist sie zu erwähnen - jeder Mensch erkennt (zumindest implizit) ihre universelle Bedeutung und Berechtigung, ohne dass das noch ausgesprochen werden müsste. Und an der Stelle kommen wir zurück zu Agile: Im Moment ist es noch so, dass agile Methoden von vielen als etwas Neues, Disruptives und Erklärungsbedürftiges angesehen werden. Gleichzeitig werden sie aber im Umfeld komplexer Faktoren immer üblicher, in der IT sind sie mittlerweile sogar der de facto-Standard. Und wie im Fall der Industrieprodukte, bei denen heute ganz selbstverständlich davon ausgegangen wird, dass sie standardisiert sind, wird es mittelfristig so sein, dass man ganz selbstverständlich davon ausgeht, dass Projektmanagement praktisch immer agil ist.

Der Begriff agiles Produktmanagement wird vermutlich bereits der nächsten Generation genauso redundant vorkommen wie standardisiertes Industrieprodukt. Man wird das vorangestellte Adjektiv agil einfach weglassen und es wird in Vergessenheit geraten. Und wie oben gesagt: das ist auch gut so.


1Bzw. Kleidung mit Knopflöchern
2Was man kennt ist die Normung, die aber kein Synonym der Standardisierung ist sondern durch sie erst ermöglicht wurde

Freitag, 23. Oktober 2015

Scrum, Gamification und Seriösität

Bild: Flickr / I am R. - CC BY 2.0

Da morgen die Agile Cologne beginnt geht mir zur Zeit wieder die Session durch den Kopf, die ich bei der letzten Ausgabe gehalten habe: Scrum und Seriösität. Dahinter steht ein Problem das mir auf verschiedenen Projekten begegnet ist, das aber erstaunlich selten thematisiert wird - Scrum wird von Management und Mitarbeitern vieler Unternehmen wegen seines äusseren Erscheinungsbildes als unseriös empfunden und deswegen abgelehnt.

Hintergrund dieses Phänomens ist weniger Scrum selbst (obwohl das in diesem Kontext immer wieder behauptet wird) sondern eher ein Konzept mit dem es häufig eingeführt und umgesetzt wird: die Gamification. Die Idee dahinter ist, dass neue Techniken durch einen eher spielerischen oder wettbewerbsartigen Ansatz besser vermittelt werden können, da Motivation, Engagement und Lernleistung der Beteiligten dann erfahrungsgemäss höher sind. Vor allem einige Praktiken erfreuen sich in agilen Projekten großer Verbreitung:

  • Bei der Lego-Simulation werden Scrum, TDD und weitere Praktiken mit Hilfe von Lego-Steinen erklärt, aus denen das Team in einem simulierten Sprint ein "Produkt" erstellt oder es testet.
  • Beim Estimation Poker wird die Komplexität von User Stories geschätzt indem die Teammitglieder Pokerkarten mit aufgedruckten Nummernwerten hochhalten.
  • Beim Scrum Promptness Game wird das letzte Teammitglied das zu einem Meeting erscheint mit Spielzeugpistolen beschossen, mit Bällen beworfen, o.ä.
  • Beim Standup-Ball wird Durcheinanderreden vermieden indem die Teammitglieder sich gegenseitig einen Ball zuwerfen, der mit der "Sprecherrolle" verbunden ist.
  • In manchen Projekten rotieren bestimmte Rollen wie z.B. der Releasemanager durch das Team, wobei derjenige der sie gerade innehat durch einen auffälligen Hut, ein Plüschtier auf dem Schreibtisch oder Ähnliches sichtbar gemacht wird.

Grundsätzlich erkenne ich zwar den Sinn dieser Vorgehensweisen, in der Realität führen sie aber häufig zu mitunter heftigen Abwehrreaktionen. Viele Mitarbeiter haben das Gefühl, dass ihre Arbeit zu einem "Kinderspiel" reduziert wird und fühlen sich nicht mehr ernstgenommen oder wertgeschätzt, andere sehen den Mehrwert nicht und haben das Gefühl, dass sie ihre Zeit verschwenden. Das Management wiederum bekommt schnell den Eindruck, dass die Teammitglieder für "Ball- und Kartenspielen" bezahlt werden wollen und ist dazu nicht bereit. Auch interne Kontrollabteilungen reagieren schnell allergisch wenn Ausgaben für Pokerspiele, Plüschtiere oder Ähnliches genehmigt werden sollen.

Zum Teil ist diese Ablehnung von Gamification-Elementen ein kulturelles Problem, das seine Ursache darin hat, dass sich amerikanische Konzepte nicht immer Eins zu Eins auf Deutschland übertragen lassen, zum Teil ist es sicher auch so, dass die deutsche Unternehmenskultur tendenziell "Spassfeindlich", bzw. ernsthaft ist. Auch wenn ich bestimmte Spielelemente (wie z.B. das Planning Poker) für sehr sinnvoll halte würde ich aufgrund meiner Erfahrungen mittlerweile empfehlen, sie nur sehr vorsichtig und sehr dosiert einzusetzen, und auch nur dann wenn das Entwicklungsteam sie nicht grundsätzlich ablehnt. Der Schaden ist sonst schnell größer als der Nutzen.

Montag, 19. Oktober 2015

Ein Bild sagt mehr als 1000 Worte (VII)

Ich sage nur: Technischer Fortschritt.
5 MB harddrive being shipped by IBM - 1956.

Freitag, 16. Oktober 2015

How to write a User Story

Eine Zusammenfassung die ich in einem meiner Projekte benutzt habe um Product Owner zu coachen. Natürlich geht sie auf die dortigen Besonderheiten ein, weshalb manche Aspekte besonders betont werden. Bemerkenswert ist aber nicht nur was darin steht, sondern auch was nicht - beispielsweise wird kaum darauf eingegangen wie Stories geschnitten werden. Auch das sagt etwas über dieses Projekt aus.

What is a story about?

  • A Story is a requirement for a small feature that can be implemented within one two-week-sprint.
  • A Story describes a complete, working, testable feature (no separation in frontend/backend).
  • A Story does not describe the current state of the application in detail.
  • A Story does not describe what is planned for future sprints.
  • A Story tells the development team what to implement, not how.

The Structure:

  • A Card of roughly Din A 6-size is what classic User Stories are written on (meanwhile digital tools like Redmine or Jira are common as well).
  • A Title is written on the front side (or in the top field of the digital form).
  • Acceptance Criteria were originally written on the back of the card (in this project we add them in a mandatory field in our digital tool).
  • Additional Information can be written in the description field of the digital tool – the shorter and catchier the better. 
  • And keep in mind – the description is a supplement to the Acceptance Criteria, not the other way round.

The Title:

  • The classic Title format is: As <Role> I want to <Perform Action> so that <I can have a Business Value>. For example: As a User of my company’s intranet I want to upload a profile picture so that the offshore colleagues can see my face.
  • All three parts are important: The Role tells the developers which permissions are required, the Action is the new feature, the Business Value justifies cost and effort of the story. 
  • Of course you can choose another format (for example the FDD-Syntax: <action> the <result>  to <object>. Example: Trigger a signal to confirm readiness) but in that case you should name the role and the business value in the description. 

The Acceptance Criteria:

  • The Criteria define which actions must be executable before the story is considered done
  • The Criteria must be testable: not "Performance must be better", but "Pages must load in less than three seconds". 
  • It is recommended to put them in If-Then-form if possible: If I upload my profile picture and save it, then users who are logged in can see it on my profile page
  • It is best practice to create them together with someone from the QA, because they can give you input about the testability.

The Additional Information:

  • As said above: the shorter and catchier the better. And the description is a supplement to the Acceptance Criteria, not the other way round. 
  • Valuable Information could be: 
    • Preconditions (which Story must be finished before we can start this one?) 
    • Dependencies (which features/teams might be affected when we work on this component?) 
    • Constraints (the new page must be designed according to the company’s CI) 
  • Important: Please name Preconditions, Dependencies or Constraints as such. Otherwise the developers might think they are requirements and try to implement them. 

Feasibility and Size of a story:

  • Only the development team can say if a story is feasible and estimate it’s size. Thinking about feasibility and size without developers included is nothing more than a waste of time, money and brains. 
  • There is a meeting for that, it’s the Backlog Grooming
  • Stories are estimated in complexity, not in days/hours.

And one last thing: the earlier and the more people are involved in the creation of a story, the better the result.

Dienstag, 13. Oktober 2015

No Grooming in England

Bild: Pixabay/Superedd - Lizenz

Dass es Begriffe gibt, die in anderen Sprachen eine andere, mitunter negative Bedeutung haben, ist keine neue Erkenntnis. Auch im Fall von Agile und Scrum ist das nicht völlig auszuschließen, denn wer kann schon wissen, ob nicht z.B. auch im Indonesischen, Arabischen oder Russischen Wörter wie Kanban oder Backlog existieren, die dort aber eine völlig andere Bedeutung haben? Was wirklich überraschend ist, ist aber die Tatsache, dass derartige Missverständnisse ausgerechnet in einer Sprache auftauchen, von der man es am wenigsten erwarten würde - im Englischen.

Scrum ist zwar im englischen Sprachraum entstanden, allerdings nur in einem besonderen Teil davon, in Nordamerika. Die Unterschiede zwischen dem hier gesprochenen Englisch und dem im Rest der Welt gesprochenen sind häufig größer als man denkt und mitunter Ursache peinlicher Missverständnisse. Auch im Bereich des agilen Projektmanagements kann es dazu kommen, wie ich bereits zweimal selbst erleben durfte:

Zum einen geht es um das Wort Scrum selbst. In den USA ist es ein Lehnwort aus einer dort völlig unbekannten Sportart, dessen ursprüngliche Bedeutung in der Alttagssprache eher unbekannt ist. Im britischen Englisch dagegen kennt man nicht nur den Sport (Rugby) sondern auch die ursprüngliche, weitaus ältere Bedeutung des Wortes: Scrum wird zwar im Regelfall mit "Gedränge" übersetzt, der tatsächlichen Bedeutung kämen aber "Tumult" oder "chaotischer Menschenhaufen" näher. Über "Media Scrums" (Gruppen von Reportern, die einen Politiker bedrängen) heisst es zum Beispiel: "The disorganization and pressure of the scrum makes it notorious". Dass viele britische Manager derartige Zustände ungern in ihrem Unternehmen sehen möchten ist nachvollziehbar. Gegebenenfalls hilft es, hier einfach von Agile Software Development zu sprechen.

Ein wesentlich peinlicheres Beispiel ist das Grooming, hinter dem sich zunächst einmal nichts anderes verbirgt als ein Meeting in dem die User Stories der nächsten Sprints durchgesehen und optimiert werden. Dass britische Teammitglieder auf diesen Begriff trotzdem häufig sehr ungehalten reagieren liegt in einer umgangssprachlichen Bedeutung, die so in kaum einem Wörterbuch zu finden ist: Unter Grooming versteht man dort auch das Verführen kleiner Kinder durch pädophile Sexualstraftäter. Da ich die Erfahrung gemacht habe, dass selbst das Ansprechen dieses Themas dem einen oder anderen sehr unangenehm sein kann, würde ich grundsätzlich empfehlen in Teams mit englischen oder schottischen Mitgliedern nicht vom Grooming zu sprechen sondern den unverfänglicheren Begriff des Backlog Refinement zu benutzen.

Mittwoch, 7. Oktober 2015

Brauchbare Illegalität und Agilität

Bild: Pixabay/Foto-Rabe - Lizenz

Zu den in meinem Bekanntenkreis am meisten diskutierten Artikeln der letzten Tage gehört Nützliche Kriminalität aus der letzten Frankfurter Allgemeinen Sonntagszeitung. Die beiden Autoren, Rainer Hank und Georg Meck, versuchen den VW-Abgasskandal von einer neuen Seite zu betrachten und führen ihn auf ein Systemversagen innerhalb des Konzerns zurück. Demnach könnte es so gewesen sein, dass Mitarbeiter gegen die Abgasvorschriften verstießen weil sie glaubten, dem Unternehmen nützlich sein zu können indem sie Abläufe verkürzten und so Geld sparten. Hank und Meck berufen sich dabei ausdrücklich auf Niklas Luhmann, der diese Gedanken vorformuliert haben soll.

Nun fürchte ich, dass die beiden Luhmann entweder missverstanden haben oder dass ihr Artikel von der Redaktion zusammengekürzt wurde, denn in seinem Werk Funktionen und Folgen formaler Organisation ist dieses Phänomen der brauchbaren Illegalität1 etwas weitreichender dargestellt. Es tritt demnach vor allem dort auf, wo die Anweisungen des Managements an die Mitarbeiter in sich so widersprüchlich sind, dass sie gar nicht erfüllt werden können. Da die Nichterfüllung aber mit Strafe verbunden ist, greifen die Mitarbeiter praktisch in Notwehr zu unerlaubten Methoden um die Ziele doch zu erreichen. Da das zumindest auf der Ausführungsebene allgemein bekannt ist, entsteht etwas, was Luhmann die informelle Organisation nennt, praktisch ein Geheimbund, der ein nicht (mehr) funktionsfähiges System durch Regelverstöße und darauf aufbauende (Schein)Erfolge am Leben hält. Genau das könnte bei VW passiert sein.2

Zurück zu meinem Bekanntenkreis. Was dort auf allgemeinen Unglauben gestoßen ist, ist die Möglichkeit, dass das Management tatsächlich in sich widersprüchliche Befehle geben könnte. Warum sollte es das tun, oder bei anderer Auslegung - wie könnte es sein, dass es diese Widersprüchlichkeit selbst nicht bemerkt? Die Antwort darauf liegt wieder bei Luhmann selbst. Er sieht diese Widersprüchlichkeit als Folge des Anpassungsdrucks, den eine sich ständig ändernde Umgebung (z.B. durch neue Umweltvorschriften) auf ein zu Beginn noch funktionierendes System ausübt. Ursprünglich sinnvolle Vorgehensweisen funktionieren plötzlich nicht mehr, was das Management aber nicht nachvollziehen kann (warum soll heute falsch sein was gestern richtig war?). Es erwartet weiterhin, dass die "bewährten" Methoden die gleichen Ergebnisse bringen wie früher und zwingt die Mitarbeiter so in die oben genannten informellen, bzw. illegalen Verhaltensweisen.

Was das alles mit Agilität zu tun hat? Nun, mit ihr kann man die Wahrscheinlichkeit, dass diese Situation überhaupt entsteht, deutlich herabsetzen. Die agilen Methoden gehen in ihren Grundannahmen davon aus, dass sich Umgebungsfaktoren regelmässig ändern und dass man beweglich (agil) darauf reagieren muss wenn man erfolgreich sein will. Ein regelmässiges Inspect and Adapt sorgt deshalb frühzeitig dafür, dass sich Organisationen und Erwartungshaltungen den geänderten Rahmenbedingungen anpassen. Infolgedessen versucht das Management nicht mehr die aktuellen Probleme mit überholten Methoden zu lösen, seine Anweisungen sind nicht mehr (oder zumindest weniger) widersprüchlich und die Mitarbeiter werden nicht mehr in informelle Strukturen und brauchbare Illegalität getrieben.

So hätte es sein können. Aber im Fall VW ist es für derartige Überlegungen wohl zu spät.


1Dass in dem Artikel von Nützlicher Kriminalität und Nützlicher Illegalität die Rede ist, dürfte Folge einer fehlerhaften Rückübersetzung aus dem Englischen sein.
2Gemeint ist damit an dieser Stelle nicht der Gesamtkonzern sondern die für die Abgaswerte zuständige Entwicklungsabteilung.

Montag, 5. Oktober 2015

Der Scroduct Ownster

Bild: Wikimedia Commons / Wilhelm von Kaulbach - Public Domain
Zu den einschneidendsten Änderungen die Scrum in das Projektmanagement gebracht hat gehört die Teilung des bisherigen Projektleiters oder Teamleiters in zwei Positionen, den Scrum Master und den Product Owner. Der Grund für diese Aufteilung war die Erkenntnis, dass die Konzentration aller Verantwortlichkeit auf eine Person sich zu häufig als dysfunktional erwiesen hat, da diese dann zwei sich widersprechende Rollen erfüllen sollte: Zum einen sollte der Projektleiter dafür sorgen, dass die Teammitglieder sich an die Projektmethodik hielten, also an Prince2, PMP, ITIL oder andere. Zum anderen wurde von ihm aber auch erwartet, dass er neue Produkte oder Features möglichst schnell an den Markt brachte, damit mit ihnen Geld verdient werden konnte.

Wenn nun gegen Ende des Projekts oder eines Projektabschnitts ein (scheinbar) fertiges Produkt vorlag, die Methodik aber noch Quality Gates oder Dokumentationen vorsah, entstand ein Intra-Rollen-Konflikt - sollte die Vermarktung des Produktes jetzt warten bis die Prozesse sauber abgeschlossen waren, oder waren die Prozesse verzichtbar wenn der Markt mit schnellem Geld lockte? In der Theorie wurde zwar verlangt eine Lösung zu finden die beide Aspekte berücksichtigte, in der Realität war es aber anders - fast immer entschieden sich die Projektmanager für eine der beiden Seiten, vernachlässigten die andere und fügten dem Projekt und Produkt so Schaden zu. Mal wurden von den Teams möglichst viele neue Produkte und Funktionen in möglichst kurzer Zeit verlangt (Featuritis, bzw. Feature Creep), mal wurde das einmal beschlossene Vorgehen in Beton gegossen und jede Anpassung abgelehnt (Methodismus). Der eine Fall führt zu Bugs in der Produktion, der andere zu verspäteter Auslieferung.

Die Teilung in Scrum Master und Product Owner beseitigt diesen Intra-Rollen-Konflikt: Der Product Owner ist nur dafür verantwortlich die Anforderungen so in das Team zu steuern, dass möglichst viele Features möglichst schnell entstehen können, der Scrum Master sorgt nur für die Einhaltung der vorgegebenen Regeln und damit für Prozessqualität (und höchstens indirekt für Produktqualität). Sollte beides im Widerspruch stehen kann nicht die eine Seite die andere unterdrücken (alleine deshalb nicht weil keiner der beiden dem Team Befehle geben darf), sondern sie müssen sich auf einen gangbaren Mittelweg einigen.1 Leider wird dieser Hintergrund von vielen Managern nicht verstanden, weshalb eine häufige "Effizienzsteigerungsmassnahme" die ist, die Positionen des Scrum Masters und des Product Owners wieder zusammenzulegen. Der damit einhergehende, bzw. zurückkehrende Intra-Rollen-Konflikt ist in einem der großartigen "The wrong way to do agile"-Videos von Atlassian sowohl visuell als auch semantisch passend dargestellt worden: das Ergebnis ist der "Scroduct Ownster", ein kaum noch arbeitsfähiges Mischwesen.


Abschreckend genug ist dieses Bild aber wohl nicht, denn noch immer liest man wieder und wieder Stellenausschreibungen wie diese hier aus der letzten Woche, in der sich der folgende Satz findet:
Es handelt sich bei dieser Position um eine interne Produktmanager-Position (mit einer Zusammenlegung der Rollen Scrum Product Owner und Scrum Master).
Ich wage die Voraussage, dass dieses Projekt relativ schnell im Murks enden wird. Aber das müssen die dort zuständigen Leute dann vor sich selbst verantworten.


1Natürlich könnte man an dieser Stelle aufschreien und klar machen, dass die Scrum-Regeln nie geändert werden dürfen. Das wäre dann aber auch nur wieder Methodismus. Klar ist aber, dass es einen Kernbereich gibt, der vor "Anpassungen" geschützt sein sollte.

Freitag, 2. Oktober 2015

Die bösartige und die gutartige unsichtbare Hand des Projektmanagements

Bild: Michelangelo Buonarroti - Gemeinfrei

Ein Hoch auf die Wissenschaft! In diesem Fall auf drei Herren namens Albert O. Hirschmann, Bent Flyvbjerg und Cass R. Sunstein. Obwohl zu unterschiedlichen Zeiten tätig haben die drei sich um die Erforschung des Projektmanagements verdient gemacht: Hirschmann legte die theoretische Basis, Flyvbjerg und Sunstein fügten die empirische Validierung hinzu.

Den Anfang machte Hirschmann, der in den 60er Jahren das Prinzip der unsichtbaren Hand formulierte. In diesem ging er davon aus, dass große Projekte und Vorhaben von wiederkehrenden Mustern geprägt sind, deren sich die handelnden Personen aber nicht bewusst sind. Durch diese Muster werden die Projekte in immer ähnlicher Weise geleitet, praktisch durch eine unsichtbare Hand. Diese unsichtbare Hand existiert wiederum in zwei Ausformungen - einer bösartigen (malevolent hiding Hand) und einer gutartigen (benevolent hiding Hand). Der ersten, bösartigen Ausformung liegen wiederum zwei Phänomene zugrunde, die gewissermassen die Wurzel des Übels bilden: die Scheinbare Imitation (Pseudo-Imitation) und der Scheinbar umfassende Plan (Pseudo-Comprehensive Program).

Bei der Scheinbaren Imitation handelt es sich zunächst um die Fehlannahme, neue Projekte seien nicht einzigartig sondern im Grunde nur Wiederholungen vergangener Vorhaben. Man müsste also "nur" das Gleiche machen wie immer und alles würde gutgehen. Dass das spätestens ab einem gewissen Komplexitätsgrad nicht mehr funktioniert dürfte jedem klar sein der bereits in größeren Projekten gearbeitet hat. Irgendwann wird offensichtlich, dass das vom letzten Projekt "kopierte" Vorgehen nicht ohne Anpassungen anwendbar ist - und das zweite Phänomen tritt auf: der Scheinbar umfassende Plan. Ihm liegt die Annahme zugrunde, dass es möglich ist alle Fehlerquellen und Störungen zu erkennen und auf einmal zu beseitigen, um von da an bis zum Schluß ohne weitere Planänderungen weiterarbeiten zu können. Auch das wird natürlich durch die Realität widerlegt, denn Unvorhersehbares passiert immer. Im Regelfall folgt darauf ein zweiter scheinbar umfassender Plan, auf den eine weitere Störung, und so weiter. Im Endeffekt steigen Dauer und Kosten durch die ständige Fehlplanung ins Unermessliche.

In Hirschmanns Vorstellung führt diese Führung durch die unsichtbare bösartige Hand aber keineswegs immer zum Schlechteren, den eine zweite wirkt ihr entgegen: die der unsichtbaren gutartigen Hand. Dort wo Pläne fehlschlagen tun sich nämlich Lücken auf, in denen sich die Kreativität aller Beteiligten entfalten kann. Getrieben von der Erkenntnis, dass das bisherige Vorgehen nicht funktioniert wird Neues ausprobiert, Neues erfunden und Altes verworfen. Am Ende steht möglicherweise eine neue Methode die so viel besser ist, dass das Projekt schneller und kostengünstiger fertiggestellt werden kann als ursprünglich geplant. In diesem Zusammenhang kann es sogar von Vorteil sein, dass zu Beginn Risiken ignoriert werden - hätte man sie gekannt, die (noch unentdeckten) Lösungswege aber nicht, wäre das Projekt gar nicht erst begonnen worden.

So viel zu Hirschmann, jetzt zu Flyvbjerg und Sunstein. Das Ziel dieser beiden war die Beantwortung der Frage was denn nun häufiger vorkommt - die bösartige oder die gutartige unsichtbare Hand des Projektmanagements. Zu diesem Zweck wurden über 2000 Großprojekte untersucht, die zwischen 1927 und 2013 in über 100 Ländern auf 6 Kontinenten stattfanden (zur Methodik empfehle ich das Abstract der beiden, der Link ist weiter unten). Die deprimierende Erkenntnis: in 78% der Fälle wurde das Projekt von einer bösartigen Hand geführt, nur in 22% von einer gutartigen. In mehr als drei Viertel der Fälle konnte die freigesetzte Kreativität die Fehlentwicklung durch unrealistische Planungen also nicht kompensieren.

Der Erkenntnisgewinn: den Realitätsgehalt langfristiger Planungen von Anfang an kritisch zu hinterfragen und sie früh und regelmässig anzupassen macht mehr Sinn als darauf zu hoffen, dass ein wundersamer Kreativitätsschub alles retten wird. Keine wirklich bahnbrechende Erkenntnis, aber ab jetzt auch wissenschaftlich fundiert.

---

Bent Flyvbjerg und Cass R. Sunstein

The Principle of the Malevolent Hiding Hand;
or, the Planning Fallacy Writ Large

Oxford/Harvard, September 2015