Die narzisstisch gekränkten Entwickler und ihre Abneigung gegen Agile und Scrum

Bild: Pixabay / Geralt - Lizenz

Seit ich angefangen habe in agilen Projekten zu arbeiten ist es fast zu einer Routine geworden: in regelmässigen Abständen schicken mir Freunde, Kollegen und sonstige Leute Links zu Seiten auf denen irgendwer in meist epischer Breite erklärt, warum Agile im Allgemeinen und Scrum im Besonderen etwas Furchtbares ist (bzw. geworden ist) und besser heute als morgen abgeschafft werden sollte. Mitunter sind es sogar einigermassen bekannte Zeitgenossen die Sich da äussern - recht moderat Dave Thomas, ein Unterzeichner des agilen Manifests etwa (Time to kill agile) und Andy Hunt, ein weiterer Unterzeichner (The failure of agile), wesentlich radikaler Erik Meijer, Mitentwickler von Visual Basic und .net (Scrum is a cancer) und zuletzt IT-Blogger Michael O. Church (Why Agile and especially Scrum are terrible). Geballte Kompetenz und/oder Prominenz also.

Nun bin ich sicher nicht einmal in Ansätzen in der Lage so zu programmieren wie die genannten Herren, widersprechen möchte ich aber trotzdem und zudem noch einen Verdacht äussern: Bei diesen Leuten handelt es sich möglicherweise um einen Typ Mensch den ich auf Projekten häufiger erlebe, und den ich als den "narzisstisch gekränkten Entwickler" bezeichne. Eine narzisstisch gekränkte Person ist laut Sigmund Freud jemand der es nicht verwinden kann, dass jemand dem er es eigentlich nicht zutraut etwas genau so gut kann wie er selbst. Dadurch fühlt der narzisstisch Gekränkte sich in seinem Selbstwertgefühl angegriffen, worauf er in der Regel mit Wutanfällen reagiert. Die Auslassungen der oben genannten Entwickler lesen sich vor diesem Hintergrund sofort ganz anders, denn ihnen allen ist eines gemeinsam: Die Klage darüber, dass die Begriffe Agile und Scrum (angeblich) von Nicht-Entwicklern übernommen sind, von Projektmanagern, Abteilungsleitern, Testern oder (ganz schlimm) Unternehmensberatern.

Keine Frage - mit Sicherheit ist es richtig, dass hier vieles im Argen liegt. Von jeder der vier genannten Gruppen habe ich Exemplare erleben dürfen, die die agilen Ideen solange vergewaltigt haben bis sie in ihr Gegenteil verdreht wurden. Und dennoch: aus der mitunter fundamentalen Ablehnung schaut auch etwas ganz anderes heraus, nämlich ein zum Teil kaum verhüllter Standesdünkel. "Wie kann es sein, dass jemand der kaum oder gar nicht programmieren kann sich anmaßt einem Entwickler zu erklären, wie er seinen Code schreiben soll?" Diese Frage zieht sich im Hintergrund durch viele der Kritiken und Angriffe denen Scrum und Agile ausgesetzt sind, genau wie die Aussage "Lasst uns doch einfach programmieren." Auch von vielen Programmierern in den Projekten bekommt man immer wieder Ähnliches zu hören.

Allein - so einfach ist es nicht. "Die 'Experten' einfach programmieren lassen" ist nämlich so ziemlich der sicherste Weg zu exorbitanten Kostensteigerungen. Wenn Programmierer sich erst einmal "im Tunnel befinden", sich in den Flow vertieft haben" oder "dem Perfektionismus hingegeben haben" dann bekommt man zwar durchaus bemerkenswerte Ergebnisse, früher oder später wird man aber auch fast zwangsläufig mit den folgenden Phänomenen konfrontiert: Für viele Komponenten werden unverhältnismäßig hohe Aufwände investiert, da sich durch die Wahl des jeweils komplexeren Lösungsansatzes die Möglichkeit bietet "eine Doktorarbeit in Code zu schreiben", gleichzeitig wird wie bei allem was man "einfach drauf losmacht" nicht weit genug in die Zukunft gedacht - und nach einem opulenten Einstieg in ein Projekt ist plötzlich ein zeitlicher Verzug da, der gegen Ende zu Hast, Hektik und Murks führt.

Das alles soll keineswegs heißen, dass Entwickler keine Projekte planen können, aber genauso wie die meisten Projektmanager nicht wissen wie man entwickelt, genauso wenig wissen die meisten Entwickler wie man auf der Management-Ebene IT-Projekte durchführt. Dafür können tatsächlich Nicht-Entwickler besser geeignet sein. Und genau diese Tatsache ist es, die vielen Programmierern die Narzisstische Kränkung zufügt, die sie so wüten lässt.

Aber jetzt kommt die große Frage: wenn Manager in der Regel nicht nicht entwickeln können und Entwickler in der Regel nicht managen - sind dann nicht alle IT-Projekte von vornherein zum Scheitern verurteilt? Nicht unbedingt. Denn tatsächlich gibt es eine Methode, die (richtig umgesetzt) beide Seiten zusammenbringen kann. In ihr beschränken sich die (Produkt)Manager darauf, Anforderungen zu erfassen und zu priorisieren und fertige Features abzunehmen, sagen den Entwicklern aber nicht wie sie zu entwickeln haben. Die Entwickler dagegen sind frei in der Programmierung, überlassen dem (Produkt)Manager aber die Priorisierung der Anforderungen und die Abnahme der fertigen Features. Sogar einen Namen hat diese sagenhafte Methode: man nennt sie Scrum. Und jeder der sich von seinem Entwickler-Standesdünkel (oder dem Gegenstück, der Management-Arroganz) befreien kann wird einsehen, dass man wunderbar damit arbeiten kann.