Man kann sagen, dass „The Phoenix Project“ sein Ruf vorauseilte. In den vergangenen Jahren wurde es mir mehrmals als ein Mix aus Sachbuch und Fiktion empfohlen, der typische Fallstricke eines IT-Unternehmens und von Prozessen im IT-Betrieb entlarvt. Dabei waren die Meinungen gemischt. Während die Entwickler darüber schmunzeln und das Buch witzig finden, habe ich es durchaus auch von Kollegen auf dem Management-Karrierepfad empfohlen bekommen, weil man da „mal sieht, was noch so an IT dranhängt“. Ich war gespannt und habe es mir als Hörbuch mit ca. 14h Laufzeit im englischen Original gegönnt.

Von Phönixen und Einhörnern

Parts Unlimited ist eine amerikanische Firma, die Autoteile bereitstellt und mal ein big player auf dem Markt war, aber leider nicht mehr ist. Insbesondere in punkto IT haben sie den Anschluss verpasst. Das Project Phoenix soll es kitten, hat aber bereits Unmengen an Geld verbrannt und hängt der Deadline um Monate hinterher. Bill Palmer war bisher Director of Midrange Technology Operations und ist nach einem Anruf des CEOs plötzlich Vice President (VP) of IT Operations. Die Art und Weise der Beförderung ist bereits wenig glanzvoll. Keine offizielle Ankündigung, viele angepisste und vor den Kopf gestoßene Kollegen und hinzu kommt noch die Gewissheit, dass alle von Bills ehemaligen Chefs gefeuert wurden, bevor er die Rolle einnahm. Ist sein Kopf der nächste, der rollt? Feiern und Freude bleiben aus, denn über Bill bricht das halbseidene Kartenhaus zusammen zu dem die Firma in den letzten Jahren geworden ist als selbst das System zur Zeiterfassung ausfällt und niemand weiß, was den Kollegen an Lohn ausgezahlt werden muss. Und das ist nur der erste von zahlreichen Konflikten, die Bill begegnen und seine ersten Monate als VP zum Spießrutenlauf machen.

Management-Fibel „How not to do“

Tatsächlich fühlt sich The Phoenix Project anfangs mehr als eine Management-Fibel an. Mit Bills Beförderung und seinem Stolpern von einem Problem ins nächste wird sehr formelhaft aufgezeigt, an wievielen Stellen die Firma die eigenen Prozesse nicht einhält oder fatalerweise nie welche etabliert hat. Obwohl es viele teuer bezahle Anzugträger gibt, ist Parts Unlimited im Grunde nur noch wie ein Netz: Loch an Loch und hält doch. Das Mismanagement schließt ein, dass es nur Druck, aber kein Reporting gibt. Der Change Management Prozess existiert, aber es hält sich niemand daran und tut einfach was er will, wann er will. Es scheint keine interne IT-Abteilung oder klar abgesteckte Aufgaben zu geben, sondern die Arbeit wird denjenigen zugeworfen, die gerade da sind. Es gibt keine Übersicht, über die Arbeit, die getan wird – nur menschliche „Speicher“. Wenn diese ausfallen, dann ist Pumpe. Auch die Erhaltung der Infrastruktur ist eine Katastrophe. Man nehme mal alleine Bills Laptop, das quasi Schrott ist, von Servern wollen wir mal gar nicht anfangen. Und wenn all die Probleme zusammenkommen, schieben alle Nacht- und Wochenendschichten um irgendwas lauffähiges zusammenzufrickeln. Und während all dem laufen ständig irgendwelche Auditoren rum, die die Einhaltung von Richtlinien überprüfen sollen und am besten von dem Chaos nichts mitkriegen dürfen. Duh. Kurzum: die Firma hat IT absolut unterschätzt, keine Ahnung wie man IT managed und geht mit einer überholten Vorstellung von „Management durch Druck“ davon aus, dass wenn man genug Köpfe einschlägt, der Laden schon irgendwie läuft.

„How Homer Simpson would stop nuclear meltdowns“, via Benjamin Adriaenssens (Youtube)

Durch die Entwickler-Brille gesehen …

Leider bleibt das Buch auf der Ebene einer Management-Fibel. Was die harten Fakten betrifft, hält es sich mehr als bedeckt. Es fallen zwar manchmal Wörter wie Datenbank-Change und Server, aber alles nur sehr oberflächlich. Wer auch immer den Eindruck hat, dass es ein IT-Buch ist: das ist es nicht. Es geht um Prozesse, Management und darum wie wichtig DevOps für die Gewährleistung der Prozesse und Dienste ist. Für Softwareentwickler und DevOps-Ingenieure ist es damit ganz amüsant, aber wird den Horizont der Leute kaum erweitern. Denn: wir wissen das alles schon. Ich spreche von wir, da ich Softwareentwicklerin bin und auf DevOps-Prozesse angewiesen bin und seit Jahren in agilen Softwareentwicklungsprozessen, hauptsächlich nach Scrum, arbeite. Und ich will nie wieder zu dem zurückgehen, was nicht agil ist. Für die agile Softwareentwicklung ist DevOps unerlässlich. DevOps schließt die Bereitstellung von Technologie und Prozessen ein, damit Softwareentwicklung gemanaged werden kann. Beispielsweise durch Versionierung bzw Versionsverwaltung (Git, SVN, …), Continuous Integration, Build- und Deployment und Bereitstellung von Umgebungen mit bspw. den Zielen Test, Integration, Produktion und was man ggf sonst noch so braucht.

