Probleme entstehen. Wo sie herkommen, ist nicht immer gleich klar. Irgendwann sind sie da. Und sie dürfen nicht ignoriert werden. Erst recht nicht, wenn sie lebensbedrohlich (für das Projekt) sind.

Vor 50 Jahren, am 20. Juni 1975 lief in den USA „Jaws (Der Weiße Hai)“ in den Kinos an (Deutschlandstart: 18. Dezember 1975). Als erster Film überhaupt spielte er über 100 Millionen Dollar ein und wurde zum ersten Sommer-Blockbuster überhaupt. Ein Begriff, den er bis heute prägt. Ich bin schon immer sehr großer Fan und war auch dieses Jahr zu einer Jubiläumsvorstellung noch einmal im Kino. Gerade wenn ich einen Film schon mehrfach gesehen habe, fallen mir beim erneuten Anschauen öfter erstaunliche Dinge auf. In der Handlung des Films gibt es interessante Parallelen zum Umgang mit Problemen in Software-Projekten, die ich hier gerne aufzeigen möchte. Der Ablauf der Ereignisse im Film entspricht mehr oder weniger genau den Abläufen in Software-Projekten, wenn (größere) Probleme auftreten.

Spoiler-Warnung! Du musst den Film nicht gesehen haben, bevor du den Beitrag weiterliest. Ich verrate jedoch wesentliche Teile der Handlung. Ich empfehle dir aber sowieso den Film zu schauen, denn er ist ein Meisterwerk. Einen kleinen Appetizer von mir persönlich findest du hier.

Das Problem selbst ist verborgen, seine Auswirkungen sind jedoch schmerzhaft zu spüren

Der Film beginnt damit, dass eine Gruppe nachts am Strand der Ferieninsel Amity Island feiert. Alle haben offensichtlich eine gute Zeit. Ein junges Paar verlässt die Gruppe und beschließt schwimmen zu gehen. Der Mann ist aber zu betrunken und schafft es nicht mehr, der Frau ins Wasser zu folgen. Die Frau genießt es sichtlich, allein im Meer zu schwimmen. Plötzlich gibt es jedoch ein Problem. Sie fängt an zu schreien und wird unter offensichtlichen Schmerzen wild im Wasser hin und her gerissen, bis sie plötzlich ganz unter Wasser gezogen wird und verschwindet.

Hier gibt es direkt Parallelen zu Software-Projekten. Auch diese fangen meist fröhlich an. Alle im Team haben eine gute Zeit. Doch dann, oft wie aus dem Nichts, läuft es plötzlich gar nicht mehr gut. Es passiert etwas Schreckliches. Genau wie im Film ist nicht klar, was eigentlich das Problem ist. Aber die Schmerzen sind direkt deutlich zu spüren (Performanz stimmt nicht, Instabilität, Deadlines können nicht gehalten werden, o. Ä.). So weit, so gut. Es ist völlig normal, dass in Projekten auch mal Probleme auftreten. Wir müssen aber richtig mit ihnen umgehen.

Eigentlich wird direkt erkannt, dass etwas nicht stimmt und woran es wohl liegt

Nachdem der junge Mann im Film am nächsten Morgen die Frau als vermisst gemeldet hat, macht sich die Polizei unter Leitung von Chief Brody auf die Suche nach ihr. Schnell wird ihre Leiche mit massiven Wunden am Strand gefunden. Chief Brody ordnet sofort eine gerichtsmedizinische Untersuchung an. Nach Untersuchung der Wunden bekommt er als Rückmeldung vom Inselarzt: „Hai Angriff“. Chief Brody macht das einzig vernünftige in dieser Situation und beschließt die Strände zu schließen, um keine weiteren Menschen in Gefahr zu bringen. Er macht sich mit seinen Kollegen auf, um entsprechende Schilder am Strand aufzustellen.

Genauso verläuft es auch in Software-Projekten, wenn ein größeres Problem aufgetreten ist. Sobald auffällt, dass etwas nicht stimmt, wird dies gemeldet. Es wird zudem direkt untersucht, wie es wohl dazu kommen konnte. Das Team hat meist direkt eine gute Einschätzung, woran es liegt. Die Zeichen sind oft recht klar. Die wahrscheinliche Ursache meist schnell gefunden. Diese Erkenntnisse werden besprochen und es ist damit schnell klar, was getan werden muss. Die Maßnahmen zur Verhinderung weiterer Probleme sind naheliegend und das Team beginnt damit, sie zu ergreifen.

