Drei Jahre lang haben wir im Wasserfall-Modell gearbeitet. Es funktionierte, aber mit der wachsenden Anzahl von Projekten und den Anforderungen an schnellere Lieferungen stießen wir an Grenzen. Kunden wollen nicht 6 Monate auf ein erstes Ergebnis warten.
Warum nicht Wasserfall¶
Wasserfall funktioniert für Projekte mit klar definierten Anforderungen, die sich nicht ändern. In der Praxis ist das jedoch selten. Kunden ändern ihre Meinung nach dem ersten Prototyp — im Wasserfall-Modell bedeutet das Change Requests und Verzögerungen.
Scrum-Grundlagen¶
Zweiwöchige Sprints. Sprint Planning, Daily Standup (15 Minuten), Sprint Review mit dem Kunden, Retrospektive. Product Backlog priorisiert vom Product Owner. Der Scrum Master rotiert.
Widerstand gegen Veränderung¶
Kulturelle Barriere: Warum jeden Tag ein Meeting? Warum kann ich nicht zwei Wochen in Ruhe arbeiten? Es dauerte drei Sprints, bis sich das Team angepasst hatte. Und weitere drei, bevor es wirklich funktionierte.
Was funktioniert, was nicht¶
Funktioniert: kurze Iterationen, Retrospektiven, User Stories. Funktioniert nicht: reines Scrum mit einem Festpreisvertrag. Kompromiss: Scrum innerhalb des Teams, vereinbarte Meilensteine für den Kunden.
Tools¶
JIRA mit dem Agile-Plugin für Backlog und Sprint Board. Confluence für Dokumentation. Das physische Board wurde wegen Remote-Entwicklern aufgegeben.
Erkenntnisse nach einem Jahr¶
Scrum ist kein Allheilmittel, aber für die meisten Projekte besser als Wasserfall. Disziplin, Kundenbeteiligung und Geduld sind entscheidend.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns