Agilität ist der Herzschlag des 21. Jahrhunderts. Umfangen wird dieses schlagende Herz vom magischen Dreieck. Wie es dazu kam, dass unser Herz hauptsächlich im agilen Beat schlägt, wir aber auch ein Herz für das klassische Projektmanagement haben, erfahren Sie in diesem Bericht.

Im Juli diesen Jahres feiert die K&K Software AG ihr 20-jähriges Bestehen. Angefangen hat alles im Jahr 2000. Durch die ersten erfolgreich abgeschlossenen Projekte stieg das Vertrauen unserer Auftraggeber und es war möglich größere Projekte und Kunden zu gewinnen. Unsere ersten Erfahrungen mit Großprojekten machten wir mit der klassischen Wasserfall- und V-Modellmethode basierend auf umfangreichen Lasten- und Pflichtenheften. Viele Projekte konnten wir mit diesen Umsetzungsstrategien erfolgreich durchführen, bis uns ein komplexes Großprojekt zum Umdenken zwang. Bei diesem Großprojekt waren die Anforderungen nicht klar definiert. Es gab zwar eine Vision, aber noch keinen ausformulierten Plan zur Umsetzung. Im Nachhinein betrachtet war es etwas naiv zu glauben, dass wir die komplexen Anforderungen trotzdem umgesetzt bekommen. Es kam wie es kommen musste. Bereits nach kurzer Zeit war klar, dass dieses Projekt zu Scheitern drohte. Wir mussten uns schleunigst etwas überlegen, damit wir doch noch zu einem Erfolg kommen konnten. Gerade zu dieser Zeit kam ein neuer Softwareentwickler in unser Team. Er berichtete von der agilen Projektmanagementmethode “Scrum”, welche er von seinem vorherigen Arbeitgeber kannte. Interessiert setzten wir uns mit Jeff Sutherland und Ken Schwaber auseinander, den Pionieren des Scrum Framework. Das Vorgehensmodell erweckte großes Interesse bei uns. Im agilen Projektmanagement werden die Entwicklungsteams als selbstorganisierende Einheit betrachtet, welche eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Der Projektleiter nimmt im Scrum eher die Rolle eines Moderators als eines Managers ein. Scrum versteht sich als ein Gegenentwurf von Befehl- und Kontroll-Organisationen und ist prädestiniert für flache Unternehmenshierarchien.* (*Quelle: https://de.wikipedia.org/wiki/Scrum#cite_note-13)

Der agile Ansatz wirkt sich also auf die ganze Organisation im Unternehmen aus. Die Werte im agilen Projektmanagement sollten sich mit denen der eigenen Firmenphilosophie decken. Da sich unsere Philosophie und Arbeitsweise sowieso schon mit den agilen Werten überschnitt, konnten wir uns gut mit diesen identifizieren, was unsere Entscheidung erleichterte. So herrschte in unserem Unternehmen beispielsweise schon immer viel Gestaltungsfreiheit bei der Umsetzung, bei der Auswahl der Arbeitswerkzeuge und den eingesetzten Technologien.

Außerdem schien es als sei Scrum die perfekte Lösung für unsere anfängliche Schwierigkeit mit besagtem Großprojekt. Die Komplexität des oben genannten Projekts war für uns nicht beherrschbar, die Anforderungsdetails änderten sich während der Entwicklung häufig und dem Projektleiter viel es schwer seine Vision den Entwicklern zu vermitteln. Genau hier setzt Scrum an.
Wesentlich für Scrum ist, dass Projekte nicht mehr von A bis Z durchgeplant werden, da es aufgrund der sich ständig ändernden externen Faktoren bei umfangreichen Projekten ohnehin kaum möglich ist, bereits zu Beginn eines Projekts einen endgültigen und allumfassenden Plan zu entwickeln.

Kleine Teile ergeben ein großes Ganzes

Im Gegensatz dazu verfolgt Scrum einen agilen (sprich: wendigen) Ansatz. Es formuliert statt eines endgültigen Plans zunächst nur eine auf Anwenderbedürfnissen und Markterfordernissen basierende Produkt-Vision. Diese werden im weiteren Projektverlauf nach und nach konkretisiert. Die Entwicklung erfolgt nicht geradlinig, sondern in zyklischen Schritten. Die Anwenderbedürfnisse werden dabei zu Projektstart in sogenannten “User Stories” mittels ein, zwei prägnanter Sätze auf den Punkt gebracht.

Ein wesentlicher Bestandteil im Scrum sind die Sprints. Die Sprints teilen das Projekt in kurze Zyklen. Vor jedem Sprintstart werden Anforderungen und Entwicklungsaufträge (in Form von Userstories) neu priorisiert und die Stories mit der höchsten Priorität in den beginnenden Sprint eingeplant um im Sprint dann umgesetzt zu werden. Zum Ende eines jeden Sprints wird eine lauffähige Produktiv-Version an den Enduser ausgeliefert.
Ein Sprint sollte nie die maximale Länge von einem Monat übersteigen. Bei K&K hat sich eine 14-tägige Sprintlänge als sinnvoll herausgestellt. Da so die Zeit kurz genug ist um einen regelmäßigen Austausch zu haben und die Kunden an die Methode zu gewöhnen, aber auch lang genug, damit genügend Zeit für die Umsetzung bleibt und die Meetings nicht zu viel Zeit einnehmen.

Beim agilen Ansatz muss demzufolge weniger Zeit für eine detaillierte Planung vor dem Projektstart aufgewendet werden, da während des Projektes fortwährend weiter geplant wird. Daraus ergeben sich die Vorteile:

• echtes Enduser-Feedback und “Lessons Learned”-Prozess
• entwickelt man permanent “das Wichtigste zuerst”
• Software ist immer dem aktuellen Stand angepasst (bezüglich Technik, Anforderungen, Unternehmensstruktur etc.)

Wie verhalten sich die Zielgrößen des magischen Dreiecks im agilen Prozess?

In den meisten Projekten müssen Zielvorgaben für “Zeit”, “Qualität (Inhalt, Umfang)” und “Kosten” gleichermaßen erreicht werden. Die Schwierigkeit dabei ist, dass die unterschiedlichen Größen in Beziehung zueinander stehen. Dies wird im magischen Dreieck verbildlicht. Jede Änderung an einer dieser Größen wirkt sich auf die anderen Größen aus.

Im Scrum werden durch eine fortwährende Priorisierung während des Projektes immer die wichtigsten Teile zuerst bearbeitet. Die Komponenten “Kosten” und “Zeit” werden zu Anfang des Projektes besprochen und dann in die Anzahl der Sprints mit dem entsprechenden Stundenkontingent umgerechnet.

Wir können dennoch auch klassisches Projektmanagement

Dennoch wissen wir, dass sich für manche Projekte eher eine klassische Entwicklung anbietet. Selbstverständlich haben wir für eine sehr lange Zeit mit klassischen Methoden Software entwickelt und kennen und können auch nach dieser Methode ein Projekt durchführen. Bei Projekten, die bereits einen genauen Projektumfang haben, kann man eine klassische Projektplanung mit dem Wasserfall- oder V-Modell verwenden. Hierbei erfolgt die Umsetzung einer genauen Spezifikation.
Nachfolgende Gegenüberstellung zeigt, wann sich welche Entwicklungsform bevorzugt anbietet.