Technologische Voraussetzungen für Agilität
Technologische Voraussetzungen für Agilität
Um auf agile Weise Software zum Beispiel mittels Scaled Agile Framework (SAFe) entwickeln zu können, müssen wesentliche agile Softwaretechniken vorhanden sein bzw. vorgängig umgesetzt werden (Mathis, 2018):
- Emergentes Design und Architektur
- Automatisiertes Testen und testgetriebene bzw. Test-First-Entwicklung
- Refaktorisierung
- Versionsverwaltung und kontinuierliche Integration
- Pair-Programming/Pair-Work
- Clean Code
Die oben aufgeführten Punkte sind einzelne Praktiken aus der agilen Softwareentwicklung, die für einen nachhaltigen Erfolg notwendig sind. Im Rahmen einer Nutzung von SAFe ist eine integrierte Qualitätskultur in einem Unternehmen erforderlich. Es ist eine irrige Annahme, durch weniger Qualität die Geschwindigkeit erhöhen zu können. Gemäss Mathis führen Fehler und andere Mängel in der Softwareentwicklung dazu, dass sich fatale Nebeneffekte ergeben; werden diese toleriert, verzögert sich die Entwicklung und wird weniger vorhersehbar. Um mit mehreren Scrum-Teams in SAFe skalieren zu können, ist es unabdingbar, dass eine Qualitätskultur gelebt wird.
Im Rahmen von SAFe wird von den Teams erwartet, dass diese eine testgetriebene Entwicklung durchführen sowie Fehler selbstständig entdecken und korrigieren, bevor sie ein Inkrement ausliefern. Gemäss Mathis sind Bugs keine Flüchtigkeitsfehler, sondern ein Indiz dafür, dass ein Entwicklungsprozess lückenhaft oder nicht optimal strukturiert ist. Im Gegensatz zu Scrum geht SAFe nicht von vierwöchigen Sprints, sondern von zweiwöchigen Iterationen aus. Um dieses Tempo halten zu können, ist es unabdingbar, dass Fehler umgehend behoben werden. Für die Fehlererkennung setzt agile Softwareentwicklung auf automatisierte Tests, um sicherstellen zu können, dass das auszuliefernde Inkrement (Software) funktionstüchtig ist.
Mathis führt zwei weitere Gründe an, die für eine Einhaltung dieser Qualitätskultur sprechen. Technisch zieht ein gebrochener Build es nach sich, dass sich neue Fehler unerkannt ein-schleichen und die Behebung überproportional aufwendiger wird. Die Vorteile eines stabilen Prozesses und einer zuverlässigen Aussage über den Stand der Entwicklung gehen verloren. Psychologisch vollzieht sich ein Bedeutungsverlust der Anforderung, möglichst fehlerfreie Software zu entwickeln – damit werden neue Fehler nicht mehr als gravierendes Problem wahrgenommen.
DevOps
Um agile Produkte entwickeln zu können, müssen Unternehmen neben den organisatorischen auch technologische Massnahmen treffen, damit ein Framework wie SAFe funktionieren kann. Das zentrale Ziel aller agilen Teams in SAFe ist die erfolgreiche Ausführung bzw. Lieferung funktionsfähiger Sprints und Releases der Programmziele des ART-PI. Dabei legt SAFe den Fokus auf DevOps als Voraussetzung. Deswegen nutzt SAFe auch sogenannte Enabler-Features. Enabler sind technische Initiativen, die dazu dienen, notwendige Fähigkeiten des Systems bereitzustellen.
Enabler kommen auf allen vier Ebenen vor und wurden vor-her als ‹Architektur-Epics›, ‹Architektur-Features› und ‹User-Storys› bezeichnet.
Die Teams planen ihre Tätigkeiten, demonstrieren ihre Lösungen, lernen gemeinsam aus Fehlern und verbessern und optimieren den Prozess sowie den Code fortlaufend, ähnlich wie dies aus anderen Methoden wie Total-Quality-Management (TQM) bekannt ist. Dadurch wird vermieden, dass sich die Teams ausschliesslich auf lokale Belange konzentrieren. Stattdessen arbeiten sie gemeinsam lösungsorientiert auf das übergeordnete Ziel hin bzw. fokussieren sich darauf, Lösungen zu erforschen, zu integrieren, bereitzustellen und freizugeben.
SAFe Prinzipien für einen effektiven Entwicklungsfluss
Wie die meisten Frameworks basiert auch SAFe auf bestehenden Modellen, die erfolgreich sind, und bedient sich ihrer. So nutzt SAFe unter anderem die Prinzipien von Don Reinertsen (2009) mit einer geringfügigen Erweiterung. Die Integration des Systemdenkens hat in SAFe eine besondere Bedeutung, wie es William Edwards Deming (2000) formuliert hat:
- Ein System muss eine Intention haben, um zielgerichtet zu funktionieren.
- Eine Optimierung eines Teils muss nicht das Gesamtsystem optimieren.
- Ein System kann sich schneller als sein langsamster Integrationspunkt bewegen.
- Ein kontinuierlicher Verbesserungsprozess sorgt für langfristigere Systemoptimierung als eine punktuelle Verbesserung.
Mit einem ergänzenden Einbezug des Managements stützt SAFe sich auf eine weitere These Demings (1993): Nur das Management kann ein System verändern. Daher nimmt SAFe das Management für die Entwicklung und die Strukturierung von Leadership (Führung) und Firmenkultur explizit in die Pflicht.
Um einen organisatorischen Nutzen mit einer agilen PM-Methodik wie SAFe erzielen zu können, ist es erforderlich, dass die technische Infrastruktur die agilen Anforderungen erfüllen kann. Wird dieser Punkt nicht oder zu wenig beachtet, besteht die Gefahr, dass die vermeintliche ‹Agilität› des Unternehmens sich als reines ‹Wunschdenken› entpuppt.
Literaturverzeichnis:
- Scaled Agile Framework (2021). SAFe 5.0 Framework. Retrieved from https://www.scaledagileframework.com/
- Mathis, C. (2018). SAFe - das Scaled Agile Framework: Lean und Agile in großen Unternehmen skalieren (2., überarbeitete und aktualisierte Auflage). Heidelberg: dpunkt.verlag.
- Reinertsen, Donald G. (2009). The principles of product development flow. Celeritas.
- Deming, Wiliam Edwards (1993). The new economics for industry, government, education.
- Deming, Wiliam Edwards (2000). Out of the Crisis.
Teilen
Adresse
IT-onBase AG
Industriestrasse 12
CH-3661 Uetendorf
Telefon
+41 31 537 28 00
E-Mail-Adresse
info@it-onbase.ch