Doch es wird direkt politisch

Chief Brody und sein Team kommen im Film jedoch gar nicht dazu, mit der Schließung der Strände auch nur anzufangen. Die Nachricht vom Hai-Angriff hat sich auf der kleinen Ferieninsel schnell herumgesprochen. Die Inselverwaltung unter Führung des Bürgermeisters mischt sich sofort in die Polizeiarbeit ein. Sie hat Angst um das Image der Insel. Ein Hai-Angriff ist ganz schlecht für das Touristen-Business der Insel, das so kurz vor dem Nationalfeiertag am 4. Juli nicht gefährdet werden darf. Chief Brody wird sofort bedrängt, die Strände nicht zu schließen. Der Bürgermeister hat auch direkt den Inselarzt mitgebracht, der mittlerweile seine Meinung geändert hat. Er behauptet nun, es könnte auch ein Bootsunfall gewesen sein und die Todesursache könnte Schiffsschraubenverletzungen sein. Da Chief Brody nun jegliche Grundlage fehlt, bleiben die Strände offen.

Leider läuft es in Software-Projekten zu oft sehr ähnlich. Wenn die nötigen Maßnahmen ergriffen werden sollen, um Probleme zu beheben, mischt sich „das Management“ ein. Durch die Maßnahmen würde offensichtlich werden, dass es wirklich ein größeres Problem im Projekt gibt. Sie haben Angst davor, dass dies ein schlechtes Licht auf das Projekt und somit auch auf ihre Arbeit wirft. Das wollen sie unbedingt vermeiden. Die Unternehmensleitung und/oder Auftraggeber sollen das nicht erfahren. Die möglichen negativen Konsequenzen der Maßnahmen werden übermäßig groß geredet. Die negativen Konsequenzen durch das Auslassen der Maßnahmen werden klein geredet. Das Team ist sich zwar meist ziemlich sicher, woran es liegt, kann es aber es nicht 100%ig beweisen und fügt sich.

Irgendwann ist Problem nicht mehr zu übersehen

Die Strände bleiben im Film somit leider geöffnet und es kommt, wie es kommen muss. Wenige Tage später wird ein badendes Kind auf seiner Luftmatratze von einem Hai angegriffen und getötet. Der Stand war gut besucht und viele Menschen haben den Haiangriff miterlebt. Das Hai-Problem ist jetzt offensichtlich und kann nicht mehr geleugnet oder ignoriert werden.

Nur weil Probleme ignoriert werden, verschwinden sie nicht von allein. Wenn in Software-Systemen etwas nicht stimmt, dann tritt dies immer und immer wieder zutage. Irgendwann sind die Auswirkungen dann so drastisch, dass sie weit über das Projekt hinaus wahrgenommen werden. Wir bekommen beispielsweise immer wieder mit, dass es zu größeren Verlusten von (persönlichen) Daten in größerem Umfang kommt. Solche Meldungen gehen oft sogar weit über die Fachpresse hinaus. Es ist unmöglich, das Problem dann noch klein zu reden oder zu ignorieren.

Blinder Aktionismus und panische Überreaktionen folgen

Der Tod des Kindes ist natürlich ein Schock. Alle wissen es: Amity Island hat ein Hai-Problem. Als Ferieninsel machen sich natürlich alle Sorgen um ihr Business. Sie wollen vermeiden, dass die Touristen aus Angst nicht mehr auf ihre Insel kommen. Sie müssen schnell handeln und setzen eine Belohnung von 3.000$ (Wert im Jahr 2025 ca. 18.000$) aus, um den Hai zu töten. Daraufhin machen sich dutzende Hobby-Hai-Jäger ans Werk. Die meisten wissen gar nicht genau, was sie tun und greifen zu fragwürdigen Methoden. Außerdem behindern sich die vielen Hai-Jäger offensichtlich gegenseitig. Es herrscht Chaos auf der Insel.

