Wider den Kompliziertismus!

Die Welt ist ein ungeheuer komplexer Ort.

Alle Dinge interagieren ständig aufgrund physikalischer, chemischer und evolutionärer Gesetze miteinander.
Die Interaktion zwischen Menschen ist mit enormen Komplexitäten behaftet.

Zwischen Menschen aus unterschiedlichen Kulturen, Ländern, Städten, manchmal sogar Stadtteilen und ganz sicher aus unterschiedlichen sozialen Herkünften gibt es enorme Unterschiede.Jeder Mensch ist anders. Jeder Mensch hat zeitabhängige Stimmungen.

Die Systeme, die wir in IT-Projekten bauen, sind manchmal ganz einfach. Als Modelle der physisch-technischen, sozialen oder kulturellen Wirklichkeit aber oft sehr, sehr komplex.

Schon kleinste Abweichungen im Verständnis oder der Definition eines Begriffs können weitreichende Folgen in der Systemmodellierung haben. Beispiel: Die Modellierung der Ehe in einem IT-System: Nur zwischen Mann und Frau? Zwischen gleichgeschlechtlichen Partnern? Jeweils wie vielen Personen welchen Geschlechts? In welchem Mindestalter? Was sind die damit verbundenen Rechtsgüter? Was, wenn die Ehe im Ausland geschlossen wurde, wo andere Regeln gelten? Welchen Einfluss haben gemeinsame voreheliche oder aus früheren Partnerschaften stammende Kinder? Spielt die kirchliche Trauung irgendeine Rolle?

Die Welt ist komplex, keine Frage.

Was ist die angemessene Reaktion darauf?

Einige Menschen blähen ihre Einschätzung jedweder Aufgabe grundsätzlich und systematisch auf. Komplex ist für sie das Gleiche wie kompliziert. Sie vermuten und berücksichtigen vorauseilend schon einmal alle denkbaren (und im Zweifel auch nicht denkbare) technischen, organisatorischen und fachlichen Komplikationen – und schlagen am Ende noch einen Risikoaufschlag drauf.
Wenn ein Satz in einer Anforderung komplizierter oder weniger kompliziert interpretiert werden kann, wählen sie immer die kompliziertere Interpretation. Sie wählen die kompliziertesten Architekturen und Implementierungsmuster, betreiben furchtlos das Aufhäufen technischer Schuld. Aufwands- und Preisabschätzungen treiben sie per Hau-den-Lukas in die Höhe, bis die Glocke klingelt.
Provokant formuliert: Komplexität wird zur Ideologie der Kompliziertheit, zum Kompliziertismus. Alles ist irre kompliziert und kaum beherrschbar, lasst es uns noch komplizierter machen.

Warum macht jemand das? Angst, die Aufgabe zu unterschätzen. Frühere schlechte Erfahrung. Überforderung, durch die ein paar Bäume wie ein großer, dunkler Wald aussehen. Viel Feind, viel Ehr. Geldschinderei gegenüber dem Kunden. Ressourcenschinderei gegenüber dem eigenen Chef. Vorauseilende Begründung für das eigene Versagen (“ich hab ja gleich gesagt, dass das irre komplizert ist”). Aufblähen der eigenen Wichtigkeit und demonstratives Zur-Schau-Stellen kritischen Denkens.

Einfachste oder zumindest in der Regel gut beherrschte Dinge werden so mühelos zu kaum überwindbaren Hürden, zu Sorgen, zu Angstbergen, zu Problemen.

Ich bin sehr erfolgreich mit dem gegenteiligen Ansatz. Ich glaube, dass es die Aufgabe von Projektleitern, Architekten und Beratern ist, die jeweils eleganteste und damit oft einfachste Lösung zu finden.

Ich gehe dabei oft zunächst von der naivstmöglichen Annahme aus. Wie würde die einfachste Lösung aussehen?
Natürlich bleibt die Lösung dann meist nicht so einfach. Ich schaue dann, welche zusätzliche Komplexität ich unbedingt berücksichtigen muss. So wird die Lösung Schritt für Schritt komplexer, aber in einer sehr kontrollierten Weise und nur auf Basis von verifizierten Annahmen.

Jederzeit beachte ich Vereinfachungsmöglichkeiten: Welche Anforderungen sind ähnlich und können generisch behandelt werden? Wo bestehen Anforderungen nur noch aus historischen Gründen, die heute eigentlich keine Bedeutung mehr haben?
Wo kommt die Anforderung überhaupt her? Wenn es niemanden mehr gibt, der weiß, warum es eine Anforderung gibt, ist sie vielleicht obsolet.

Oder als Scum Master/Agile Coach: Muss der Prozess wirklich so aufwändig sein? Muss wirklich eine monatelange Tool-Auswahl gemacht werden oder weiß das Team eh schon, welches der Sieger sein wird? Braucht es eine Earned-Value-Analyse oder reicht ein einfaches Burndown?Braucht es wirklich ein Zehn-Mann-Team oder wird nicht alles viel einfacher, wenn man zwei Fünf-Mann-Teams bildet? Hat das Sprint Commitment für dieses Team wirklich einen Mehrwert oder performt es auch ohne optimal?
Muss wirklich in Story Points geschätzt werden oder reichen Personentage?

Das Ziel: Die ohnehin schon komplexe Welt nicht ohne Not kompliziert machen.

 

