Dienstag, 31. Januar 2017

Kommentierte Links (XXI)

Grafik: Pixabay / Geralt - Lizenz
  • Steven Levy: The Final Days of Obama’s Tech Surge

    Mein erster Job nach der Universität war in einer Behörde und ich kann mich noch gut daran erinnern wie bürokratisch, hierarchisch, ineffizient und langwierig viele Prozesse dort waren. Die in diesem Artikel von Steven Levy beschriebene Einführung agiler Methoden in der amerikanischen Bundesverwaltung dürfte vermutlich eines der ambitioniertesten Change-Vorhaben gewesen sein die man sich vorstellen kann - und dazu eines mit Erfolg: alleine das vor dem technischen Versagen stehende Obamacare-Programm zu retten ist eine Großtat gewesen. Der Ausblick ist trotzdem finster, denn der neue amerikanische Präsident gilt als eher technik-avers.

  • Mary Poppendieck: The End of Enterprise IT

  • Wenn man nach einem Beispiel für ein agil operierendes Unternehmen sucht und nicht wieder bei Spotify, Google und Netflix landen will bietet sich der Bank- und Versicherungskonzern Internationale Nederlanden Groep (ING) an. Sowohl die Erkenntnis mittlerweile ein im Finanzsektor operierendes IT-Unternehmen geworden zu sein als auch die Bereitschaft sich wie eines zu verhalten sind gleichermassen selten und vorbildlich. Bemerkenswert wird diese Transformation vor dem Hintergrund, dass die ING kein junges Unternehmen ist sondern ein altes - die Firmen aus denen sie hervorging wurden 1845 und 1881 gegründet. Eine lange Geschichte ist also kein Grund dafür, "dass so etwas bei uns nicht geht".

  • Ken Schwaber: Scrum @21

    Man hätte eigentlich erwarten können, dass der Begründer von Scrum anlässlich des 20. Geburtstags seiner Methode den großen Blick zurück wirft. Aus irgendeinem Grund hat er sich das stattdessen für das 21. Jubiläum aufbewahrt, warum auch immer. Ich bin angesichts solcher historischen Ausführungen immer fasziniert wie lange es diese Ideen schon gibt. Ich bin zwar zum Zeitpunkt der ersten öffentlichen Vorstellung von Scrum in den USA gewesen - allerdings auf einem Schüleraustausch. Und ich habe auch schon mit Entwicklern zusammengearbeitet die damals noch nicht einmal geboren waren.

  • Marek Kirejczyk: Hype Driven Development

    Ohne Public Enemy zitieren zu wollen: das bereitwillige Aufspringen auf gerade angesagte Hypes ist riskant und führt schnell zu schwerwiegenden Problemen. Marek Kirejczyk hat das Phänomen des "Hype Driven Development" (HDD) näher betrachtet und eine angepasste Version des Gartner Hype Cycle erstellt um seinen typischen Ablauf darzustellen. Ich fürchte, dass mir HDD schon mehrfach begegnet ist, zu häufig habe ich Entwickler und Manager mit offensichtlicher Wahllosigkeit oder Unkenntnis von Microservices, API Driven Development, Big Data oder anderen Buzzwords reden hören. Am Ende wurde es dann meistens teuer. Ach ja: und auch Agile, Scrum und DevOps können als Hype eingeführt werden. Keine gute Idee.

  • Stefan Wolpers: How to Align Scrum Teams

    Scrum sagt viel über einzelne Teams aus aber wenig bis gar nichts über die Koordination mehrerer Teams. Stefan Wolpers schreibt ein paar gute Ideen dazu auf, dazu einige Antipattern, erste Schritte und Hintergründe. Seiner Schlussthese kann ich aus eigener Erfahrung nur voll zustimmen: eine Koordination von Scrum Teams kann nur erfolgen wenn es sich um autonome Feature-Teams handelt. Alles weitere endet in einer Verschwendung von Geld, Ressourcen und Zeit.