Solch blinden Aktionismus beobachten wir wieder leider auch oft in Software-Projekten, sobald ein Problem bekannt wurde. Die ganze Zeit wurde versucht, das Problem klein zu reden und es zu ignorieren. Jetzt, wo es (zu) viele mitbekommen haben, muss natürlich sofort gezeigt werden, dass das Problem „natürlich ernst genommen“ wird. Möglichst viele Maßnahmen sollen möglichst vielen Leuten zeigen, dass jetzt „alles getan wird“, um das Problem zu beheben. Leider ist hier oft keine klare Methodik zu erkennen. Dass etwas getan wird, scheint wichtiger zu sein, als was tatsächlich getan wird.

Prinzip Hoffnung: Schnelle Ergebnisse schönreden

Die Hobby-Hai-Jäger fangen tatsächlich einen Hai. Einen Tigerhai. Der ist ein Menschenfresser und in den Gewässern von Amity Island sogar recht selten. Die Inselverwaltung ist überglücklich, dass direkt ein Erfolg gezeigt werden kann. Mit großer Presse wird der getötete Hai präsentiert und das Problem sofort als gelöst bezeichnet.

Auch diese Situation kennen wir nur zu gut aus Software-Projekten. Wenn viele Entwickler gleichzeitig an vielen Stellen panisch nach Ursachen von Problemen suchen, dann werden sie auf jeden Fall welche finden. Ziemlich sicher sogar welche, die bisher völlig unentdeckt geblieben sind. Wahrscheinlich sogar welche, die zu schlimmen Problemen führen. Da schnell Ergebnisse gebraucht werden, um weiteren (öffentlichkeitswirksamen) Schaden zu vermeiden, werden diese Ergebnisse sehr gerne (zu) schnell (der Öffentlichkeit) präsentiert. Damit kann gezeigt werden, dass schnell gehandelt wurde und das Problem gelöst ist.

Neutrale Bewertung einholen

Entgegen dem blinden Aktionismus der Inselverwaltung handelt Chief Brody im Film jedoch mit Vernunft. Er holt sich professionelle Hilfe. Diese trifft in Gestalt von Matt Hooper, einem Hai-Experten vom Ozeanischen Institut auf. Unbeeindruckt vom panischen Treiben auf der Insel untersucht Hooper völlig neutral die vorliegenden Fakten. Er betrachtet erneut die bisherigen Opfer und sieht sich auch den gefangenen Tigerhai genau an.

Erfreulicherweise holen sich auch Software-Projekte oft professionelle Hilfe zur Bewertung der aktuellen Situation. Manchmal auf eigene Initiative. Manchmal auf „Druck von außen oder oben“. Eine neutrale Perspektive, die unbeeindruckt von den Emotionen im Projekt die Fakten untersucht, ist extrem hilfreich. Eine neutrale Bewertung der Situation ist eine solide Grundlage, um darauf basierend, besonnen die richtigen Entscheidungen für die Problembehebung zu treffen.

Argumente dafür schönreden, Argumente dagegen schlechtreden

Hooper kommt im Film sehr schnell zur Erkenntnis, dass der gefangene Hai nicht für die bisherigen Opfer verantwortlich ist. Die Wunden der Opfer passen überhaupt nicht zum Bissradius des gefangenen Tigerhais. Zudem hat er den Mageninhalt des Tigerhais untersucht. Wäre der Hai für den Tod des Kindes verantwortlich, hätte er dort Hinweise finden müssen. Zudem hat er am Boot eines bisher unentdeckten weiteren Opfers einen riesigen Zahn von einem Weißen Hai gefunden. Damit ist ihm auf Basis von klaren Fakten klar, dass der getötete Tigerhai nicht die Ursache des Problems ist. Chief Brody schließt sich Hoopers professioneller Meinung an und gemeinsam versuchen sie den Bürgermeister davon zu überzeugen, dass das echte Problem, der Weiße Hai, weiterhin gefunden werden muss. Der möchte davon jedoch nichts hören. Er ist überglücklich, dass er mit dem Tod des Tigerhais der Öffentlichkeit eine Problemlösung präsentierten konnte und bemüht sich ausschließlich um Schadenbegrenzung für das Touristen Business. Von „weiteren“ Problemen möchte er nichts hören.

Leider erleben wir genau solche Situationen immer wieder in Software-Projekten. Es liegen harte Fakten vor, die aufzeigen, dass ein Problem vorliegt. Dennoch wird nicht auf Basis dieser Fakten gehandelt. Es wird viel Zeit darauf verwendet, die Fakten zu hinterfragen. Da wir es im Software Business ganz selten mit 100%igen Fakten zu tun haben, bleibt immer eine kleine Unsicherheit bestehen. Wenn die Experten sich mit einem Fakt nur zu 99% sicher sind, dann wird ewig darüber diskutiert, dass es damit ja wohl nicht 100%ig ist. „Auf solch unsicherer Basis können wir nicht das ganze Projekt umwerfen.“ Selbst wenn es dann mehrere solcher 99%igen Fakten gibt, die jeder einzeln schon dafür sorgen müssten, das Vorgehen im Projekt zu ändern, reicht das leider nicht immer aus. Das Team klammert sich an die äußerst unwahrscheinliche Chance, dass es dann doch anders ist. Die Basis für das momentane Vorgehen ist zwar noch nicht mal annähernd bei 99% (eher so bei 8%), aber das wird nicht mehr hinterfragt. Denn das hat man ja vor langer Zeit schon so entschieden. Für Änderungen will man aber 100%ig sicher sein. Das ist aber leider im Software Business (beinahe) nie der Fall.

Einfach so weitermachen trotz ungutem Gefühl

Entgegen jeder Vernunft werden die Strände auf Amity Island wieder geöffnet. Die Badegäste haben jedoch alle ein ungutes Gefühl und keiner geht baden. Der Bürgermeister überredet jedoch einige Gäste, doch ins Wasser zu gehen. Nachdem die Ersten mit sichtlichem Unbehagen ins Wasser gehen, folgen ihnen auch alle anderen.

Diese Situation ist uns leider auch nur zu gut bekannt. Eigentlich haben alle Team Mitglieder ein ungutes Gefühl dabei, im Projekt genauso weiterzumachen. Für jede:n Einzelne:n ist mehr oder weniger klar, dass es (noch) ein Problem gibt und dass es sehr gefährlich ist, das Problem nicht explizit anzugehen. Jedoch sagt keiner etwas. Oder zumindest nicht genügend viele. „Wenn kein anderer was sagt, dann wird das so schon passen.“ Alle sehen die Wand und fahren trotzdem mit voller Geschwindigkeit darauf zu.

Problem geht einfach nicht weg

Der Weiße Hai ist aber immer noch da. Denn er geht nicht von allein weg. Hooper erklärt im Film sogar genau, warum das so ist. Der Weiße Hai bleibt so lange in einem Gebiet, bis ihm dort die Nahrung ausgeht. Und so kommt es leider unvermeidlich zum nächsten Opfer, das auch wieder unter den Augen einer größeren Öffentlichkeit vom Hai getötet wird.

Es ist nur eine Frage der Zeit, bis Software-Probleme (wieder) auftauchen. Software altert nicht und sie unterliegt auch keiner mechanischen Abnutzung. Wenn ein Problem existiert, wird es immer und immer wieder auftreten. Die Auswirkungen können variieren. Mal sind sie weniger drastisch und werden nur von wenigen bemerkt. Mal sind sie katastrophal und alle bekommen es mit. Da oft viele Dinge zusammenwirken müssen, damit das Problem auftritt, kann es aber eine ganze Weile dauern. Aber die Frage ist nie, ob ein Problem (wieder) auftritt, die Frage ist nur, wann.

Dranbleiben und tun, was getan werden muss

Chief Brody hat jetzt genug. Es darf so nicht weitergehen. Der Weiße Hai muss getötet werden. Er lässt sich vom Bürgermeister alle Vollmachten geben, so dass er selbst entscheiden kann, was als nächstes getan wird. Endlich bekommt er die Unterschrift des Bürgermeisters, aber erst, nachdem dessen eigener Sohn in direkter Gefahr war.

