Der Besitzer der vertrauten Stimme ist zur Überraschung von Maxine der Barkeeper, der sie beim letzten Treffen im Dockside bedient hat.
Er stellt ein Tablett mit Getränken neben ihr ab und klopft Kurt freundlich auf die Schulter. Dann wendet er sich Kirsten zu und sagt: »Oh, wenn das nicht Kirsten Fingle ist! Lange nicht gesehen! Willkommen im Dockside, dem Hauptquartier der aufblühenden Rebellion.«
»Ich glaub’s nicht!« Kirsten starrt ihn an.
»Äh, Sie kennen sich?«, fragt Kurt, nicht ganz so selbstbewusst wie gewohnt.
Kirsten lacht. »Das ist Dr. Erik Reid. Vielleicht wissen Sie das nicht, aber Steve und Dick versuchen seit Monaten, ihn für das Board von Parts Unlimited zu gewinnen. Er arbeitet mit unserer Firma seit Jahrzehnten zusammen. Tatsächlich war Erik in den 1980er-Jahren an der Einführung des ersten MRP-Systems beteiligt, und danach half er in unseren Werken dabei, Lean-Prinzipien und -Praktiken anzuwenden. Wir waren eines der ersten Unternehmen mit einem automatisierten MRP-System, und Erik gilt unter unseren Kollegen aus der Fertigung als echte Legende.«
»Er?«, wundert sich Kurt ungläubig und zeigt mit dem Daumen auf den Barkeeper.
Maxine ist ebenfalls überrascht. Schließlich hat sie vor Jahren die Weiterentwicklung und den Betrieb dieses erstaunlichen selbst entwickelten MRP-Systems übernommen. Sie war immer beeindruckt davon gewesen, wie darin nicht nur eine geniale Arbeitsweise kodifiziert worden war, die zu einem fantastischen Arbeitsfluss führte, sondern die auch ein kontinuierliches Lernen ermöglichte, und zwar für die Montagearbeiter wie für die Betriebsleiter.
»Glauben Sie nicht alles, was Sie hören«, schnaubt Erik.
Maxine versucht auf die Schnelle, ihn einzuschätzen. Er sieht aus wie Mitte bis Ende 50, ungefähr das richtige Alter, um Stammvater des MRP-Systems sein zu können. Er ist groß gebaut, scheint körperlich in guter Verfassung zu sein und hat schulterlange, graue Haare, die sie an Jeff Bridges als »Dude« in The Big Lebowski erinnern. Aber Erik wirkt nicht sanft und cool, sondern eindeutig scharf und aufmerksam.
Er wendet sich mit einem verschmitzten Lächeln an Maxine. »Im Namen aller Mitarbeiter in der Produktion danke ich Ihnen, dass Sie sich so gut um das MRP-System gekümmert haben. Sie haben geholfen, eine Software zu bewahren und weiterzuentwickeln, die ein Meisterwerk an Einfachheit und Lokalität ist. Sie setzen dabei nicht nur in hervorragender Weise die Geschäftsziele um, sondern haben auch ein System geschaffen, in dem kleine Teams von Engineers produktiv und unabhängig voneinander arbeiten können, mit sorgfältig und hervorragend voneinander isolierten Komponenten. Die nicht, wie so oft, zu einem riesigen, hässlichen und verzwickten Durcheinander komplektiert wurden.
Eine wahrhaft großartige technische und architektonische Leistung«, sagt er strahlend. »Die von Ihnen damit ermöglichte Produktivität der Entwickler ist ein schönes Zeugnis eleganter Einfachheit. Und noch beeindruckender ist der rücksichtslose Abbau technischer Schulden im Rahmen Ihrer täglichen Arbeit. Ich freue mich, Sie endlich kennenzulernen!«
Maxine starrt Erik an. Es kommt nicht jeden Tag vor, dass ein Barkeeper einem Komplimente für den in vielen Jahren sorgfältig geschriebenen und gepflegten Code macht, denkt sie.
»Vielen Dank – ich werde dafür sorgen, dass das ans Team weitergegeben wird«, sagt sie ratlos, kann ihren Stolz aber nicht verbergen.
»Äh, was bedeutet ›komplektiert‹?«, fragt Kurt.
Erik antwortet: »Es ist ein archaisches Wort, das von Sensei Rich Hickey wiederbelebt wurde. ›Komplektieren‹ bedeutet, etwas Einfaches in etwas Komplexes zu verwandeln.1
In eng gekoppelten und komplektierten Systemen ist es fast unmöglich, etwas zu ändern, denn sobald man etwas in einem Bereich des Codes modifiziert, muss man gleich Hunderte oder sogar Tausende anderer Bereiche ebenfalls anpassen. Und selbst die kleinsten Veränderungen können in weit entfernten Teilen des Systems völlig unvorhersehbare Folgen haben, vielleicht in einem Bereich, von dem man noch nie gehört hat.
Sensei Hickey würde sagen: ›Stellen Sie sich vier voneinander unabhängige Stränge oder Fäden vor – ein einfaches System. Nehmen Sie nun diese vier Fäden und verflechten Sie sie. Jetzt haben Sie ein komplektiertes System.‹ Beide Konfigurationen (verflochten und unverflochten) können dieselbe technische Aufgabe erfüllen, aber eine ist dramatisch einfacher zu ändern als die andere. Im einfachen System können Sie Anpassungen an einem Strang vornehmen, ohne die anderen berühren zu müssen. Was natürlich ausgesprochen positiv ist.«
Erik lacht: »Wenn man jedoch in einem komplektierten System eine Modifikation an einem Strang vornehmen will, ist man gezwungen, auch die anderen drei Stränge zu ändern. Oft kommt es auch vor, dass man bestimmte Änderungen überhaupt nicht vornehmen kann, weil alles zu eng miteinander verflochten ist.
»Und wenn das passiert«, fährt er fort, »sind Sie in einem Arbeitsmuster gefangen, in dem Sie die realen Geschäftsprobleme nicht mehr problemlos abbilden können – stattdessen sind Sie gezwungen, den ganzen Tag nur noch irgendwelche Rätsel zu lösen, um herauszufinden, wie Sie eine benötigte kleine Veränderung vornehmen können, während Sie permanent durch das komplekte System behindert werden. Sie müssen Besprechungen mit anderen Teams ansetzen, um sie davon zu überzeugen, etwas für Sie zu ändern und es möglicherweise an einen Manager zu eskalieren, vielleicht sogar bis ganz nach oben.
Ihre Arbeit entfernt sich immer mehr von dem eigentlichen Geschäftsproblem, das Sie zu lösen versuchen«, sagt er. »Und genau das, Dwayne, ist passiert, als die Router in den Produktionswerken ausgetauscht wurden. Bis dahin gab es drei unabhängige Stränge mit dazugehörigen Teams, die unabhängig voneinander arbeiten konnten, mit dem Nachteil, dass auch drei Netzwerk-Switches unterhalten und gewartet werden mussten.
Bei der Reduzierung auf einen Switch wurden die Wertströme komplektiert, und gegenseitige Abhängigkeiten wurden eingeführt, die vorher nicht existierten. Jetzt musste ständig kommuniziert und koordiniert werden, man musste Zeitpläne abstimmen, Reihenfolgen festlegen, sich miteinander arrangieren und Konflikte lösen. Durch den erhöhten Koordinationsaufwand verlängern sich die Vorlaufzeiten und verringert sich die Qualität, was – bei Ihrer Geschichte – zu einer einwöchigen Katastrophe mit erheblichen Geschäftsauswirkungen geführt hat, die letztlich erst durch den CEO aufgelöst werden konnte«, erklärt Erik fröhlich.
»Bei der Softwarebereitstellung haben, wie die Senseis Dr. Nicole Forsgren und Jez Humble in ihrer Forschung feststellten, Vorlaufzeiten die gleiche Bedeutung«, fährt er fort. Die Vorlaufzeiten für Deployments, deren Häufigkeit und die für Problemlösungen benötigte Zeit sind wesentliche Faktoren, um den Auslieferungszeitpunkt von Software sowie die operationelle und organisatorische Leistung eines Unternehmens zu prognostizieren – und zudem korrelieren sie mit der Anzahl von Burn-out-Fällen, dem allgemeinen Mitarbeiterengagement und vielem mehr.
Einfachheit ist wichtig, weil sie Lokalität ermöglicht. Lokalität im Code ermöglicht die nur lose Kopplung von Systemen und versetzt uns in die Lage, Software schneller ausliefern zu können. Die Teams können zügig und unabhängig voneinander entwickeln, testen und letztlich den Kunden oder Nutzern Werte bereitstellen. Lokalität innerhalb eines Unternehmens oder von Abteilungen ermöglicht den einzelnen Teams, Entscheidungen zu treffen, ohne mit Personen außerhalb des Teams kommunizieren und sich mit ihnen koordinieren zu müssen, wobei möglicherweise Genehmigungen von organisatorisch weit entfernten Stellen oder Komitees eingeholt werden müssen, bei denen das relevante Wissen für angemessene Entscheidungen gar nicht ausreichend vorhanden ist«, stellt er voller Abscheu fest.
»Entwickler sollten bei Bedarf in der Lage sein, Werte zu schaffen, indem nur eine Datei, ein Modul, ein Dienst, eine Komponente, ein API-Aufruf, ein Container, eine Anwendung geändert werden muss! Deshalb ist es so extrem sinnvoll, Lösungen für übergreifend vorkommende Aufgaben an einer Stelle zu bündeln, wie beispielsweise Regeln für das Logging, die Sicherheit oder die Anzahl von Wiederholungsversuchen. Man ändert etwas zentral, und schon wirkt es überall«, sagt er. »Ist es nicht absurd, dass bei der Einführung eines Features manchmal Änderungen von dem UI-Team, dem Frontend-Team, dem Backend-Team und dem Datenbankteam vorgenommen werden müssen?«
»Interessant«, sagt Maxine. »Mehr Lokalität in unserem Code sowie in unserer Firma wäre wünschenswert – anders als in der jetzigen Situation, in der der Code überall zersplittert rumliegt!«
»Ja, genau. Zersplittert!«, stimmt Erik zu. »Solche Exzellenz erreicht man nicht ohne entsprechenden Einsatz. Das erfordert ständige Fokussierungund Verbesserung der täglichen Arbeit, und das sollte sogar Vorrang haben vor der täglichen Arbeit selbst. Ohne diese gnadenlose Fokussierung wird jedes einfache System im Laufe der Zeit wieder erodieren und zunehmend unter einer dicken Schicht technischer Schulden begraben werden. Sehen Sie sich nur die Katastrophe an, die sich Phoenix-Build-System nennt.«
Maxine runzelt die Stirn. »Sie behaupten, dass Phoenix früher einfacher war, aber jetzt bis zur Unkenntlichkeit komplektiert worden ist? Dass Phoenix früher einen großartigen Build-Prozess besaß, der aber im Laufe der Jahre zugunsten der Features vernachlässigt wurde und schließlich ganz verkümmert ist?«
»Exakt«, bestätigt Erik. »Die Verantwortung für den Build-Prozess wurde von Dev zu QA und dann zu Praktikanten verlagert. Technologiegiganten wie Facebook, Amazon, Netflix, Google und Microsoft übertragen die Verantwortung für die Entwicklungsproduktivität nur den erfahrensten, qualifiziertesten Engineers. Aber hier bei Parts Unlimited geschieht das genaue Gegenteil.«
Dwayne lacht: »Wenigstens werden unsere Builds nicht mehr ausgelagert. Vor nicht allzu langer Zeit kostete jeder Build 85 Dollar.« Alle, auch Maxine, brechen in schallendes Gelächter aus.
Kirsten sagt: »Ich höre immer wieder, dass sich Engineers über technische Schulden beklagen. Aber was genau ist das, abgesehen davon, dass es etwas Negatives zu sein scheint?«
Erik lacht. »Es gibt viele Definitionen, aber ich bevorzuge die ursprüngliche von Ward Cunningham in 2003 aufgestellte. Er hat es so ausgedrückt: ›Technische Schulden sind das, was man zu spüren bekommt, wenn man das nächste Mal etwas ändern will.‹ Es gibt viele Phänomene, die man als technische Schulden bezeichnet, aber in der Regel bezieht sich der Begriff auf Dinge, die wir bereinigen oder bei denen wir Einfachheit schaffen oder wiederherstellen müssen, damit wir schnell, sicher und gefahrlos Änderungen am System vornehmen können.
Manchmal ist es ein Build- oder Testsystem, das den Entwicklern kein schnelles Feedback gibt oder das überhaupt nicht mehr funktioniert«, fährt er fort. »Manchmal sind es einfache Komponenten, die komplektiert werden, sodass man sie kaum noch logisch durchdenken oder nur noch mit immensem Aufwand oder unter Inkaufnahme großer Risiken ändern kann. Manchmal sind es Entscheidungsprozesse oder Organisationsstrukturen, die ihre Lokalitätseigenschaften verlieren, sodass selbst kleinste Entscheidungen eskaliert werden müssen – Ihr berüchtigter Apparat.
Ich nenne diese Probleme gern ›Komplexitätsschulden‹, denn es sind nicht nur technische Fragen – es sind grundsätzliche Businessfragen. Und man muss immer eine Wahl treffen«, sagt er. »Man kann sich entscheiden, neue Features zu programmieren oder aber Komplexitätsschulden zu begleichen. Wenn ein Dummkopf seine ganze Zeit nur mit Features verbringt, werden ganz unvermeidlich selbst einfache Aufgaben schwierig und immer länger dauern. Und egal, wie sehr Sie sich bemühen oder wie viel Arbeitsleistung Sie einsetzen, so ein System bricht schließlich unter seinem eigenen Gewicht zusammen und zwingt Sie, von vorne anzufangen.«
Er sieht Maxine an und fährt fort: »Deshalb ist das, was Sie mit dem MRP-System angestellt haben, so bemerkenswert. Ihre Teams sind in der Lage, neue Funktionen in einer Geschwindigkeit hinzuzufügen, um die sie das gesamte Phoenix-Team beneiden sollte. Und das ist nur möglich, wenn man die Rückzahlung technischer Schulden als Teil der täglichen Arbeit begreift. Es ist ein großartiges Beispiel für das Erste Ideal der Lokalität und Einfachheit in Programmcode und Organisation. Gut gemacht, Maxine.«
Erik steht auf. »Ich bin heute Abend etwas unterbesetzt. Ich schaue später noch einmal vorbei – schön, Sie wiedergesehen zu haben, Kirsten!«
»Oh, noch eine Sache«, fügt er hinzu und dreht sich um. »Beachten Sie die Ergebnisse, die die Technologiemitarbeiter bei der Messung des Mitarbeiterengagements im Vergleich zum Rest des Unternehmens erzielen, und denken Sie über etwaige Differenzen nach, insbesondere beim Phoenix-Projekt.«
Während Maxine Erik nachschaut, der zurück zum Tresen geht, hört sie, wie alle in heftige Diskussionen ausbrechen.
Sie bemerkt ratlos: »Ich verstehe nicht wirklich, was gerade passiert ist.« Sie sieht Kirsten und Kurt an und fragt: »Was war das denn? Und was meinte er mit dem Ersten Ideal?«
»Ich habe keine Ahnung«, antwortet Kurt und schüttelt den Kopf. »Ich kenne Erik seit über einem Jahr. Ich hatte absolut keine Ahnung, dass zwischen ihm und der Firma eine Verbindung besteht …«
Dwayne sagt zu Kurt: »Ich habe mir nie die Mühe gemacht, es zu erwähnen, weil es mir nicht so wichtig erschien. Aber eines Abends hat Erik mich gefragt, ob ich etwas über die Konfiguration von Kubernetes-Clustern wüsste. Das war ziemlich merkwürdig.«
»Das ist seltsam«, bestätigt Shannon. »Wenn ich jetzt darüber nachdenke, hatte ich einmal eine Debatte mit ihm darüber, wie weitgehend man die Daten von Karteninhabern isolieren sollte, um die Sicherheitsstandards der Kreditkartenindustrie zu erfüllen. Er hat mir sogar Links zu den spezifischen Unterabschnitten der entsprechenden Richtlinien geschickt und schien sehr viel Ahnung zu haben. Expertenwissen sogar. Ich dachte mir, es läge daran, dass hier in der Bar auch Kreditkartenzahlungen akzeptiert werden.«
»Mir ist zu Ohren gekommen, dass er viele Gespräche mit Bill Palmer, dem neuen VP of IT Operations, geführt hat«, steuert Kirsten bei. »Bill hat mir erzählt, dass Erik ihm etwas beibringt, das er die Drei Wege und die vier Arten von Arbeit genannt hat.«
»Davon habe ich noch nie gehört«, sagt Maxine. »Er erwähnte nur das Erste Ideal … Ich frage mich, wie viele weitere Ideale es gibt.«
»Und was meinte er mit ›Messung des Mitarbeiterengagements‹?«, fragt Kurt.
»Ich habe keine Ahnung«, gibt Kirsten zu. »Ich weiß nur, dass wir mit die höchsten Werte an Mitarbeiterzufriedenheit in unserer Branche haben – mit Ausnahme der IT-Abteilung, hier liegt sie bei –27, wenn ich mich nicht irre.«
»Ist das schlecht?«, fragt Dwayne.
Kirsten wirkt betreten. »Äußerst schlecht.«
Maxine ist nicht überrascht. Und doch stört sie etwas. Im Townhall-Meeting sprach Steve darüber, wie sehr ihm das Engagement der Mitarbeiter am Herzen liegt. Was denkt er wohl, wenn er erfährt, dass in der Abteilung, die für das strategisch wichtigste Programm im Unternehmen verantwortlich ist, Unzufriedenheit herrscht? Sollte ihn das nicht beunruhigen?
Als Erik noch einmal mit einem Bier in der Hand vorbeikommt, steht Maxine auf und eilt ihm nach. »Nochmals vielen Dank für die freundlichen Worte, Erik. Sie haben das Erste Ideal erwähnt – wie viele gibt es davon, und wie lauten sie?«
»Ha! So funktioniert das nicht«, antwortet Erik lachend. »Tatsächlich habe ich auch Bill Palmer ziemlich durch die Gegend gescheucht, um alle vier Arten von Arbeit zu erkennen. Aber … vielleicht kann ich Ihnen allen einen Startbonus geben.«
Erik und Maxine kommen zurück an den Tisch. »Es gibt fünf Ideale«, beginnt Erik. Die ganze Tafel richtet ihre Aufmerksamkeit auf ihn. »Ich habe Ihnen bereits vom Ersten Ideal der Lokalität und Einfachheit erzählt. Wir müssen Dinge so konzipieren, dass in unseren Systemen und den Organisationen, die diese Systeme erschaffen, das Lokalitätsprinzip verwirklicht ist. Und wir müssen für Einfachheit sorgen in allem, was wir tun. Wir wollen intern möglichst keine Komplexität haben – weder in unserem Code noch in unserer Organisation oder in unseren Prozessen. Die Außenwelt ist komplex genug, es ist also nicht zu tolerieren, dass wir sie in Bereichen zulassen, die wir tatsächlich kontrollieren können! Wir müssen uns unsere eigene Arbeit so einfach wie möglich machen.«
Maxine setzt sich wieder hin, öffnet ihren Laptop, freut sich, dass sie diesmal daran gedacht hat, ihn einzupacken, und beginnt, sich Notizen zu machen.
»Das Zweite Ideal: Fokus, Flow und Freude. Es geht darum, wie sich unsere tägliche Arbeit anfühlt. Ist unsere Arbeit von Langeweile und dem Warten auf andere Menschen geprägt, die für uns Dinge erledigen sollen? Arbeiten wir blind an kleinen Teilen eines Ganzen und sehen die Ergebnisse unserer Arbeit erst während eines Deployments, wenn alles in die Luft fliegt, was zu Noteinsätzen, Strafaktionen und Burn-out führt? Oder arbeiten wir in kleinen Schüben, idealerweise im One-Piece-Flow, einem mitarbeitergebundenen Arbeitsfluss, und erhalten so schnell und kontinuierlich Feedback zu unserer Arbeit? Das sind die Bedingungen, die Fokus und Flow, Herausforderungen, Lernen, Entdeckerfreude, die Beherrschung unseres Handwerks und sogar Spaß an der Arbeit ermöglichen.«
Er schaut sich mit einem süffisanten Gesichtsausdruck am Tisch um. »Und das ist im Moment alles, was Sie von mir bekommen. Die anderen drei Ideale werde ich Ihnen verraten, sobald Sie dazu bereit sind.«
»Nehmen Sie uns auf den Arm?«, fragt Maxine. »Sie ziehen eine Art Yoda- oder Mr.-Miyagi-Spielchen mit uns ab? Kommen Sie, verraten Sie uns wenigstens die Bezeichnungen der anderen Ideale!«
»Zum Glück für Sie, junge Lady, habe ich keine Zeit zum Streiten, denn an der Bar steht eine Schlange, um die ich mich kümmern muss«, antwortet Erik. »In absoluter Kurzform: Das Dritte Ideal lautet Verbesserung der täglichen Arbeit. Denken Sie darüber nach, was die Toyota-Andon-Cord bzw. -Reißleine uns darüber lehrt, inwiefern wir die Verbesserung der täglichen Arbeit über die tägliche Arbeit selbst stellen müssen. Das Vierte Ideal ist die psychologische Sicherheit, durch die wir dafür sorgen, dass über Probleme gesprochen werden kann, denn die Lösung von Problemen erfordert Prävention, die wiederum Ehrlichkeit erfordert, und Ehrlichkeit erfordert die Abwesenheit von Angst. In der Produktion ist die psychologische Sicherheit ebenso wichtig wie die physische Sicherheit. Und schließlich ist das Fünfte Ideal die Kundenorientierung, bei der wir uns schonungslos fragen, ob etwas für unsere Kunden tatsächlich von Bedeutung ist, womit zum Beispiel eine Frage gemeint ist wie: Sind unsere Kunden bereit, uns für ein Produkt zu bezahlen, oder haben wir es nur aus Eigeninteresse geschaffen?«
Erik trinkt sein Bier aus und sagt mit einem Lächeln: »Ihnen allen viel Glück. Bis nächste Woche.«
»Warten Sie, warten Sie, das war’s?«, fragt Maxine, aber Erik ist schon weg. Maxine schaut auf ihre schnell getippten Notizen:
Erstes Ideal – Lokalität und Einfachheit
Zweites Ideal – Fokus, Flow und Freude
Drittes Ideal – Verbesserung der täglichen Arbeit
Viertes Ideal – Psychologische Sicherheit
Fünftes Ideal – Kundenorientierung
Maxine starrt auf die Liste – das klingt ja alles ganz nett, aber wie in aller Welt sollen sie diese Ideale dazu nutzen, den Verlauf des Phoenix-Projekts zu verändern?
»Das war wirklich seltsam«, findet Kurt und spricht aus, was alle denken.
Nörgel-Dave fügt hinzu: »Der Teil über das Vierte Ideal hat voll gesessen. Eine Kultur der Angst, in der sich jeder davor fürchtet, schlechte Nachrichten zu verbreiten? Das trifft es genau.«
»Erik hat recht«, stimmt Adam zu. »Niemand spricht über das eigentliche Problem. Die meisten trauen sich nicht, ihre Meinung zu äußern oder das Richtige zu tun. Sie sagen einfach Ja, egal ob sie einverstanden sind oder nicht. Aber möglicherweise ergibt sich daraus eine Chance. Es gibt zurzeit einige große, klaffende Löcher im Organigramm«, sagt er zu Kurt. »Du solltest für eine der offenen Positionen deinen Hut in den Ring werfen. Vielleicht sogar für den Posten von William?«
Stille senkt sich über den Tisch, als sich alle auf Adam und Kurt konzentrieren.
»Das ist eine ziemlich gute Idee, Kurt. Du könntest in QA wirklich etwas bewegen. Du weißt, wie sehr wir uns hier darüber freuen würden«, sagt Shannon, während alle am Tisch murmelnd Zustimmung signalisieren.
»Vielleicht«, sagt Kurt und nickt langsam. »Aber wisst ihr, wenn wir wirklich etwas verändern wollen, gibt es einen anderen Weg. Ich denke darüber nach, Chris mitzuteilen, dass ich Peters Posten will.«
Maxine hört einige am Tisch schwer atmen, gefolgt von Nörgel-Daves lautem Lachen. »Du hast recht, Kurt. Mit der Übernahme eines Dev-Teams würdest du auf jeden Fall viel mehr bewirken können. Wir alle wissen, dass wir die Art und Weise ändern müssen, wie QA Tests durchführt, aber noch besser wäre es, wenn wir die Art und Weise ändern könnten, in der DevTests durchführt. Und dazu muss man Dev-Manager sein – auch wenn sich da ein klitzekleines Problem auftut: Sie werden dir diesen Posten niemals geben, Kurt«, bedauert er. »Du weißt: weil du ›bloß ein QA-Manager‹ bist.«
Maxine verzieht das Gesicht. Nörgel-Dave äußert ein allzu populäres Vorurteil, das Entwickler über QA-Leute pflegen, wie sie beschämt erkennt. QA wird oft als minderwertig angesehen, selbst wenn diese Abteilung für wichtiger als Ops gehalten wird. Das ist alles Schwachsinn, findet Maxine. Schließlich hat sie ihre eigene Ops-Karriere bereits in der Highschool begonnen, indem sie regelmäßig die Sicherungsbänder gewechselt hat, und war später selbst in der Qualitätssicherung beschäftigt – ohne diesen Hintergrund wäre sie in beruflicher Hinsicht nicht zu der Person geworden, die sie heute ist. Technologie ähnelt immer noch viel zu oft einem Kastensystem.
Adam sagt zu Kurt: »Du weißt, dass ich dich wirklich bewundere und gern mit dir arbeite. Du bist ein hervorragender Manager – aber ich muss Dave recht geben. Niemals wird dieser Haufen von Dev-Managern einen QA-Manager auf diesen Posten lassen. Vielleicht solltest du dich einfach mit Williams Position zufriedengeben. Schließlich muss auch jemand die Qualitätssicherung aus der Steinzeit führen und automatisierte Tests im Rest des Phoenix-Projekts einführen.«
»Ich muss Ihren Freunden zustimmen, Kurt«, bestätigt Kirsten. »Sie und ich, wir wissen beide, dass William nie ein echter Fan von Ihnen war. Er hat Sie in den Sitzungen nie lobend erwähnt. Wahrscheinlich werden sie jemanden von außen besetzen.«
Kurt schmunzelt, von Kirstens Beobachtung offensichtlich nicht sonderlich beunruhigt. In einer großartigen William-Imitation sagt er: »›Ja, Kirsten, Sie haben recht. Obwohl Kurt ein gewisses Potenzial zeigt, ist mir klar, dass er vom Testen nichts versteht. Vielleicht wird er in ein paar Jahren die Reife haben, die Qualitätssicherung zu leiten.‹«
Alle lachen. Kurt fährt mit seiner normalen Stimme fort: »Leute, das ist eine echte Gelegenheit für uns, etwas zu verändern. Aber ich glaube nicht, dass wir das von QA aus tun können – QA, wie wir es kennen, verändert sich. Wir können nicht weiterhin diejenigen sein, die alles erst im Nachhinein testen. Wir müssen richtig ins Spiel kommen, und das bedeutet, dass wir uns in die Entwicklungsteams vorarbeiten müssen, die ja für die Auslieferung von Features und deren Qualität in der Praxis verantwortlich sind. Alles andere ist Zeitverschwendung.«
Er fährt fort: »Wenn wir Peters Team übernehmen könnten, wäre es mein Ziel, zu zeigen, dass wir jedes andere Dev-Team im Phoenix-Projekt übertreffen können. An diesem Tisch sitzen einige der größten technischen Talente des Unternehmens, und wir haben bereits die Infrastruktur geschaffen, um einige hervorragende technische Praktiken ins Spiel zu bringen.«
Kurt lehnt sich vor. »Wenn ich Chris dazu bringen kann, mir diese Chance zu geben, wärt ihr dann bereit, mitzumachen und zu zeigen, dass wir das Schicksal des Phoenix-Projekts ändern können?«
»Verdammt ja, Kurt. Ich bin dabei«, sagt Nörgel-Dave. Maxine ist überrascht, dass er der Erste ist, der sich freiwillig meldet.
Maxine schließt sich an. »Und ich. Das ist genau das, woran ich gern mitarbeiten würde. Und ich weiß, dass wir alle anderen Teams locker überflügeln können. Ich habe die Konkurrenz aus nächster Nähe gesehen«, sagt sie lächelnd.
Alle am Tisch sagen zu und freuen sich auf diese mögliche Gelegenheit. Nörgel-Dave fasst zusammen: »Okay, wir sind alle dabei, Kurt. Aber ehrlich gesagt: Erwarte nicht zu viel. Adam hat recht – es ist nicht sehr wahrscheinlich, dass sie dir ein Dev-Team geben.«
Kirsten wirft ein: »Kurt, ich glaube, Sie haben den richtigen Riecher. Wenn Sie wollen, schreibe ich ein Empfehlungsschreiben an Chris.«
»Das wäre fantastisch, Kirsten«, strahlt Kurt, offensichtlich überrascht und dankbar über Kirstens Angebot. In diesem Moment wird Maxine klar, dass Kurt die ganze Zeit ohne wirkliche Deckung durch irgendeine Führungsebene operiert hat. Er könnte für sein abtrünniges Verhalten gefeuert werden, ist ihr klar.
»Ich helfe gern«, sagt Kirsten. »Aber lassen Sie mich eines klarstellen. Ich bin bereit, einen Brief zu schreiben, in dem ich Kurts Ideen unterstütze, aber ich darf mich nicht öffentlich zusammen mit euch Rebellen zeigen. Zumindest jetzt noch nicht. Ich muss als unparteiisch wahrgenommen werden.«
»Aha. Sie sind also bereit, uns dabei zu helfen, ein Risiko einzugehen und dafür schlimmstenfalls gefeuert zu werden, aber Sie selbst wollen auf der sicheren Seite bleiben«, kommentiert Nörgel-Dave, nur halb im Scherz. Kirsten hebt lediglich ihr Glas als Antwort.