Angeberwissen zu Scrum - Teil 2

Für große Projekte taugt Scrum nicht!

Wird gerne auch abgewandelt zu: in traditionellen Unternehmen geht Scrum nicht! Stimmt’s? Tja – kommt darauf an, wie Sie denn bisher Ihre großen Projekte gemanaged haben. Die agile Fraktion kümmert sich herzlich wenig um Budgets und Zuständigkeiten – man setzt einfach voraus, dass sich das Management bereits darum kümmert. Wie das Management das macht, liegt außerhalb der Kernmethodik von Scrum. Der Witz an der Sache ist: genau genommen ändert sich an den Projektvorbereitungen nicht so viel, wenn Sie dann auf „Agile“ umsteigen! Oder wird Ihnen irgendjemand in Ihrem Konzern mal eben so 1-2 Millionen Euro genehmigen, wenn Sie weder Umfang noch Termin benennen können?

Die Frage ist ja eher, wie Sie zu einer Aussage dazu kommen: 

Aussage zu...	Traditionell	Agil
Budget	Sie investieren sehr viel Zeit in Anforderungen mit Lasten- und Pflichtenheft Schätzung von Aufwand in PT – am besten bereits mit den Entwicklern Projektplanung – mit allen Beteiligten Risiko-Planung für Puffer („known unknowns“) Planung für Management-Puffer („unknown unknowns“) Da Sie den Budget-Rahmen meist vorher kennen, machen Sie alle Klimmzüge, um irgendwie im Bereich zu bleiben.	Sie investieren viel Zeit in Erstellung des Product Backlog mit bekannten Anforderungsblöcken und Verfeinerungen für die zunächst anstehenden Anforderungen Schätzung der Einträge mit Story Points durch das Team Risiko-Analyse mit dem Team Puffer-Bestimmung (alle „unknowns“) Budget-Bestimmung durch Teamgröße über Zeit Wenn Sie über den Rahmen hinauskommen, sprechen Sie mit den Anforderungsgebern und streichen Anforderungen durch Priorisierung.
Termine	Ihre Planung (s.o.) führt in MS Project oder einem anderen Tool zu einer Zeitaussage. Ihre Vorlagen erinnern Sie daran, Zeit (und Aufwand) für Test und Bugfixing sowie Stabilisierung und Wartung nach Go-Live zu reservieren. Spätestens jetzt sprechen Sie mit den Stakeholdern, um Inhalte herauszunehmen, damit es noch passt.	Sie erstellen eine sehr grobe Release-Planung auf Basis der bisherigen Team-Geschwindigkeit und fügen Release-Sprints ein. Termine werden sich ändern - machen Sie das doch einfach transparent durch Zeitpuffer!
Umfang	Anforderungen haben Sie bereits aufgelistet – für die gesamte Laufzeit, alles andere wird durch ein rationales Change Request Verfahren abgewickelt: damit kann Ihnen keiner mehr etwas vorwerfen.	Der Umfang wird sich ändern. Schon morgen. Sie passen sich von Sprint zu Sprint an – und nutzen das Budget für den wirklich gewünschten Nutzen.
Zuständigkeiten	Sie haben rechtzeitig den Projekt-Sponsor ausgemacht und binden ihn ein. Im Zweifel hat er mehr zu sagen als die Benutzer des Systems.	Die Anwender – vertreten durch den Product Owner – reden mit. Kein „Wünsch Dir Was“, sondern direktes Feedback in beide Richtungen: „Das Feature wird sehr teuer!“ vs. „Die Umsetzung erleichtert meine Arbeit nicht!“

Sehr wichtige Elemente für die erfolgreiche Verwendung von agilen Methoden sind Transparenz und Vertrauen. Mussten Sie gerade lachen, weil Transparenz durch die vielfältigen Reporting-Ebenen sowieso verlorengeht? Wie wäre es, wenn sich das ändern würde? 

Scrum never fails!

Gerne auch mit einem Augenzwinkern kolportiert. 

Ich meine: vertrauen Sie keiner Methode! Nur Menschen lösen Probleme, nicht Methoden. Schon gar nicht Methoden, die man auf Papier kauft und ins Regal stellt...

Vereinfacht gesagt, können Sie mit Wissen, Methoden und Maschinen sehr gut vorhersagbare Aufgabenstellungen bearbeiten, während Sie hingegen für komplexe Problemstellungen Ideen und Können benötigen. 

Zur vertiefenden Lektüre empfehle ich das „Institut für Institut für dynamikrobuste Höchstleistung“ und die kompakten „Denkzettel“, insbesondere Nummer 16. 

In einem Scrum-Team kann sich keiner mehr verstecken!

Ein Management-Traum! Endlich wird deutlich, wer reinhaut und wer nur CO2 produziert! Dann schmeißen wir jedes Jahr die schlechtesten 10% raus?

In jedem Team werden Sie gruppendynamische Effekte aller Arten beobachten, bis hin zu „den / die ziehen wir doch mit“ und auch „mit dem Bart passt der nicht bei uns ins Team“.

Bei Scrum ist es zunächst Aufgabe des Managements, das Team zusammenzustellen. Der ScrumMaster soll für die Team-Findung sorgen, also Storming – Norming – Performing usw. Das Team kann natürlich sich über seine Zusammensetzung Gedanken machen. Aber möchten Sie wirklich ein Team aus lauter Superhelden haben? Die Kunst ist doch, aus dem, was man vorfindet, das Beste zu machen.
Wie in der Bundesliga: natürlich kann man sich verstärken oder mal jemanden auf die Bank setzen. Und eine Mannschaft aus lauter Superstürmern gewinnt keinen Pokal.