Tabu: Probleme anderer Leute

Ich behaupte, dass es einer der größten Problemauslöser in Projekten und tatsächlich auch im sonstigen Leben ist, anderer Leute Probleme zu lösen.
Glauben Sie nicht? Ein paar Beispiele:

In erstaunlich vielen Festpreis-Projekten wird die Spezifikation erst nach der Beauftragung des Dienstleisters fertiggestellt. Mein Lieblingsbeispiel ist ein Projekt vor einigen Jahren, bei dem ich für einen Teil des Projekts selbst eine sehr vage Wildcard (“muss alles können, was das heutige System auch kann”) in die Leistungsbeschreibung schrieb. Die guten Absichten dahinter: Das Team soll wegen der knappen Deadline schon mal anfangen zu arbeiten. Der Dienstleister will den Auftrag haben und deshalb dem Kunden entgegen kommen. Effekt: Der Abschluss der Spezifikation verzögert sich, weil der Kunde sieht, dass es ja trotzdem vorangeht. Entwickelt das Team etwas, das er gar nicht haben wollte, kann er immer noch sagen: das war gar nicht so spezifiziert. Vielleicht entwickelt das Team auch eine hypergenerische eierlegende Wollmilchsau, um jeder potentiellen Anforderung des Kunden entsprechen zu können – wenn sie denn irgendwann kommt. Gleichzeitig streitet der Auftragnehmer um jede “neue” Anforderung, um im Budget bleiben zu können, oder er verlangt immer wieder Budgeterhöhungen. Enorme Reibungsverluste sind die Folge.

Das Projektteam hat versucht, das Problem des Kunden zu lösen, die Spezifikation nicht vor Projektbeginn fertigzustellen.

Der Freiberufler beginnt mit der Arbeit, obwohl er noch keinen Vertrag hat (“Vertrag ist irgendwo im Einkauf unterwegs. Machen Sie sich keine Sorgen.”). Effekt: Der Vertragsabschluss zieht sich, und die Verhandlungsposition der Freiberuflers über die Bedingungen des Auftrags wird schwächer und schwächer. Im Extremfall heißt es dann am Ende: “Ihre Rechnung zahle ich nicht, wir hatten doch noch gar keinen Vertrag!” Der Freiberufler muss vor Gericht ziehen und wird ggf. nur ein “marktübliches” Honorar aufgrund der offensichtlich erbrachten und vom Auftraggeber nicht gestoppten Leistung nachfordern können, das deutlich unter dem angestrebten liegt.

Der Freiberufler hat das Problem des Auftraggeber zu lösen versucht, die eigenen Prozesse nicht im Griff zu haben oder die Beauftragung nicht rechtzeitig angestoßen zu haben.

Das andere Teilteam sollte eine Schnittstelle zum Import von Daten liefern. Sie wird nicht rechtzeitig fertig. Das konsumierende Teilteam programmiert also erstmal gegen einen Mock. Die Schnittstelle ist immer noch nicht fertig. Das Team programmiert die Schnittstelle heroisch selbst, erreicht dafür aber nicht die eigenen Ziele.

Die gelieferte Datenqualität ist grauenvoll. Weil der Zulieferer der Daten so schwer greifbar ist, entwickelt das Team über Wochen einen Bereinigungsalgorithmus und hochflexible Darstellungsmechanismen.

Ein Team-Mitglied performt einfach nicht, aus welchen Gründen auch immer. Die restlichen Team-Mitglieder wollen keine Kollegenschweine sein, decken den Minderleister und arbeiten selbst eine Stunde mehr am Tag, erst über Tage, dann Wochen, dann Monate.

Die Deadline für das neue Projekt ist viel zu eng gesetzt, das Verkaufsteam sagt dem Auftraggeber trotzdem zu, die Entwickler beginnen einen “Todesmarsch” mit zehn Stunden Arbeit täglich und Wochenendarbeit, oft in dem Wissen, dass die Aufgabe dennoch nicht zu schaffen ist.

Das Management schafft es einfach nicht, auch nur grundlegende Vorgaben zur Arbeitsweise, Qualitätsanforderungen und Zielen der Software-Entwicklung zu machen. Die Teams organisieren selbständig Workshops und Seminare, um das Führungsdefizit auszugleichen. Effekt: Ein Glaubenskrieg zwischen den Teams und am Ende innerhalb der Teams geht los, ob Scrum oder Kanban, Merging oder Baselining, sind Senior-Software-Ingenieure mehr verantwortlich für ein Team-Ergebnis als “normale” Ingenieure, Cloud oder nicht… und viel Zeit und Motivation gehen verloren.

Das Management lässt die Teams in hallende Großraumbüros mit zu wenig Besprechungsräumen ziehen. Niemand kommt mehr in den Flow, die Arbeitsleistung sinkt um 50-75%. Die Entwickler behelfen sich mit Noise-Cancelling-Kopfhörern oder kommen besonders früh oder bleiben besonders spät, weil es da ruhiger ist. In den regulären Arbeitszeiten wird entweder kaum noch miteinander gesprochen, weil es ja alle stört, oder es schert sich niemand mehr um den Krach, denn es erwartet ja eh niemand mehr hohe Leistungen.

Der Abteilungsleiter trifft einfach keine Entscheidungen. Die Mitarbeiter entwickeln telephatische Kräfte um herauszufinden, was der Chef denn wohl wollen können würde und arbeiten unter Annahmen. Der Chef staucht die Mitarbeiter im Problemfall zusammen (“Das habe ich nie so entschieden!”) und streicht im Erfolgsfall die Lorbeeren ein.

Fallen Ihnen mehr Beispiele ein?

Mein Tipp: Lösen Sie nicht anderer Leute Probleme bzw. nehmen sie nicht anderen ihre Verantwortung ab. Weisen Sie den Verantwortlichen auf sein Problem hin und bieten sie die Hilfe an, die Sie im Rahmen Ihrer Fähigkeiten, Möglichkeiten und der eigenen Verantwortung leisten können.

 

Binsenweisheiten und Ewige Wahrheiten (Teil 1)

Zu meinem Posting “Binsenweisheiten – It’s simple, but not easy!” kam mir der Gedanke, dass es interessant wäre, reale oder vermeintliche Binsenweisheiten einmal aufzulisten, weitere von den Lesern dieses Blogs zu sammeln und zu diskutieren, wie “binsig” oder “ewig” sie denn nun wirklich sind.

Hier ist also meine absichtlich provokativ unvollständige Liste. Ich bitte um Ergänzungsvorschläge im Kommentarbereich:

  1. Die Geschwindigkeit eines geeigneten Teamaufbaus hängt mindestens von der Verfügbarkeit von Mitarbeitern der benötigten Qualifikation, der Verfügbarkeit von Arbeitsmitteln und der Parallelisierbarkeit der Aufgaben ab.
  2. Verantwortung ist nicht teilbar – entweder man ist ganz verantwortlich oder nicht verantwortlich (siehe “Über Verantwortung (Teil 1)“).
  3. Die Behebung eines spät gefundenen Software-Bugs kostet exponentiell mehr, als die eines früh gefundenen.
  4. Menschen arbeiten nicht schneller, wenn sie Angst haben.
  5. Änderungen gerade in Entwicklung befindlicher Anforderungen kosten zusätzliches Geld, manchmal viel Geld.
  6. Auch externe Berater sind Menschen mit Menschenwürde, Bedürfnissen, Privatleben, Stärken und Schwächen.
  7. Einem verspäteten Projekt mehr Mitarbeiter hinzuzufügen, macht es noch später.
  8. Nur was Du misst, kannst Du steuern.
  9. Umsatz ist nicht Gewinn.
  10. Wenn die Entwicklung eines Features mehr kostet als es einbringt, sollte man es nicht entwickeln.

Fallen Ihnen weitere ein? Widersprechen Sie einer der obigen vermeintlichen Binsenweisheiten? Was ist Ihre Erfahrung mit dem eigenen Befolgen solcher Grundregeln?

Hinterm Horizont geht’s manchmal nicht weiter

Im Jahr 2010 machte ich mit meiner Familie eine lange Reise nach Vancouver Island vor der Westküste Kanadas. Im fantastischen Strathcona Provincial Park unternahmen wir mit einer befreundeten Familie von einem Campingplatz am Buttle Lake aus eine Wanderung auf dem Flower Ridge Trail, der auf einem schneebedeckten Gipfel mit grandioser Aussicht über die ganze Insel enden sollte.

Stunde um Stunde liefen wir steil bergauf… und immer wieder hatten wir den Eindruck, hinter dem vor uns liegenden Buckel müsse nun endlich der ersehnte Gipfel liegen. Wir motivierten die Kinder (“Kommt, nur noch bis dort hinten!”) und uns selbst, die Gedanken wanderten zu den Vorräten, die dem Gipfelschmaus zum Opfer fallen sollten und wir korrigierten noch einmal den Sitz der Rucksäcke, um voller Elan diese vermeintlich letzte Anhöhe zu erklimmen.

Aber Pustekuchen. Mal um Mal stellte sich heraus, dass dahinter nur einfach der nächste, vielleicht sogar noch steilere Buckel wartete. Nach dem dritten oder vierten Effekt dieser Art, fingen wir an zu lachen und Witze darüber zu machen, während die Kinder langsam nölig wurden. Bei einer Rast an einem kleinen Teich, den nächsten Höhenrücken vor uns, hatte eines der Kinder einen hysterischen Anfall.

Wir überwanden schließlich weitere drei Bergschultern, bis wir aufgrund der fortgeschrittenen Zeit auf einer Art “Untergipfel” beschlossen, den höchsten Punkt unserer Wanderung erreicht zu haben und uns nach ausführlichem Picknick an den Abstieg machten.

Diese Art von Effekt nennt man “Receding Horizon Problem”, das Problem des zurückweichenden Horizonts.

Immer wieder scheint das Ergebnis, das Ziel, in Reichweite zu liegen, aber beim nächsten Überprüfen der eigenen Position stellen wir fest, dass es wieder weiter von uns fortgerückt ist – in wiederum scheinbare Reichweite. Wie Odysseus’ Sirenen lockt uns das wegeilende Ziel weiter, immer weiter. “Nur noch ein kleines Stückchen, noch eine überschaubare Anstrengung, bald sind wir da und dann löst sich alles in Zufriedenheit und Glückseligkeit auf.”

