Skip to main content

Die methodische Vielfalt des Projektmanagements schien in den letzten Jahren ins Unermessliche zu wachsen. Kanban, Lean oder doch Scrum? Unabhängig der Methode können wir vorab bereits eines sagen: agile Prozesse sind – nicht nur aus unserem Alltag als Softwareentwickler – nicht mehr wegzudenken. Insbesondere die aus dem Software-Bereich stammende Scrum-Methode findet in nahezu jedem Projekt Anwendung. Doch ist sie wirklich die Agile-Allzweckwaffe oder doch nur eine Methodenkeule?

Der agile Urknall

Beginnen wir beim kleinsten gemeinsamen Nenner, dem “Agile Manifest”:

  • Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
  • Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.
  • Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
  • Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

source: agilemanifesto.org

Die Verfasser des Manifests waren sich der klassischen Management-Werte und ihres Stellenwerts bewusst. Dennoch hoben sie explizit den Wert der hier in Bold angeführten Dinge darüber, um nach besseren Wegen der Entwicklung zu suchen. Dies ist ihrer Meinung nach nur möglich, wenn diese selbst praktiziert werden und anderen dabei geholfen wird, dies zu tun.

Im Mittelpunkt der agilen Arbeit stehen damit Iteration und empirisches Lernen wie auch Kommunikation und Transparenz. Die Vorteile für den Entwicklungsprozess liegen klar auf der Hand:

  • Im gesamten Team findet ein steter Lernprozess statt.
  • Flexible Reaktionen auf neue Dynamiken im Markt.
  • Kundenzentriertes Arbeiten.
  • Schnelle Fehlererkennung.

Vorteile, die sich laut 72 % der agil arbeitenden Unternehmen in qualitativ besseren Projektergebnissen widerspiegelt. Doch welche Methode wird innerhalb dieser Unternehmen angewandt? Die Antwort fällt eindeutig aus: acht von zehn Unternehmen nutzen Scrum. (Source: bitkom-research.de)

Scrum in der unserer Praxis

Eine Erfahrung, die auch wir teilen. Dank klarem Framework und der Freiheit, flexibel zu agieren und zu reagieren, haben wir Scrum für erfolgreiche Softwareprojekte nicht nur schätzen gelernt, sondern als aktiven Prozess etabliert:

1

Festlegen der Rollen

Der Product Owner dient als Repräsentation der Stakeholder, verantwortlich für den wirtschaftlichen Erfolg. Der Scrum Master ist verantwortlich für die Umsetzung der Scrum-Methode.
2

Erstellen des Backlog

Product Owner erarbeitet zusammen mit dem Kunden / Stakeholder das Backlog. Jedes Backlog Item erhält eine User-Story. Diese vermittelt den Entwicklern warum und wie die gewünschte Funktionalität zu erwarten ist und sollten innerhalb eines Sprints abgearbeitet werden können. Akzeptanzkriterien je Item stellen eine Checklist für den Entwickler dar, an der er sich orientieren kann.
3

Bestimmen der DoD (Definition of Done)

Zusammen mit dem Team erarbeiten wir eine DoD welche auf inidividuell auf das Projekt zugeschnitten ist. Die DoD legt anschließend fest, nach welchen Kriterien ein Backlog Item als fertig (done) gilt. z. B. Reviews, automatisierte Tests oder Dokumentationen.
4

Festlegen der Sprintlänge

Je nach Teamgröße sind erfahrungsgemäß zwei bis drei Wochen eine optimale Sprintlänge.
5

Planen des Sprints

Die Sprintplanung sieht eine Schätzung der Backlog Items in sogenannten Storypoints vor. Diese Schätzung betrachtet die Komplexität der Items und erfolgt durch die Entwickler, die diese Items tatsächlich umsetzen. In der Vergangenheit hat es sich bewährt durch tägliche 30 Minütige Refinements, Backlog Items für den nächsten Sprint auszuformulieren und zu schätzen - so verteilt sich die Arbeit des Schätzens gleichmäßig und nicht auf einen Tag.
6

Umsetzung

Während der eigentlichen Umsetzung des Sprints stellen tägliche zeitlich limitierte Dailys sicher, dass der Fortschritt überwacht und Probleme rechtzeitig kommuniziert werden.
7

Review

Zusammen mit dem Kunden wird die funktionale Software nach jedem Sprint unter die Lupe genommen und folgende Fragen beantwortet: Sind wir noch auf Zielkurs? Gilt es anders zu priorisieren?
8

Metriken / Retrospektive

Jeder Sprint wird gemessen, die sogenannte Velocity besagt wie viele Storypoints pro Sprint umgesetzt wurden. Anhand dieses Durchschnitts erfolgt die nächste Sprintplanung. Am Ende eines jeden Sprints werden die Entwickler nach ihrer Zufriedenheit befragt, Probleme werden offen angesprochen - diese gilt es in den nachfolgenden Sprints so schnell wie möglich zu klären. Dieser Prozess erfordert eine hohe Kommunikations- und oftmals auch Kritikfähigkeit.

Ob in der Zusammenarbeit mit kleinen Teams, in komplexen Projekten oder bei unvorhersehbaren Herausforderungen, Scrum hat sich für uns als zuverlässiger und erfolgreicher Prozess bewährt. Etabliert heißt jedoch nicht festgefahren. Dank seiner Flexibilität und den dahinter liegenden Werten – Respekt, Mut, Offenheit, Fokus, Commitment – lässt sich Scrum auf nahezu jedes Entwickler-Projekt adaptieren. Bestehende Strukturen, Teamgröße und Projektkomplexität bestimmen dabei über die Auslegung des Scrum-Frameworks.

Für uns wird Scrum so zum agilen Taschenmesser, das je nach Projektanforderung das passende Werkzeug bereithält. Damit nicht doch aus Versehen die Keule ausklappt, erfordert es jedoch von allen Teilnehmern Commitment, Offenheit und Kommunikation.

Bist du bereit über dein nächstes Projekt zu sprechen? Ruf uns an, chatte online mit uns oder lass uns eine Nachricht da und wir finden die passende Vorgehensweise für deine Software.

Kontakt aufnehmen