Donnerstag, 26. Januar 2017

Code Ownership (III)

Bild: Pexels/Markus Spiske - Lizenz
Was hatten wir bereits? Erstens: Code Ownership ist schlecht. Und zweitens: Code Ownership kann auch versehentlich entstehen. Was bleibt noch? Vieles, an dieser Stelle aber zunächst ein weiterer Fall - Code Ownership durch eine Gruppe, beispielsweise durch ein Entwicklungsteam. Auch das ist ein Antipattern, wenn auch ein weniger offensichtliches (und natürlich eines das nur da ein Thema ist, wo es mehr als ein Team gibt).

Zunächst einmal ist der Bus-Faktor relativ gering, da nicht ein Entwickler das "Wissensmonopol" auf einen Code-Abschnitt besitzt sondern mehrere. Wenn also der Fall eintritt, dass ein Team-Mitglied von einem Bus angefahren wird und ausfällt können die anderen einspringen. Das offensichtlichste Risiko von Code Ownership ist demnach nicht gegeben. Warum soll dieser Fall dann trotzdem problematisch sein? Aus den folgenden Gründen:

Auch Gruppen-Code Ownership erzeugt immer einen Flaschenhals. Wenn beispielsweise nur eines von vier Teams an der Entwicklung des CRM-Teils einer Anwendung beteiligt war, dann tritt ein Problem auf wenn z.B. gegen Ende eines Projekts nur noch CRM-Funktionen zu entwickeln sind. Die anderen Teams müssen sich in diesem Fall neu in diesen Bereich einarbeiten, was Zeit und Geld kostet. Umgekehrt ist das CRM-Team nur eingeschränkt in der Lage einzuspringen wenn etwa das Search-Team von einer Grippewelle ausser Gefecht gesetzt wird.

Gruppen-Code Ownership erzeugt oft eine suboptimale Architektur. Bleiben wir beim Beispiel des CRM-Teams. Mit großer Wahrscheinlichkeit wird es (bewusst oder unbewusst) alle die Kunden betreffenden Funktionen im eigenen Teil der Anwendung einbauen, selbst wenn sie eigentlich im User Management oder im Checkout mehr Sinn gemacht hätten. Mögliche Gründe dafür sind, dass man nicht auf eine Zulieferung des anderen Teams warten will oder dass man schlicht nicht weiss, dass diese Funktion an anderer Stelle mehr Sinn machen würde (durch die Code Ownership ist diese andere Stelle einfach nicht bekannt).

Eine weitere häufige Folge von Gruppen-Code Ownership ist eine schlechte Absicherung der Gesamtanwendung durch Tests. Den eigenen Bereich abzusichern und stabil zu halten ist im eigenen Interesse, aber übergreifende System- oder End to End-Tests? Wer nur für einen Teil des Ganzen zuständig ist wird die Zuständigkeit dafür nicht zwingend bei sich sehen und selbst wenn doch - die fehlende Kenntnis der restlichen Anwendung wird es schwer machen zu erkennen wo Bedarf besteht und wo nicht.

Eine globale Shared Code Ownership, also gemeinsame Zuständigkeit und Weiterentwicklung aller Anwendungsteile durch alle Entwickler, kann diesen Fehlentwicklungen entgegenwirken. Natürlich erfordert das ein höheres Mass an Verantwortungsbewusstsein und Kommunikation, allerdings ist das angesichts des Gewinns an Qualität und Stabilität ein vertretbarer Preis.

Montag, 23. Januar 2017

Pair Programming

Bild: Flickr/WOCinTech ChatCC BY 2.0
Eine der Techniken die ich häufig empfehle ist das Pair Programming. Es sitzt nicht mehr ein Entwickler vor einem Rechner sondern zwei, die gemeinsam am Code arbeiten. Auf den ersten Blick erscheint das vielen Managern und Programmierern widersinnig, sie befürchten, dass die Teams dadurch weniger produktiv werden. Tatsächlich ist es auch so, dass Umsetzung zunächst länger zu dauern scheint, allerdings wird das durch andere Faktoren mehr als ausgeglichen:
  • Pair Programming sorgt dafür, dass zum frühestmöglichen Zeitpunkt eine Qualitätssicherung stattfindet. Viele Fehler können direkt bei der Entstehung entdeckt und beseitigt werden, statt in nachgelagerten Bugfixing-Phasen.
  • Der entstehende Code hat meistens eine hohe Qualität, da die Erfahrungen von mehreren Personen in ihn einfließen und nicht nur von einer.
  • Dadurch dass sie durchgehend erklären was sie tun und warum verbessern die Beteiligten ihre kommunikativen Fähigkeiten.
  • Es wird ein permanenter Wissenstransfer gefördert, der dadurch verstärkt wird, dass nicht bloss Theorie vermittelt wird sondern das Gelernte direkt in der Praxis Anwendung findet.
Je nach Betrachtung kommen noch weitere Faktoren dazu, die aber nicht unumstritten sind, z.B. dass Pair Programming mehr Spass macht, einen stabileren Arbeitsrhythmus erzeugt oder zu mehr Disziplin führt.

Herausgreifen würde ich speziell die Dimension des "Spass habens", da sie essentiell wichtig ist. Wenn Entwickler Pair Programming als belastend empfinden wird es sich nicht durchsetzen, wenn sie ihm neutral oder ambivalent gegenüberstehen besteht das Risiko, dass es mit der Zeit einschläft. Nur wenn sie diese Tätigkeit gerne durchführen kann man sicher sein, dass sie regelmässig stattfindet. Aus diesem Grund macht es Sinn Rahmenbedingungen zu schaffen, die diese Arbeitsweise möglichst angenehm machen. Dazu gehören z.B. passende Arbeitsplätze mit großen Tischen und Bildschirmen und separate Räume in denen man sich unterhalten kann ohne andere Leute zu stören. Genauso wichtig ist aber eine Einigung auf bestimmte Abläufe:
  • Es sollte nach Möglichkeit nicht zu einer Aufteilung in "Vorführer" und "Zuschauer" kommen. Diese Konstellation führt zu oft dazu, dass der Zuschauer schnell das Interesse verliert und der Vorführer kein Feedback erhält.
  • Wesentlich besser funktioniert die Aufteilung in "Navigator" (schlägt die jeweils nächsten Arbeitsschritte vor) und "Driver" (gibt Feedback und setzt um). Durch diese Arbeitsteilung wird verhindert, dass einer der Beteiligten inaktiv wird.
  • Um beiden Beteiligten die Möglichkeit zu geben beide Rollen auszuführen sollte gegelmässig getauscht werden (von alle 10 Minuten bis einmal pro Tag habe ich schon alles gesehen).
  • Zumindest in der Anfangsphase macht ausserdem ein Timeboxing Sinn, da diese sehr intensive Art der Zusammenarbeit sonst schnell überfordernd wirken kann.
Selbst wenn Pair Programming sich zu Beginn komisch anfühlt - auf Dauer ist es ein guter Weg zu höherer Qualität und früherer Qualitätssicherung, der daher jedem Team zu empfehlen ist.

Donnerstag, 19. Januar 2017

Was gehört in einen Sprint 0?

Bild: Pxhere/Matt Lee - CC0 1.0
Vor den ersten "echten Sprint" (einen in dem Software entwickelt wird) einen vorbereitenden "Sprint 0" zu setzen ist in vielen Scrum Teams üblich. Häufig werden hier allerdings Tätigkeiten durchgeführt die nicht so wirklich zu Scrum passen: die nächsten Sprints werden detailliert durchgeplant, Teile der Entwicklung (z.B. Teile des Backends) werden vorweggenommen oder alle User Stories werden bereits in Unteraufgaben geteilt. Alles Dinge die das Inspect & Adapt zu sehr einschränken würden. Ich empfehle eine Konzentration auf andere Dinge:

Onboarding:

Diese klassischen Anfangs-Tätigkeiten fallen in jeder Methode an: Beschaffung und Verteilung von Schlüsselkarten, Zugangsberechtigungen, Nutzeraccounts, Hardware, Arbeitsplätzen, Schrankfächern und dergleichen mehr.

Knowledge Transfer:

Wer kennt die bestehenden Anwendungen besonders gut, wer ist Experte für welche Programmier-Sprache, wie bedient man Wikis und Ticketsysteme, welche Tricks gibt es beim Einrichten der Zugänge und nicht zuletzt: welche Gerichte sollte man in der Kantine essen und welche nicht.

Besuche beim Kunden/Benutzer:

Da man Anwendungen nicht für sich selber baut sondern für diejenigen die sie später anwenden sollen ist ein Besuch bei denen sehr zu empfehlen. Haben sie wirklich die Wünsche und Bedürfnisse die von den Business Analysten und Requirement Engineers unterstellt wurden? Das ist nicht immer der Fall.

Produktvision formulieren:

Welches Problem lösen wir mit unserem Produkt, welchen Bedarf befriedigen wir oder welchen neuen Markt wollen wir mit ihm erschaffen? Nur wer das weiß kann auf ein Ziel hinarbeiten ohne sich auf halbem Weg in einem Gemischtwarenladen unnötiger Features zu verlieren.

Backlog Refinements:

Gerade zu Beginn sind Anforderungen oft in einem noch nicht umsetzbaren Zustand. Zu groß, zu unklar, zu detailliert, zu mehrdeutig, etc. Um nicht im Planning von Sprint 1 in Probleme zu laufen macht es Sinn bereits Vorarbeiten zu leisten.

Architektur/Teststrategie/Entwicklungsstandards/etc.

Ein großer Unterschied zum klassischen Vorgehen. Diese Dinge sollen nicht komplett im voraus festgelegt werden, im Gegenteil. Sie müssen so schlank und flexibel gestaltet werden, dass sie im Zweifel den Bedürfnissen angepasst werden können.

Technische Infrastruktur:

Von den Staging-Umgebungen über die Build Pipeline bis hin zu den Testautomatisierungs- und Monitoring-Tools gibt es einiges an technischen Voraussetzungen die in Scrum zwingend nötig sind, so dass sie schon von Beginn an bereitgestellt werden müssen.

Workshops zu Methoden und Techniken:

Scrum, Kanban, XP, TDD, Micoservices und was es sonst noch gibt - dort wo die Teammitglieder es noch nicht kennen sollte es vermittelt werden. Und selbst wenn alle es bereits kennen macht das Sinn, denn häufig verstehen verschiedene Menschen etwas völlig Unterschiedliches unter den selben Begriffen.

Last but not least: Teamevents:

Auch das Socializing sollte nicht unter den Tisch fallen. Das kann vom gemeinsamen Mittagessen bis zum mehrtägigen Hackathon alles Mögliche bedeuten, wichtig ist, dass die Teammitglieder sich kennen und schätzen lernen. Das ist die Grundlage für vieles weitere.

Montag, 16. Januar 2017

Design Sprints in Agile und Scrum

Ich gestehe, ich bin im Moment zu faul um etwas zu schreiben, stattdessen mal wieder ein Video, diesesmal zum Thema Design Sprints.



Einen Hinweis gebe ich aber noch mit: wer glaubt, dass in einem Designsprint der Inhalt des folgenden Entwicklungssprints vorbereitet wird, der hat das Konzept nicht verstanden.

Donnerstag, 12. Januar 2017

How to split a User Story

Bild: Wikimedia Commons/Evan Amos - CC0 1.0
Das Kleinschneiden von Anforderungen in User Stories die innerhalb eines Sprints umgesetzt werden können kann sehr erklärbedürftig sein. Selbst erfahrene Product Owner kommen immer wieder an eine Stelle an der sie Schwierigkeiten bekommen. Für die von mir gecoachten POs habe ich irgendwann begonnen eine Übersicht zu erstellen nach welchen Kriterien man das Messer ansetzen kann. Sie ist sicher noch nicht vollständig, hat aber einigen Teams weiterhelfen können.

Nach MVP-Kriterien
Vor allem dort sinnvoll wo schnelle vorzeigbare Ergebnisse nötig sind. Die Story sollte die kleinstmögliche nutzbare Funktionalität ergeben, selbst wenn sie noch "aufgehübscht" werden muss. Das passiert dann in späteren Stories.

Nach Arbeitsschritten
Der Klassiker. Ich möchte mich einloggen. Ich möchte eine personalisierte Willkommensseite sehen. Ich möchte eine neue Seite anlegen, etc. Jeder Schritt kann eine eigene User Story sein.

Nach Happy-/Unhappy Path
Darauf kommen erstaunlich wenige. Happy Path: Ich möchte mein Geburtsdatum eingeben können. Unhappy Path: Ich möchte eine Fehlermeldung angezeigt bekommen wenn ich in dieses Feld Buchstaben eingebe. Das kann man sehr gut separat umsetzen.

Nach GUI-Elementen
Im oberen Seitendrittel möchte ich meinen Benutzernamen und mein Profilbild sehen. Im mittleren Seitendrittel möchte ich Statusmeldungen eingeben und sehen können. Im unteren Seitendrittel möchte ich eine Liste meiner älteren Statusmeldungen sehen.

Nach Benutzer-Rollen
Zu Beginn gibt es bei diesem Vorgehen nur eine Rolle: den Administrator, der alles sehen und machen kann. Mit den weiteren Rollen werden nach und nach Beschränkungen eingeführt: Redakteur, Auditor, Gast, etc.

Nach Datei-/Daten-Typen
Macht z.B. Sinn wenn verschiedene Dateitypen importierbar und lesbar sein müssen: Erst CSV, dann XLSX, dann Word, dann PDF, dann PPT.

Nach Datenquellen/Schnittstellen
Wenn verschiedene andere Systeme angeschlossen werden müssen, z.B. die der Fabrik, der Marketing-Abteilung, der Tochtergesellschaft und des Lieferanten.

Nach Performance-Bedürfnissen
Schon etwas technischer. Zu Beginn kann man etwa eine Abfrage über die gesamte (noch kleine) Datenbank laufen lassen, später mit Verschlagwortung oder mehr Rechenleistung die Verarbeitung größerer Datenmengen sicherstellen.

Nach "Low hanging Fruits"
Wenn Teile der Anforderungen komplex oder unklar sind kann man sich auf die anderen konzentrieren. Dadurch gewinnt man die Zeit um die schwierigeren Bereiche zu analysieren und zu verstehen (siehe unten: Spike).

Nach Testszenarien
Auch hierauf kommt nicht jeder. Wenn Anforderungen einen hohen Testaufwand mit sich bringen kann man auch den reduzieren indem man kleinere Stories schneidet. Möglichkeiten wären etwa der Login-Status oder Datumskonstellationen.

Nach Endgeräten
Ich erinnere mich an ein Projekt in dem die Anwendung immer zuerst für das iPad des Projektleiters optimiert wurde. Je nach Gerät/Betriebssystem (Apple, Android, Windows, Kindle, Tolino) können andere Anpassungen nötig sein.

Nach Browsern
Ähnlich wie der letzte Ansatz. Eine klassische Reihenfolge wäre Safari, Chrome, Firefox, Edge, IE10, IE9, IE8, IE7. Masochisten können auch bis auf den IE6 runtergehen.

Der Sonderfall: Spike
Eine Forschungsaufgabe um schlecht geschriebene und/oder dokumentierte Software zu verstehen. Sollte nur sparsam und timeboxed eingesetzt werden, da es sonst schnell ausufern kann.

Wie oben gesagt: es gibt bestimmt noch viele weitere Möglichkeiten. Ein Großteil dürfte aber durch diese Liste abgedeckt sein.

Montag, 9. Januar 2017

Die agile Transition eines Teams in Richtung Scrum

Bild: Publicdomainpictures/Hefzul Bari - CC0 1.0
Im Moment bin ich für verschiedene Firmen als Agile Coach tätig, was unter anderem bedeutet, dass ich Teams die noch nie agil gearbeitet haben die damit verbundenen Arbeitsweisen und Werte vermittle (im Normalfall führen wir Scrum ein). Häufig ist die Zeit die ich mit einem Team verbringe von Anfang an zeitlich beschränkt, was im Regelfall mit der Budgetierung zu tun hat. Aufbauend darauf habe ich überlegt: wie lange sollte ein Coach bei einem Team bleiben und was sollte in dieser Zeit passieren? Basierend auf meinen Erfahrungen habe ich ein Phasenmodell entwickelt, das im Einzelfall natürlich häufig angepasst werden muss, das aber eine gute Idee davon vermittelt was wann zu tun ist.

Erste Phase: Initiieren (ca 3 bis 4 Wochen)

Diese Phase umfasst die Sprints 0 und 1. Im Sprint 0 finden neben dem normalen Onboarding die Kickoff-Workshops zu Methode und Produktvision statt, ausserdem nach Möglichkeit ein erstes Backlog Refinement. In Sprint 1 (ich empfehle zweiwöchige Sprints) gibt es die erste Hands on-Erfahrung, dazu erfahrungsgemäss einen hohen Diskussions- und Erklärbedarf. Der Coach sollte deshalb vier oder fünf Tage die Woche vor Ort sein.

Zweite Phase: Stabilisieren (ca 6 bis 8 Wochen)

Der Name sagt es, es geht um Stabilisierung - aber was heisst das? Zunächst, dass die Meetings und Rollen verinnerlicht werden, aber auch, dass verhindert werden muss, dass sich bewusst oder unbewusst Antipattern einschleichen. Das können Command & Control oder Konzern-Anarchismus sein, fast noch schwerwiegender sind aber mit bestem Willen durchgeführte Verschlimmbesserungen (Harikiri), wie z.B. separate Entwicklungs- und Testsprints. Der Coach sollte in dieser Phase drei oder vier Tage die Woche vor Ort sein, gegen Ende vielleicht weniger.

Dritte Phase: Experimentieren (ca 4 bis 6 Wochen)

Routinen können gut sein, Erstarrung ist schlecht. Um sich ständig zu verbessern sollte jedes Team regelmässig Experimente durchführen: ein Ziel setzen, definieren wie der Erfolg gemessen oder überprüft wird, Zeitraum festlegen, durchführen. Klingt einfach, ist aber schwer und sollte daher begleitet werden. Einerseits um Frustration zu vermeiden, andererseits um Klarheit zu haben was verändert werden kann (z.B. Länge der Sprints) und was nicht (z.B. die Rollen). Der Coach sollte ein bis zwei Tage die Woche vor Ort sein, u.a. abhängig davon wie schnell der Scrum Master in seine Rolle hineingewachsen ist.

Wie oben gesagt: ich empfehle zweiwöchige Sprints, dieses Konzept basiert darauf. Und für alle Controller die auf der Suche nach Einsparpotential sind: das hier ist kein Luxuspaket sondern eine Grundbetreuung. Wer daran spart macht nichts billiger sondern einiges teurer, denn selbst wenn die Kosten für den Coach wegfallen - an anderer Stelle wird das durch Irrtümer, Fehler und verlangsamtes Lernen mehr als ausgeglichen. 

Freitag, 6. Januar 2017

Die Schmerzen des Übergangs

Mir fällt da nur eine Beschreibung ein: wortgewaltig.

Dienstag, 3. Januar 2017

Truthiness