Nur dass es nicht so ist. Wir investieren immer mehr Zeit, Kraft, Geld, Emotionen und sonstige Ressourcen. Und weil die jeweils nächste Investition ja nur so klein zu sein scheint (und wir ja auch schon so viel investiert haben!), machen wir das viel zu oft bis weit hinter den “Point of No Return” hinweg.

Dieser Punkt ist der, ab dem sich eine Investition nicht mehr lohnt und jede weitere Investition den Verlust nur noch vergrößert. Der Sprint gerissen ist. Der Kollege seine abhängige Aufgabe nicht mehr schaffen kann. Das Projekt unwirtschaftlich wird. Man nicht mehr rechtzeitig nach Hause kommt. Eine Beziehung zerstört ist. Man beginnt, die Einstellung des Mitarbeiters zu bereuen. Die anderen Chancen, die man mit der gleichen Investition hätte realisieren können, zunichte sind. Der Aktienkurs endgültig abstürzt. Man pleite ist. Man unaufhaltbare (negative) Konsequenzen verursacht hat.

Aber was, wenn hinter dem nächsten Hügel tatsächlich das Ziel ist?

Sehen Sie? So fängt es an… und so hört es auf.

Besser, Sie kennen den Point of No Return, wissen immer, wo sie in Bezug auf ihn sind, und kehren davor um.

Hört sich leicht an? Nein, das ist nach all den sozialen Aspekten eine der schwierigsten Aufgaben im Management überhaupt.

Haben Sie eigene Beispiele für Receding-Horizon-Situationen? Dann würde ich mich über einen Kommentar zu diesem Eintrag freuen.

Über Verantwortung (Teil 2)

In meinen Postings “Über Verantwortung (Teil 1)” und “Verantwortungsflucht – weitere Strategien“ habe ich über die Natur von Verantwortung und Strategien geschrieben, ihr vermeintlich zu entgehen.

Aber wie stellt man ein Klima, eine “Kultur der Verantwortung” her, wie es immer so schön heißt?

Dafür gibt es aus meiner Sicht drei Bausteine (die teilweise ein bisschen binsig daherkommen, siehe “Binsenweisheiten – It’s simple, but not easy“):

1. Gemeinsames Verständnis über Verantwortung herstellen

Da vielen Menschen die Natur von Verantwortung unklar ist (komischerweise lernt man das weder in der Schule noch auf der Universität), sollte an Mitarbeiter/Team-Mitglieder klar kommuniziert werden, wie in dem Unternehmen oder dem Projekt Verantwortung verstanden wird und warum das so ist.

2. Vorbild sein (aka “Eat your own dogfood”)

Verantwortliches Handeln von den Kollegen zu fordern, es aber selbst nicht zu zeigen, wird zu Recht als Heuchelei wahrgenommen und untergräbt Vertrauen und Motivation. Zudem liefert es eine billige Ausrede im Sinne von “Du machst es ja selber nicht”.

Leben Sie also Verantwortung möglichst konsequent so vor, wie Sie es von Ihren Kollegen, Mitarbeitern und Team-Mitgliedern wünschen:

Übernehmen Sie Verantwortung.

Übernehmen Sie sie nur für Aufgaben, die sie auch tatsächlich erledigen können.

Geben Sie Ihr Bestes, ihr gerecht zu werden.

Wenn etwas schief geht, gehen Sie frühzeitig offen damit um, damit Ihnen geholfen werden, jemand anderes übernehmen oder das Vorhaben abgebrochen werden kann.

Lernen Sie aus Fehlern.

Wenn Sie erfolgreich sind, sprechen sie sachlich darüber und zeigen sie den anderen Beteiligten Wertschätzung für ihren Beitrag.

3. Konsequenzen transparent machen und konsequent ziehen

Sorgen Sie dafür, dass die Übernahme von Verantwortung Konsequenzen hat, sowohl positive als auch negative, je nach dem Grad und der Häufigkeit der Erfüllung. Sorgen Sie dafür, dass diese Konsequenzen vollständig bekannt sind – um Überraschungen bei Betroffenen zu vermeiden und Spekulationen über Konsequenzen (die in der Regel viel beängstigender ausfallen als die von Ihnen tatsächlich beabsichtigten Folgen) zu vermeiden.

Wenden sie die Konsequenzen konsequent, aber mit Augenmaß und Fairness an. Dabei ist es vor allem wichtig, dass die Konsequenzen von dem Betroffenen und seinem Umfeld als fair wahrgenommen werden. Fair kann eine Konsequenz nur sein, wenn sie alle Umstände berücksichtigt. Denn oft genug gibt es tatsächlich Umstände, die weniger beim Einzelnen als in der Organisation liegen – dann kann dem Betroffenen der Misserfolg nur bedingt angelastet werden und die Organisation muss dringend daraus lernen.

Überhaupt: Die wichtigste Konsequenz aus Fehlern ist immer Lernen!

Vor allem dafür ist die Ursachenanalyse wichtig: Gibt es einen abstellbaren Grund für das Nichterreichen des Ziels? Was müssen wir nächstes Mal besser machen?

Das Fairness-Gebot gilt natürlich auch für positive Konsequenzen. Gerade dabei ist die Wahrnehmung des Umfelds besonders wichtig, sonst entstehen Neid und bei Wiederholung der Eindruck von Lieblingswirtschaft (“unverdiente Beförderung”).

Verbieten sollten sich solche Konsequenzen, die als Strafe oder gar Rache gemeint sind (z.B. Mobbing oder öffentliches Zur-Sau-Machen) oder so gedeutet werden – sie führen nicht zu dem gewünschten Lerneffekt, sondern zu Groll beim Betroffenen und Initiative lähmender und Misstrauen schaffender Angst vor ähnlicher Behandlung bei allen anderen.

Viel besser und aus meiner Sicht einzig sinnvoll sind schützende Konsequenzen. Beispiel: Wenn ein Mitarbeiter wiederholt (!) eine übernommene Aufgabe nicht erfüllt, obwohl ihn keine höhere Gewalt daran gehindert hat oder er zur Übernahme der Aufgabe unter schlechten Bedingungen gezwungen wurde, dann ist er vielleicht (noch) nicht qualifiziert genug. Das Unternehmen, das Projekt und nicht zuletzt er selbst müssen davor geschützt werden, nochmal in eine solche Pleite zu laufen. Die sinnvolle Konsequenz wäre, den Mitarbeiter zunächst wieder Aufgaben erledigen zu lassen, die er sicher erfolgreich abschließen kann und ggf. eine Qualifizierung durchzuführen oder ihn schlicht mehr Erfahrung gewinnen zu lassen.

Im Extremfall kann eine schützende Konsequenz natürlich auch sein, sich von einem ständig die Anforderungen nicht erfüllenden Mitarbeiter zu trennen – das ist hart, aber in dem Fall oft für beide Seiten der richtige Schritt zum Schutz der wirtschaftlichen Interessen des Unternehmens, der Harmonie unter den Mitarbeitern sowie der Motivation, Gesundheit und letztlich Karriere des Mitarbeiters (bevor er/sie sich eine immer tiefere Grube gräbt).

In sehr vielen Fällen ist dem Mitarbeiter, der an seiner Verantwortung gescheitert ist, übrigens genug Konsequenz durch das Wahrnehmen des eigenen “Versagens” geschehen. Die meisten Mitarbeiter wollen ihren Job gut machen und leiden genug, wenn das nicht gelingt!
Profis gehen damit offensiv lernend um, manchen muss man in diese Richtung auf die Sprünge helfen, manche versuchen, von ihnen verursachte Probleme vor sich selbst und anderen zu verstecken oder zu leugnen – dann muss man ihnen die Augen öffnen.

 

 

 

Typologie von Software-Entwicklern (Teil 3): Der Dementor

Nach der Diva und dem Ideologen nun ein paar Worte zum Team-Mitglied-Typ “Dementor”.

In den Harry-Potter-Büchern gibt es geistartige magische Wesen namens Dementoren, die jedem, der in ihre Nähe kommt, die Lebensfreude absaugen, bis nur noch Verzweiflung, Düsternis und Qual übrig sind.

Frau Rowling hat diese Figur mitten aus dem Leben gegriffen und nur leicht übertrieben.

Manche Projekte oder Teams scheitern an Menschen, die wie wahre Dementoren wirken.

Macht keinen Sinn. Das funktioniert doch nicht. Boah ist das alles Mist. Das haben wir schon früher ohne Erfolg versucht. Das haben schon andere ohne Erfolg versucht. Ich hab soooo keinen Bock. Sorry, ich bin halt nicht sozialkompetent. Muss ich das wirklich machen? Ist doch alles Scheiße. Ich kann halt nicht pünktlich sein. Ich bin so genervt. Ist doch egal, ob wir fertig werden, interessiert doch eh keinen. Es ist doch eh alles egal. Das Management/der PO/der Scrum Master/irgendjemand ist doch voll bescheuert. Ich bin nicht fertig geworden, aber nach/vor X Uhr arbeite ich nicht. Natürlich ist das schief gegangen, was dachtest Du denn? Nimm halt nicht Windows! Hab ich mir schon so gedacht, dass das nichts wird. Das hätte ich Euch schon am Anfang sagen können. Was willst Du denn? Das kriegen wir niemals hin. Hm-hmmm. Klar kann ich gleichzeitig “Tank World” spielen und programmieren. Da mache ich nicht mit. Ihr habt doch alle keine Ahnung. Stöhn. Das hat dein Vorgänger auch schon versprochen… und wo ist er jetzt? Warum ich? Ich will nicht mit Dir reden. Murmel-murmel. Ja, wir waren irgendwie verabredet, aber ich hatte etwas Besseres zu tun.

Höhnisches Lachen, wenn jemand anderes etwas Positives oder auch nur Konstruktives äußert. Spielen mit dem Handy in der Besprechung. Füße auf dem Tisch. Mürrisches Gesicht. Jeder Handgriff wird diskutiert. Null-Bock-Körperhaltung. Der Blick immer knapp am Gesprächspartner vorbei. Bloß nicht lächeln. Provokativ langsames Reagieren auf oder gar Ignorieren von Ansprache oder Kritik. Augenrollen. Sarkasmus. Zynismus. Unleserlich schreiben. Spätes Kommen und frühes Gehen. Demonstrative Freude am Misserfolg.

Dementoren ziehen meine Lebensfreude ab.

Jetzt bin ich selbst deprimiert. Ist doch alles Mist.

Der Dementor steckt in jedem von uns.

Verantwortungsflucht – weitere Strategien

In meinem Posting “Über Verantwortung (Teil 1)” nenne ich eine ganze Reihe von Strategien, wie Menschen in Projekten und anderswo versuchen, sich aus ihrer Verantwortung herauszuwinden.

Seit ich den Beitrag geschrieben habe, sind mir ein paar weitere häufig verwendete Strategien bewusst geworden, Kritik über nicht erfüllte Verantwortung (vermeintlich) zu entgehen.
Die möchte ich Ihnen nicht vorenthalten:

  1. Retourkutsche: Aber Du hast das (oder etwas völlig anderes) doch auch falsch gemacht!
  2. Kindergarten: Kollege X nimmt doch seine Verantwortung auch nicht wahr!
  3. Verstecken in einer diffusen Menge: Niemand hier nimmt seine Verantwortung wahr!
  4. Ebenenwechsel: Mir gefällt Dein Ton nicht! Überhaupt: Du hast mich auf dem Kieker!
  5. Relativierung: Ja klar, das ist ja auch die Katastrophe des Jahrhunderts. Du übertreibst total! Im Verhältnis zum Bruttosozialprodukt von Brasilien sind das doch nur Peanuts.
  6. Plattes Leugnen: Ich hab doch gute Arbeit gemacht!
    Gern hilfsweise ergänzt um:

    1. Du verstehst das nur nicht.
    2. Wir haben viel gelernt.
    3. Wir hatten eine gute Zeit! (Absurd, ich weiß, aber ein reales Beispiel!)

Fallen Ihnen weitere Verantwortungsvermeidungsfluchtstrategien ein? Dann ab in einen Kommentar damit.

Binsenweisheiten – It’s simple, but not easy

Viele der Dinge, die in Management-Beratungsartikeln und bestimmt auch in diesem Blog angeprangert oder empfohlen werden, erscheinen trivial.

“Mein Gott, warum muss man dazu einen Artikel schreiben – das weiß heutzutage doch nun wirklich jedes kleine Handwerkerle!”, denken und kommentieren viele der Leser sinngemäß.

Schaut man dagegen in die Realität, werden selbst die grundlegendsten Binsenweisheiten systematisch ignoriert oder kunstvoll begründet, warum sie nun gerade in diesem Fall nicht gelten sollen. Man könnte meinen, die Welt bestünde vor allem aus Ausnahmen, so häufig passiert das.

Das ist natürlich Quatsch.

Die ewigen Wahrheiten des Managements, insbesondere der Projektsteuerung und -führung gelten, wie der Name schon sagt, praktisch immer. Ignoriert werden sie zum Beispiel aus Betriebsblindheit, Selbstüberschätzung, Überforderung, falsch verstandenem Nonkonformismus, Gier, Realitätsverleugnung, Augen-zu-und-durch-Mentalität, Unwissen, Faulheit, Prokrastination oder vermeintlich nicht änderbaren äußeren Umständen.

Ein sehr sprechendes Beispiel: Ich wurde vor fast 10 Jahren zum Projektleiter eines bereits komplett vorbereiteten Großprojekts berufen, in dem ein offenbar rein rechnerisch ermittelter Teamaufbau von 40 Team-Mitgliedern innerhalb von zwei Wochen geplant war. Als ich darauf hinwies, dass so ein Teamaufbau meines Wissens nach eher unrealistisch sei, wurde das einfach “sportlich” genannt und ansonsten der Einwand ignoriert.

Es kam, wie es kommen musste:

Es gab gar keine 40 verfügbaren Kollegen, und schon gar nicht mit den benötigten Profilen. Erst tröpfelten sie, dann kamen sie in hastig zusammengekratzten Schüben, aber alles gleichzeitig zu langsam (Spezifikateure), zu schnell (Entwickler, Tester) und zu unkoordiniert. Schlüsselpersonen waren noch im Vorprojekt gebunden.

Beim Kunden gab es trotz für rechtzeitig gehaltener Ansage des Bedarfs nicht genug Platz, selbst für die viel langsamer als geplant eintreffende Mannschaft. Zwischenzeitlich musste eine Gruppe hochbezahlter Team-Mitglieder in einem überfüllten Besprechungsraum “arbeiten”.

Die initialen Aufgaben waren gar nicht so weit parallelisierbar, dass sie sinnvoll auf die tatsächlich verfügbaren neuen Team-Mitglieder hätten aufgeteilt werden können. Das halbe Team wartete wochenlang auf ein reifes Fachkonzept (es war noch ein Wasserfall-Projekt), während die Spezifikateure angesichts dieses Drucks brutale Überstunden schoben.

Die in dem Projekt eingesetzten Projektleiter und Teilprojektleiter (inkl. mir zu dem Zeitpunkt!) hatten gar keine Erfahrung mit einem so großem Team und den dafür spezifischen Herausforderungen und benötigten Führungstechniken.

Eskalationen der Probleme wurden von den Vorgesetzten zwar gehört, aber letztlich weitgehend ignoriert, nach Vogel-Strauß-Manier (“Es muss einfach gehen!”).

Dieser Effekt zusammen mit einer verblüffenden Flut weiterer, schon in der Projektvorbereitung angelegter und dann im Projektverlauf nicht mehr wirklich in den Grifff zu bekommender Fehler führte dazu, dass das Festpreis-Projekt mehr als doppelt so lang und teuer wurde wie geplant und mein Arbeitgeber erhebliche Rückstellungen bilden musste, um die Verluste auffangen zu können. Nur gut, dass er finanziell ausreichend potent war, viele andere Consulting-Unternehmen hätte ein solches Projektergebnis zerlegt.

Waren die Vorgesetzten inkompetent, unerfahren, dumm? Natürlich nicht – das waren alles kompetente, erfahrene und grundsätzlich kluge Menschen.

Der initiale Fehler, einen so krassen, nicht mit personellen, räumlichen und planerischen Ressourcen abgesicherten Teamaufbau zur Prämisse des Projekts zu machen, wurde nach meiner Einschätzung primär aus zwei Gründen gemacht:
Aus der Akquisitions-Eigendynamik heraus und aus Gier (sorry für das harte Wort) nach dem zweistelligen Projektbudget und der Beauftragungskontinuität beim Kunden.

Hinzu kam: Gerade aufgrund des Eindrucks, dass die Verantwortlichen kompetent, erfahren und klug sind, wurde die Machbarkeit nie ausreichend von den Ausführenden infrage gestellt (“sie werden schon wissen, was sie tun, und letztlich tragen ja sie die Verantwortung”).

Ähnliche reale Beispiele für das Ignorieren von “Ewigen Wahrheiten”, das zu negativen, manchmal verheerenden Folgen führte, kann ich und können Sie sicher noch Dutzende geben.

Was wäre passiert, wenn die Ewige Wahrheit, die Binsenweisheit über eine realistische Teamaufbaugeschwindigkeit und die notwendige planerische Detaillierung der benötigten Profile und ihrer Einsatzzeitpunkte berücksichtigt worden wäre?

Die Projekt-Akquisiteure (keine geringeren als ein Geschäftsbereichsleiter und ein Vorstand!) hätten innehalten und Zeit für eine haltbare Neuplanung geben müssen, und den Kunden darüber informieren, dass und wie sich das Projekt dadurch verändert.

Hätte das zu einem Verlust des Projekts geführt? Vielleicht. Vielleicht aber auch einfach nur zu einem erfolgreichen, lukrativen Projekt.

Zahlen mit und ohne Sinn

Kaum eine Organisation verzichtet auf das Folterinstrument namens “Reporting”.

Ein Auftraggeber außerhalb der Organisation (“Kunde”) oder innerhalb (“Manager”) verpflichtet den Auftragnehmer/Mitarbeiter dazu, über sein Handeln und den Fortschritt von Projekten regelmäßig Rechenschaft abzulegen: “Was Du nicht misst, kannst Du nicht steuern”.

Meist werden neben ein paar qualitativen Aussagen zum Stand der Dinge Key Performance Indicators (KPIs), Kurven und Statistiken gefordert. Zahlen sollen objektive Transparenz schaffen und so das Steuern erleichtern.

So weit, so gut.

Es gibt allerdings einen nahezu allgegenwärtigen Effekt, der viele Berichtende in den Wahnsinn treibt: Zahlen ohne Sinn.

  1. Es werden sehr häufig Zahlen und Statistiken angefordert, die schwer oder  aufwändig zu ermitteln sind. Entweder, weil es Quantifizierungen qualitativer Effekte sind (“Wie ist die Stimmung im Team?”) oder weil die eingesetzten Systeme die Zahlen nicht von selbst hergeben, sie also manuell gesammelt oder aus dem Vorhandenen zusammeninterpretiert werden müssen.
    Kontraproduktiver Nebeneffekt zum reinen Zeitaufwand: Schnell setzt hier ein solider Schlendrian ein, denn wenn der Berichtende schon riesige Mühe hat, die Zahlen zu besorgen, kann sicher auch niemand nachvollziehen, ob sie wirklich stimmen!
  2. Der Gegenstand des Reportings bildet gar nicht die Realität des Projekts ab.
    Beispiele: Über Epics soll berichtet werden, aber viel von dem, was die Teams tun, gehört zu keinem Epic. Die “Lines of Code per Day” sollen berichtet werden, sie haben nur praktisch keine Aussagekraft. In einem Scrum-Projekt wird die Team-Velocity verlangt, aber das Team jeden Sprint umgebaut, was für die Velocity jedes Mal einen Reset bedeutet und die Werte zwischen Sprints unvergleichbar macht.
  3. Das Management hat fast nie eine klare Idee, was es aus den Zahlen überhaupt für Steuerungsimpulse ableiten soll. Wenn KPI X nach oben oder nach unten geht, was heißt das und was macht man dann? Was sind gefährliche Grenzwerte? Was ist Rauschen, was Signal? Keine Ahnung, aber schön die Zahlen zu haben…
  4. Wenn ein Manager doch eine Idee davon hat, was er tun will, wenn sich die Zahlen in die eine oder andere Richtung bewegen, trifft er Entscheidungen oft allein auf dieser Basis (Am Tag nach dem Release: “Die Zahl der beobachteten Produkte im Shop ist nach Update der Benutzeroberfläche gesunken? Panik! Rückgängig machen!”).
    Dabei können Zahlen nur ein Indikator für Probleme sein, da sie immer eine – zum Teil grobe – Vereinfachung sind und einen qualitativen Kontext brauchen, um korrekt verstanden zu werden: Natürlich geht die Benutzung einer neu gestalteten Funktion immer erstmal zurück, bis sich die Leute daran gewöhnt haben. Die zurückgehende Team-Velocity ist auf Urlaube zurückzuführen. Das Burndown, das Story Points aus abgeschlossenen User Storys darstellt, verlässt kurz nach Beginn des Betrachtungszeitraums seinen Ideal-Korridor – weil das Team richtigerweise mit der größten, risikoreichsten Story beginnt und deshalb die Abtragung erst später, dafür aber größer als bei den anderen Storys erfolgt.

