Agiles Vorgehen löst keine Probleme

Nein, die Probleme verschwinden nicht direkt. Aber sie werden meist besser sichtbar. Das agile Vorgehen vertraut weniger auf langfristige Planung, sondern auf fortlaufende Verbesserung.

Agiles Vorgehen geht auf das agile Manifest zurück. Es sind im Kern vier Forderungen:

  1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  2. Funktionierende Software mehr als umfassende Dokumentation
  3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  4. Reagieren auf Veränderung mehr als das Befolgen eines Plans

Diese Forderungen werden ergänzt mit zwölf Prinzipen:

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
  2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Diese Prinzipen wiederum werden durch Rahmenwerke – wie Scrum – konkret im Projekt einsetzbar.

Agil oder nicht?

Zunächst muss aber klar sein, ob dieses agile Vorgehen der richtige “Werkzeugkasten” ist. Es ist dann geeignet, wenn das Projektziel nicht festgelegt werden kann oder soll, erfordert also eine Offenheit im Bezug auf das Ergebnis.

Mindset

Speziell in den 12 Prinzipien wird klar, dass das agile Vorgehen eine spezielle Einstellung, ein Mindset verlangt:

  • Die Motivation entsteht durch die Sinnhaftigkeit der Aufgabe
  • Die Teams organisieren sich selbst
  • Es werden Hypothesen für wertvolle Software aus Nutzersicht aufgestellt
  • Die Entwicklung bestätigt oder widerlegt die Hypothesen.
  • Das Team lernt darauf und justiert neu.
  • Das Team wünscht sich eine laufende Veränderung und Verbesserung. Es heißt das Unbekannte willkommen und ist offen für Änderungen.
  • Das Vorgehen folgt einer Produktvision, anhand dieser werden Entscheidungen abgeglichen und ausgerichtet.

Wenn diese Offenheit nicht vorhanden ist, ist das agile Vorgehen nicht das Richtige.

Wahrhaftigkeit

Das Vorgehen zeigt dabei schnell, wenn die Organisation oder das Team nicht “wirklich” agil vorgeht. Häufig werden “Daily Standups” eingeführt, das Projekt aber eigentlich noch komplett geplant. Auch wenn Features zwar in Tickets formuliert, aber nicht aus Sicht des späteren Kunden, sondern aus Sicht der Features der Shopsoftware aufgebaut.

Anzeichen für nicht wirklich funktionierendes agiles Vorgehen:

  • Das Projekt ist bereits komplett geplant, bzw. es existieren detaillierte Pläne für zukünftige Sprints.
  • Es existiert eine Gesamtaufwandsschätzung. Einen Festpreis.
  • Es wurde noch nie ein echter Nutzer gefragt und einbezogen.
  • Die Anforderungstickets definieren keinen Business-Value.
  • Der Product-Owner ist häufig nicht greifbar.
  • Es gibt einen Projektmanager – dieser entfällt im Agilen, da das Team sich selbst organisiert.
  • Architektonische Entscheidungen werden bereits früh getroffen und nicht durch Erkenntnisse aus vorangegangenen Sprints.
  • Das Team liefert am Ende eines Sprints Features und kein Produktinkrement.
  • Es wurde noch keine Entwicklung eines vorangegangenen Sprints verworfen.
  • Kunde oder Stakeholder verlangt für jeden Sprint Return-On-Invest.

Alles deutet darauf hin, das weiter versucht wird, ein Produkt vorab zu planen. Der entscheidende Vorteil am Agilen ist aber, dass genau diese Produktplanung aus dem Feedback der Kunden entsteht. Auch wenn dieses anders ausfällt, als gedacht.

Dabei entsteht Software, die vom Kunden gerne genutzt wird, weil sie wirklich seine Probleme löst.

Zudem verspricht Scrum bei einem eingespielten Team in der Perspektive “Doppelt so viel Arbeit in der Hälfte der Zeit” zu schaffen. Dies gelingt, wenn das Team komplett fokussiert und frei von Störeinflüssen arbeiten kann und die Zahnräder aus Team, Scrum-Master, Product-Owner und Stakeholder irgendwann gut ineinandergreifen.