Da die Wasserfall-Logik der alten Projektmanagement-Methoden der nötigen Agilität der Software-Entwicklung geopfert wurde, entstehen in vielen Firmen heute noch Spannungen, wie man mit den gefühlt diametral unterschiedlichen Systemen umgehen soll. Denn auch wenn IT-Abteilungen für die Software-Entwicklung häufig SCRUM einsetzen und dadurch viel bessere Ziele erreichen, da die Entwickler während eines Sprints endlich mal 2 Wochen Luft haben, um in Ruhe arbeiten zu können, ist die Schnittstelle zu Entscheidern, Management, Finance häufig großer Reibung ausgesetzt. Lassen Sie mich das etwas näher erläutern.
Jeder, der schon einmal im klassischen Projektmanagement gearbeitet hat, kennt das Dreieck des Projektwesens: Zeit, Umfang und Kosten. Wenn z.B. der Umfang eines Projektes steigt, steigen auch die Kosten und es dauert länger. Oder wenn man in der selben Zeit mit weniger Personen ein Projekt beenden will, sinkt der Umfang des Projektes. Will man aber z.B. einen höheren Umfang in der selben Zeit und mit den selben Ressourcen umsetzen, leidet darunter die transzendente vierte Dimension des Dreiecks — die Qualität.
Viele Firmen von heute folgen noch starr dem Projektdreieck im täglichen Leben. Im vierten Quartal werden Gelder für Projekte des Folgejahres allokiert (Kosten-Fixierung), Planungen für Live-Gang des Projektes festgelegt (Zeit-Fixierung) und der Umfang nur minimal zur Disposition gestellt. Dies führt dazu dass SCRUM, was eine viel höhere Agilität in Zeit und somit Kosten bedarf, um Umfang zu halten, später häufig flexibel auf der vierten Dimension des Projekt-Dreiecks arbeitet — der Qualität. D.h. es gibt Resultate, die “in time, in budget und in-scope” sind und gleichzeitig einer niederen Qualität ausgesetzt sind. Und dann wird SCRUM von vielen in Frage gestellt, da es ja „augenscheinlich nix bringt”.
Auf der anderen Seite sehen wir auch in Firmen, die ihren Teams reines SCRUM erlauben, dies auch dem Risiko ausgesetzt ist, dass die Abteilungen dies ausnutzen können, da die Entwickler-Teams von sich aus die Geschwindigkeit vorgeben und sie den Sprint dazu nutzen können, einfach weniger zu arbeiten. Ganz häufig höre ich von Entscheidern: „Irgendwie fehlt mir die Kontrolle.” Im sogenannten Estimation-Poker legt das Team für jede Aufgabe der kommenden zwei Wochen fest, wie lange etwas dauern soll. Jeder, der schon einmal in diesen Estimation-Poker Runden saß, kann mir zustimmen, wie hoch hier manchmal geschätzt wird. Denn je höher geschätzt wird, um so hat ein Entwickler Zeit, eine Aufgabe zu erledigen. Und wer hätte nicht gern eine stressfreiere Arbeitszeit? D.h. SCRUM funktioniert wegen der hohen Eigenverantwortung aller Beteiligter nur, wenn diese Freiheit vom Einzelnen nicht ausgenutzt wird.
Morgen werden wir verstärkt die wichtige Rolle des Product Owners innerhalbs SCRUM anschauen, da viele outsourcing Firma primär nach SCRUM arbeiten und der Product Owner die wichtigste Schnittstelle zum Kunden darstellt. Donnerstag werden wir uns dann dem Prozessmanagement zuwenden.
— –
Wenn Sie Interesse an A.I. Schulungen für Führungskräfte haben oder A.I. Projekte realisieren wollen, kontaktieren Sie mich gerne: ansgar_linkedin@goldblum-consulting.com