Möglichst wenige, richtig definierte, realitätsnahe, leicht ermittelbare Zahlen können ein sehr hilfreiches Instrument beim Steuern von Projekten sein – wenn klar ist, was sie einem sagen und was daraus folgt.

Typologie von Software-Entwicklern (Teil 2): Der Ideologe

Nach der Diva nun ein paar Charakterisierungen eines weiteren weit verbreiteten Entwicklertyps: des Ideologen.

Der Ideologe möchte, dass bei der Entwicklung einer Software alles richtig gemacht wird.

“Richtig” heißt für ihn in der Regel, “dem höchsten Stand der Wissenschaft entsprechend” – was immer er darunter versteht. Der Stand der Wissenschaft (hier: der theoretischen Wissenschaft) wird im Zweifel auch mal fix von ihm selbst definiert.

In der Regel besteht dieser “Stand der Wissenschaft” aus einer Menge abstrakter Konzepte, die nur tendentiell auf das anstehende Problem anwendbar sind, weil hoffnungslos überdimensioniert.

Der Ideologe ist von dem Konzept, das er zuletzt neu verstanden hat, über alle Maßen überzeugt und strebt danach, es so konsequent wie möglich anzuwenden, nach dem Prinzip: Wenn ich Hämmer geil finde, ist jedes Problem ein Nagel.

Objektorientierung? Alles wird in so viele voneinander abgeleitete, winzige Klassen wie möglich zerlegt, bis zu dem Punkt, an dem manche Klassen nur noch aus Deklarationen und geerbten Eigenschaften ohne eigenen Code bestehen; bis der Code vor ellenlangen Bezeichnern mit geerbten, also implizit geforderten Parametern nur so wimmelt und jedes Debugging einem Doodle-Jump-Spiel mit vielen, vielen Ebenenwechseln ähnelt.

Interfaces? Alle Methoden einer Klasse dürfen nur noch über Interfaces aufgerufen werden, auch die trivialsten! Damit treibt man schön den Aufwand für die Signaturerstellung, muss ja alles doppelt gemacht werden…

Service Oriented Architecture? Jede Klasse ein Service, der per SOAP- oder REST-Protokoll mit den anderen Services redet, damit auch das letzte Quäntchen Performance irgendwo in den Netzwerk-Controllern verreckt. Aber alles so herrlich lose gekoppelt!

Projektstrukturierung? Der Theoretiker schafft es, so abstrakte Kategorien und Zerlegungen für jedes Schnipselchen der Software zu definieren, dass sich alle anderen Team-Mitglieder (und oft auch er selbst) in den Tiefen unendlicher und oft ungeeignete Zerlegungsdimensionen nutzender Ordnerhierarchien verlieren.

Verstehen Sie mich nicht falsch: All diese Konzepte sind toll und bei richtiger Anwendung sehr hilfreich. Nur eben dann nicht, wenn sie zur Ideologie werden (“Am serviceorientierten Wesen soll mein Code genesen!”), um die herum Fragen wie Eignung, Angemessenheit und Verständlichkeit verbogen werden.

Die zweite irritierende Haupteigenschaft des Ideologen: Er möchte (und kann) seine Ideologie nicht unbedingt selbst umsetzen. Oft genug kann er es gar nicht, denn das reale Verständnis reicht über das Lesen von einen paar Artikeln im Web und ein bisschen “Spielen zuhause” nicht hinaus!
Die Umsetzung können gern andere machen, solange sie dem Geist seiner Ideen folgen…

Wie die Diva kann der Ideologe ganze Teams lähmen, wenn ihm nicht genügend gesunder Entwicklerverstand entgegengesetzt wird, zum Beispiel deshalb, weil das Management seine Buzzwords für bare Münze nimmt und ihn als Experten für die neuesten Trends zum Verantwortlichen für Architektur oder den Software-Entwicklungsprozess macht.

Nein, man muss nicht die allerneueste Technologie verwenden, uns reicht es, gut funktioniernde Software zu bauen, deren Grundlage alle im Team gut beherrschen. Nein, Konsequenz ist nicht das höchste Prinzip, wohlfundierter, dem Problem und den Randbedingungen angemessener Pragmatismus ist es.

Was tun mit Ideologen? Lasst sie so lange ihre eigenen Ideen (nicht projektkritisch!) in Prototypen umsetzen und sich die Hörner daran abstoßen, bis sie sie von selbst verwerfen (“toller Ansatz, aber unausgereift”) oder sie die nötige Zielorientierung entwickeln und das Ergebnis geläutert ins Team tragen können. Nicht alles, was ein Ideologe mitbringt, ist ja falsch oder auch nur schlecht. Nur die blinde Missionierung eines Projekts zum Glauben an untaugliche Techno-Gottheiten ist es.