© saicle/Shutterstock.com
PHP Magazin
Kolumne: A2 - alles Agile

Agile Fluency: Delivering Zone

Eine agile Transformation wird in vielen Kontexten zum Selbstzweck, wenn nicht beachtet wird, was der Kunde am Markt wirklich benötigt. Das Agile Fluency Model hilft dabei, Transparenz zu schaffen, welche agilen Transitionen wirklich nötig sind, um hinreichend für den Markt transformiert zu sein. In der vorangegangenen Ausgabe der Kolumne haben wir uns mit der Focusing Zone aus dem Agile Fluency Model beschäftigt. In dieser ersten Zone findet die Teambildung statt, die Ausrichtung, ein Produkt für den Kunden zu entwickeln. Hierbei können Scrum oder Ideen aus dem Extreme Programming [1] Anwendung finden, um die Anforderungen der Kunden zu verstehen und das Produkt zielgerichtet für den Kunden zu entwickeln. Die Transparenz darüber, an was gerade gearbeitet wird, hat sich in der Focusing Zone erhöht, ebenso haben sich die Kommunikationsmuster verbessert. Der Erfahrung nach brauchen Teams zwischen drei und sechs Monaten, um in dieser Zone fluent zu werden. Die nächste Zone im Agile Fluency Model [2] ist die Delivering Zone, die es dem Team ermöglicht, in der passenden Taktung Richtung Markt zu liefern.

René Schröder


Viele Diskussionen drehen sich zum Beispiel im Umfeld von Scrum [3] um die „richtige“ Sprintlänge. Oft werden hier verschiedene, dogmatische Ansichten vertreten wie etwa „Eine Woche Sprintlänge muss immer das Ziel sein, um möglichst häufig zu lernen“ oder „Wir müssen Vier-Wochen-Sprints haben, um am Ende des Sprints genug Zeit zum Testen zu haben“. Diese und ähnliche Sichtweisen sind legitim und verständlich, sie lassen aber einen Punkt unbeachtet: Die richtige Sprintlänge bestimmt mittelbar der Kunde bzw. der Markt. Eine pauschale Aussage wie „Wir müssen jede Woche Richtung Markt liefern und deshalb einwöchige Sprints haben“ kann somit in vielen Kontexten nicht gelten. Wenn der Kunde im Markt die Lieferungen gar nicht benötigt oder verarbeiten kann, hat das Team zu viel Zeit und Ressourcen in die agile Transformation gesteckt, um eine Sprintlänge von einer Woche zu erreichen. Es ist von Bedeutung zu verstehen, was der Markt benötigt, die Reaktion des Markts zu reflektieren (Inspect) und das Vorgehen entsprechend sinnvoll anzupassen (Adapt). Das geschieht in der Zone zwei des Agile Fluency Models (Abb. 1), der Delivering Zone. Die genaue Einordnung der Zone im Agile Fluency Model ist Tabelle 1 zu entnehmen.Abb. 1: Deliver ValueLieferung ist dabei im Model [2] wie folgt definiert: Das Team kann seine letzte Arbeit – im Fall von Scrum: das letzte Product Increment – mit minimalem Risiko und minimalen Kosten Richtung Markt liefern, wann immer dieser es fordert.Techniken als hilfreiche WegbereiterTransparencyCore MetricDas Team kann seine letzte Arbeit mit minimalem Risiko und minimalen Kosten Richtung Markt liefern, wann immer dieser es fordert.Reduce RiskSystemische Fehler im Produktlebenszyklus werden früh aufgezeigt.Increase SatisfactionDas Team bietet nützliche Releasevorhersagen für Manager und Kunden.AchievementIncrease ProductivityDas Team hat eine verringerte Fehlerrate, was dazu führt, dass weniger Zeit für Bugfixing aufgewendet werden muss und mehr Zeit für Produktverbesserungen bleibt.Die technische Codebasis beinhaltet weniger technische Schulden, womit Neuanforderungen einfacher und billiger zu implementieren sind.Increase ROIDas Team liefert Richtung Markt, im vom Markt geforderten Takt.AlignmentIncrease ProductivityWeniger Fehler und weniger technische Schulden tragen im Team zur Zufriedenheit und Moral bei, was sich positiv auf die Produktivität auswirkt.Die technische Codebasis beinhaltet weniger technische Schulden, womit Neuanforderungen...

