Was bedeutet das Agile Manifest in der Praxis?
Das Agile Manifest soll das Fundament unserer Arbeit sein. Dieses Thema habe ich auch in mehreren Folgen hier im Podcast besprochen. Zum Beispiel:
Doch was bedeutet das Agile Manifest in der Praxis? Folgende Beispiele sollen Dir dabei helfen.
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Beispiel 1: Das Team steht vor einem kritischen Bug kurz vor dem Release. Statt dem offiziellen Prozess für Bug-Tracking zu folgen, setzen sich die Entwickler spontan zusammen, besprechen das Problem direkt und lösen es gemeinsam in einer Stunde. So sparen sie Zeit und vermeiden Verzögerungen, während der Kunde pünktlich das Update erhält.
Beispiel 2: Ein Kunde bittet um eine kleine Änderung. Statt ein Ticket zu erstellen und den formalen Prozess abzuwarten, spricht der Entwickler direkt mit dem Kunden, klärt die Anforderungen und implementiert die Änderung noch am selben Tag. Der Kunde ist zufrieden, und das Team vermeidet unnötigen bürokratischen Aufwand.
Beispiel 3: Das Team erhält widersprüchliche Anforderungen von verschiedenen Stakeholdern. Anstatt lange Dokumentationen zu wälzen, organisiert der Product Owner ein schnelles Meeting mit allen Beteiligten. In 30 Minuten klären sie Missverständnisse und stimmen sich ab, sodass das Team direkt weiterarbeiten kann. Der schnelle Austausch spart Zeit und sorgt für Klarheit.
Funktionierende Software mehr als umfassende Dokumentation
Beispiel 1: Das Team entwickelt eine neue API. Statt viel Zeit in die detaillierte Dokumentation jeder Funktion zu stecken, konzentrieren sich die Entwickler darauf, die API frühzeitig zum Laufen zu bringen und sie dem Kunden zur Verfügung zu stellen. Der Kunde kann die API direkt testen und gibt wertvolles Feedback, das in die Weiterentwicklung einfließt. Die Dokumentation wird später nach Bedarf ergänzt.
Beispiel 2: Beim Sprint-Review stellt das Team eine fast fertige Version der neuen App vor, ohne dass die Enddokumentation abgeschlossen ist. Der Kunde testet die App live und gibt sofort Feedback. Das Team kann die App schnell anpassen und optimieren, während die Dokumentation später vervollständigt wird. So erhält der Kunde schneller eine funktionierende Lösung, die seinen Bedürfnissen entspricht.
Beispiel 3: Ein Entwicklerteam steht vor der Wahl, eine Woche mit der Erstellung eines umfangreichen Architektur-Dokuments zu verbringen oder die grundlegende Funktionalität der Anwendung schnell zum Laufen zu bringen. Sie entscheiden sich dafür, die Software zuerst zum Laufen zu bringen, sodass der Kunde sofort testen kann. Die technische Dokumentation wird später ergänzt, basierend auf den tatsächlichen Implementierungsdetails.
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Beispiel 1: Das Team entdeckt während der Entwicklung, dass eine vereinbarte Funktion nicht den tatsächlichen Bedürfnissen des Kunden entspricht. Statt sich auf den ursprünglichen Vertrag zu berufen, kontaktiert der Product Owner den Kunden direkt. Gemeinsam passen sie die Anforderungen flexibel an, um ein besseres Ergebnis zu erzielen. Der Fokus liegt auf einer Lösung, die dem Kunden wirklich hilft, anstatt auf starren Vertragsdetails.
Beispiel 2: Ein Kunde möchte die Navigation der App ändern. Statt die Änderung per E-Mail zu beantragen und den Prozess durch mehrere Genehmigungsstufen zu führen, lädt das Team den Kunden zu einem gemeinsamen Design-Workshop ein. Dort wird ein interaktiver Prototyp erstellt und sofort angepasst, basierend auf dem direkten Feedback des Kunden. So wird die neue Navigation schnell und zielgerichtet implementiert.
Beispiel 3: Der Kunde stellt während der Entwicklung fest, dass sich die Prioritäten geändert haben. Anstatt sich auf die vertraglich festgelegten Spezifikationen zu berufen, trifft sich das Team regelmäßig mit dem Kunden, um die neuen Prioritäten zu besprechen und das Produkt entsprechend anzupassen. Die enge Zusammenarbeit ermöglicht es, die wichtigsten Anforderungen schnell zu erfüllen, ohne durch Vertragsverhandlungen aufgehalten zu werden.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Beispiel 1: Das Team entdeckt während des Entwicklungsprozesses, dass eine neue Markttrends-Analyse eine signifikante Anpassung der Funktionen erforderlich macht. Anstatt starr am ursprünglichen Plan festzuhalten, organisiert das Team ein Meeting, um die neuen Anforderungen zu besprechen und den aktuellen Sprint entsprechend anzupassen. Sie integrieren die neuen Features direkt in die laufende Entwicklung, um das Produkt optimal an den neuesten Marktbedürfnissen auszurichten.
Beispiel 2: Während eines Projekts erfährt das Team von einem unerwarteten technischen Problem, das den ursprünglichen Plan in Frage stellt. Anstatt den gesamten Plan neu zu erstellen und den Zeitplan zu verzögern, hält das Team eine schnelle Besprechung ab, um die beste kurzfristige Lösung zu finden. Sie passen die Vorgehensweise flexibel an und integrieren die notwendige Änderung sofort, um das Projekt auf Kurs zu halten.
Beispiel 3: Während eines Sprints wird klar, dass ein neues Sicherheitsrisiko entdeckt wurde, das sofortige Maßnahmen erfordert. Anstatt den bestehenden Plan zu verfolgen, verschiebt das Team schnell Prioritäten, um das Sicherheitsproblem zu beheben. Sie setzen eine kurzfristige Lösung um und passen den ursprünglichen Plan dynamisch an, um sicherzustellen, dass die Sicherheitsanforderungen erfüllt werden.
