Projektmanagement mit SCRUM bildet eine wirksame Umsetzung von leanen Gedanken.
Am Ende steht ein weitaus besseres und der Projektvision näher stehendes Produkt.
Die Ursprünge von Projektmanagement nach SCRUM basieren auf dem 1986 erschienenen Artikel von Hirotaka Takeuchi und Ikujiro Nonaka "The New New Product Development Game"1. Weiterentwickelt wurde die Idee von Jeff Sutherland, der erstmals die Rollen der einzelnen Projektmitglieder neu beschrieb2. Seitdem wurde das Thema stark in der IT-Branche vorangetrieben und findet seit einiger Zeit immer mehr Anklang in Bereichen klassischen Projektmanagements.
Stakeholder
Mit SCRUM möchte ich Ihnen hier kurz eine Methode vorstellen, die auch für Unternehmen, die sich auf den Lean-Weg begeben haben, interessant sein könnte.
Wie funktioniert SCRUM?
Bei SCRUM gibt es 3 Rollen: Den Product Owner, den SCRUM-Master und die Entwickler. Alle drei zusammen bilden das SCRUM-Team (Abb. 1).
Der Product Owner ist Schnittstelle zwischen den Stakeholdern/Projektsponsoren und dem SCRUM-Team. Er verantwortet am Ende den Erfolg des Projektes ("Das Richtige zu bauen"). Er vermittelt dem SCRUM-Team die Projektvision. Er generiert die zu entwickelnden Eigenschaften im Projekt (Produkteigenschaften) und entscheidet über die Priorisierung. Um sich nicht von der Produktvision zu entfernen, hält er regelmäßig Rücksprache mit den Stakeholdern.
Scrum Master
Product
Entwicklungsweise besteht ein Entwicklungsteam aus drei bis sieben Personen.
Der SCRUM-Master nimmt die Rolle einer "dienenden Führungskraft" ein. Er fungiert als Coach für die Mitglieder des SCRUM- Teams. Er schirmt sie sowohl von internen als auch externen Ablenkungen ab. Er ist dafür verantwortlich, dass innerhalb des Projektes SCRUM richtig verstanden und eingesetzt wird.
Das interdisziplinäre Entwicklungsteam ist für die Lieferung der einzelnen Produkteigenschaften in der vom Product Owner gewünschten Reihenfolge verantwortlich. Dabei steuern und managen sich die einzelnen Teammitglieder selbst. Die Größe eines solchen Teams kann variieren. Das Team muss klein genug sein, um flexibel bleiben zu können, und groß genug, um die Arbeit innerhalb der Zeitintervalle (Sprints) erledigen zu können. Üblicher-
Verlauf eines SCRUM-Projektes
Am Anfang eines SCRUM-Projektes entwickelt der Product Owner (PO) zusammen mit den Stakeholdern eine Produktvision (Abb. 2, Nr. 1). Diese schneidet der PO in kleinere, selbständig entwickelbare Teile und priorisiert diese im sogenannten Product Backlog. Zusammen mit dem SCRUM-Team wird dann in der Sprint Planung 1 ein Sprintziel festgelegt und aus dem Product Backlog diejenigen Teile definiert, die am Ende des Sprints abgeliefert werden sollen (Abb. 2, Nr. 2). In der Sprint Planung 2 legt das Entwicklungsteam fest, wie das Ziel und die Aufgaben umgesetzt werden sollen. Dies geschieht in Form von einzelnen To Dos, die jeweils nicht mehr Zeit als einen Personentag benötigen sollten (Abb. 2, Nr. 3). Beide Sprintplanungen sind gut an einem Tag zusammen durchführbar.
Dann beginnt der eigentliche Sprint (Abb. 2, Nr. 4), der je nach Team ein bis vier Wochen dauern sollte. Während eines Sprints werden die Aufgaben aus der Sprint Planung 2 abgearbeitet. Um auch hier einen Nutzen aus bereits gemachten Erfahrungen ziehen zu können, ist die Dauer der Sprints nicht variabel, sondern immer gleich. Während des Sprints werden die To Dos abgearbeitet. Es findet jeden Tag ein zehnminütiges Treffen (Daily SCRUM: Abb. 2, Nr. 5) statt, bei dem die einzelnen Mitglieder über ihre Tätigkeit des Vortages berichten und darüber, welche Dinge erledigt werden konnten und mit welchen Hindernissen zu rechnen ist. Das Daily SCRUM Meeting dient dem Austausch des Teams und nicht dem Reporting an den SCRUM- Master oder den Product Owner. Nach Ablauf des Sprints wird im Sprint Review der fertige Projektteil an den Product Owner übergeben, der seinerseits beurteilt, ob das Produkt seinen Erwartungen entspricht und weiter gemacht werden kann, oder ob der fertige Projektteil überarbeitet werden muss (Abb. 2, Nr. 6). Nach dem Sprint Review wird im Retrospektive Meeting gemeinsam reflektiert, was gut war und was im letzten Sprint hätte besser laufen können (Abb. 2, Nr. 7). Auch der Sprint Review und das Retrospektive Meeting können an einem Tag abgehalten werden. Nach dem Retrospektive Meeting beginnt der Zyklus von vorne und der Product Owner priorisiert sein Product Backlog erneut, oder er kann auch neue Dinge aufnehmen, die sich inzwischen ergeben haben.
Scrum Team
Daily Scrum
Vergleicht man klassisches Projektmanagement mit SCRUM-Projekten, so liegt der größte Unterschied darin, dass man sich bei SCRUM nicht der Illusion hingibt, von Anfang an den genauen Weg, der am Ende zum Projektziel führt, zu kennen. Oft begegnen einem während der Arbeit Hürden und Hindernisse, die man nicht vorausgesehen hat. SCRUM findet die Lösung für dieses Problem in dem Ansatz der Anwendung der Theorie der empirischen Prozesssteuerung. Dabei wird Wissen aus vorhergehenden Erfahrungen gewonnen und Entscheidungen auf der Basis des Bekannten getroffen. Die daraus resultierende Flexibilität und Agilität ergibt sich aus drei Säulen:
• Transparenz: Die wesentlichen Aspekte im Projekt müssen für die sichtbar sein, die für das Ergebnis verantwortlich sind. Deshalb werden Fortschritte und
Hindernisse regelmäßig kommuniziert und für alle festgehalten.
• Überprüfung: Nachdem man das Projektziel in einzelne kleinere messbare Projektziele aufgeteilt hat, können diese regelmäßig abgeliefert werden. Dabei werden sowohl das Produkt, als auch das Vorgehen gemeinsam stetig reflektiert.
• Anpassung: Die Anforderungen an das Produkt und die Art der Vorgehensweise werden bei Scrum nicht von Anfang an unwiderruflich festgelegt. Vielmehr werden durch regelmäßige, kurzzyklische Runden diese kontinuierlich angepasst.
Ist SCRUM für jedes Projekt einsetzbar?
SCRUM lebt sehr stark vom Coaching des Entwicklungsteams und von der kontinuierlichen Verbesserung und Überarbeitung der Projektziele. Gleichzeitig wird durch die Sprint Retrospektive auch ein Prozess der kontinuierlichen Verbesserung hinsichtlich des operativen Projektmanagements und der Arbeitsweise des Teams ermöglicht. Gerade in diesen Punkten sehe ich die Verknüpfung zu Lean und einer Art "KATA-Coaching". Aus den Erfahrungen heraus fallen während der einzelnen Sprints immer wieder Anforderungen weg, die am Anfang noch angedacht waren, da das gewünschte Ergebnis immer wieder neu bewertet und angepasst wird. Es gibt kein Projektende in Form eines Big Bang, sondern stetige kleine messbare Projektschritte.
Jochen Wenz arbeitet seit 2007 in den Themenfeldern Lean und Six Sigma. Durch seine Tätigkeiten bei Daimler, BASF, Roche und nunmehr als Projektleiter Lean Management bei der Hornbach Baumarkt AG konnte er in vielen verschiedenen Anwendungsbereichen sein Wissen vertiefen. Neben der Arbeit leitet er den Lean Stammtisch Mannheim und moderiert die größte Lean-bezogene Gruppe auf Xing „Lean for Professionals“ mit mehr als 4.800 Mitgliedern.
Als ich zum ersten Mal mit dem Thema in Berührung kam, klang es für mich sehr starr. Die vielen Meetings, wer welche Aufgaben erledigen muss, weckten bei mir die Befürchtung, die Kreativität würde eingeschränkt. Nach den nun gemachten Erfahrungen bin ich begeisterter SCRUM-Anwender und kann sagen, dass das genaue Gegenteil der Fall ist. Das Entwicklungsteam agiert selbständig und wird durch den SCRUM-Master gecoacht. Durch die Abstimmung zwischen Product-Owner und Stakeholdern weiß im SCRUM-Team immer jeder, was die Produktvision ist.
SCRUM, Projekte näher an der Vision der Stakeholder zu realisieren. Dabei entwickelt sich zugleich durch den KVP-Gedanken der Retrospektive-Sitzung auch das SCRUM-Team stetig weiter. Der SCRUM-Master, der durchaus auch die Rolle eines KATA-Coaches einnehmen kann, unterstützt dabei fachlich. Wir haben diese Methode inzwischen in fast allen Projektteams innerhalb und außerhalb der IT umgesetzt und machen ausschließlich gute Erfahrungen damit.
Wenn man die Komplexitätsstudie von Ralph Stacey zu Rate zieht (Abb. 3), so eignet sich SCRUM insbesondere für Projekte im Bereich "komplex", in denen also bei dem Zusammenspiel von Problem und Lösung eines von beiden nicht bekannt ist. Für die "Komfortzone", in Fällen, in denen sowohl das Problem, als auch die Lösung schon bekannt sind, eignet sich hingegen das klassische Projektmanagement besser.
Quellenangaben:
1Nonaka, Ikujiro/Takeuchi, Hirotaka (1986): The New New Product Development Game. In: Harvard Business Review, January-February 1986, Repr. 2Sutherland, Jeff/Schwaber, Ken (2013): The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game, July 2013.
Durch die Nutzung von stetigen PDCA-Zyklen in Daily SCRUM Meetings und auch im Sprint allgemein, schafft es
Weiterführende Literatur:
Internetforen:
