Ist Scrum ein Allheilmittel für das Projektmanagement?

Scrum ist als ein agiles Projektmanagement-Framework zu verstehen, das von Schwaber und Sutherland kreiert worden ist. Es liefert definierte Rollen, Artefakte und Events – ist aber kein definiertes Prozesshandbuch, das im Detail schildert wie in bestimmten Situationen reagiert werden soll. Somit dient das Framework auch nicht als Phasenmodell, das ein Projekt über einen kompletten und komplexen Lebenszyklus hinweg begleitet. Der Einsatz von Scrum empfiehlt sich in der Praxis vor allem für komplexe Projekte, in denen eine Lösung dringend und vor allem schnell erfolgen soll oder in denen die Anforderungen noch nicht vollständig definiert wurden.[1]

Kurz zu den wichtigsten Bestandteilen von Scrum

Der Product Owner stellt seinerseits einen Plan über die gewünschten funktionalen und nicht-funktionalen Anforderungen bereit und schreibt diese im sogenannten Product Backlog fest. Innerhalb dieses Product Backlogs werden die Anforderungen dann zusammen mit dem Entwickler-Team priorisiert. Die Priorisierung ist dabei besonders wichtig, da letztendlich die Entwickler darüber entscheiden, welche Funktionalitäten innerhalb einer Iteration auch wirklich implementiert werden können. Diese priorisierten Anforderungen werden dann wiederum im sogenannten Sprint Backlog erfasst, wie Darstellung 11 zeigt. Diese Iteration wird in Scrum als ein Sprint betitelt und hat eine Dauer von maximal 30 Tagen. Am Ende eines Sprints sollte dann auch der Prototyp einer Software vorliegen, der die priorisierten Funktionalitäten aus dem Product Backlog demonstrieren kann. Jede der einzelnen Funktionalitäten kann sich in einem oder auch in mehreren Sprints innerhalb der Entwicklung befinden. Scrum gibt dabei aber keine expliziten Methoden zur Softwareentwicklung selbst vor. Allerdings ist ein tägliches Meeting, das sogenannte Daily Scrum, für 15 Minuten angedacht. In diesem Daily Scrum liefert der Entwickler einen Fortschrittsbericht ab und bekommt die Chance derzeitige Probleme und Herausforderungen anzusprechen.[2] Ziel eines Sprints sollte es sein eine Funktionalität zu entwickeln, die auch auslieferbar wäre.

Scrum SWOT Analyse

[3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

Zusammenfassung

Es ist wichtig festzuhalten, dass Scrum ein Framework und kein Prozess ist. Es werden verschiedene Rollen, Meetings und Artefakte definiert und deren Zusammenspiel beschrieben. Ein projektspezifisches Vorgehen muss aber immer innerhalb der jeweiligen Projekte im Rahmen von Scrum definiert werden und kann sich von einem zum anderen Projekt unterscheiden. Scrum ist zudem kein Allheilmittel, es kann keine Projektrisiken verhindern aber es macht sie frühzeitig sichtbar und somit auch beherrschbar. Scrum allein ist kein Projektbeschleuniger, denn die Teams werden durch den Einsatz von Scrum nicht besser oder schneller. Jedoch fokussieren sie sich nur auf die Dinge, die aktuell relevant sind und dadurch kann gewährleistet werden, dass die wirklich wichtigen Aufgaben auch früher fertig werden.

[1] Vgl. Cockburn, A. (2003): Agile Software-Entwicklung. In: mitp, Bonn, 2003.

[2] Vgl. Schwaber, K. (2004): Agile project management with scrum. In: Microsoft, Redmond, 2001.

[3] Vgl. Ionel, N. (n.a.): Critical Analysis of the scrum project management methodology. URL: https://de.scribd.com/document/252676701/CRITICAL-ANALYSYS-OF-THE-SCRUM-PROJECT-MANAGEMENT-METHODOLOGY-pdf, Abruf am: 29.03.2018

[4] Vgl. Rising, L. & Janoff, N. S. (2000)

[5] Vgl. Nichols, D. M. & Twidale, M. B. (2003): The Usability of Open-Source Software. First Monday 1 (8), 2003.

[6] Vgl. Ionel, N. (n.a.)

[7] Vgl. Rising, L. & Janoff, N. S. (2000): The SCRUM software development process for small teams. In: IEEE Software, 2000.

[8] Vgl. Rising, L. & Janoff, N. S. (2000)

[9] Vgl. Ionel, N. (n.a.)

[10] Vgl. Highsmith, J., & Cockburn, A. (2001)

[11] Vgl. Ionel, N. (n.a.)

[12] Vgl. Highsmith, J., & Cockburn, A. (2001)