Ja, hi. Wir reden heute ein bisschen über Scaling Scrum, ein bisschen über Challenging Scrum und ein bisschen über Art-Child-Experience.

Das Ganze wird in Deutsch stattfinden. Wir wollen möglichst authentisch über unseren praktischen Arbeitsalltag berichten.

Wenn ihr zwischendurch irgendwelche Fragen habt, gern her damit. Ansonsten auch gerne danach. Wir haben noch genügend Zeit.

Und jetzt wünsche ich euch viel Spaß bei unserem Vortrag.

Wusstet ihr, dass über 30% aller großen IT-Projekte scheitern?

Und mit scheitern meine ich jetzt nicht over time oder over budget, sondern ich meine, dass damit wirklich keine Software rauskommt, die am Ende genutzt werden kann.

Aber warum ist das eigentlich so? Große IT-Projekte werden immer komplexer, immer verzahnt, es sind immer mehr Leute involviert.

Was dabei irgendwie unumgänglich ist, ist, dass Missverständnisse passieren. Ein Bild, das hierfür sehr bezeichnend ist, ihr habt es bestimmt schon mal gesehen, ist das Bild der Schaukeln.

Und so ist es wirklich. Das können wir jetzt sagen. Am Anfang seht ihr, was der Kunde mal gesagt hat, was er möchte.

Und ganz am Ende dann, was er eigentlich haben wollte, dazwischen die ganzen Missverständnisse, wie sich das Projekt ändert, wie die Anforderungen missinterpretiert werden von den einzelnen Leuten.

Das bedeutet, ein Grund, warum viele Projekte scheitern, ganz klar Missverständnisse zwischen den ganzen Involvierten.

Das ist aber nicht der einzige Grund, es gibt noch einige weitere, zum Beispiel Requirements to Change, also Anforderungen können sich ändern.

Es gibt, ich meine, immer schneller neue Technologien, darauf muss man reagieren können. Der Hauptwettbewerber bringt vielleicht ein neues Produkt auf den Markt, auch darauf will reagiert werden.

Es gibt neue Regulatorien, Umwelteinflüsse. Wenn man da im Projekt nicht reagieren kann, dann ist das zum Scheitern verurteilt.

Was kann noch passieren? Stakeholder Change. Wir haben schon gehört, es gibt extrem viele Stakeholder in großen IT-Projekten.

Wenn sich da irgendwas verändert und das Projekt nicht reagieren kann, dann ist es auch zum Scheitern verurteilt.

Understanding Changes passiert auch häufig, also einfach das Verständnis des Kunden für das Problem oder auch für die Lösung ändern sich.

Selbst wenn man jetzt verstanden hat, dass sich irgendwas geändert hat, also Anforderungen, Stakeholder oder das Verständnis des Kunden, dann muss man auch erst mal schaffen, diese Veränderung zu managen.

Nicht umsonst gibt es in der Uni tausende Change-Management-Kurse. Leute ändern sich ungern.

Man muss ihnen wirklich gute Argumente vorbringen und hört immer zu, die Sätze, ja, das mache ich schon 20 Jahre so, das klappt immer oder never change a running system.

Also wenn man möchte, dass Leute sich ändern, dann muss man da hart darum kämpfen und das ist wirklich keine einfache Sache. Auch daran können Projekte scheitern.

Selbst wenn man dann geschafft hat, diesen Change zu managen und man hat ein neues System, dann ist immer noch die Systemintegration anstehend.

Viele IT-Systeme sind über Jahrzehnte gewachsen, das sind riesen Monolithen, keiner weiß mehr ganz genau, wie die funktionieren, keiner traut sich daran.

Das bedeutet, System Integration ist wirklich schwierig und auch ein Grund für das Scheitern vieler Projekte.

Genau das ist jetzt auch der Grund, warum, wie ich euch zu Beginn gesagt habe, über 30% aller großen IT-Projekte scheitern.

Ihr seht schon, diese Zahl gilt für Wasserfallmodelle, also Projekte, die mit dem herkömmlichen Wasserfallmodell gemanagt werden.

Bei agilen Projekten sieht es schon wesentlich besser aus.

Zwischen 2013 und 2017 sind also nur 16% aller großen agilen IT-Projekte vollkommen gescheitert.

Aber was bedeutet eigentlich Agile? Ich denke, ihr kennt das. Ich finde, am besten beschreibt es das Agile Manifest.

Das wurde 2001 von 17 unabhängigen Entwicklern niedergeschrieben und besagt die Grundprinzipien agiler Entwicklungen.

Das erste hierbei ist Individuals and Interactions over Processes and Tools.

Das bedeutet natürlich nicht, dass man keine Prozesse anwenden und keine Tools nutzen muss.

Das bedeutet lediglich, dass es für die Software am Ende viel wichtiger ist, dass kompetente Menschen effizient zusammenarbeiten.

Das zweite Prinzip ist Working Software over Comprehensive Documentation.

Das auch wieder bedeutet nicht, dass ein Softwareprodukt nicht dokumentiert werden muss.

Es bedeutet lediglich, dass der Hauptfokus auf der Software liegt und die Dokumentation nicht wie beim Wasserfallmodell schon komplett vorher als Spezifikation vorgelegt werden muss,

sondern man eben auch parallel oder etwas nachgelagert zur Entwicklung dokumentieren kann.

Dann ist die Chance auch viel höher, dass die Dokumentation tatsächlich dem implementierten Code entspricht.

Das dritte Prinzip ist Customer Collaboration over Contract Negotiation.

Auch das wiederum. Vertragsverhandlungen muss es einfach geben, da führt nichts dran vorbei.

Aber wesentlich wichtiger ist eben die Zusammenarbeit mit dem Kunden und bei agiler Softwareentwicklung auch das frühe Einholen von Feedback des Kunden,

um eben genau zu verhindern, dass man irgendwas entwickelt, was eigentlich so gar nicht gewollt war, was nicht den Anforderungen entspricht.

Und das vierte und letzte Prinzip des Agilen Manifests, Responding to Change over Following a Plan.

Genau damit verhindert man eben, dass man Sachen entwickelt, die zwar mal so geplant waren, und das war auch schön zu der Zeit, aber entspricht gar nicht mehr dem heutigen aktuellen Stand.

Man muss irgendwie agil und flexibel auf sich ändernde Anforderungen reagieren können.

Man verfährt also iterativ in dem sogenannten Deming Cycle mit den Phasen Plan, Do Check, Adjust.

Man plant eine Phase, man setzt das Ganze um, man checkt, ob es tatsächlich den Anforderungen entspricht.

Und gegebenenfalls muss man es auch nochmal anpassen, also nur weil man etwas mal dokumentiert hat, eine Software geschrieben ist, heißt das nicht, dass das in Stein gemeißelt ist.

Wenn es eben nicht den Anforderungen entspricht, dann muss das Ganze angepasst werden.

Kleiner Fakt, am Rande Deming war ein amerikanischer Statistiker und Wirtschaftsexperte, der nach dem zweiten Weltkrieg nach Japan geholt wurde,