PHP Magazin
Kolumne: A2 - alles Agile

Agile Fluency: Delivering Zone

Eine agile Transformation wird in vielen Kontexten zum Selbstzweck, wenn nicht beachtet wird, was der Kunde am Markt wirklich benötigt. Das Agile Fluency Model hilft dabei, Transparenz zu schaffen, welche agilen Transitionen wirklich nötig sind, um hinreichend für den Markt transformiert zu sein. In der vorangegangenen Ausgabe der Kolumne haben wir uns mit der Focusing Zone aus dem Agile Fluency Model beschäftigt. In dieser ersten Zone findet die Teambildung statt, die Ausrichtung, ein Produkt für den Kunden zu entwickeln. Hierbei können Scrum oder Ideen aus dem Extreme Programming [1] Anwendung finden, um die Anforderungen der Kunden zu verstehen und das Produkt zielgerichtet für den Kunden zu entwickeln. Die Transparenz darüber, an was gerade gearbeitet wird, hat sich in der Focusing Zone erhöht, ebenso haben sich die Kommunikationsmuster verbessert. Der Erfahrung nach brauchen Teams zwischen drei und sechs Monaten, um in dieser Zone fluent zu werden. Die nächste Zone im Agile Fluency Model [2] ist die Delivering Zone, die es dem Team ermöglicht, in der passenden Taktung Richtung Markt zu liefern.

René Schröder


Viele Diskussionen drehen sich zum Beispiel im Umfeld von Scrum [3] um die „richtige“ Sprintlänge. Oft werden hier verschiedene, dogmatische Ansichten vertreten wie etwa „Eine Woche Sprintlänge muss immer das Ziel sein, um möglichst häufig zu lernen“ oder „Wir müssen Vier-Wochen-Sprints haben, um am Ende des Sprints genug Zeit zum Testen zu haben“. Diese und ähnliche Sichtweisen sind legitim und verständlich, sie lassen aber einen Punkt unbeachtet: Die richtige Sprintlänge bestimmt mittelbar der Kunde bzw. der Markt. Eine pauschale Aussage wie „Wir müssen jede Woche Richtung Markt liefern und deshalb einwöchige Sprints haben“ kann somit in vielen Kontexten nicht gelten. Wenn der Kunde im Markt die Lieferungen gar nicht benötigt oder verarbeiten kann, hat das Team zu viel Zeit und Ressourcen in die agile Transformation gesteckt, um eine Sprintlänge von einer Woche zu erreichen. Es ist von Bedeutung zu verstehen, was der Markt benötigt, die Reaktion des Markts zu reflektieren (Inspect) und das Vorgehen entsprechend sinnvoll anzupassen (Adapt). Das geschieht in der Zone zwei des Agile Fluency Models (Abb. 1), der Delivering Zone. Die genaue Einordnung der Zone im Agile Fluency Model ist Tabelle 1 zu entnehmen.Abb. 1: Deliver ValueLieferung ist dabei im Model [2] wie folgt definiert: Das Team kann seine letzte Arbeit – im Fall von Scrum: das letzte Product Increment – mit minimalem Risiko und minimalen Kosten Richtung Markt liefern, wann immer dieser es fordert.Techniken als hilfreiche WegbereiterTransparencyCore MetricDas Team kann seine letzte Arbeit mit minimalem Risiko und minimalen Kosten Richtung Markt liefern, wann immer dieser es fordert.Reduce RiskSystemische Fehler im Produktlebenszyklus werden früh aufgezeigt.Increase SatisfactionDas Team bietet nützliche Releasevorhersagen für Manager und Kunden.AchievementIncrease ProductivityDas Team hat eine verringerte Fehlerrate, was dazu führt, dass weniger Zeit für Bugfixing aufgewendet werden muss und mehr Zeit für Produktverbesserungen bleibt.Die technische Codebasis beinhaltet weniger technische Schulden, womit Neuanforderungen einfacher und billiger zu implementieren sind.Increase ROIDas Team liefert Richtung Markt, im vom Markt geforderten Takt.AlignmentIncrease ProductivityWeniger Fehler und weniger technische Schulden tragen im Team zur Zufriedenheit und Moral bei, was sich positiv auf die Produktivität auswirkt.Die technische Codebasis beinhaltet weniger technische Schulden, womit Neuanforderungen...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang