.st0{fill:#FFFFFF;}

Scrum Einführung

Hilfe: kein Inkrement?

 Juni 28, 2017

von  Sebastian

Das Inkrement

Das Inkrement, potentiell auslieferbares Inkrement oder potential shippable increment hat eine zentrale Bedeutung in Scrum. Die Namen sind oft unterschiedlich gewählt, es geht aber immer um dasselbe. Das Grundlegende hinter diesem Inkrement ist ganz zentral in Scrum und wichtig zu verstehen. Das Inkrement steht in Scrum (spätestens) am Ende des Sprints zur Verfügung und kann im Sprint Review damit gezeigt werden.

Bei diesem Sprint Review können der Product Owner, Stakeholder und andere Personen das Inkrement betrachten und bekommen einen Eindruck über den Fortschritt des Projektes. Zudem kann hier das typische und oft genannte "inspect & adapt" aus Produktsicht zum Tragen kommen.

In dem folgenden Video gehe ich auch einige Prinzipien hinter dem Inkrement ein. Wenn Sie kein Inkrement haben, schauen Sie sich bitte das Video an und erarbeiten Sie - zum Beispiel in Retrospektiven - die fehlenden Dinge auf.

Warum ist das Inkrement in Scrum wichtig?

Produktinkrement in Scrum

Das Inkrement in Scrum hilft allen Beteiligten zu erkennen, wie der Fortschritt des Projektes und damit auch des Produktes ist. Sie bekommen zu jedem Inkrement ein Gefühl darüber, wie Anforderungen umgesetzt sind und wie sich diese anfühlen und erleben lassen.

Durch das Inkrement sind Sie überhaupt erst in der Lage inkrementell zu arbeiten! Es ist wichtig zu verstehen, dass wir Menschen - also auch der Kunde - erst in der Lage sind ein Produkt, ein Inkrement oder Prototyp dann zu verstehen, wenn er das erste Mal etwas sehen und ausprobieren  und es wahrhaftig erfahren kann.

Das Inkrement ist genau der Teil, der die richtige Agilität ausmacht. Also wendig und flexibel auf dem Markt zu bestehen und sich diesem anzupassen. Nur wenn Sie nach dem Sprint etwas lauffähiges und werterzeugendes abliefern können, dann haben Sie die Möglichkeit überhaupt auf Änderungen am Markt eingehen und reagieren. Es ist damit Ihre Möglichkeit, Einfluss zu nehmen. 

In dem folgenden Bild sehen Sie zwei Teams. Ein Team erzeugt regelmäßig ein Inkrement, das andere nicht. Während ersteres immer die Möglichkeit hat, auf Reaktionen seitens Kunden & Stakeholder einzugehen, fehlt das beim zweiten Team. Hier ist eine Rückmeldung nur nach einer bestimmten Anzahl von Inkrements möglich.

Wenn Sie in einem turbulenten Umfeld arbeiten, kann das im schlimmsten Fall nicht ausreichen.

kein Inkrement

Woran erkennen Sie, dass Sie kein Inkrement haben?

Die einfache und schnelle Antwort ist, "daran, dass die Arbeit nicht fertig ist". Sie haben es nicht geschafft Ihre Arbeit in ein "done" Inkrement umzusetzen. Oft haben Teams zunächst gar keine richtige Definition of Done oder aber sie ist einfach noch nicht ausreichend.

Letzteres ist ein Inspect & Adapt, dann müssen und sollten Sie sich schnellstens darum kümmern, dass diese Definition of Done passend ist.

Wenn Sie in einem Sprint Review nichts zeigen können, weil Sie zum Beispiel nur ein Design von der Software erstellt haben oder etwas anderes, das für sich genommen nichts an Wert erzeugt, dann bringt Ihnen das im Sinne einer agilen, inkrementellen Entwicklung recht wenig.

Wenn Sie im Unternehmen gefragt werden, wie denn nur der Stand vom Produkt sei und ob Sie mehr Details erläutern können, dann ist das Inkrement ebenso nicht ausreichend.

Woran erkennen Sie, Ihr Inkrement funktioniert?

Ein Inkrement erlaubt es, immer wieder auf einen alten, auslieferbaren und funktionierenden Stand zurück zugehen. Natürlich passiert es mal, dass das nicht immer der Fall ist, aber wenn es die Ausnahme ist, dann ist es eben nicht hilfreich. Schaffen Sie so einen Stand, schaffen Sie auch Inkremente!

Ebenso haben Sie ein recht geringes Risiko, denn nach einem Sprint können Sie einen neuen Weg einschlagen und sich auf den Kunden neu einlassen und neue Wünsche und Anforderungen bearbeiten.

Hilfe, ich habe kein Inkrement!

Scrum Master

Nun ist guter Rat in der Regel teuer. Es kann bei Ihnen der Fall sein, dass Sie kein Inkrement erzeugen können oder wollen. Wenn es um das Können geht, dann ist die Sache oft auf technische Infrastruktur zurückzuführen oder bestimmte Fähigkeiten, die fehlen.

Ohne ein Continuous Integration und mit kurzen Sprintzyklen werden Sie wenig Software erzeugen, die lauffähig, getestet und dem Kunden vorgeführt werden kann, erzeugen.

Wenn Sie nicht im Softwarebereich tätig sind, dann müssen Sie sich ebenso die gleichen Fragen stellen. Wenn Sie Prozesse oder Dienstleistungen mit Scrum erstellen, fragen Sie sich immer, was am Ende des Sprints erstellt werden kann, das Wert erzeugt und erlebbar ist.

Fehlt es Ihnen an Fähigkeiten, dann ist das genau ein Punkt der in der Retrospektive sofort zu erkennen ist. Es fällt auf und das nach einem Sprint. Wenn Sie sich das in einem klassischen Projekt vorstellen, dann kommen solche Dinge typischerweise erst später zum Tragen. Doch auch im Sprint Review sollten hinsichtliches des Produktes schon Probleme angesprochen und ans Tageslicht kommen.

Scrum ist ein hervorragendes Diagnosetool für Ihren Prozess, das gnadenlos alles an die Oberfläche spült, was bei Ihnen nicht funktioniert. Umgehen müssen Sie damit dann selbst und Lösungen finden. Kein Inkrement zu haben ist nicht optimal, aber oft im Umfeld normal. Nutzen Sie hier immer die Retrospektiven, um Verbesserungen zu erzielen.

Achten Sie beim Sprint Planning direkt darauf, was Sie konkret einplanen. Kann das am Ende dann auch wirklich ein funktionierendes Inkrement werden? Oft kann dieser explizite Schritt schon ein andere Bewusstsein beim Scrum Team fördern.

Typische Antipattern für kein Inkrement in Scrum

  • Wenn der Product Owner oder andere Stakeholder nachfragen, wie ist denn eigentlich der "Stand im Projekt", dann ist das ein Alarmsignal, dass Sie kein Inkrement haben.
  • Sie benötigen mehrere Sprint, um überhaupt etwas zeigen zu können. Kunden, ob intern oder extern, haben lange keine Klarheit, was eigentlich das Produkt macht.
  • Sie suchen nach Möglichkeiten den Sprint zu verlängern, da die Zeit nie ausreicht etwas aaslieferbares zu erstellen.
Kein Inkrement - das sind die Anti-Pattern!

Sebastian

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
Hier gehts lang!
>