Es geht bei DevOps somit weniger um die Entwicklung selber, sondern um die reibungslose Testung, Auslieferung und Bereitstellung – um die Sicherstellung der Prozesse. Der Blick auf agile Softwareentwicklung fehlt dem Buch fast vollständig. Das Wort fällt glaube ich nicht einmal, obwohl klar ist, dass es darauf hinaus will. Lediglich über ein Kanban-Board als Visualisierung der todo-, in-progress und done-work ist die Rede. Das ist das Dilemma der Praktiker die das Buch lesen oder hören. Für mich war es eine ermüdende vierzehnstündige Erinnerung daran, was wäre, wenn wir nicht so arbeiten würden wie wir es tun. Um den Kreis noch zu schließen: der Begriff der agilen Softwareentwicklung umschreibt einen unbürokratischen Weg der Softwareentwicklung, indem Ergebnisse schnell, aber funktional und getestet zur Verfügung gestellt werden und ebenso schnell ausgeliefert werden können. Auf Änderungen kann ebenso schnell agiert werden. Im Gegensatz zu Softwareentwicklungsmodell wie dem Wasserfall-Modell wo zuerst lang und bürokratisch beschrieben wird wie es gemacht wird, dann entwickelt und ausgeliefert wird. Zwar unter Umständen dafür „alles auf einmal“, aber nach einer sehr langen verstrichenen Zeit und wenig bis gar keiner Flexibilität für Änderungen, was in der IT-Industrie aufgrund der Schnelllebigkeit u.U.schädlich geworden ist.

„Gene Kim Defines the 3 Ways of The Phoenix Project“, via Abacus Solutions (Youtube)

Was haben Gene Kim, Kevin Behr und George Spafford eigentlich gegen Software-Entwickler?

The Phoenix Project erschien 2013 und es fällt mir ehrlich gesagt schwer anzunehmen, dass DevOps zu diesem Zeitpunkt noch in den Kinderschuhen steckte. Gene Kim, Kevin Behr und George Spafford versuchen in dem Buch deutlich zu machen, dass IT im Unternehmen (selbst wenn es selber kein IT-Unternehmen ist, sondern nur hausinterne IT bereitstellt) essentiell ist um mitzuhalten, wettbewerbsfähig zu sein und in ihrer Komplexität nicht unterschätzt werden darf. Und dafür ist DevOps zwingend notwendig. Sechs Jahre nach Erscheinen wirkt diese Erkenntnis „spät“. Unternehmen, die das noch nicht gemerkt haben, haben etwas verpasst. Wobei natürlich die Anforderungen jedes Unternehmens unterschiedlich sind. Aber auf manche Aspekte wie Versionsverwaltung und Backups sollte man wirklich nie verzichten. Insofern kann man die Aussage des Buches unterstützen, hinnehmen und verstehen. Sie wirkt halt nur aus heutiger Sicht überholt. Nun arbeite ich aber in einem IT-Betrieb, der eben Software bereitstellt, womit die Kenntnis all dieser Prozesse für uns naheliegender ist als für andere Unternehmen.

Was mir neben dem abhanden sein des Begriffs agiler Softwareentwicklung sehr übel aufstößt ist das Bild, das die Autoren von Softwareentwicklern zeichnen. Dafür dass es eine „Novel about IT, DevOps and Helping Your Business Win“ ist, wird das IT darin doch sehr vernachlässigt. Es wird ein geradezu feindseliges Bild von Softwareentwicklerin gezeichnet und das von jemandem, der mal „IT Manager“ war und jetzt VP ist. Unser Protagonist Bill Palmer sagt an einer Stelle, dass er Softwareentwicklern generell misstrauisch gegenüber steht. Sie für seltsam hält, dass sie sich nicht an Prozesse halten, einfach tun was sie wollen und damit alles zum Einsturz bringen können. Bitte was? Wem soll denn damit geholfen sein, wenn man so ein feindseliges Bild entwirft? Natürlich durchlaufen die meisten Charaktere hier eine Entwicklung, aber Bills Einstellung verändert sich nicht. Im Gegenteil, er kommt später mit Entwicklern zusammen, wo er Hipster oder sozial dysfunktionale Charaktere erwartet hätte, findet stattdessen „Hippies“ vor und gibt an ihren Humor nicht zu verstehen als sie eine task force „Project Unicorn“ nennen wollen. Was hat er denn bitte gegen Einhörner? 😉 Nein im Ernst: vermutlich soll die feindselige Einstellung auch eine Satire sein, aber die kann hier leider sehr schnell missverstanden werden und ist daher unklug gewählt. Das Buch versucht eigentlich das Bewusstsein für die Wichtigkeit von IT in Unternehmen zu fördern, aber untergräbt gleichzeitig die Arbeit, Schweiß und kognitive Leistung von den Praktikern, die das ganze Zeug basteln. Das ist mies und nicht zielführend. Und aus eigener Erfahrung muss ich leider sagen, dass die Lücke im beiderseitigem Verständnis zwischen Managern und IT-Praktikern oft sehr schnell zu zwischenmenschlichen Problemen führt und ein Projekt empfindlich stört. Da wäre es besser, wenn man sich solche Meinungen wie da oben nicht anliest.

