Projektleiter Scrum gesucht?

Derzeit kommt man nicht umhin, für alle möglichen Positionen in der IT angesprochen zu werden, gerne für PHP-Entwicklung in München, selbst wenn man nie PHP gemacht hat und in Norddeutschland wohnt.

Ganz beliebt - auch bei Freelancer-Vermittlern, so hört man - sind Projektleiter Scrum.

Was ist daran verwunderlich?

Gerade in Scrum gibt es einfach keinen Projektleiter - das Gespann aus Product Owner, Team und Scrum Master agiert dynamisch und selbständig, wobei der Scrum Master als "Servant-Leader" dem Team bei der Verbesserung hilft.

Problem: die meisten Aufgaben landen beim Product Owner! Schließlich gibt der theoretisch gesehen auch das Geld. Einen guten Product Owner zu finden, ist schwer, weil die Aufgabenvielfalt einfach sehr groß ist. Der PO in der Scrum-Theorie hat auch den leicht amerikanischen "Boss"-Touch: my way or the highway.

Ist der Scrum Master verantwortlich? In der Theorie: nein. Oder jein. Frage: Wenn Sie 100.000 EUR von Ihrem eigenen Geld investieren, möchten Sie dann, dass jemand verantwortlich ist?

Will sagen: niemand gibt Geld für Selbstverwirklichung und Regentanz-Seminare. Wenn ich als Investor mich entscheide, Scrum zu machen, will ich wissen, dass es auch funktioniert. Ergo muss der Scrum Master zeigen, dass es einen Fortschritt gibt oder er zumindest einen Master-Plan hat. Oder der Product Owner übernimmt das. Ich kann das Geld ja auch traditionell investieren in ein Projekt - also warum sollte ich Scrum wählen, außer, ich muss unbedingt schnell, effizient und effektiv sein?

Scrum ist eigentlich einfach - aber nicht ansatzweise leicht! Es erfordert ein "erwachsenes" Team und völlige Transparenz. Nur dann wird das agile Vorgehen nützlich sein.

Man kann also vermuten, dass viele Scrum machen, weil es so in (der Computerwoche | dem Manager-Magazin | der Wirtschaftswoche) stand. Wie damals in der IBM-Werbung: "Wir müssen ins Internet - Warum? - Steht da nicht!".

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...