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.

 

Über Verantwortung (Teil 1)

Verantwortung sollte ein lange und gut verstandenes Konzept sein. In der Realität treffe ich dennoch immer wieder auf ein grobes Missverständnis des Wesens von Verantwortung, das manchmal an surreale Diskussionen darüber erinnert, ob die Erde rund oder flach ist.

Dabei ist Unklarheit über die Verantwortlichkeiten – wer welche trägt und was das heißt – eine der größten Bremsen für funktionierende Organisationen!

Im beruflichen Kontext heißt Verantwortung zu haben, dass einem die Folgen des eigenen Tuns zugeschrieben werden und Konsequenzen nach sich ziehen.
Übernimmt man Verantwortung, akzeptiert man sowohl die Zuschreibung als auch die Konsequenzen.

Die positiven Folgen beim Erfüllen der Verantwortung können zum Beispiel sein: Lob, Anerkennung, Bewunderung, Beförderung, Gehaltserhöhung, Macht, Einfluss, Privilegien, interessantere Aufgaben, erweiterte Führungsverantwortung.

Auf der anderen Seite stehen beim Scheitern Kritik, Zurechtweisung, Schuldzuweisungen, Rufverlust, Ausgrenzung, Neid, Überforderung, Konkurrenz, Karriere-Stagnation, Degradierung, Verachtung, Positionsverlust, Abmahnung, Entlassung.

Verantwortung ist keine moralische Kategorie wie Schuld. Schuld setzt vorsätzliches oder grob fahrlässiges Verhalten voraus, Verantwortung lediglich das Annehmen eines Auftrags. Schuld ist grundsätzlich negativ, Verantwortung kann sowohl zu positiven als auch negativen Ergebnissen führen.

Im Folgenden einige Strategien, die gern angewendet werden, um (vermeintlich) Verantwortung zu entgehen.

  1. Ahnungslosigkeit: Ich wusste nicht, dass ich verantwortlich bin!
  2. Gegenseitigkeit: Machst Du mich nicht verantwortlich, mach ich Dich nicht verantwortlich!
  3. Schwarzer Peter: Ich habe die Verantwortung doch delegiert!
  4. Diffusion: Wir sind alle irgendwie verantwortlich – und deshalb ist es irgendwie keiner!
  5. Rückzieher: Ich habe gar nicht gesagt, dass ich das hinbekomme!
  6. Opfer: Die Umstände haben mich gehindert!
  7. Ablenkende Moralisierung: Ich bin gar kein schlechter Mensch! Warum wirfst Du mir das vor?
  8. Mitleid heischen: Ich bin sooooo verantwortlich, ich bin so schlecht, so ein armes Würstchen, ich habe so einen Bockmist gebaut, ich fühle mich so furchtbar wegen meiner Verfehlungen, bitte hab Mitleid mit mir… und (teil-)befreie mich von der Verantwortung.

So als Liste lesen sie sich fast lustig, oder? Schreiben Sie weitere Strategien, denen Sie schon begegnet sind, als Kommentar zu diesem Blog-Beitrag!

Natürlich werden diese Strategien nur angewendet, wenn es darum geht, den Folgen der Verantwortung für ein suboptimales Ergebnis zu entgehen. Lob nimmt jeder strahlend entgegen. Mit Verantwortung ist es ein bisschen wie mit dem Raubtierkapitalismus: Gewinne werden gern privatisiert, Verluste sozialisiert.
Zum Einheimsen von Erfolgen werden übrigens all die oben genannten Strategien umgedreht… Übung: Formulieren Sie die Punkte 1.-8. so, dass sie damit einen Erfolg für sich verbuchen oder verstärken können!

Hier die Grundregeln für Verantwortung, die ich für “ewige Wahrheiten” halte:

  1. Im direkten Verhältnis zwischen Auftraggeber und Auftragnehmer (Vorgesetzen/Mitarbeiter, Projektleiter/Team-Mitglied, PO/Scrum-Team) ist Verantwortung unteilbar. Jeder, der einen Auftrag annimmt, ist voll verantwortlich. Nimmt eine Gruppe (wie z.B. ein Scrum-Team) einen Auftrag an, ist jeder im Team gesamtverantwortlich.
  2. Verantwortung wird man nicht durch Delegation los. Reiche ich die Aufgabe oder einen Teil davon an jemand anderen weiter, bin ich meinem Auftraggeber gegenüber immer noch genauso verantwortlich! Ich habe lediglich ein neues Verantwortungsverhältnis gestartet: Das zwischen dem Delegationsempfänger und mir.
    Selbst, wenn ich keinerlei inhaltliche Arbeit mehr selbst mache (wie die meisten Manager) bin ich immer noch für die Auswahl und Führung der operativ arbeitenden Menschen und letztlich für deren Ergebnis verantwortlich.
  3. Wer einen Auftrag annimmt, darf das nur tun, wenn er ihn erfüllen kann und will. Im Zweifel sollte man vorher seinem Auftraggeber die Risiken mitteilen, die man an dem Auftrag sieht. Mit der Annahme des Auftrags wird man verantwortlich. Deshalb sollte am Beginn jeder Verantwortungsübernahme eine Prüfung stehen, ob die Voraussetzungen stimmen.
    Verantwortung kann man auch übernehmen, wenn man zu einem Auftrag “nein” sagt: Verantwortung für sich selbst!
  4. Wenn sich die Bedingungen nach dem Übernehmen der Verantwortung auf eine Weise ändern, dass der Auftrag nicht mehr innerhalb der vereinbarten Randbedingungen erfüllt werden kann, ist man verpflichtet (und berechtigt!) den Auftraggeber schnellstmöglich darüber zu informieren, ggf. neue Bedingungen für den Auftrag auszuhandeln oder den Auftrag zurückzugeben.

Im Teil 2 zum Thema “Verantwortung” bald in diesem Blog: Eine Kultur der Verantwortlichkeit entwickeln.

Kosten Projektleiter, Architekten und Tester Geld?

Viele Unternehmen und Organisationen legen einen seltsamen Geiz an den Tag, wenn es um die Besetzung eines Projekt-Teams mit Projektleitern, Architekten oder Testern geht. Der Projektleiter zu teuer, die Architekten bauen doch eh nur Luftschlösser, testen kann doch auch der sowieso zu teure Projektleiter oder na gut, wir geben drei Projekten zusammen einen Tester, der aber nur ein kaltzustellender minderleistender Entwickler ohne “Bock” auf die Aufgabe ist. Ach so – und die Software spezifizieren kann auch ein Fachbereichsmitarbeiter, der so etwas noch nie gemacht hat, ein Junior-Produktmanager, gar eine Sekretärin oder ein Praktikant, die lernen das dann per Trial & Error. Vielleicht. Hoffentlich. Ganz bestimmt. Im Traum.

Ich behaupte, gute Projektleiter/Scrum Master, Architekten, Tester und Spezifikateure kosten überhaupt kein Geld, im Gegenteil.

Nanu? Aber das Unternehmen zahlt ihnen doch jeden Monat Gehalt oder Honorar, im Fall von qualifizierten externen Mitarbeitern sogar stattliche Summen! Das ist doch Geld, oder nicht?

Klar, aber meine Aussage bezieht sich auf das Ergebnis des Projekts und die Gesamtkosten, nicht auf die Einzelvergütung. Ein Projekt ist ja viel mehr wert als sein Budget, sonst würde es sich nicht lohnen. Ein Projekt, für das nicht mindestens ein Effekt in Höhe von Budget plus Projektrisiko plus angestrebte Umsatzrendite erwartet wird, braucht man gar nicht erst zu starten. (Und ja, auch “strategische” Projekte sollten sich mit einer monetär bezifferbaren Wirkungserwartung verknüpfen, Wirtschaftsunternehmen sind kein Ponyhof!)

Nun ist es so, dass Projekte, die mit unerfahrenen oder gar ungeeigneten Projektleitern oder Scrum Mastern, Spezifikateuren und Product Ownern, keinen oder nur Aushilfsarchitekten, keinen oder nur Aushilfstestern ausgestattet werden, ein fantastisch großes Risiko haben, die schillernde Statistik gescheiterter Entwicklungsanstrengungen zu bereichern.

Das Team wird nicht effizient wirksam, weil seine Mitglieder nicht an einem Strang ziehen. Es wird Ungeeignetes entwickelt oder die mangelhafte Benutzerfreundlichkeit macht das Produkt zur Totgeburt. Die fachlichen Klärungen sorgen für jede Menge Aktivität, aber lähmen den eigentlichen Fortschritt. Das Team häuft technische Schulden auf, die zukünftige Projekte zu erdrosseln drohen. Fehler werden spät gefunden und damit viel zu teuer beseitigt, oder sogar erst vom Kunden “entdeckt”, wenn das Produkt schon auf dem Markt ist.

