Um ganz ehrlich zu sein: Wenn das Hauptprodukt Ihres Unternehmens Software ist, wissen Sie natürlich auch einiges über Softwareentwicklung. In diesem Beitrag werde ich Ihnen meine Erkenntnis darüber vermitteln, wie sich der Softwareentwicklungsprozess auf jeden anderen Aspekt Ihres Unternehmens (und Ihres Lebens) anwenden lässt – unabhängig von Ihrer Branche, Ihrer Position und Ihrer Abteilung. [Spoiler-Alarm: Ein Buch, das du unbedingt lesen solltest – „The Phoenix Project“ – wartet auf dich!]
Wir haben„The Phoenix Project“für unseren internen Buchclub ausgewählt. Eigentlich hatte ich nicht vor, eine Rezension zu schreiben, aber dieses ungewöhnliche Wirtschaftsbuch bietet so viele Aha-Momente, dass wir es einfach nicht für uns behalten können. Ich bin zwar kein Entwickler (arbeite aber mit einigen großartigen zusammen), habe jedoch gelernt, wie sie an ihre Arbeit herangehen, und coole Tools wie [Kanban] zur Visualisierung und Verwaltung von Arbeitsabläufen kennengelernt. Tools, die für jeden funktionieren können und werden!
„Das Phoenix-Projekt: Ein Roman über IT, DevOps und wie Sie Ihrem Unternehmen zum Erfolg verhelfen“
Von Gene Kim, Kevin Behr und George Spafford
Stellen Sie sich einen fiktiven Roman vor, in dem sich eine Gruppe sehr unterschiedlicher Personen zusammenschließt, um einen Drachen zu besiegen und ein Dorf zu retten – nur dass in dieser Geschichte die „Krieger“ Geschäftsleute sind, das Dorf ein angeschlagenes Produktionsunternehmen (vertikal integriert mit E-Commerce- und Einzelhandelskomponenten) und der Drache die Probleme symbolisiert, mit denen das Unternehmen konfrontiert ist, insbesondere die unzähligen Herausforderungen des IT-Betriebs (der, wie wir feststellen werden, mit jeder anderen Abteilung verflochten ist!).
Jedes Unternehmen – oder jede Person –, das bzw. die mit, in, für oder im Umfeld von „DevOps“ arbeitet, sollte diesen humorvollen, aber oft auch beängstigenden Roman lesen. Wenn man unser aktuelles Geschäftsumfeld und insbesondere die globale Arbeitswelt auf den Punkt bringt, bedeutet das, dass dieses Buch für JEDEN geeignet ist.
Nahezu jedes Unternehmen – im wahrsten Sinne des Wortes – läuft mit DevOps und wird von DevOps gesteuert. Es ist das Herzstück des Nervensystems der Organisation. Es sei denn, man ist ein Kind, das im Vorgarten einen Limonadenstand betreibt, an dem nur bar bezahlt werden kann.
Was ist DevOps?
In der Informationstechnologie ist DevOps eine Kombination aus Entwicklung (Dev) und Betrieb (Ops). Die heutige Softwarekultur ist nicht mehr „in Silos“ organisiert, sondern vereint diese Fachkräfte in einem einzigen Team, das den gesamten Anwendungslebenszyklus abdeckt – von der Entwicklung und dem Testen über die Bereitstellung und den Betrieb bis hin zur Qualitätssicherung und Sicherheit. Die Erfahrung lehrt uns, dass das Arbeiten in Silos, d. h. der Verzicht auf den Austausch von Informationen und Wissen mit anderen, mehr Probleme schafft als löst.
Die Geschichte des „Phoenix-Projekts“ und warum DevOps wichtig ist
DevOps ist die „Produktionsrevolution“ unserer Zeit. Anhand des fiktiven Technologieunternehmens „Parts Unlimited“ (PU) veranschaulichen die Autoren, wie viele Unternehmensumgebungen typischerweise funktionieren (dysfunktional!) und wie jede Veränderung – oder das Ausbleiben derselben – transformativ wirken kann, wobei DevOps dabei im Mittelpunkt steht. Software ist ein integraler Bestandteil jedes Unternehmens, auf jeder Ebene. Die Geschichte liefert großartige Einblicke aus allen Perspektiven und richtet sich nicht nur an technische Fachleute.
Unsere PU-Geschichte (Wortspiel beabsichtigt) beginnt mit einer Katastrophe, die nur darauf wartet, sich zu ereignen. Ein IT-Leiter der mittleren Ebene (Bill), dessen Vorgesetzte auf mysteriöse Weise „gekündigt“ haben, wird zum Vizepräsidenten für IT-Betrieb befördert – eine Position, die er weder begehrt noch annehmen möchte. Seine Mission (man denke an „Mission: Impossible“) – direkt vom zunächst charmanten CEO übertragen – besteht darin, kritische Geschäftsabläufe wiederherzustellen und zu verhindern, dass das Unternehmen in die Schlagzeilen gerät … und das alles inmitten eines seit Jahren überfälligen, viel zu umfangreich angelegten neuen Produkts, „Projekt Phoenix“, und angesichts des schwankenden finanziellen Vertrauens der Öffentlichkeit in das Unternehmen.
Bills Schreiben scheint zum Scheitern verurteilt zu sein; das Projekt Phoenix ist für PU eine Frage von „alles oder nichts“. Um das Projekt herum toben interne Machtkämpfe, und Marketingchefin (und designierte Nachfolgerin des CEO) Sarah ist die Hauptgegnerin – mit einem unheimlichen Talent dafür, anderen die Schuld für ihre eigenen Pannen zuzuschieben, zumindest laut der IT-Abteilung.
Dann taucht das erste Problem auf … Die Lohnabrechnungssysteme sind FUBAR (Fouled Up Beyond All Recognition). Bills Anweisung ist klar: Rette das Unternehmen vor sich selbst.
Die Entkopplung
Unser fiktives Team weist zu Beginn alle Anzeichen dafür auf, dass die Mitglieder ihren Teamkollegen weder vertrauen noch ihnen Beachtung schenken. Mangelnde Kommunikation ist dabei noch das geringste – und letztlich doch der Kern – ihrer Probleme. Anstatt sich zusammenzuschließen, um Probleme zu lösen, schieben sie sich gegenseitig die Schuld zu und ziehen voreilige, unangebrachte Schlussfolgerungen übereinander. Persönliche Eigenheiten stehen der Professionalität im Weg. Herablassung und unternehmensinternes „Theater“ sind an der Tagesordnung.
Die Unstimmigkeiten zwischen den Abteilungen sind offensichtlich. Die Autoren geben uns einen Einblick darin, was die Mitarbeiter des IT-Betriebs über den Rest des Unternehmens denken:
- Marketingfachleute sind „Absolventen der Fachrichtungen Kunst oder Musik, keine Fachleute mit einem Hintergrund im Bereich Technologiestrategien“
- Verkäufer versprechen den Kunden das Unmögliche und erwarten von der IT-Abteilung, dass sie einfach eine Lösung findet und liefert; man kann ihnen nicht trauen: „Du kennst doch das Sprichwort, oder? Man erkennt einen Anbieter daran, dass er lügt, wenn sich seine Lippen bewegen.“
- Vizepräsidenten halten im Grunde den ganzen Tag lang PowerPoint-Präsentationen – und zwar voreinander.
- Entwickler „gießen Öl ins Feuer“; bringen Systeme ständig zum Absturz; sind mit den Gedanken woanders oder im Urlaub; verursachen oft Probleme, verschwinden dann und überlassen es dem IT-Betrieb, das Chaos zu beseitigen
- Informationssicherheit im Raum ist der beste Weg, um sicherzustellen, dass etwas NICHT erledigt wird.
Ein Mitarbeiter meint, dass die beliebte britische Fernsehserie „The IT Crowd“ (eine meiner Lieblingsserien!) das Los der IT-Mitarbeiter treffend widerspiegelt. Das IT-Team – das die Abkürzung CIO eher mit „Career Is Over“ (Karriere ist vorbei) als mit „Chief Information Officer“ assoziiert – ist der Ansicht, dass eine Beförderung nicht unbedingt etwas Gutes ist. Wenn man sich zurückhält, kann man der Unternehmensbürokratie aus dem Weg gehen. Das hat mich an die „Mitläufer“ in manchen Reality-TV-Shows erinnert.
Im Verlauf der PU-Geschichte nehmen die Verdächtigungen zu, und es entstehen Verschwörungstheorien darüber, wie es den Konkurrenten immer wieder gelingt, ihnen zuvorzukommen. Sind da vielleicht zu geschwätzige Leute am Werk?
Und es kommt noch schlimmer. Schriftliche Spezifikationen werden gar nicht erst erstellt. Trotz des hohen Bedarfs des Unternehmens an Hightech-Lösungen für das Marketing werden die IT- und Betriebsabteilungen überhaupt nicht konsultiert, und das Marketing lagert IT-Anschaffungen häufig aus und umgeht damit die Abteilung gänzlich.
Die Übergaben, insbesondere zwischen der Entwicklung und dem IT-Betrieb, werden nie gut abgewickelt. Es gibt die unvermeidlichen „ROUND-TUIT“-Projekte: IT-Upgrades und Wartungsarbeiten, die ständig aufgeschoben werden, weil unvorhergesehene Notfälle und andere Prioritäten sie in den Hintergrund drängen. Das ist ein Kampf zwischen den Fraktionen.
Die Bewertung – Das System ist kaputt
Bill nimmt seine Beförderung – und all die Brände, die es zu löschen gilt – gelassen hin. Sein Führungsstil, bei dem er sich unter die Mitarbeiter mischt (und die schwierigen Fragen stellt), hilft ihm dabei, die Probleme des Unternehmens aus einer übergeordneten Perspektive zu betrachten, da sie das Geschäft selbst betreffen.
Er weiß, dass der Einsatzbetrieb eigentlich nicht wie bei der Feuerwehr funktionieren sollte, und obwohl PU als großes Unternehmen mehr Personal zur Verfügung hat, um die rasanten täglichen „Feuerwehreinsätze“ zu bewältigen als kleinere Unternehmen, bleiben die Probleme dieselben. Alles wird als dringend eingestuft. Doch wenn alles dringend ist – kann dann überhaupt etwas wirklich dringend behandelt werden?
Prozesse, Vorgehensweisen und Systeme für das Änderungsmanagement sind zwar vorhanden, werden aber selten befolgt. Eine angemessene Planung, bei der „alle an einem Tisch sitzen“, fehlt in der Regel. Die erforderlichen Testumgebungen existieren nicht, angeblich aufgrund fehlender finanzieller Mittel. Willkürliche Termine für die Inbetriebnahme in der Produktion werden festgelegt, ohne dass dabei berücksichtigt wird, was vor der Bereitstellung tatsächlich geschehen muss.
Die Unterstützung kommt nicht von der obersten Führungsebene des Unternehmens. Moderne Ausrüstung und Schulungen sind ein Luxus, den man sich nicht leisten kann. Das Unternehmen agiert im Grunde genommen blind. Es fehlt an Lagebewusstsein. Die linke Hand weiß nicht, was die rechte tut.
Proaktives Handeln ist nur ein nachträglicher Einfall. Transparenz wird dringend benötigt.
Die Projektumsetzung wird von willkürlichen – und doch stets dringenden – festen Terminen bestimmt, die auf externe Verpflichtungen der Führungsspitze zurückzuführen sind, ohne dass diese die internen Probleme vollständig versteht. Die Entwicklung muss dann unzumutbare und inakzeptable Abkürzungen nehmen, um den Termin einzuhalten. Das Produkt wird mit ziemlicher Sicherheit unbrauchbar sein, und diejenigen, die lautstark danach verlangt haben, werden schwer enttäuscht sein. Das Kundenerlebnis wird so schlecht sein, dass die Kunden zur Konkurrenz abwandern. Der IT-Betrieb wird alles in seiner Macht Stehende tun müssen, um das Produkt zum Laufen zu bringen – und dabei verbergen, was hinter den Kulissen vor sich geht.
Das Team bemüht sich, das Perfekte nicht zum Feind des Guten werden zu lassen. Die geschäftlichen Auswirkungen werden jedoch verheerend sein; das Unternehmen arbeitet nicht auf Unternehmensniveau.
Die neu veröffentlichte Phoenix-Software sorgt gerade für Furore.
Single Point of Failure – Wer ist Ihr Brent?
Dann gibt es noch den „Single Point of Failure“ – jenen unverzichtbaren Mitarbeiter, der bei jedem wichtigen Projekt eine zentrale Rolle spielt und in tausend verschiedene Richtungen gezogen wird. Scheinbar kann ohne seine Beteiligung nichts geschehen. Er oder sie ist weder ersetzbar noch nachbildbar. In „The Phoenix Project“ heißt er Brent.
Ohne eine zentralisierte Projektliste lässt sich die Produktion nicht steuern: Die Produktionsabteilung (PU) hat keinen Überblick über ihre Prioritäten und Verpflichtungen hinsichtlich des Bedarfs, den Status der laufenden Arbeiten und die Verfügbarkeit von Ressourcen. Der IT-Betrieb ist in jeden Arbeitsablauf eingebunden, was zu Engpässen bei den laufenden Arbeiten, den Projektleistungen, Ausfällen und der Einhaltung von Vorschriften führt.
Bei PU galt es bislang als Zeitverschwendung, Prioritäten zu planen. Dort hält man sich nicht an die allgemeine Regel, dass, wenn etwas (in der Dringlichkeit) nach oben rückt, etwas anderes nach unten rücken muss. Man hat noch nicht herausgefunden, wie man den Aufwand für die Fehlerbehebung reduzieren kann, damit umsatzfördernde Projekte umgesetzt werden können.
Wie gehen Sie mit dem „Single Point of Failure“ Ihres Unternehmens um? Das Buch beginnt mit einer Erläuterung der Theorie der Engpässe.
Was ist die Theorie der Engpässe?
Die Theorie der Engpässe (TOC) ist ein Managementkonzept, das davon ausgeht, dass nur wenige Engpässe (wie beispielsweise eine einzelne Schwachstelle in der Personalbesetzung oder ein Engpass in einer Fertigungslinie) Sie daran hindern, Ihre Ziele zu erreichen. Wenn Sie sich darauf konzentrieren, können Sie den Engpass identifizieren und ihn umgehen. Denken Sie an die Redewendung „Eine Kette ist nur so stark wie ihr schwächstes Glied.“
Wenn Sie jedoch an einer anderen Stelle Verbesserungen vornehmen – sei es vor oder hinter dem Engpass –, bleibt diese Einschränkung dennoch bestehen. In unserem Fertigungsszenario staut sich die Arbeit im vorderen Bereich, während es im hinteren Bereich des Engpasses an unfertigen Erzeugnissen (WIP) mangelt.
Das Prozessmanagement in DevOps unterscheidet sich nicht wesentlich von der Fertigung oder dem Betrieb einer Fabrik – und umgekehrt. Jede Abteilung kann von den anderen lernen. Mit denselben Werkzeugen und Techniken lassen sich Prozesse dokumentieren, Verschwendung von Zeit und/oder Material aufdecken und das gesamte System verbessern.
Eines der Vorstandsmitglieder von PU stand Bill als Mentor zur Seite. Durch die Darstellung der „Vier Arten von Arbeit“ und der „Drei Wege“ verhalf er ihm zu einer nützlichen Ausrichtung auf die jeweilige Aufgabe.
Die drei Wege verstehen
„Die drei Wege“ beschreiben die Werte und Philosophien, die den Rahmen für die Prozesse, Abläufe und Praktiken jedes Systems bilden. Das Ziel jedes Unternehmens, jeder Abteilung und jedes einzelnen Mitarbeiters ist es, das System wirklich zu verstehen – und zu schätzen –, um die eigene Arbeit zu verbessern und bessere Produkte und Dienstleistungen zu liefern:
- Systemdenken– Kontrollieren Sie Einschränkungen und beschleunigen Sie Arbeitsabläufe, indem Sie von links nach rechts vorgehen (schnellere Ergebnisse erzielen)
- Feedback verstärken – Die Feedbackschleife verkürzen, indem man von rechts nach links vorgeht (bessere Qualität liefern)
- Kultur des Experimentierens und Lernens– Tests begrüßen und fördern, um die aus Fehlern gewonnenen Erkenntnisse schneller umzusetzen (Risiken mindern und kontinuierliche Verbesserungen erzielen)
Die vier Arten von Arbeit verstehen
Indem wir unsere Tätigkeiten in einzelne Bereiche unterteilen und jeder Art von Arbeit Kennzahlen zuweisen, können wir Engpässe, d. h. Einschränkungen, besser erkennen:
- Geschäftsprojekte– Arbeit mit direktem Einfluss auf das Geschäftsergebnis, z. B. neue Produkte, neue Funktionen
- Interne IT-/Betriebsprojekte – Arbeiten zur Unterstützung von Geschäftsprojekten wie F&E (Forschung und Entwicklung), neue Architektur, Infrastruktur oder Technik
- Änderungen– Anpassungen an geplanten Arbeiten im Rahmen „interner Projekte“, die „Geschäftsprojekte“ unterstützen
- Ungeplante Arbeit– Fehler, Mängel, Nacharbeiten, Krisenmanagement usw., die Zeit von umsatzgenerierenden „Geschäftsprojekten“ abziehen
Die Schlussfolgerung lautet eindeutig: Gut durchgeführte interne Projekte wirken sich positiv auf Geschäftsprojekte aus und reduzieren zudem den Umfang an ungeplanter Arbeit.
Ohne das Ende des Buches („Project Unicorn!“) vorwegzunehmen, sei nur so viel gesagt: Die Spannungen eskalieren bis zu einem Punkt, den kein Unternehmer, kein Mitarbeiter, kein Manager und auch sonst niemand gerne erleben möchte.
Die Lösung liegt in Ihrer Reichweite
- Automatisieren Sie wiederkehrende Prozesse so weit wie möglich, überwachen und dokumentieren Sie die Arbeit (insbesondere Änderungen) und überprüfen, überprüfen, überprüfen Sie alles
- Probleme früher erkennen, die Arbeit in überschaubarere Teilaufgaben aufteilen, sich mit allen Beteiligten abstimmen, um die Ergebnisse zu überprüfen, bei Bedarf Änderungen vornehmen und die Ergebnisse schneller liefern
- Standardisierung für bessere, reproduzierbarere, genauere und schnellere Ergebnisse
- Kommunizieren
„The Phoenix Project“ hat mich dazu gebracht, viele Dinge aus einer neuen Perspektive zu betrachten. Zum Beispiel ist alles ein System: ein Unternehmen, eine Produktionsstätte, der Verkehrsplan einer Stadt, sogar die eigene Familie oder der eigene Körper. Die Lösungen für das Management all dieser „Systeme“ sind sich unheimlich ähnlich. Ich kann es jedem nur wärmstens empfehlen: Lest das Buch.
Das Wichtigste auf einen Blick
- Seine Kunden auf einer persönlicheren Ebene kennenzulernen, kann für ein Unternehmen von unschätzbarem Wert sein.
- Bürokratie ist ein fester Bestandteil jedes Unternehmens. Wenn das Unternehmen wächst, sind neue Sicherheitsvorkehrungen erforderlich, um eine reibungslose Kommunikation zu gewährleisten. Auch wenn Ihr Unternehmen klein ist und es zu Personalfluktuation kommt, treten diese Kommunikationsprobleme auf Unternehmensebene ebenfalls auf.
- Der Prozess des Veränderungsmanagements erfordert Disziplin – seine Entwicklung ist mühsam, aber es ist noch viel schlimmer, wenn es ihn NICHT gibt. „Man kann das Strategische erst erreichen, wenn man das Taktische beherrscht.“
- Wenn dich jemand fragt, wie du ein Problem gelöst hast, gibt es nichts Schlimmeres, als zu sagen: „Ich weiß es nicht.“ Dokumentiere es! Wenn es das nächste Mal passiert, haben wir die Antwort parat. Wissen ist Macht. Wissen, das nicht weitergegeben wird, ist wertlos – und schlimmer noch: Es sorgt für Chaos.
- Wenn eine Abteilung einen Meilenstein erreicht, eine andere Gruppe im Unternehmen davon aber negativ betroffen ist, veranstalte keine „Bierparty“ und verschicke keine Rundmail. Das gehört sich einfach nicht. Es hat dir wahrscheinlich auch nicht gefallen, als deine gesamte fünfte Klasse – außer dir – zur Geburtstagsparty des coolen Kindes eingeladen wurde. Und wenn du das coole Kind warst, solltest du dich schämen. Denk daran: Niemand ist eine Insel. Entweder gehen wir gemeinsam unter oder schwimmen gemeinsam. Warte mit der Feier, bis alle gemeinsam feiern können.
- Wenn Sie Neuigkeiten zu berichten haben, teilen Sie diese mit. Vielleicht hat der neu eingeführte Change-Management-Prozess Sie gerade vor einer Katastrophe bewahrt – verbreiten Sie die Nachricht! Betonen Sie, wie gut etwas funktioniert. Lob, Anerkennung und Dankeschöns kosten wenig Zeit und zahlen sich in Form von Arbeitsmoral und Begeisterung reichlich aus. „Vorbeugen ist besser als heilen“, aber das Problem bei der Prävention ist, dass die Menschen selten davon wissen. Kommunizieren Sie die Erfolge!
- Wenn jeder versteht, inwiefern seine Arbeit die Leistungskennzahlen (KPIs) des Unternehmens – also die Messgrößen für die Gesamtgeschäftsleistung – gefährdet, wird er sich dadurch nicht entmutigt, sondern eher gestärkt fühlen und bessere geschäftliche bzw. berufliche Entscheidungen treffen.
- Probleme treten immer wieder auf. Ziehen Sie keine voreiligen Schlüsse. Handeln Sie nicht unüberlegt und verschlimmern Sie das Problem nicht noch weiter. Stechen Sie anderen nicht in den Rücken, schieben Sie die Verantwortung nicht auf andere ab und suchen Sie nicht nach Sündenböcken. Stellen Sie sicher, dass Abläufe vorhanden sind. Halten Sie sich an die Abläufe. Tragen Sie proaktiv zur Lösung bei und verbessern Sie die Abläufe bei Bedarf.
- Lernen Sie einander kennen – und verstehen Sie einander –, sowohl auf persönlicher als auch auf beruflicher Ebene. Das schafft Respekt, Vertrauen und bessere Arbeitsbeziehungen. Wenn ich jemanden kennenlerne, insbesondere jemanden, mit dem ich zusammenarbeite (oder den ich im Vorstellungsgespräch auf eine Stelle befrage!), lautet meine neue Lieblingsfrage: „Was unterscheidet für Sie einen guten von einem schlechten Arbeitstag?“
Fazit
Bei unserem letzten Buchclub-Treffen mussten meine Kollegen schmunzeln, da sich offenbar jeder von uns mit einer oder mehreren Figuren, Verhaltensweisen und/oder Handlungen identifizieren konnte. Dann rafften wir uns wieder auf, schüttelten den Staub ab und sprachen über unsere eigenen inneren Fortschritte auf dem Weg zu mehr Struktur, besseren Prozessen und einer größeren Offenheit für Veränderungen, um unseren Kunden bessere Produkte und Dienstleistungen bieten zu können.
xTuple legt großen Wert auf Innovation sowie auf die unternehmensweite Vernetzung und den Austausch unterschiedlicher Perspektiven – intern mit den Mitarbeitern und extern mit Kunden sowie der breiteren Tech-Community.
Beendet diesen Wahnsinn und redet miteinander. Schafft einen klar definierten, nachhaltigen Prozess, auf den sich alle einigen können. Definitionen sind wichtig. Verständnis ist wichtig. Passt den Prozess so lange an, bis er funktioniert. Das ist machbar.
