Die Innovation and Planning (IP) Iteration findet bei jedem Program Increment (PI) statt und dient mehreren Zwecken. Sie dient als Schätzungspuffer für die Erfüllung der PI-Ziele und bietet dedizierte Zeit für Innovation, Weiterbildung, PI-Planung und Inspect and Adapt (I&A)-Events.
100%ige Auslastung führt zu Unvorhersehbarkeit.
Don Reinertsen
Trägheit ist der Rückstand vergangener Innovationsbemühungen. Wenn sie nicht gemanagt wird, verschlingt sie die Ressourcen, die für die Finanzierung der nächsten Generation von Innovationen erforderlich sind.
Geoffrey Moore
SAFe hat einen intensiven Fokus auf die kontinuierliche Lieferung von Kundennutzen, und die Leute sind damit beschäftigt, an den Features zu arbeiten, zu denen sie sich während der PI-Planung verpflichtet haben. Jede Iteration zählt und die Teams sind meist mit gesenkten Köpfen dabei, kurzfristigen Wert zu liefern. Eine Iteration nach der anderen marschiert die Lösung näher an den Markt heran. Die Aufmerksamkeit für die Bereitstellung der Lösung ist intensiv und unerbittlich.
Natürlich kann die Konzentration auf eine Sache – die Lieferung – zu einem Mangel an Konzentration auf eine andere Sache – die Innovation – führen. Angesichts der ständigen Dringlichkeit der Lieferung besteht die Gefahr, dass die Tyrannei des Dringenden [1] jede Gelegenheit zur Innovation zunichte macht. Um dem entgegenzuwirken, bietet SAFe dedizierte Innovations- und Planungsiterationen, die ein wichtiger Aspekt der breiteren Innovationskultur des Lean Enterprise sind.
Verstehen der IP Iterationsaktivitäten
Innovations- und Planungsiterationen bieten eine regelmäßige, auf der Kadenz basierende Gelegenheit – jedes Program Increment (PI) – für Teams, an Aktivitäten zu arbeiten, die sich nur schwer in ein kontinuierliches, inkrementelles Wertlieferungsmuster einfügen lassen. Dazu können gehören:
- Zeit für Innovation und Erforschung, die über die Iterationen hinausgeht, die der Lieferung gewidmet sind
- Arbeit an der technischen Infrastruktur, an Werkzeugen und anderen Hindernissen für die Bereitstellung
- Schulungen zur Unterstützung des kontinuierlichen Lernens und der Verbesserung
- Cross-Training zur Entwicklung von Fähigkeiten in neuen Domänen, Entwicklungssprachen und Systemen
- Dedizierte Zeit für das Inspect & Adapt (I&A)-Event, das Refinement des Backlogs, einschließlich der Priorisierung von Features mithilfe von Weighted Shortest Job First (WSJF), und die PI-Planung
- Integration der Solution, einschließlich Verifizierung und Validierung, wenn Releases am PI-Ende erfolgen
- Abschließende User Acceptance tests und Dokumentation sowie alle anderen Bereitschaftsaktivitäten, die nicht in jeder Iteration durchführbar oder wirtschaftlich sind
IP-Iterationen erfüllen eine weitere kritische Rolle, indem sie einen Schätzungspuffer für die Erfüllung der PI-Ziele bieten und die Vorhersagbarkeit der PI-Leistung verbessern.
Agile Release Trains (ARTs) berichten in der Regel, dass ihre Gesamteffizienz, Geschwindigkeit und Arbeitszufriedenheit durch regelmäßige Gelegenheiten, “ihre Batterien aufzuladen und ihre Werkzeuge zu schärfen”, verbessert werden.
Allow Time for Innovation
Eine der Säulen des SAFe Lean-Agile Mindset ist Innovation, aber inmitten von Lieferterminen Zeit für Ideenfindung und Veränderung zu finden, kann schwierig sein. Zu diesem Zweck nutzen viele Unternehmen IP-Iterationen für Forschungs- und Designaktivitäten wie Hackathons. Es gibt zwei einfache Regeln für Hackathons:
- Die Leute können an allem arbeiten, was sie wollen, mit wem sie wollen, solange die Arbeit die Mission des Unternehmens widerspiegelt
- Die Teams stellen ihre Arbeit am Ende des Hackathons anderen vor
Die Erkenntnisse aus Hackathons fließen routinemäßig in die Programmbacklogs ein und helfen oft, Innovationen voranzutreiben. Sie machen auch noch Spaß!
Dedicate Time to PI Events
Durch die Durchführung der I&A- und PI-Planung während der IP-Iteration wird eine Verringerung der Geschwindigkeit der regulären Iterationen vermieden. Wichtiger noch: Da diese Ereignisse in einem regelmäßigen Rhythmus stattfinden und weit im Voraus geplant werden können, ist ihr Auftreten besser gewährleistet.
Außerdem ist es wahrscheinlich, dass einige Just-in-Time- und Last-Moment-Verfeinerungen des Programm- und Lösungs-Backlogs sowie die Ausarbeitung von Features und Fähigkeiten während dieses Zeitraums die Produktivität der kommenden Planungssitzung erheblich steigern können.
Integrate the Complete Solution
Die PI System Demo findet am Ende jeder PI statt. Sie ist die integrierte Präsentation der Arbeit aller Teams im Zug, die in einer Staging-Umgebung stattfindet, die die Produktion so genau wie möglich emuliert. Für ARTs, die Teil eines Solution Trains sind, fließt die PI System Demo in die aggregierte Solution Demo ein, die ebenfalls während der IP Iteration stattfindet. Sie ist eine strukturiertere und formalere Angelegenheit, da sie die Akkumulation aller Funktionen und Fähigkeiten demonstriert, die im Laufe der gesamten PI für einen Solution Train entwickelt wurden.
Wenn eine Lösung Hardware (und andere Komponenten) umfasst, ist es schwieriger, eine durchgängige Integration zu erreichen, und eine vollständige Integration ist möglicherweise nur während der IP-Iteration möglich. In diesen Fällen ist es nur vernünftig, dies einzuplanen.
Die IP-Iteration sollte jedoch nicht der einzige Versuch sein, die Assets in das System zu integrieren. Die vollständige oder teilweise Integration erfolgt im Laufe der PI, wobei eine vollständige Lösungsintegration mindestens einmal pro PI erfolgt. Dieser Ansatz validiert die Annahmen früh genug, um auf signifikante Probleme und Risiken innerhalb des PIs reagieren zu können.
Advance Development Infrastructure
Lean Delivery erhöht den Druck auf die Entwicklungsinfrastruktur: Neue Continuous-Integration-Umgebungen müssen bereitgestellt, neue Testautomatisierungs-Frameworks implementiert und gewartet, agile Projektmanagement-Tools eingeführt, team- und trainingsübergreifende Kommunikationssysteme aufgerüstet oder verbessert werden, und die Liste geht weiter. Oftmals stammen die Verbesserungsgeschichten aus der Iterations-Retrospektive des Teams oder aus den Enablern.
Wir alle wissen, dass wir unsere Werkzeuge von Zeit zu Zeit schärfen müssen; agile Teams sind da nicht anders. Sie haben sogar eine noch größere Abhängigkeit von ihren Arbeitsumgebungen, so dass Zeit darauf verwendet werden muss, diese kontinuierlich zu verbessern. Es ist oft effizienter, die Infrastruktur zu verbessern oder eine Migration zu einem Zeitpunkt durchzuführen, an dem die Teams nicht mitten in der kritischen Arbeit stecken.
Kontinuierliches Lernen ermöglichen
Mitarbeiter auf allen Ebenen sind lebenslang Lernende. Änderungen in der Technologie sowie Änderungen in der Methode und Praxis sind Routine; Möglichkeiten zur Weiterbildung sind jedoch weitaus seltener. Außerdem erfordert die Umstellung auf Lean-Agile viele neue Techniken und Fähigkeiten, darunter
- Feature- und Story-Schreiben
- Einbauen von Qualität
- Automatisiertes Testen
- Kollektive Verantwortung
- Agile Architektur
- Kontinuierliche Integration
- Paarweises Arbeit
- Beherrschen der Product Owner- und Scrum Master-Rollen
- Teambildung
Praktiker sind auch gefordert, ihre technischen Fähigkeiten auf dem neuesten Stand zu halten. Neue Technologien werden häufiger als je zuvor eingeführt. Die Investition in Mitarbeiter, die über mehrere Systeme, Domänen und Sprachen hinweg arbeiten können, schafft eine “T-förmige” (tiefe Kenntnisse in einem Bereich, Arbeitswissen in mehreren anderen Bereichen) und sogar “E-förmige” (tiefe Kenntnisse in mehr als einem Bereich) Belegschaft. Dies bietet dem Unternehmen ein Maximum an Agilität und Flexibilität, um die wichtigsten Backlog-Elemente zu liefern. Es ist jedoch schwierig, neben dem Drang, ständig neue Funktionen zu liefern, Zeit für diese Art von Wachstum zu finden. IP-Iterationen sind ein perfekter Zeitpunkt für diese Investition.
Sich Zeit für Weiterbildung zu nehmen, gibt Teams und Führungskräften eine willkommene Gelegenheit, diese neuen Techniken zu erlernen und zu beherrschen. Sie kann auch genutzt werden, um Communities of Practice zu starten und zu unterstützen, die sich mit diesen und anderen Themen beschäftigen. Die Nettoergebnisse kommen sowohl dem Einzelnen als auch dem Unternehmen zugute: Die Beherrschung der Techniken und die Arbeitszufriedenheit der Mitarbeiter steigen, die Geschwindigkeit nimmt zu und die Time-to-Market sinkt.
Leverage the Built-In Estimation Buffer
Lean Flow lehrt uns, dass der Betrieb bei “100 Prozent Auslastung zu unvorhersehbaren Ergebnissen führt [2].” Einfach ausgedrückt, wenn man alle auf volle Auslastung plant, hat man nicht die Möglichkeit, zu flexen, wenn Probleme unvermeidlich auftreten. Das Ergebnis ist Unvorhersehbarkeit und Verzögerungen bei der Wertlieferung. Als Gegenmaßnahme bietet die IP-Iteration ein “Schutzband” (oder einen Puffer), um zu verhindern, dass unfertige Arbeit aus dem aktuellen PI auf den nächsten PI übertragen wird.
Während der PI-Planung plant der ART keine Features oder Stories für die IP-Iteration, wodurch den Teams ein Puffer (zusätzliche Zeit) zur Verfügung steht, um auf unvorhergesehene Ereignisse, Verzögerungen aufgrund von Abhängigkeiten und andere Probleme zu reagieren, was ihre Fähigkeit erhöht, die PI-Ziele von Team und Programm zu erreichen. Dieser Puffer erhöht die Vorhersagbarkeit des Programmergebnisses erheblich, was für das Unternehmen extrem wichtig ist. Diese Zeit jedoch routinemäßig für die Fertigstellung der Arbeit zu verwenden, ist ein Fehlermuster. Dadurch wird der primäre Zweck der IP-Iteration verfehlt, und die Innovation wird wahrscheinlich darunter leiden. Teams müssen darauf achten, dass dieses Schätzungs-Leitband nicht einfach zu einer Krücke wird.
Ein Beispiel für einen IP-Iterationskalender
IP-Iterationen haben einen gewissen Standardzeitplan und ein Standardformat. Abbildung 1 zeigt einen beispielhaften IP-Iterationskalender. Die orangefarbenen Elemente stellen Solution Train-Ereignisse dar, während die blauen Elemente für einen einzelnen ART stehen.
Learn More: [1] Hummell, Charles E. Tyranny of the Urgent. IPV Booklets, 2013. [2] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.