Und dramaturgisch?

Tatsächlich ist The Phoenix Project irgendwo zwischen Roman und Sachbuch, aber der Spagat gelingt nur bedingt. Die Sprache ist zu einfach und die Handlung ist so flach wie vom Reißbrett eines Management-Märchens. Wenn ich jedes Mal wenn das Wort Exasperation („Verzweiflung/Verärgerung“) oder exasperated fällt 5€ bekommen hätte, könnte ich jetzt davon in den 5-Sterne-Urlaub fahren. Die Charaktere sind sehr stereotyp und einfach gestrickt, worin vermutlich ein Hauch Satire liegen soll. Es gibt nicht selten Meetings in denen die Leute rumschreien, die aufrechten Charaktere sind wie der Protagonist alle Ex-Militärs und verstehen sich bestens miteinander, wenn es um den Austausch von Militär-Floskeln und-Erfahrungen geht; die Frau an der Spitze gefährdet das ganze Unternehmen, etc etc. Es würde leichter fallen es als Satire aufzufassen, wenn die Sprache etwas ausgefeilter und lebhafter wäre. Für Leute, die öfter zum Sachbuch als zu Romanen und Erzählungen greifen, ist es vielleicht angenehmer als für Roman-Leser.

Mehr Management-Märchen als IT-Sachbuch

„Wenn das Buch so schlecht ist, aber die grundlegende Botschaft so gut – für wen ist das Buch jetzt?“ Vermutlich für Leute, die in das Management in einem IT-Betrieb oder einer IT-Abteilung eines Unternehmens einsteigen und von DevOps noch nicht gehört haben. Vermutlich auch eher Stoff für andere Branchen als die IT-Industrie selber. Wenn euer Unternehmen Software produziert, dann habt ihr von DevOps hoffentlich schon gehört. Als Berufseinsteiger in der Softwareentwicklung macht das Buch eher Angst vor der Arbeit in einem Betrieb. Wie man meinen Ausführungen oben entnehmen kann fehlt mit agiler Softwareentwicklung außerdem ein aus meiner Sicht wichtiger Teil für den Weg zum Erfolg. Auf „Spaß“ muss man sich nur einstellen, wenn man schadenfroh sein will oder wenn man distanziert über all die Tropen schmunzeln kann. Wenn man schon in so einem IT-Betrieb arbeitet, fühlt sich das Buch teilweise anstrengender als der eigene Arbeitstag an aufgrund der Fülle an Problemen und verärgerten Managern, die einem darin begegnen. Fairerweise muss man sagen, dass es ein schöner Kniff ist, dass letzten Endes ein „zu guter“ Softwareentwickler als Bottleneck vieler Operationen identifiziert wurde. Das geht zwar wieder in Richtung „Softwareentwickler denunzieren“, aber ich bin tatsächlich etwas erleichtert, dass man hier in die Richtung knappe Ressource argumentiert, weil dieser „Brent“ nicht überall sein kann, aber scheinbar als einziger alles weiß. Besser als das leistungsgetriebene Bild eines Softwareentwicklers, der konstant nicht genug gibt. „Brents“ sind ein Anti-Pattern, das erschreckend oft auftritt: ein Spezialist, der sein Wissen nicht teilt und sich unabkömmlich macht. Ob sich Gene Kims Philosophie der „Three Ways“ etabliert haben, weiß ich nicht. DevOps ist für mich schon lange ein Teil meines Arbeitslebens, weswegen das Buch für mich und vielleicht auch für alle Praktiker aus der IT-Branche keine Neuerungen (mehr) beinhaltet.

Es ist ja sicherlich alles wahr, was die Kernaussage des Buchs betrifft. D.h. dass IT im Unternehmen wichtig ist und DevOps essentiell für die schnelle und funktionale Bereitstellung von IT. Aber wenn mich jemand fragt, ob man das Buch kennen muss, würde ich sagen: eigentlich nicht. Kennt ihr „The Phoenix Project“? Und wie habt ihr es wahrgenommen? Dass ich es übrigens als Hörbuch gehört habe, liegt daran, dass ich schon ein Sachbuch zur Hand hatte und auf die Gefahr hin, dass es mich nach Feierabend irgendwie auslaugt, nicht noch ein zweites angefangenes rumliegen haben wollte. Bei Stoffen, die ich als anspruchsvoll erwarte, greife ich doch manchmal lieber zum Hörbuch, das ich dann flüssiger beende. Ich bin jedenfalls sehr gespannt auf eure Meinung über das Buch, da ich mir bewusst bin, dass ich als Softwareentwicklerin biased bin.

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