Agile, iterative und inkrementelle Entwicklung

Agile, iterative und inkrementelle Entwicklung

Ich darf täglich Kunden beobachten, die entweder mit Scrum Produkte entwickeln oder es demnächst vorhaben. Leider geht das Verständnis von Scrum, wenn sie sich dafür als “agile Entwicklung” entscheiden, in der Praxis und Theorie weit auseinander.

Häufig kommen das Aussagen, dass “Scrum so einfach nicht funktioniert” und wir “einen pragmatischen Ansatz benötigen, um Scrum an unsere Umgebungen anzupassen”. Innerlich baut sich dann ein Gefühl bei mir auf, dass sich zwischen Schmunzeln, Lachen, Wut und Ohnmacht ausdrückt.

Das ist gar nicht negativ auf den Kunden bezogen, sondern fängt bei mir selbst an. Ich trage - nicht erst seit gestern - die Gedanken von Scrum und Co durch die Welt, weil ich davon überzeugt. Vielleicht oft nicht aus der gesamten Perspektive, die für den ein oder anderen Betrachter notwendig sind. Deshalb versuche ich einen neuen Anlauf hier im Blog, der in meine must-have Readinglist für alle Kunden, Partner und Interessenten eingeht 🙂

agile, iterative und inkrementelle Entwicklung

Die Rahmenbedingungen müssen stimmen

Damit eine agile, iterative und inkrementelle Entwicklung wirklich Sinn macht, müssen die Rahmenbedingungen für Ihr Umfeld stimmen. Wenn Sie nicht die Rahmenbedingungen besitzen, die für Scrum optimal sind, dann werden Sie auch nur bedingt Vorteile in diesem Framework finden.

Diesen Rahmenbedingungen können Sie sich mit dem Stacey Landscape Diagram recht gut nähern oder Sie verwenden das Cynefin Framework. Wenn Ihre Analyse ergibt, dass Ihr Produkt, welches Sie entwickeln möchten, in einer komplexen Umgebung befindet, dann liegen Sie an der Stelle schon mal recht gut für einen Einsatz von Scrum. Wenn Sie die Rahmenbedingungen begriffen haben, spielen zudem noch eine Menge an weiteren organisatorischen Rahmenbedingungen mit in eine Entscheidung für eine Umsetzung mit Scrum. Ein Klassiker dabei ist immer wieder zu denken, mit einem großen “Roll-Out” kann eine solche Einführung gelingen. Das funktioniert nicht, denn Scrum basiert zum einen auf Empirie und zum anderen auf einem Inspect & Adapt Ansatz. Ohne jetzt zu sehr in die Details einzusteigen, wenn Sie nicht in der Lage sind, auf Basis Ihrer gemachten Erfahrungen den Prozess kontinuierlich zu verbessern, diesen transparent zu haben und darauf hin Anpassungen vorzunehmen, dann wird Ihnen auch der Erfolg von einem Scrum Team verwehrt bleiben.

Sie müssen überhaupt erstmal inkrementell entwickeln können!

Wenn Sie die benötigten Rahmenbedingungen (sowohl für Ihr Umfeld, als auch Ihre Organisation) vorfinden, dann ist das ein erster wichtiger Schritt. Allerdings müssen Sie auch die Fähigkeit besitzen, inkrementell Produkte zu entwickeln, denn dieses Denken in Inkrementen ist essentiell und sehr wichtig. Inkrementell bedeutet, dass Sie innerhalb Ihrer gewählten Länge des Sprints (wenn Sie sich nach dem agilen Manifest richten, dann müssen Sie innerhalb weniger Wochen oder Monate (regelmäßig) liefern, nach dem Scrum Guide, darf dieses nicht mehr als ein Monat sein) ein erlebbares Inkrement liefern können, das einer sauberen Definition of Done entspricht und durch den Kunden auch inspiziert werden kann. Das bedeutet, dass der Kunde Erfahrungen mit dem Inkrement machen und etwas “erleben” kann.

Natürlich ist oft die Euphorie recht groß zu Beginn einer neuen Transformation auf Scrum, aber auch voller Gefahren, wenn man die wirkliche Tragweite eines Inkrements nicht richtig verstanden hat. Deshalb gehe ich auf die aus meiner Sicht größten Stolpersteine noch einmal ein:

  • Sie liefern ein Inkrement aus und dieses Inkrement ist nicht erlebbar. Das kann die unterschiedlichsten Gründe haben wie zum Beispiel: Die Software ist nicht in einem Zustand, so dass sie ein Kunde auch wirklich erleben kann. Sie haben ein Produkt erstellt, aber keinen wirklichen “Durchstich” durch das Produkt generiert, so dass dem Kunden nur ein Blick auf einen Teil des Produktes möglich ist und der ganze Wert nicht erkenntlich ist. Ein Blick auf das Produkt ist also im Sinne eines Projektfortschritts wenig transparent.

  • Wenn Sie Ihre bisherige Entwicklung lediglich in “Sprints” zwängen, innerhalb in des Sprints aber nach wie vor ein sequentielles Vorgehen umsetzen, dann werden Sie keine agile Entwicklung und keinen Vorteil aus Scrum ziehen können. Das mag zu Beginn vielleicht noch ein logischer Weg sein, verstößt später aber gegen das Inspect und Adapt und auch eine regelmäßige Lieferung von funktionierender Software wird dann problematisch werden.

Sie müssen sich grundsätzlich einmal über den Wertstrom für Ihr Produkt, Ihre Software oder Ihren Service bewusst werden. Nur wenn Sie diesen kennen, können Sie überhaupt entscheiden, wie Ihre Teams organisiert sein sollten. Nur wenn Sie die Teams richtig aufstellen, dann können Sie auch inkrementell entwickeln.

Kennen Sie die Scrum Werte und agilen Prinzipien?

Leider immer sehr vernachlässigt und als “einfach” abgestempelt: die agilen Prinzipien und Scrum Werte. In der Regel haben natürlich die wenigsten Unternehmen, die keinen besonderen Wert darauf legen, diese verstanden. Ich werde die an dieser Stelle nicht erneut herleiten, sondern verweise auf meine bisherigen Blogbeiträge dazu.

Nicht erreichte Product Backlog Einträge gehören nicht in den nächsten Sprint - oder doch?

Immer wieder sehe ich gerne den folgenden Effekt bei Srcum Teams. Der Sprint ist zu Ende und es gibt noch einige Arbeit die im Sprint geplant wurde, aber nicht erledigt werden konnte. Sie liegt also als halbfertige Arbeit vor und gilt nicht als “fertig”, da sie natürlich nicht der Definition of Done entspricht.

Was macht der Product Owner und das Entwicklungsteam? Ganz oft nach dem Motto: was muss, das muss eben und schon stehen diese Einträge wieder im nächsten Sprint. Es wird sich häufiger nicht einmal die Mühe gemacht, dass man sich dem Thema erneut widmet.

Dafür gibt es folgende Ursachen aus meiner Sicht:

  1. Sie entwickeln nicht wirklich inkrementell, denn diese Einträge müssen immer gemacht werden, egal was passiert. Sie sind also zu erledigen, da sonst andere Dinge überhaupt nicht erledigt werden können (Vorarbeiten Integration, etc.).
  2. Sie haben doch nicht die Rahmenbedingungen von komplexen Produkten. Sie müssen nämlich bestimmte Aufgaben immer machen und es ist egal, wie sich der Markt entwickelt. Da würde ich zum einen immer gerne mal hineinschauen, ob dem auch wirklich so ist. Zum anderen scheint wenig Notwendigkeit zu bestehen, mit Scrum zu entwickeln.

Wie Sie richtig gute Product Backlog Items erstellen

Im Folgenden Abschnitt möchte ich das Augenmerk noch einmal genau darauf legen, wie Sie konkret auf gute Produkte hin entwickeln können. ich starte dabei ich mit den elementaren Variablen auf die Scrum fokussiert: Flexibilität und Kundennutzen.

Die Flexibilität fokussieren

Vielleicht ist die Annahme für viele zu trivial und wird gerne als überzogen und zu theoretisch abgetan. Nur wenn Sie dieses Inkrement liefern können, auch dann haben Sie überhaupt die Möglichkeit eine wirkliche agile und inkrementelle Entwicklung durchzuführen. Wenn Sie einmal das Konzept von einem Inkrement verstanden haben, dann begreifen Sie auch sehr schnell den Sinn von Scrum und dann wird schnell alles schlüssig.

Hinweis!

Wenn Sie zu den Personen gehören, die einfach “agile Elemente” einmal ausprobieren und nicht alle Vorteile von Scrum ausschöpfen wollen oder müssen, dann können Sie das natürlich tun. Ihr Ergebnis ist dann kein Scrum, Sie können aber trotzdem Ihre ersten Versuche machen und ausprobieren, wie sich zum Beispiel bestimmte Praktiken wie Planning Poker, User Stories oder Taskboards anfühlen und bei Ihnen einsetzen lassen.

Sie brauchen eine Flexibilität, um an einem dynamischen und volatilen Markt bestehen zu können. Wir erinnern uns an das Cynefin Framework, nur wenn Sie die Schritte “probe - sense - respond” benötigen, dann sind Sie auch im komplexen Bereich. Und dann brauchen Sie auch genau diese Inkremente. Wenn Sie die Inkremente nicht schaffen, dann entwickeln Sie an Ihrem Markt vorbei. Wenn Sie nicht am Markt vorbei entwickeln, dann haben Sie diese komplexen Rahmenbedingungen nicht. Und dann brauchen Sie dieses Inkrement auch nicht, dann sollten Sie aber genau überlegen, was für Vorteile Sie sich von Scrum erhoffen und warum Sie es einsetzen.

Die Kunden im Blick

Als nächstes müssen Sie Ihre Kunden im Blick behalten. Das sagt sich zwar einfach, ist aber in der Realität schwer. Denn Kunden im Blick halten bedeutet nicht, dass Sie mit diesem “halt mal sprechen” und dann der Meinung sind, zu wissen was dieser genau braucht. In komplexen Rahmenbedingen “driftet” die Erwartungshaltung des Kunden beachtlich. Und das auch oft so, dass Sie die Erwartungshaltung nicht einfach in einem Gespräch erarbeiten können, sondern der Kunde muss diese erleben. Nur durch die oben genannte Flexibilität hat ein Product Owner überhaupt die Möglichkeit irgendeine Verbesserung zur Optimierung des Mehrwerts für den Kunden herbeizuführen. Er ist derjenige, der das Beste aus dem Produkt mit dem Entwicklungsteam zusammen herausholen muss. Dafür ist es unabdingbar, den Kunden und die Wünsche zu erleben, zu reflektieren und dann zu kennen.

Gute Product Backlog Items erstellen

Im Grunde ist das einfach aber nicht leicht umzusetzen. Sie haben genau dann gute Product Backlog Items, wenn diese für sich einzeln genommen

  • einen Mehrwert liefern und
  • sich einzeln in ein Inkrement überführen lassen

Das finden wir zum Beispiel in den INVEST Kriterien von User Stories. Sie müssen einen Wert (value) liefern und sie dürfen nicht voneinander abhängig sein. Wenn Sie dieses Muster etablieren, dann werden Sie mit Ihrem Inkrement Erfolg haben.

Leave a Reply 0 comments

Leave a Reply:







>