Den generellen Ablauf des SCRUM Prozesses dürfte mittlerweile fast jeder kennen. Sollte dem jedoch nicht so sein, so soll er an dieser Stelle noch einmal, bezogen auf die Softwareentwicklung, kurz erklärt werden.Ein Team bestehend aus idealerweise sieben Entwicklern bearbeitet in zwei bis vier Wochen andauernden Iterationen (Sprints) die zuvor vom Product Owner im Product Backlog priorisierten Aufgaben (Tasks). Zu Beginn jeder Iteration legt das Team gemeinsam die Menge an Tasks fest, die in dem nächsten Sprint bearbeitet werden. Im Daily SCRUM Meeting stimmen sich die Entwickler täglich kurz ab und halten sich dadurch gegenseitig immer auf dem Laufenden. Am Ende eines Sprints wird dem Kunden das erzielte Ergebnis (Product Increment) präsentiert (Sprint Review) und das Team spricht darüber wie es sich selbst verbessern kann (Sprint Retrospektive). Der SCRUM Master unterstützt das Team und sorgt für einen reibungslosen Prozessablauf.
Die SCRUM Methode ist so kompakt, dass sie problemlos auf einem Bierdeckel niedergeschrieben werden kann
Möchte man also einen SCRUM Prozess etablieren, könnte man meinen es braucht nicht mehr als sieben Entwickler und einen Bierdeckel. Der Teufel liegt allerdings im Detail und trägt den Namen „agile Entwicklung“. Während sich SCRUM problemlos auf einem Bierdeckel erklären lässt, braucht es für die agile Entwicklung schon eine Niederschrift mit vier Werten und zwölf Prinzipien, genannt Agiles Manifest. Der eigentliche Mehrwert von SCRUM kommt also nicht durch SCRUM an sich zum Vorschein, sondern durch die Verinnerlichung jener agilen Prinzipien und Werte.
Kontinuierliche Auslieferung
Hintergrund
Um die Bedürfnisse der Kunden zu erfüllen, muss die Frage beantwortet werden, welches primäre Ziel die Software erfüllen muss. Meistens sollen mit der beauftragten Softwareentwicklung Prozesse vereinfacht und somit Geld gespart werden. Dazu bedarf es einer möglichst schnellen, günstigen und qualitativ hochwertigen Umsetzung seiner Anforderungen in ein entsprechendes Softwareprodukt. Nachdem bekanntlich Kosten, Zeit und Qualität nicht als Ganzes gesenkt werden können, bedient man sich in der agilen Entwicklung einem Trick, der sich auch in dem ersten Prinzip wiederspiegelt. Anstatt ein fertiges Softwareprodukt auszuliefern, liefert man möglichst schnell eine erste Version der Software. Diese erste Version kann meistens bereits nach wenigen Wochen geliefert werden und ist gerade gut genug, um ein wenig Mehrwert für den Kunden zu erzeugen.
Worauf geachtet werden sollte
Was in der Theorie einfach klingt, erfordert jedoch einiges an Erfahrung und vor allem präzise priorisierte Anforderungen. Ein kleines funktionierendes Inkrement zu liefern ist selten das Problem. Mit diesem Inkrement allerdings einen messbaren Mehrwert für den Kunden zu liefern, stellt die eigentliche Herausforderung dar. Statt bereits zu Beginn einen Login Prozess für ein System zu entwickeln, welches ansonsten keine Funktionalität bietet, kann dem Kunden beispielsweise eine erste Möglichkeit zur Datenpflege geboten werden.
Es soll jedoch nicht nur frühestmöglich Mehrwert geliefert werden, sondern vor allem kontinuierlich. Das macht die Priorisierung zu einer kontinuierlichen Aufgabe, die sicherlich Zeit kostet. Im Gegenzug stellt sie allerdings sicher, dass dieser Aufwand stetig durch einen realen Wertezuwachs gedeckt wird.
Flexibilität
Hintergrund
Agile Entwicklung ist kein Allheilmittel. Um Projekte erfolgreich zu organisieren, kommt es daher vor allem auf die Erfahrung in der Auswahl des passenden Modells an. Dabei lassen sich zwar oftmals einige Tendenzen erkennen, trotzdem ist jedes Projekt individuell zu betrachten und einzuordnen.
Über die Jahre hinweg hat sich herausgestellt, dass Softwareprojekte und darunter speziell Neuentwicklungen, oftmals bestimmte Gemeinsamkeiten aufweisen. Möchte man eine neue Software entwickeln bzw. entwickeln lassen, sollte zumindest eine grobe Vision existieren, die erkennbar macht, wobei und wie die Software helfen soll. Ab diesem Zeitpunkt setzen die verschiedenen Prozessmodelle an.
Die Entwicklung nach dem Wasserfall Prinzip fängt jetzt an und arbeitet die Features der Vision vertraglich exakt aus, einschließlich Logik, Benutzeroberfläche, Abhängigkeiten zwischen Features, zeitlichem Aufwand und so weiter. Ist das Projekt schriftlich spezifiziert, beginnt die Umsetzung anhand der Spezifikation.
Die agile Entwicklung wählt einen anderen Ansatz und versucht dabei zwei Dinge. Zum einen jenes Feature zu identifizieren das dem Kunden einen konkreten Mehrwert liefert. Zum anderen dieses Feature direkt umzusetzen und anschließend auch an den Kunden auszuliefern. Anforderungen oder Aufgaben die noch weiter entfernt liegen, werden beispielsweise im Product Backlog festgehalten, allerdings noch nicht exakt ausgearbeitet.
Worauf geachtet werden sollte
Beim Ansatz der agilen Entwicklung kann es zu Unsicherheiten auf Seite des Kunden kommen, da keine exakte Zeit- und Budgetplanung geliefert wird, während das Wasserfallmodell genau dies als vermeintliche Sicherheit liefert. Allerdings ist die Sicherheit des Wasserfallmodells oft nicht real, genauso wie die Unsicherheit der agilen Entwicklung nicht real ist. Agile Methoden erlauben sehr wohl eine zeitliche Planung einzelner Meilensteine oder eines MVPs. Allerdings wird hier der Ansatz gewählt die Zeiteinschätzung erst dann abzugeben, wenn alle Variablen bekannt sind.
In der Software Entwicklung hat sich herausgestellt, dass die besten Ideen zur Verbesserung eines Systems zum Zeitpunkt des Betriebs und nicht zur Planung entstehen. Bestimmt fallen Ihnen bei der täglichen Arbeit am PC bestimmte Funktionen in Programmen auf, die für Sie nicht optimal funktionieren oder eventuell fehlt Ihnen sogar etwas? Hätten Sie die Software geplant, hätten Sie daran gedacht? Und vor allem wie viel Zeit und Ressourcen hätte es Sie gekostet im Voraus alle Eventualitäten zu bedenken? Genau hier setzt die agile Entwicklung an und möchte Ihnen einen Wettbewerbsvorteil schaffen. Zum einen indem die initialen Kosten für die Planung reduziert werden und zum anderen durch die Möglichkeit, jederzeit Änderungen in die Software einbringen zu können.
Wichtig ist es allerdings sich im Klaren zu sein, wann welche Entscheidungen getroffen werden müssen. Es gibt zentrale Entscheidungen, die nicht oder nur schwer rückgängig zu machen sind. Allerdings sind die meisten nicht dieser Natur und lassen sich mittels vernachlässigbar geringem Aufwand revidieren. Genau dieses Prinzip beschreibt der Amazon Gründer Jeff Bezos recht anschaulich, indem er Entscheidungen als Type 1 und Type 2 Decisions unterteilt. Type 1 Decisions sind eben beschriebene irreversible Entscheidungen. Type 2 Decisions werden als Tür beschrieben, die man wieder rückwärts verlassen kann, sollte sich das Beschlossene als ungeeignet herausstellen. Dementsprechend lassen sich Type 2 Decisions schnell treffen und ermöglichen dadurch agiles Handeln. Type 1 Decisions kommen in der Regel mit erheblichen Kosten einher, sowohl zeitlich als auch finanziell. Jeff Bezos beschreibt in diesem Bezug das Phänomen, dass sich zu oft auf Type 1 Decisions gestützt wird, obwohl es sich eigentlich nicht um irreversible Entscheidungen handelt.
Trotz der Möglichkeit flexibel auf Änderungen zu reagieren, sind ein paar Spielregeln zu beachten, um sicherzustellen, dass dabei kein Chaos entsteht. Änderungen sollen nicht willkürlich vorgenommen werden. Das bedeutet jeder darf Änderungen zu jeder Zeit vorschlagen. Allerdings werden diese vor der Umsetzung im Team diskutiert, um sicherzustellen, dass jeder die Änderung auch verstanden hat. Sollten auf Kundenseite mehrere Leute an der Entwicklung beteiligt sein, ist es ebenso wichtig auch hier Änderungen vor der Implementierung zu besprechen. Des Weiteren werden, gerade auch wegen dieser Herangehensweise, Änderungen nicht sofort (bei SCRUM etwa im aktuellen Sprint), sondern frühestens zum folgenden Sprint umgesetzt.
Fazit
Wie man sieht, füllen die agilen Prinzipien nicht nur einen Bierdeckel, sondern locker ganze Bücher. Gegenüber dem Wasserfall Ansatz haben agile Methoden wie SCRUM entscheidende Vorteile. Dazu zählt die Möglichkeit flexibel auf Veränderungen reagieren zu können sowie die kontinuierliche Auslieferung mehrwertschaffender Versionen. Folglich sind für die erfolgreiche Anwendung stetige Analysen und Verbesserungen im Projektverlauf erforderlich. Nur so können wir und auch unsere Kunden von agilem Vorgehen maximal profitieren.