Bild: Flickr / Daniel Lobo - CC BY 2.0
Mein im letzten Monat geschriebener Artikel zu den Wasserfall-Populisten hat es geschafft auch in meinem realen Leben zu einem größeren Gesprächsthema zu werden. Vor allem an der Behauptung, dass in der Wirtschaft Entscheidungen auf der Basis von Populismus getroffen würden, haben einige meiner Bekannten Anstoss genommen. Gerade dort wo es um (viel) Geld geht wäre es doch genau umgekehrt, da würden nur die harten Fakten zählen: Zeit, Kosten, Ertrag. Wer da nicht mit überprüfbaren Argumenten kommen würde, der würde sich selbst diskreditieren. Nun ja, es wäre schön wenn es so wäre. Um zu erklären warum das nicht so ist möchte ich einmal mehr einen Begriff aus der Politik einführen.

Passend zur Wahl von "postfaktisch" zum Wort des Jahres 2016 hat ein weiteres Wort ein rundes Jubiläum gefeiert: 2006 war "Truthiness" in Amerika das Wort des Jahres, ein Begriff mit einem sehr ähnlichen Inhalt. Laut Definition bedeutet er:
Truth coming from the gut, not books; preferring to believe what you wish to believe, rather than what is known to be true.
So gesehen die Grundlage auf der die Postfaktizität beruht - da sich eine Aussage gut anfühlt wird sie als wahr betrachtet, unabhängig davon ob sie sich durch Fakten belegen lässt oder nicht. Nochmal ein Vergleich mit der Politik: was in den letzten zehn Jahren zu beobachten war - sowohl von extremen Parteien als auch vom politischen Mainstream sind Truthiness-Aussagen benutzt worden um Wähler zu gewinnen. "Die Ausländer nehmen uns die Arbeitsplätze weg", "Mehr Überwachung führt zu mehr Sicherheit", "Umverteilung von Einkommen führt zu sozialer Gerechtigkeit", etc. Gegen diese Narrative zu argumentieren ist schwierig, da viele Menschen einen verhängnisvollen Fehlschluss begehen: für sie fühlen sich diese "Wahrhaftigkeiten" so selbstverständlich richtig an, dass es gar nicht nötig ist sie zu validieren. Umgekehrt können alle widersprechenden Zahlen und Aussagen nur falsch sein, da es gar nicht möglich ist etwas zu widerlegen was so offensichtlich richtig ist.

Zurück in die Wirtschaft. Auch hier kann man immer wieder (Projekt)Manager antreffen, die mit größter Selbstverständlichkeit Truthiness-Aussagen von sich geben: "Bei großen und komplexen Aufgaben muss man mehr und detaillierter planen, damit alles funktioniert", "Wenn alle von Anfang an ordentliche Arbeit machen gibt es keine Bugs", "Eine Methode die seit 20 Jahren eingesetzt wird kann nicht auf einmal ungeeignet sein" und dergleichen mehr. Keine einzige dieser Aussagen würde einer empirischen Validierung standhalten, aber ungeachtet dessen klingen sie zunächst einmal so naheliegend, dass sie von vielen Menschen einfach so hingenommen werden. Und weil sie derartig gut klingen wird auch hier zu oft darauf verzichtet, sie mit Zahlen belegen zu lassen.

Was kann man an dieser Stelle tun? Im Grunde nur eines: die Zahlen trotzdem liefern. In den meisten Fällen ist das ohne großen Aufwand möglich, mitunter reicht sogar nur eine einzige Frage ("Wenn Ihr sagt, dass Detailplanung der beste Weg ist - wie viele Projekte habt Ihr denn damit in time und in budget beenden können?"). Manchmal führt das relativ schnell dazu, dass die scheinbaren Wahrheiten sich als falsch herausstellen, manchmal kann es auch Wochen oder Monate dauern. Wenn der Punkt des Erkenntnisgewinns dann erreicht ist bleibt "nur noch" eines zu tun: sich von den Truthiness-Wahrheiten zu verabschieden, ohne dass ihre Vertreter einen Gesichtsverlust erleiden. Nochmal ein Thema für sich.