Rettet Scrum mein Projekt?

Immer, wenn ich auf das Thema Scrum treffe, langweile ich mich fast – der Scrum-Hype ist doch eher vorüber, die Nutzung beginnt. Erkennt man IMHO daran, dass die Computerwoche dauernd berichtet. Sogar im SPIEGEL taucht Agilität in der IT auf, auch wenn ich mich bei IT-Artikeln im SPIEGEL immer frage, ob sie nicht mal was von heise.de einkaufen sollten. 

Zahllose Blogs, Artikel, Fachbücher und Podcasts behandeln so ziemlich jede Facette von Scrum: in der Software-Entwicklung, außerhalb der Software-Entwicklung, Scrum im Unternehmen / Konzern / Start Up, Warum ich nicht Scrum machen sollte, Scrum für Hundeerziehung und und und...

Überraschend aber, wie viele Leute noch nie etwas oder nur ganz wenig von Scrum gehört haben! Neulich kam z.B. die Frage auf, wie denn Risikomanagement in Scrum funktionieren würde – das würde in Scrum ja nicht adressiert?

Das zeigt: lesen hilft – aber reicht nicht. Schließlich ist Scrum ja gerade dazu gedacht, Risiken zu vermeiden, indem man eben nicht erst am Ende merkt, dass die Lösung nicht zum Problem passt. Warum ist das Scrum-Framework so schwer zu verstehen?

Der immer noch eher knappe Scrum-Guide lässt viel weg – und das lässt viele Fragen offen, vor allem, wenn der Leser nicht über jahrelange Projektleitungserfahrung verfügt.

Was braucht man alles in einem Projekt?

Eine Roadmap-Planung mit Meilensteinen

Warum? Trotz aller Agilität: auch hier geben wir Geld aus, und der Geldgeber will wissen, ob er noch was dafür bekommt. 

Wie? Wir behaupten aber vorher nicht, dass wir die Meilensteine scharf voraussagen können! Sondern zeigen auf, WAS einen Wert hat, WANN es logischerweise kommen soll und WANN wir glauben, dass es kommen könnte.

Risiko-Betrachtung

Warum?Weil der Product Owner das viele Geld nicht riskieren darf – wenn es weg ist, ist auch das agile Projekt schnell vorbei 

Wie? Vom Kunden und Produkt zum Inkrement: wenn der Product Owner die größten Risiken kennt, dann adressiert er sie – natürlich – in den ersten Sprints!

Budget

Warum? Ohne Moos nix los – auch bei Scrum. Was kostet das Ganze? Wie lange reicht das Budget? 

Wie? Der Product Owner kann leicht Budgets planen: bei 5 Mitarbeitern zu 4 PT pro Woche und 2 Wochen Sprint-Dauer kostet der Sprint 40 PT. Meistens ist gemeint: was kostet das Feature? Oder die Anwendung? Das ist eine typische Falle: fast alle Vorhersagen sind weit daneben. Meine Projekte als Projektleiter waren natürlich immer alle in Time und Budget – nur nicht in den VOR dem Projekt festgelegten Werten...

Festpreis

Warum? Wir sind agil, der Kunde auch, aber Festpreis muss schon sein – sonst spielt der Einkauf nicht mit. Und überhaupt, man muss ja wissen, was man bekommt! 

Wie? Agil hat einen massiven Kosten-Overhead – den man gerne bezahlt, wenn man sonst mit hoher Wahrscheinlichkeit ALLES verliert – und da muss man nicht über Flughafenbauten lästern, Software ist ein schwarzes Loch für Euros. 

Nutzen Sie Agilität vor allem dann, wenn Sie MIT dem Kunden ein komplexes Problem lösen wollen – und wirklich wollen! Ein agiles Projekt ist kein Hobby, das man sich zulegt, weil es in der Computerwoche stand – es löst fundamentale Probleme, für die auch der Kunde von gewohntem Verhalten abrücken wird, wenn er genügend Vorteile daraus zieht. Ansonsten lesen Sie die vielen Blogs zu agilen Festpreisen...

Empfehlung

Springen Sie nicht zu kurz bei agilen Projekten, der Overhead wird nicht weniger, sondern mehr! Nutzen Sie die Vorteile, wenn sich die Gesamtrechnung lohnt.

Und lesen Sie meine anderen Blog-Posts zu Agile...