In diesem Kapitel steht das Management-Framework Scrum im Fokus der Untersuchung. Dabei wird der Frage nachgegangen, welche Umgebung ein Scrum-Team benötigt, um in der Lage sein zu können, selbstorganisierend und eigenverantwortlich an der Fertigstellung von Produktinkrementen zu arbeiten. In diesem Zuge werden zunächst die in Scrum definierten Projektrollen beleuchtet, wobei der Fokus insbesondere auf den Rollen des Product Owners, des Scrum Master und des Entwicklungsteams liegt. Im Anschluss daran werden vier zentrale Artefakte diskutiert, die notwendig sind, um die agile Zusammenarbeit in Scrum zu strukturieren. Dazu gehören das Product Backlog, das Sprint Backlog, das Product Increment und die Definition of Done. Um eine reibungslose Kommunikation zwischen den Teammitgliedern zu gewährleisten, kommt den spezifischen Besprechungen in Scrum eine zentrale Bedeutung zu, wie abschließend gezeigt wird.
Anzeige
Bitte loggen Sie sich ein, um Zugang zu diesem Inhalt zu erhalten
Siehe dazu das agile Manifesto (www.manifesto.org). Das agile Manifesto wurde 2001 von in der Branche angesehenen Softwareentwicklern verfasst und beruht auf zwölf Prinzipien, in deren Zentrum „die enge Zusammenarbeit zwischen Entwickler und Kunden steht“ (Gloger und Margetich 2014, S. 6).
In Anlehnung an Stacey (2001) beschreibt Maximini (2013, S. 16 f.) verschiedene Komplexitätsgrade, die einer Produktentwicklung zugeordnet werden können: „Einfache Projekte sind solche, in denen die Rahmenbedingungen fast vollständig bekannt sind. Komplizierte Projekte sind solche, in denen mehr bekannt als unbekannt ist. Komplexe Projekte sind solche, in denen mehr unbekannt als bekannt ist. Chaotische Projekte sind solche, in denen fast nichts bekannt ist.“
Bei der Priorisierung orientiert sich der Product Owner vor allem an den Markterfordernissen. Die technische Umsetzbarkeit ist dabei zweitranging. Vgl. hierzu Gloger (2010, S. 198).
Goll und Hommel (2015, S. 100) definieren die Product Vision wie folgt: „Die Product Vision beschreibt den Grund für die Durchführung und das angestrebte Ergebnis eines Projektes. Sie legt die Richtung, in die das Projekt laufen soll, fest.“
Beispiele für Impediments können laut Hanser (2010, S. 66) „Probleme in der Teampsychologie sein (wenn also z. B. Teammitglieder nicht miteinander auskommen), können sich aber auch aus falsch verstandenen Scrum-Rollen ergeben, z. B. dem Product Owner, der versucht als Projektleiter zu fungieren“.
Häufig verwenden Scrum-Teams sogenannte „Sprint Burndown Charts“, um den Produktfortschritt und den verbleibenden Aufwand transparent darzustellen. Für weitere Ausführungen vgl. Hanser (2010, S. 77 ff.).