Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Kopfstandkino Risiko

Agile, Scrum und Risiken. Drei Dinge für mich, die zusammengehören. Hohes Risiko, hoher Gewinn, aber eben auch hohes Risiko. Wir vermeiden gerne Risiken, weil uns der Zugang fehlt. Wir arbeiten lieber darum herum, statt zu scheitern. Wenn ich Risiken angehen möchte, dann brauche ich zumindest einen Zugang, der mir einen kontrollierten Rahmen bietet. Einen Zugang, der mir hilft Entscheidungen zu treffen und mich unterstützt, kleine Fehler zu machen, statt einen großen.

Was macht agil nun anders? Agil stellt Risiken auf den Kopf – im wahrsten Sinne des Wortes. Jedes Risiko lässt sich als Chance formulieren, viele Risiken können als Eintrag im Product Backlog landen. Als Features, deren Nutzen es zu testen gilt, als minimal lieferfähiges Produkt (minimum viable product) über das sich der Mark testen lässt. Statt Risiken zu verwalten, tritt man dem Risiko entgegen, bereitet sich auf eine epische Schlacht mit ihm vor und begrüßt die Erkenntnisse, die auf dem Weg warten. Auf dem Weg heißt: nach dem Start.

Software-Anforderungen erfassen und weitergeben ist ein Kommunikationsproblem

Scrum ist ein Kommunikationsrahmen. Ein Rahmen, in dem mehr und mehr Beteiligte angehalten werden, miteinander zu sprechen und wertschätzend zu kommunizieren. Ein Rahmen, in dem ritualisiert alle relevanten Beteiligten eingebunden werden, damit ein gemeinsames Bild entstehen kann. Wir klären gemeinsam die Anforderungen. Angefangen im Sprint Planning 1: Hier holen wir uns die Personen hinzu, die uns genau sagen können, was gewünscht ist. Im Daily Scrum halten wir Kontakt mit ihnen und optimalerweise nutzen wir die Zeit nach dem Daily Scrum, um Rückfragen zu klären. Spätestens im Review zeigen wir, was umgesetzt wurde. An diesem Punkt kommt die Erkenntnis ins Spiel und wir können den Nutzen validieren. Wichtig ist jedenfalls: „Die Personen, die eine Software wollen, müssen mit den Personen kommunizieren, die die Software bauen.“ (Gojko Adzic)

Je weniger Kommunikation stattfindet, desto höher das Risiko, dass wir das Falsche liefern. Dass wir zwar technisch einwandfrei liefern, jedoch nicht das liefern, was der Kunde möchte. Oder in anderen Worten, wie Gojko Adzic es sagt: „I am getting more and more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are important, but if the communication fails then the rest ist just painting the corpse.“

Also gehen Sie das größte Risiko „Kommunikation“ an und starten Sie mit einem Prozess, der die Kommunikation in den Vordergrund rückt: Scrum!

Wie Scrum im Detail mit Risiken umgeht finden Sie unter anderem in diesem Artikel: Agiles Risikomanagement mit Scrum – empört Euch!