Es existieren viele Missverständnisse, wie Agilität in der Produktentwicklung zu verstehen ist. Da gibt es die Einen, die meinen, alles außer der Implementierung weglassen zu können: Wir dokumentieren nicht, wir testen nicht, wir planen nicht. Außerdem gibt es viel Menschen, die unrealistische Hoffnungen in die Einführung von Agilität setzen, zum Beispiel …
„We can change anything at any time“
Ein sehr häufig verbreitetes Missverständnis ist, das der „totalen Flexibilität“, d.h. in einer agil arbeitenden Organisation wäre alles flexibel und sehr schnell änderbar. Aus einer entfernten Perspektive scheint dies erstrebenswert, näher betrachtet würde dies aber eher einem Chaos entsprechen. Die Wahrheit ist, dass auch in der agilen Produktentwicklung durchaus einige Elemente stabil sein sollen und dies aus gutem Grund. In diesem Artikel soll diskutiert werden, auf welche Elemente der Organisation Flexibilität zutrifft und welche Elemente in agilen Vorgehensweisen bewusst stabil bzw. langlebig gehalten werden.
Hier zuerst ein tabellarischer Vergleich:
| Prozesselement | Klassisch | Agil | agile Prinzipien und Elemente |
| langfristige Planung | stabil | grob, flexibel | Vision und grobe Planung mit Epics |
| kurzfristige Planung | stabil über Aufgaben | stabil über Ziele | Iterationsplanung |
| Scope | stabil, komplexes Change Management | flexibel | |
| Feedback interner Stakeholder | selten, beim Erreichen eines Meilensteins | häufig und regelmäßig (Iterationen) | Fast feedback, fail early and learn: Iterationen, Sprints, Cycles |
| Feedback externer Stakeholder | noch seltener, bei Projektende | häufig und regelmäßig (Iterationen) | Customer-centric, Customer-on-site &Time-Boxing: Iterationen, Sprints, Cycles |
| Zeiträume | Meilensteine für gesamten Scope (zu Beginn flexibel, nach erster Planung werden diese zu harten Terminen) | stabile Iterationslänge | Time-Boxing |
| Meetings | flexibel, nach Bedarf | stabile wiederkehrende Meetings | Cadence, Time-Boxing |
| Reifegrade | Stabil über alle Projekte: harte Meilensteinkriterien nach Prozessdefinition | Stabil und inhaltlich getrieben: vereinbarte Qualität (DoD) für ‚releasable Features‘ | DoD, Features |
| Produktreife während der Entwicklung | Stabil: Späte Änderungen sind nicht erwünscht und oft nicht möglich. Aufwändiges Change-Management als Instrument. | Zunehmend stabil: Die Hoffnung ist, dass mit Agilität späte Änderungen möglich werden. In Wirklichkeit werden aber nur die Auswirkungen von späten Änderungen transparent gemacht, wodurch Entscheidungen zu späten Änderungen bewusster und besser getroffen werden können. | Transparenz |
| Teams | flexibel, projektspezifisch. Team-Auf- und Abbbauphasen | stabil | Team, Cluster, Team-Falvor |
| Kosten | vermeintlilch stabil über Meilensteinplanung, bei komplexen Vorhaben häufig sehr instabil | stabil durch stabile Iterationen und stabile Teams; flexibel durch flexiblen Scope (= Feature-Set) |
Agile Budgeting |
Warum brauchen wir Stabilität?
Die heute Geschäftswelt benötigt einen hohen Grad an Flexibilität als Antwort auf VUCA (englische Abkürzung für Volatilität, Unsicherheit, Komplexität, Mehrdeutigkeit). Auf der anderen Seite benötigen Menschen eine gewisse Stabilität in ihrem sozialen Umfeld, um sich sicher zu fühlen. Agile und pragmatische Organisationssysteme stellen den Menschen in den Mittelpunkt, sowohl die Kunden mit ihren Bedürfnissen, als auch die Menschen, die am Produktentstehungsprozess beteiligt sind, wobei deren gesamte Arbeitszeit durch diese Prozesse geregelt wird.
Aus diesem Grund sind in agilen & pragmatischen Organisationssystemen die Rollen-, Gruppen- und Teamstrukturen, als auch die wiederkehrenden Ereignisse und Meetings (= Events) eher stabil. Dies bedeutet, dass sie durchaus geändert werden, wenn dies nötig ist, sie sich aber grundsätzlich seltener ändern. Einmalige Änderungen pro Quartal sind normal, wobei als Grundregel, alle Änderungen gleichzeitig eingeführt werden sollten.
Und wie entsteht Flexibilität?
Auf der anderen Seite bedeutet dies, dass die Flexibilität innerhalb der sogenannten Artefakte, also den verschiedenen Backlogs, sowie der darin enthaltenen Elemente entsteht; durch Anpassung der Produkt-Features, der offenen Fragen (=Knowledge Gaps im P4-Framework), der Prototypen und Team-Ziele, sowie deren Prioritäten innerhalb der Backlogs.
Innerhalb der (stabilen) wiederkehrenden Meeting-Kadenz sind die behandelten Inhalte, bzw. deren Priorität und Reihenfolge ebenfalls flexibel. Dies benötigt aber ein gewisses Umdenken: Kommt ein neues Thema auf, laden wir nicht gleich die dazu nötigen Personen ein, sondern überlegen, in welches wiederkehrende Meeting wir das Thema mitnehmen. Dies entschlackt die Kalender der beteiligten Personen enorm, insbesondere die der Entscheider.
Fazit
Die Beispiele zeigen , dass agile und pragmatische Organisationssyteme und Frameworks, wie P4-Dev, einige Elemente bewusst stabil halten, um den Menschen in der Organisation Sicherheit zu geben, um inhaltlich flexibel zu sein.
Bild von freepik.com