Ergebnis: Budget mehrfach überzogen, riesige Opportunitätskosten angehäuft, Kunden und Mitarbeiter verloren, Projektziele nicht erreicht, Image beschädigt. Ein Desaster! Böses Team… oder?

Nach meiner Erfahrung kosten gescheiterte Projekte oft das Zwei- oder Dreifache des ursprünglichen Kostenansatzes, im Extremfall ein größeres Vielfaches – und damit manchmal das ganze Unternehmen.

Risiko? Da war doch was… Risikomanagement! Ich sehe es so, dass die Ausstattung von Projekten mit qualifiziertem Querschnitts-Personal eine Maßnahme des Risikomanagements ist. Man kann zwei bis fünfzig Entwickler zusammensetzen und hoffen, dass sie in endlicher Zeit das gewünschte Ergebnis produzieren werden. Das Risiko ist nur sehr, sehr groß, dass das nicht passiert und das Projekt entsprechend teuer wird – bei jeder ernstzunehmenden Projektgröße praktisch immer zu teuer.

Um das Risiko und damit die angenommenen Kosten zu senken, werden die Querschnittsfunktionen ins Projektteam aufgenommen.

Gute Projektleiter/Scrum Master sorgen für Disziplin und befördern Teambildung und Kommunikation, schaffen geeignete Rahmenbedingungen und beseitigen Hindernisse. Spezifikationsexperten und erfahrene Product Owner formulieren die Anforderungen an die zu entwickelnde Software so präzise, anschaulich und stabil, dass die Entwickler nur noch wenige Fragen dazu haben. Gute Architekten entwerfen eine Softwarestruktur und Strukturmuster, die dafür sorgen, dass das System redundanz- und fehlerarm, wartbar und leistungsfähig ist, und sie stellen sicher, dass das auch so umgesetzt wird. Tester finden Fehler so früh wie möglich, grenzen die Ursache ein und lassen beim Entwicklerteam nicht locker, bis das Problem beseitigt ist.

All diese Querschnittsaufgaben wirken im Idealfall stark multiplizierend. Ihr Nutzen vervielfacht sich über das ganze Team. Sonst würde man damit ja auch kaum die Kosten eines Projekts senken können, sondern bestenfalls die benötigte Zeit reduzieren!

Wird man sich dieses Zusammenhangs bewusst, wird klar, warum man hier nicht sinnlos sparen sollte: Jedes bisschen positiver Wirkung multipliziert sich positiv!

Es lohnt sich in jeder Hinsicht, Projekte richtig anzugehen, keine halsbrecherischen Abkürzungen zu nehmen und die ewigen Wahrheiten des Projektgeschäfts zu berücksichtigen. Dafür braucht man die richtigen Menschen in geeigneter Anzahl und man muss ihnen für ihre Arbeit Geld geben… das sich aus dem Risikobudget selbst finanziert: Risikosenkungsmaßnahmen, in diesem Fall die Arbeitsplätze und Gehälter oder Honorare der eingesetzten Personen, werden aus dem Wert des Risikos (finanzielle Auswirkung bei Eintritt mal Wahrscheinlichkeit) bezahlt.

Fiktives Beispiel: Angenommen, ohne den Top-Projektleiter besteht ein Risikowert von 250.000€. Den bisherigen Kandidaten durch einen über die Projektlaufzeit 50.000€ teureren zu ersetzen, senkt den Risikowert auf 100.000€. Die Maßnahme hat 100.000€ gespart, obwohl mehr Honorar bezahlt werden muss.

Natürlich gibt es auch hier eine Grenznutzenkurve: Zusätzliche Teammitglieder und zusätzliche Euro Vergütung (als ungefähres Maß für die Qualifikation eines Mitarbeiters) führen nicht unendlich zu linearen Verbesserungen beim Risiko. Der 2.000-Euro-pro-Tag-Berater halbiert nur selten das Projektrisiko gegenüber einem 1.000-Euro-pro-Tag-Berater. Zwanzig Tester finden in einem kleinen Projekt i.d.R. nicht doppelt so viele Fehler wie zehn. Mit hoher Wahrscheinlichkeit wird aber der positive Hebel zwischen einem 1.000-Euro-am-Tag-Berater und einem zu der jeweiligen Rolle verdonnerten Aufgabenneuling beträchtlich sein. Hier gilt es, das richtige Maß zu finden, das aber sehr oft weit unterschritten wird, in der Annahme, dass Querschnittsfunktionen in Projekten Geld kosten.

Meine Empfehlung: Bei PLs, POs, Scrum Mastern und Architekten, von denen es jeweils nur einen oder sehr wenige im Team geben kann, auf Qualifikation achten und dafür im Zweifel etwas tiefer in die Tasche greifen. Bei Testern auf ein ausgeprägtes Tester-Mindset achten und im Zweifel eher einen mehr ins Team stecken.

Warum wird das so oft falsch gemacht? Oft aus mangelndem Bewusstsein für den oben geschilderten Zusammenhang. Ebenso oft aber aus Gier. Aus Gier auf ein vermeintlich billig zu erzielendes Projektergebnis und/oder den damit verbundenen Ruhm werden wider jede Vernunft die Chancen hoch-, die Risiken heruntergespielt und die Kosten großzügig durch “Das wird schon irgendwie gehen”-Teams rechnerisch niedrig gehalten.

Gier vernebelt den Verstand.

Typologie von Software-Entwicklern – Teil 1: Die Diva

Etwas Lustiges zum Einstieg:

Diven sind tödlich für Teams. Und das, obwohl sie meist individuell gut bis sehr gut sind. Manchmal ist diese Güte allerdings auch nur eingebildet. Sie sind sich ihrer tatsächlichen oder nur gefühlten Kompetenz sehr bewusst und sehr sicher. Alle anderen im Team sind tendenziell Idioten, vor allem der Projektleiter/Scrum Master/Product Owner, von dem sich eine Diva kaum etwas sagen lässt, und wenn, dann nur unter augenverdrehendem Protest.

Diese Arroganz versteckt die – übrigens meist männliche – Diva gegenüber den anderen Team-Mitgliedern in der Regel unzureichend, meist gerade so viel, dass man ihr nicht den Vorwurf der direkten Beleidigung machen kann, aber offen genug, um systematisch zersetzend zu wirken.

In Momenten besonderer Entnervtheit zeigt die Diva ungeschminkt ihr wahres Gesicht und zieht gegen das aktuelle Opfer mit voller rhetorischer und manchmal körpersprachlicher Wucht zu Felde. Kritik an ihrem Kommunikationsstil wird bestenfalls beleidigt angehört und grundsätzlich dem Idiotentum des Sprechers zugerechnet, niemals aber eigenen Verfehlungen.

Die Diva nimmt sich in technischen Belangen allen anderen als weit voraus wahr. Das Verwenden gut abgehangener, funktionierender Technologien wird oft abfällig und herablassend kommentiert. Es müssen die allerneuesten, dem Bisherigen theoretisch weit überlegene Technologien und Konzepte sein, unterhalb von “Cutting Edge” macht es die Diva nicht. Die mit diesen Neuerungen verbundenen Kinderkrankheiten, Unvollständigkeiten und sonstigen Schwierigkeiten betrachtet die Diva als Herausforderung und manchmal beherrscht sie sie sogar aufgrund ihrer überlegenen Sachqualifikation sogar – nur leider sonst niemand im Team.

So gut wie immer wirkt sich eine Diva negativ bis sehr negativ auf das Team aus. Zurecht ständig genervte, demotivierte und sich herabgesetzt fühlende andere Team-Mitglieder, zusammenbrechende Team-Kommunikation, ständige zersetzende Negativität gegen über allem, was nicht von der Diva selbst vorgeschlagen wurde, Monopolisierung von Know-how, passiv- oder aktiv-agressives Verhalten und von der Diva durchgesetzte technische Abenteuer sind nur die Spitze des Eisbergs.

Dennoch tun sich Unternehmen sehr schwer damit, Diven aus Teams oder gleich komplett aus der Organisation zu entfernen: Sie sind ja so gut. Man ist so abhängig von ihnen, wegen des Spezialwissens. Selbst wenn die Diva ein ganzes Team mehr oder weniger lahmlegt, erste Teammitglieder um Versetzung bitten oder gar kündigen, wird die Diva kaum jemals als Ursache wahrgenommen.

Ich sage: Diven nach maximal zwei ignorierten Warnschüssen entweder auf nicht unternehmenskritische Einzelaufgaben setzen oder ihnen die Gelegenheit geben, ein anderes Unternehmen zu ruinieren, vorzugsweise einen Konkurrenten.

Nächste Folge: der Ideologe.