Jedes Software-Projekt braucht einen Chief Brody. Jemanden, der ernsthaften Problemen auf den Grund gehen will. Der nicht müde wird, immer wieder den Finger in die Wunde zu legen. Der sich nichts vormachen lässt. Der sich nicht mit müden Ausreden und lahmen Maßnahmen zufriedengibt. Jemand, der die Stimme der Vernunft ist und die richtigen Maßnahmen ergreifen will. Brody geht dabei von Anfang an bedächtig vor. Er handelt nicht direkt aggressiv oder unvernünftig, sondern spielt nach den vorherrschenden Regeln. Aber nur bis zu einem gewissen Punkt. Wenn die Regeln nicht (mehr) funktionieren, dann müssen sie geändert oder umgangen werden. Auch wenn er selbst nicht weiß, was genau getan werden muss. Er weiß, dass es so nicht weitergehen darf. Er handelt nicht aus Eigeninteresse. Es geht ihm ums Projekt. Er ist bereit, seine Komfortzone zu verlassen und selbst mit anzupacken. Im Film geht Brody auf Haifang, obwohl er Angst vor Wasser hat.

Experten zur Problemlösung hinzuziehen

Um den Weißen Hai zu töten, heuert Brody den Haifänger Quint an. Zusammen mit Hooper stechen sie zu dritt mit Quints Boot in See. Der Film ist jetzt erst zur Hälfte um. In der zweiten Hälfte geht es nur noch um die Jagd auf den Weißen Hai. Darauf möchte ich jetzt hier aber gar nicht mehr eingehen. Aber wichtig ist: Brody hat Experten hinzugezogen und geht das Haiproblem gemeinsam mit ihnen an. Quint hat jahrzehntelange Erfahrung im Fangen von Haien. Er hat auch spezielle, unkonventionelle Methoden, die genau für den Umgang mit großen Haien besonders geeignet sind. Auch Hooper hat mordernste Technik, die dabei hilft, den Hai zu finden und zu töten.

Auch in Software-Projekten kann es sinnvoll und nötig sein, Experten (von außen) hinzuzuziehen, um ein Problem zu finden und zu lösen. Bestenfalls gehen die Experten zusammen mit dem Team „auf die Jagd“. Sie bringen aber oft eine Expertise ein, die im Team nicht (ausreichend) vorhanden ist. Sie haben meist jahrelange Erfahrung und schon viel gesehen. Auch wenn jedes Problem natürlich neu und projektspezifisch individuell verschieden ist, so können sie viel von ihrer Erfahrung aus anderen Projekten einbringen. Oft haben sie auch (eigene) Techniken, Methoden und Tools, die nicht unbedingt weit verbreitet sind. Vielleicht erscheinen diese auf den ersten Blick auch unkonventionell, doch sie haben sich vielfach bewährt.

”Sie werden ein größeres Boot brauchen.” … vielleicht

Nachdem Brody (und damit auch das Film-Publikum) den Weißen Hai zum ersten Mal aus der Nähe sieht, geht er erschrocken zu Quint und sagt „Sie werden ein größeres Boot brauchen (You’re gonna need a bigger boat)“. Das berühmte Filmzitat ist mittlerweile Teil der (amerikanischen) Umgangssprache. Es drückt aus, dass es definitiv ein großes, massives Problem gibt und dass ernsthafte, drastische Maßnahmen ergriffen werden müssen, um das Problem zu lösen. Wir alle können mit solchen Situationen in Software-Projekten konfrontiert werden. Probleme entstehen. Das ist leider unvermeidbar. Manchmal sind die Probleme sogar so groß, dass enorme Anstrengungen unternommen werden müssen, um sie zu beheben. Das ist nicht schön. Niemand hat Lust auf sowas. Aber es muss sein. Für das Projekt oder das Produkt. Das Schlimmste ist, nichts zu tun. Ignorieren hilft nicht. Kleinreden bringt nichts. Halbherzige Maßnahmen zu ergreifen, um Aktivität vorzutäuschen, ist Zeitverschwendung. Wenn es ein Problem im Projekt gibt, muss es ehrlich angesprochen werden, die Ursache gefunden und dann behoben werden. Auch wenn das Zeit und Budget kostet. Wird es nicht gleich richtig gemacht, dann wird es am Ende immer noch teurer.

Ein Tipp von mir für deinen nächsten Filmabend: Schau dir doch „Der Weiße Hai“ (nochmal) an und denke dabei an dein aktuelles Projekt. Ich bin mir sicher, dir fallen einige Parallelen auf, die ich hier noch gar nicht angesprochen habe. Der Film lohnt sich aber so oder so.