sauber und schnell
"Agilität will den höchsten,
nachhaltigen Mehrwert (für die Kunden/Nutzer/Anwender),
in der kürzest möglichen "Lead Time"
ausliefern."
"Lead Time" beschreibt die Zeit von der Anfrage bis zur Auslieferung.
Diesem Grundgedanken ist alles andere untergeordnet.
Under
con
struction
Mehrwert bezeichnet den realen Nutzen, den Kunden/Nutzer/Anwender durch den Erhalt der Lieferung erleben, bzw. haben.
Das kann z.B. Zeitersparnis => Existenzsicherung durch mehr eigene Kapazität für das Kerngeschäft sein oder verbesserte Datenauswertung => Existenzsicherung durch verbesserte Entscheidungsqualität etc.
Mehrwert ist immer etwas, was unsere Kunden/Nutzer/Anwender erleben. Sie geben uns das Feedback, ob sie den Mehrwert erleben, der vereinbart wurde oder nicht. Im Zweifel über das "Gesetz der zwei Füße, d.h. sie kommen wieder (und empfehlen uns sogar weiter ;-) oder eben nicht. Im besten Fall lösen unsere Angebote existentielle Probleme oder tragen wenigstens zu einer Entlastung oder zur Verbesserung der Situation bei. Anderfalls können wir nicht von "geliefertem Mehrwert" sprechen. Das ist nicht wirklich etwas Neues. So haben Unternehmen schon immer funktioniert.
Unternehmerisch macht es demnach sehr viel Sinn, Teams und Organisationen so aufzubauen, dass sie schnell und leicht den gewünschten Mehrwert liefern können. Dafür ist normalweise ein "Value Stream Mapping" oder eine "Workflow Visualisierung" ein guter Einstieg. Diese Herangehensweise ist "neu", da nicht über Abteilungen nachgedacht wird (wir wollen niemanden abteilen!) sondern über Zusammenarbeit und optimalen FLOW im Sytem. Diese Vorarbeit lohnt sich übrigens für alle Teams, da ja alle etwas FÜR andere Menchen tun, die dann wiederum etwas damit TUN oder anfangen wollen. Der ROI dieser Vorarbeit ist normalerweise in einer höheren Liefergeschwindigkeit durch besseres Verständnis, mehr Kooperation und durch Vereinfachung der Abläufe zu erleben.
Eine Zusage über Lieferung von X in der Qualität Y zum Zeitpunkt Z ist ein Vertrag. Ein Vertrag zwischen Auftraggeber*in und einem Team oder Einzelpersonen.
Dieser Vertrag ist bindend. Daher wird er nur bestätigt, wenn beide Seiten davon ausgehen, dass er erfüllbar ist.
Das ist normal, gesund und unternehmerisch sinnvoll.
Für Agilität gilt, dass wir sicherstellen, dass das Verständnis dessen, WAS geliefert werden soll optimal ist. Dafür gibt es verschiedene Instrumente, um das sichzustellen (bsp. Continous Exloration, Requirement Engineering, Refinements, Feedbackschleifen, Prototypes/Spikes/MVPs etc.) und wir nutzen gerne den offenen und strukturierten Dialog - idealerweise am anfassbaren Beispiel.
Um sicherzustellen, dass Lieferverträge so geschlossen werden, dass sie funktionieren, bedienen sich agile Teams der Vergangenheit, z.B. über Velocity oder Cumulated Flow Diagramms. Die Vergangenheit dient als Basis, um eine Prognose in die Zukunft zu stellen. Wenn die Realität doch eine andere ist, merken agile Teams das schnell in der Umsetzung und verfügen über Mittel und Wege um entweder zu justieren oder Alternativen in´s Spiel zu bringen. Diese Routinen laufen im Rahmen der vom Team als hilfreich erachteten Rhythmen und Teamroutinen ab.
Damit ein Team eine Lieferzusage wirklich ernst meinen kann, muss es in der Lage sein zuzustimmen und den Auftrag anzunehmen. Das bedeutet, dass es auch "NEIN." sagen und den Auftrag ablehnen kann.
Das ist die Grundidee des "Pull Prinzips". Das Team zieht sich die Arbeit, weil es die Lieferung zusagen kann und will, also "JA." zum Auftrag sagt.
Diese Prinzip hat es in sich. Es ist nicht mit der herkömmlichen "Befehl - Ausführunglogik" vereinbar und stellt daher alle Beteiligten die Letzteres gewohnt sind auf eine harte Probe. Wer "Befehl und Ausführen" nicht kennt, was für viele der jüngeren Menschen in den Unternehmen gilt, hat das Problem logischerweise nicht. Stattdessen können Spannungen zwischen "Jungen" und dem tradierten System zu einer Belastung werden. Das ist allerdings nicht weiter schlimm ;-).
Dafür kennt die agile Welt "Retros", Facilitation oder wertschätzende/wertebasierte Kommunikation als Wege um solche Spannungen zu lösen. Und da der Wille besser zu werden und bestmöglichen Mehrwert zu liefern der DNA agiler Arbeit innewohnt, lassen sich die zwischenmenschlichen "ersten Spannungen" in der Regel schnell lösen. Das beugt dann auch härteren Interventionen vor, auch wenn diese in der Praxis immer mal wieder vorkommen und notwendig werden können.
Transparenz ist eines der zentralen Werkzeuge der Agilität. Wir wollen sichtbar machen und zeigen, wie der Arbeitstand ist und wie gut wir vorankommen.
Boards, Backlogs, Auswertungen gehören da ebenso dazu, wie Demonstrationen, schnelle Zwischenreviews, Sneak Previews oder Proof of Concepts (= POC, was ein anfassbares unfertiges Beispiel der Lieferung ist, quasi ein Modell zum Lernen und Justieren).
Transparenz ist essentiell. Und sie ist für manche Teams bedrohlich, da sie erlebt haben, dass sie mit anderen Teams verglichen werden oder die Daten gegen sie verwendet werden ("Ihr könnt doch mehr. Bei anderen geht das doch auch...") Diese leider häufigen Managementfehler richten viel Schaden an. Ebenso wie Teams, die ihr Pflicht dem Management saubere Daten zu liefern nicht ernst nehmen.
