Bei einem meiner Spaziergänge durch einen unserer Buchläden ist mir vor einiger Zeit das Buch “Adrenalin Junkies & Formular Zombies – Typisches Verhalten in Projekten” von Tom DeMarco und anderen (konkret: die “Atlantic Systems Guild”) aufgefallen. Nachdem ich die anderen Bücher von Tom DeMarco zu Softwareengineering und Projektarbeit (konkret: The Deadline/Der Termin, Peopleware oder Slack/Spielräume) mit großen Vergnügen verschlungen habe, landete auch die Neuentdeckung auf meinem Still-to-Read-Stapel …

Mein erster Eindruck nach dem Lesen: zuerst einmal etwas enttäuscht … Das Buch liefert zwar viele interessante Einblicke in (Software-)Projektarbeit und damit auch gute Anregungen, wo man hinschauen oder eingreifen sollte/könnte – aber es fehlt die zusammenhängende, geschichtenartige “Schreibe”, die ich bisher bei Tom DeMarco gewohnt war – und geliebt habe.

Denn das Buch ist kein zusammenhängender Text, sondern eine Sammlung von 86 Mustern, die bei (Software-)Projektarbeit beobachtet werden können. Jedes Muster ist auf einer bis vier Seiten kurz beschrieben. Dabei ist die Qualität (und Lesbarkeit) der Beschreibungen stark unterschiedlich. Weiterhin sind positive, negative und neutrale Muster wild gemischt.

Hier noch die “Muster”, die mir beim Lesen des Buches als besonders lesenswert bzw. erwähnenswert aufgefallen sind – mit ein paar Kommentaren von mir dazu.

7) Manana: “Wir alle verfügen über Zeitfenster, innerhalb derer wir erkennen, dass wir in Gang kommen und dranbleiben müssen, um eine Tätigkeit abzuschließen. Stichtage jenseits dieser Zeitfenster erzeugen kein Gefühl von Dringlichkeit und folglich auch nur eine geringe Motivation, sofort zu handeln.” (S. 19) – “Ausserhalb dieses Wahrnehmungsfensters befindet sich Manana. Manana bedeutet, dass wir zwar grundsätzlich einsehen, dass wir diese Arbeit erledigen müssen, aber nicht begreifen, dass wir umgehend damit beginnen müssen, um rechtzeitig fertig zu sein.” (S. 20).

Die Lösung ist (wie bei vielen der Muster/Probleme) einfach: Zwischenziele definieren, die innerhalb des Zeitfensters liegen. Trotz dieser einfachen Lösungsmöglichkeit wird aber nicht immer (rechtzeitig) erkannt, dass überhaupt ein Problem existiert.

26) Der Versuchsballon: “Bei einem Versuchsballon handelt es sich (…) um einen Lösungsvorschlag, von dem Sie allerdings wissen, dass er unvollkommen und/oder fehlerhaft ist, und den Sie bewusst einsetzen, um von Kollegen oder Kunden Kritik zu bekommen.” (S. 68).

Schöner habe ich die Idee der iterativen Entwicklung, des häufigen Generierens und Diskutierens von Prototypen noch nicht dargestellt gesehen. Dazu passt auch das auf S. 69 abgedruckte Zitat von Albert Schweitzer sehr gut: “Beispiele sind nicht das Hauptmittel um andere zu überzeugen. Sie sind das einzig mögliche Mittel.”.

75) Die Kühlschranktür: “Teammitglieder hängen ihre Arbeitsergebnisse routinemäßig für alle sichtbar aus.” (S. 185).

Hier wird besprochen, was mit Awareness / einem Gewahrsein über die Arbeit der anderen / den Stand der Arbeiten bzw. des Projektes erreicht werden kann. Das passt auch sehr gut zu den in vielen anderen Mustern angesprochenen Problem mit der zu starken (blinden) Konzentration auf in Vorgehensmodellen vorgeschriebenen Dokumenten zur Fortschrittsdokumentation (z.B. Muster 79 Papierfabrik).

Anstelle einer “Kühlschranktür” kann man natürlich auch Medien wie Blogs benutzen – sollte sich aber immer der Vorteile der Kühlschranktür bewusst sein bzw. versuchen sie nachzubilden!

Gut hierzu passt auch das Muster 81 Lagezentrum. Hier wird ein Projektraum empfohlen, der erstens Informationsaustausch und Informationsbewahrung sicherstellt – und dem Projekt einen sichtbaren Wert gibt.

76) Morgen scheint die Sonne wieder …: “Der Projektmanager ist davon überzeugt, dass der durchschnittliche künftige Fortschritt den durchschnittlichen zurückliegenden Fortschritt übertrifft.” (S. 187).

77) Einer geht noch: “Die Beteiligten sichern Unterstützung für ein Projekt zu, blähen es dann aber immer weiter auf, bis das Projekt unter der Eigenlast zusammenbricht.” (S. 190).

83) Aus gehabtem Schaden nichts gelernt …: “Ein Team erkennt seine Fehler, aber wiederholt sie trotzdem.” (S. 203).

In diesem Muster wird ausführlich auf den Aspekt der Lessons-learned eingegangen und auch einige konkrete Tipps zu deren erfolgreichen Durchführung/Implementierung gegeben (S. 205). Erstmal sollten Nachbesprechungen überhaupt abgehalten werden. Dann sollte vermieden werden, dass die Besprechungen nur zum “Dampfablassen” genutzt werden – z.B. nur Beschreibungen von Problemen gesammelt werden, aber keine Handlungsanweisungen zur zukünftigen Begebung.