08A02 Wie Sie auf agile Software-Entwicklung umstellen – Übersicht
Ausgehend vom Beitrag 08A01 „Agile Konzepte” wird in drei aufeinander aufbauenden Beiträgen die Umstellung auf eine agile Form der SW-Entwicklung beschrieben.
Der hier vorliegende Beitrag zeigt, dass diese Umstellung Veränderungen der Unternehmenskultur voraussetzt. Das sind langfristige und strategisch relevante Investitionen. Erst auf dieser Basis können die jeweils angemessenen und vergleichsweise kurzlebigen Methoden und Techniken der agilen (aber auch „traditionellen”) SW-Entwicklung sinnvoll genutzt werden.
Dieser Beitrag gibt einen zusammenfassenden Überblick über einige Methoden und Techniken zur Kulturveränderung und schlägt danach einen agilen Umgang mit den Methoden und Techniken der agilen SW-Entwicklung vor. Das „craftsmanship” und das „Clean Code Development” haben dabei unabhängig von der Vorgehensweise eine zentrale Bedeutung.
In zwei weiteren Beiträgen (Kap. 08A03 und Kap. 08A04) werden einzelne Methoden und Techniken zur Kulturveränderung im Detail behandelt und kontextabhängige Vorgehensmuster zur Umstellung auf agile Entwicklungsmethoden ergänzt. von: |
1 Das agile Vorgehen als strategische Investition
Sie möchten Ihre Software-Entwicklung (SW-Entwicklung) auf ein „agiles” Vorgehen umstellen? Und zwar – so nehme ich an – als eine langfristig wirksame strategische Investition? Dann lade ich Sie zu einer langfristigeren Betrachtung ein. Werfen wir doch zunächst einen Blick auf die historischen Meilensteine der agilen SW-Entwicklung:
Der Begriff Agile Software-Entwicklung entstand erst 2001. Allerdings wies Winston W. Royce bereits 1970 in seinem Artikel „Management of Large Software Systems” darauf hin, dass ein „wasserfallartiges” Vorgehen ungeeignet sei, und empfahl stattdessen ein iteratives Vorgehen mit sehr vielen Rückkopplungsschleifen unter Einbeziehung auch des Benutzers [1] .
„Agile” Methoden wie RAD bereits ab 1970
Ab 1970 gab es auch schon Vorgehensmethoden und Praktiken wie Rapid Application Development (RAD) von Dan Gielan (in den 1980er-Jahren bis 1991 formalisiert von James Martin) und Evolutionary Systems Delivery (EVO) von Tom Gilb, heute von ihm „Evolutionary Project Management” genannt.
Ab 1970 gab es auch schon Vorgehensmethoden und Praktiken wie Rapid Application Development (RAD) von Dan Gielan (in den 1980er-Jahren bis 1991 formalisiert von James Martin) und Evolutionary Systems Delivery (EVO) von Tom Gilb, heute von ihm „Evolutionary Project Management” genannt.
1980er – 1990er: EVO, Crystal, Spiralmodell
Das Spiralmodell von Barry W. Boehm folgte 1986 und die Crystal-Methodenfamilie von Alistair Cockburn ab 1990.
Das Spiralmodell von Barry W. Boehm folgte 1986 und die Crystal-Methodenfamilie von Alistair Cockburn ab 1990.
Scrum seit 1995
Jeff Sutherland, John Scumniotales und Jeff McKenna entwickelten 1993 ein schlankes teambasiertes inkrementell-adaptives Vorgehen bei Easel Corporation, das sie „Scrum” nannten, inspiriert von dem Artikel „The New New Product Development Game” der Autoren Hirotaka Takeuchi und Ikujiro Nonaka. Bei Ken Schwaber's Firma Advanced Development Methods wurde in den frühen 1990er-Jahren ein ähnliches Vorgehen wie Sutherlands Scrum praktiziert und 1995 stellte Ken Schwaber „Scrum” in einem Workshop der OOPSLA '95 mit Jeff Sutherland als einem der Organisatoren vor.
Jeff Sutherland, John Scumniotales und Jeff McKenna entwickelten 1993 ein schlankes teambasiertes inkrementell-adaptives Vorgehen bei Easel Corporation, das sie „Scrum” nannten, inspiriert von dem Artikel „The New New Product Development Game” der Autoren Hirotaka Takeuchi und Ikujiro Nonaka. Bei Ken Schwaber's Firma Advanced Development Methods wurde in den frühen 1990er-Jahren ein ähnliches Vorgehen wie Sutherlands Scrum praktiziert und 1995 stellte Ken Schwaber „Scrum” in einem Workshop der OOPSLA '95 mit Jeff Sutherland als einem der Organisatoren vor.
XP seit 1996
1996 verwendeten Kent Beck, Don Wells, Ward Cunningham und Ron Jeffries bei Chrysler erstmals eXtreme Programming (XP). Nach seiner Publikation in 1999 fand es rasante Verbreitung.
1996 verwendeten Kent Beck, Don Wells, Ward Cunningham und Ron Jeffries bei Chrysler erstmals eXtreme Programming (XP). Nach seiner Publikation in 1999 fand es rasante Verbreitung.
Ab Mitte 1990er: PRINCE2, DSDM, FDD, ASD
Danach folgten Schlag auf Schlag: 1996 PRINCE2 (Nachfolger von PRINCE) als allgemeine inkrementell-adaptive Projektmanagement-Methode; 1997 DSDM; ebenfalls 1997 das Feature Driven Development (FDD) von Jeff De Luca und 1999 das Adaptive Software Development (ASD), entwickelt von Jim Highsmith und Sam Bayer, ausgehend von RAD.
Danach folgten Schlag auf Schlag: 1996 PRINCE2 (Nachfolger von PRINCE) als allgemeine inkrementell-adaptive Projektmanagement-Methode; 1997 DSDM; ebenfalls 1997 das Feature Driven Development (FDD) von Jeff De Luca und 1999 das Adaptive Software Development (ASD), entwickelt von Jim Highsmith und Sam Bayer, ausgehend von RAD.
2001: Agiles Manifest
Am 12. Februar 2001 trafen sich 17 Vertreter solcher – damals „leichtgewichtig” genannter – Methoden und Vorgehensweisen in einem Skiresort in den Rocky Mountains mit dem Ziel, das sie Verbindende kompakt zu formulieren und dafür einen auch für Topmanager attraktiven Titel zu finden. Das Ergebnis war das heute bestens bekannte „Agile Manifest” [2] . Immer wieder kommt seitdem die Forderung auf, seine vier „Werte” und zwölf „Prinzipien” im Lichte der inzwischen gemachten Erfahrungen anzupassen. Andererseits wird das Manifest in seiner Urform oft als „der” bleibende und einzige Maßstab dafür angesehen, was „Agilität” auch heute noch bedeutet. In einem Vortrag am 16. September 2013 in Vorarlberg (bei OMICRON, organisiert von PIONIERBASIS) betonte Alistair Cockburn, einer der Verfasser des Manifests, dass dieses Agile Manifest von 2001 ein „Schnappschuss” aus der damaligen Zeit heraus sei. Deshalb mache es keinen Sinn, diesen historischen Schnappschuss zu aktualisieren. Wenn sich diese 17 Unterzeichner des Manifests – oder andere Vertreter der aktuellen SW-Entwicklungsszene – heute träfen, um wiederum das sie Verbindende zu formulieren, dann wäre das Ergebnis ein anders.
Am 12. Februar 2001 trafen sich 17 Vertreter solcher – damals „leichtgewichtig” genannter – Methoden und Vorgehensweisen in einem Skiresort in den Rocky Mountains mit dem Ziel, das sie Verbindende kompakt zu formulieren und dafür einen auch für Topmanager attraktiven Titel zu finden. Das Ergebnis war das heute bestens bekannte „Agile Manifest” [2] . Immer wieder kommt seitdem die Forderung auf, seine vier „Werte” und zwölf „Prinzipien” im Lichte der inzwischen gemachten Erfahrungen anzupassen. Andererseits wird das Manifest in seiner Urform oft als „der” bleibende und einzige Maßstab dafür angesehen, was „Agilität” auch heute noch bedeutet. In einem Vortrag am 16. September 2013 in Vorarlberg (bei OMICRON, organisiert von PIONIERBASIS) betonte Alistair Cockburn, einer der Verfasser des Manifests, dass dieses Agile Manifest von 2001 ein „Schnappschuss” aus der damaligen Zeit heraus sei. Deshalb mache es keinen Sinn, diesen historischen Schnappschuss zu aktualisieren. Wenn sich diese 17 Unterzeichner des Manifests – oder andere Vertreter der aktuellen SW-Entwicklungsszene – heute träfen, um wiederum das sie Verbindende zu formulieren, dann wäre das Ergebnis ein anders.
Heute: Scrum mit XP-Techniken ist dominant
Bis ungefähr 2005 dominierte Extreme Programming (XP) die agile SW-Entwicklung. Daneben waren auch Scrum, die Crystal Family of Methodologies, Feature Driven Development (FDD), die Dynamic Systems Development Method (DSDM) und das Adaptive Software Development (nebst anderen) verbreitet. Seit 2005 entwickelte sich indessen Scrum (3.3.1 in [3] ) rasch zur heute bekanntesten agilen Vorgehensweise der SW-Entwicklung auf Teamebene, jedoch mit Einschluss vieler Techniken aus XP.
Bis ungefähr 2005 dominierte Extreme Programming (XP) die agile SW-Entwicklung. Daneben waren auch Scrum, die Crystal Family of Methodologies, Feature Driven Development (FDD), die Dynamic Systems Development Method (DSDM) und das Adaptive Software Development (nebst anderen) verbreitet. Seit 2005 entwickelte sich indessen Scrum (3.3.1 in [3] ) rasch zur heute bekanntesten agilen Vorgehensweise der SW-Entwicklung auf Teamebene, jedoch mit Einschluss vieler Techniken aus XP.
Vier Grundsätze
Kennzeichen dieses Vorgehens sind:
Kennzeichen dieses Vorgehens sind:
• | Ein einzelnes kleines und über alle Fachkompetenzen verfügendes („interdisziplinäres”) Team entwickelt ein Produkt. |
• | In fix getakteten „Sprints” mit einer Dauer von jeweils zwei bis vier Wochen, werden praktisch nutzbare Teilprodukte realisiert und geliefert. |
• | Es gibt nur eine einzige Person, die als „Product Owner” gegenüber dem Team alle Produktanforderungen vertritt und verbindlich entscheidet. |
• | Es gibt bereits eine erste Version einer das gewünschte Endergebnis beschreibenden Liste von Anforderungen (den „Product Backlog”). |
Mehr und mehr setzt sich in letzter Zeit die Erkenntnis durch, dass dieses Vorgehen ein vielfach allzu vereinfachendes, idealisierendes und starres (statt agiles) Korsett darstellt und viele Problemzonen der Produktentwicklung und des Projektmanagements unbehandelt lässt.
Scrum oft zu vereinfachend und radikal
Zudem stellt sich immer wieder heraus, dass die mit der Einführung von Scrum verbundenen Verantwortlichkeits- und Organisationsänderungen insbesondere bei etablierten Unternehmen von vielen Betroffenen als unverhältnismäßig groß und in ihrer Radikalität als unangemessen angesehen werden. Zunehmend kristallisiert sich auch heraus, dass eine historisch gewachsene Systemheterogenität mit einem geringen Grad an Automatisierung im Bereich Integration und Test eine rasche Abfolge von Inkrementen (Releases) verhindert. Und es wird zunehmend bewusst, dass bei einer agilen Vorgehensweise der SW-Entwicklung auf Teamebene auch eine ihr entsprechende – adaptive – teamübergreifende Abstimmung auf Projekt-/Programm- und Portfolioebene nötig wird.
Zudem stellt sich immer wieder heraus, dass die mit der Einführung von Scrum verbundenen Verantwortlichkeits- und Organisationsänderungen insbesondere bei etablierten Unternehmen von vielen Betroffenen als unverhältnismäßig groß und in ihrer Radikalität als unangemessen angesehen werden. Zunehmend kristallisiert sich auch heraus, dass eine historisch gewachsene Systemheterogenität mit einem geringen Grad an Automatisierung im Bereich Integration und Test eine rasche Abfolge von Inkrementen (Releases) verhindert. Und es wird zunehmend bewusst, dass bei einer agilen Vorgehensweise der SW-Entwicklung auf Teamebene auch eine ihr entsprechende – adaptive – teamübergreifende Abstimmung auf Projekt-/Programm- und Portfolioebene nötig wird.
2010: Kanban für SW
Die Problematik starrer Sprints und der oft überfordernden Organisationsänderungen wird durch das erst seit 2010 breiter bekannte, von David J. Anderson für die SW-Entwicklung angepasste „Kanban” entschärft (3.3.2 in [3] ). Es verbreitet sich derzeit rasch und wird auch zusammen mit Scrum zu „Scrumban” kombiniert.
Die Problematik starrer Sprints und der oft überfordernden Organisationsänderungen wird durch das erst seit 2010 breiter bekannte, von David J. Anderson für die SW-Entwicklung angepasste „Kanban” entschärft (3.3.2 in [3] ). Es verbreitet sich derzeit rasch und wird auch zusammen mit Scrum zu „Scrumban” kombiniert.
SAFe gewinnt an Boden
Zur team- und projektübergreifenden agilen Abstimmung der projektunabhängigen fortlaufenden Produktentwicklung auf Programm- und Portfolioebene tritt derzeit das „Scaled Agile Framework for Enterprises” (SAFe) von Dean Leffingwell stark in Erscheinung (3.3.3 in [3] ). Er hat es erstmals 2010 als Buch und als „big picture” im Internet veröffentlicht. Und für das agile Management von Projekten gewinnen DSDM und PRINCE2 (3.2 in [3] ) als Rahmen für die Arbeit einzelner agiler Teams an Bedeutung.
Zur team- und projektübergreifenden agilen Abstimmung der projektunabhängigen fortlaufenden Produktentwicklung auf Programm- und Portfolioebene tritt derzeit das „Scaled Agile Framework for Enterprises” (SAFe) von Dean Leffingwell stark in Erscheinung (3.3.3 in [3] ). Er hat es erstmals 2010 als Buch und als „big picture” im Internet veröffentlicht. Und für das agile Management von Projekten gewinnen DSDM und PRINCE2 (3.2 in [3] ) als Rahmen für die Arbeit einzelner agiler Teams an Bedeutung.
Methodenentscheidungen sind keine Langfriststrategie!
Angesichts dessen, dass Scrum erst in den letzten Jahren so dominant wurde und heute in der agilen SW-Entwicklung zunehmend bekannte Vorgehensweisen wie Kanban und SAFe erst 2010 ins breitere Bewusstsein rückten, kann heute nicht vorausgesagt werden, was in fünf oder zehn Jahren die Szene der SW-Entwicklung prägen wird und inwieweit dann „agil” (oder „lean”) immer noch dominante Begriffe sein werden.
Angesichts dessen, dass Scrum erst in den letzten Jahren so dominant wurde und heute in der agilen SW-Entwicklung zunehmend bekannte Vorgehensweisen wie Kanban und SAFe erst 2010 ins breitere Bewusstsein rückten, kann heute nicht vorausgesagt werden, was in fünf oder zehn Jahren die Szene der SW-Entwicklung prägen wird und inwieweit dann „agil” (oder „lean”) immer noch dominante Begriffe sein werden.
Längerfristig ausgelegte strategische Investitionsentscheidungen im Bereich eines spezifischen SW-Entwicklungsvorgehens sind also mit einer hohen Unsicherheit verbunden.
Systemheterogenität und Architekturmängel als Hindernisse
Eines aber ist mit Sicherheit auch langfristig gültig: Heterogene Systemlandschaften mit vielen, eher undurchsichtigen und oft improvisierten Schnittstellen, mit unüberblickbaren oder gar nicht dokumentierten Systemarchitekturen und Praktiken, die dem „Clean Code Development” widersprechen, können mit keinem wie auch immer gearteten Vorgehen der SW-Entwicklung entschärft werden. Das bedeutet im Umkehrschluss: Wichtiger als das Optimieren des Vorgehens der SW-Entwicklung ist,
Eines aber ist mit Sicherheit auch langfristig gültig: Heterogene Systemlandschaften mit vielen, eher undurchsichtigen und oft improvisierten Schnittstellen, mit unüberblickbaren oder gar nicht dokumentierten Systemarchitekturen und Praktiken, die dem „Clean Code Development” widersprechen, können mit keinem wie auch immer gearteten Vorgehen der SW-Entwicklung entschärft werden. Das bedeutet im Umkehrschluss: Wichtiger als das Optimieren des Vorgehens der SW-Entwicklung ist,
• | historisch wild gewachsene Systemlandschaften und Architekturen transparent zu machen und dann zu bereinigen sowie |
• | die Praktiken der SW-Entwicklung, vom Requirements Egineering über die Testautomation und kontinuierliche Integration bis hin zu einem zuverlässigen Configuration Management im Sinne des „Clean Code Development” zu professionalisieren. „Craftsmanship”, das handwerkliche Können, ist zentral! |
Gefordert weiterhin: „Craftsmanship”
Angenommen, all das ist erreicht. Dann geht es jetzt um das Optimieren des Vorgehens in der SW-Entwicklung. Wie und wo beginnen Sie? Und was genau bedeutet „Optimieren des Vorgehens”? Wohin soll die Reise führen?
Angenommen, all das ist erreicht. Dann geht es jetzt um das Optimieren des Vorgehens in der SW-Entwicklung. Wie und wo beginnen Sie? Und was genau bedeutet „Optimieren des Vorgehens”? Wohin soll die Reise führen?
2 Wohin wollen Sie mit Ihrem Unternehmen?
Um das zu beantworten, sollten Sie – bevor Sie sich mit spezifischen Philosophien (wie „Lean” oder „Agil”), Vorgehens-Frameworks oder Methodiken (wie Scrum, SAFe, PRINCE2, PMBOK, CMMI, RUP, V-Modell oder HERMES) beschäftigen – zusammen mit ihren „Peers” im Management Folgendes klären:
Setzen Sie sich in die Zeitmaschine
Angenommen, Sie setzen sich mit Ihren Peers in eine Zeitmaschine … und „beamen” sich fünf Jahre in die Zukunft … in eine Zukunft, in der Ihr Unternehmen ein optimales Vorgehen der SW-Entwicklung praktiziert … und Sie alle steigen aus der Zeitmaschine aus:
Angenommen, Sie setzen sich mit Ihren Peers in eine Zeitmaschine … und „beamen” sich fünf Jahre in die Zukunft … in eine Zukunft, in der Ihr Unternehmen ein optimales Vorgehen der SW-Entwicklung praktiziert … und Sie alle steigen aus der Zeitmaschine aus:
• | Woran werden Sie, als Manager, bereits in den ersten Stunden und Tagen anhand STRATEGISCH relevanter KONKRETER Beobachtungen dieses optimale Vorgehen erkennen? |
• | Was werden Ihnen die Kunden erzählen, was sich in den letzten fünf Jahren für sie markant verbessert hat – und was sie sogar begeistert? |
• | Was werden Ihnen die Mitarbeitenden erzählen, was sich in den letzten fünf Jahren für sie markant verbessert hat – und was sie stark motiviert? |
Notieren Sie all das, was Sie und Ihre Peers beobachten und von Ihren Kunden und Mitarbeitenden zu hören bekommen. Nehmen Sie diese Notizen mit in die Zeitmaschine … und beamen Sie sich wieder zurück ins Jetzt. Leiten Sie dann aus Ihren Notizen all das ab, was Ihre „besten Hoffnungen” für ein in fünf Jahren optimales Vorgehen der SW-Entwicklung sind.
(Eine ausführliche Beschreibung der Technik solcher „Reisen in die Zukunft” finden Sie in [4] )
Formulieren Sie das möglichst spezifisch und mit konkret beobachtbaren Kriterien. Vermeiden Sie dabei Fachbegriffe aus der „agilen Szene” (die in fünf Jahren vielleicht nicht mehr „in Mode” ist), sondern umschreiben Sie es in allgemein verständlichen „5-Cent-Worten”.
Etwa so:
„Die Kunden unserer CRM4KMU-Lösung erhalten nur noch zwei Mal pro Jahr einen umfassend getesteten Release ohne kurz darauf folgende Updates.”
„Pro Release erhalten wir von max. 0,2 % der Kunden unserer CRM4KMU-Lösung Fehlermeldungen.”
KONKRETE Ziele als beste Hoffnungen
Diese nicht als vage Vision oder allgemeines Leitbild, sondern als konkrete Ziele formulierten „besten Hoffungen” sind nun Ihre Messlatte für mögliche und stets an Ihr Unternehmen anzupassende Vorgehens-Frameworks oder Methodiken Ihrer künftigen SW-Entwicklung.
Diese nicht als vage Vision oder allgemeines Leitbild, sondern als konkrete Ziele formulierten „besten Hoffungen” sind nun Ihre Messlatte für mögliche und stets an Ihr Unternehmen anzupassende Vorgehens-Frameworks oder Methodiken Ihrer künftigen SW-Entwicklung.
3 Wie reisen Sie mit Ihrem Unternehmen?
Ihre Reise ins Land der besten Hoffnung und die als Orientierung möglichen generellen Vorgehens-Frameworks und Methodiken hängen ganz von Ihren spezifischen Zielen und Ihrem Unternehmen ab. Ihr Unternehmen ist ein stets komplex erscheinendes soziales System mit stets unternehmensspezifischen Problemstellungen. Generelle „Best Practices” als Lösung sind hier ungeeignet. Dinge, die in anderen Unternehmen erfolgreich waren, sind bestenfalls Denkanstöße, können aber nicht 1:1 für Ihr Unternehmen übernommen werden.
Kein Kochbuch, keine „Best Practices”
Als solche Denkanstöße und zur Orientierung (nicht aber als direkt nutzbare Blaupausen) werden im vorliegenden Beitrag unterschiedliche Vorgehens-Frameworks und Methodiken für drei von den jeweiligen Hauptaufgaben abhängige Aufgabenkonstellationen angeboten und im Kap. 08A04 im Detail behandelt:
Als solche Denkanstöße und zur Orientierung (nicht aber als direkt nutzbare Blaupausen) werden im vorliegenden Beitrag unterschiedliche Vorgehens-Frameworks und Methodiken für drei von den jeweiligen Hauptaufgaben abhängige Aufgabenkonstellationen angeboten und im Kap. 08A04 im Detail behandelt:
1. Entwicklung und Unterhalt von plattformbasierten Lösungen:
Plattformbasierte Lösungen
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) teils kundenspezifischer Varianten von SW-Lösungen und Services auf der Basis einer kundenneutralen Plattform oder eines kundenneutralen Lösungsbaukastens. Typische Beispiele: Anbieter von ERP-Lösungen; Anbieter umfassender Web-Shops samt Backoffice-Logistik und B2B-Lösungen.
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) teils kundenspezifischer Varianten von SW-Lösungen und Services auf der Basis einer kundenneutralen Plattform oder eines kundenneutralen Lösungsbaukastens. Typische Beispiele: Anbieter von ERP-Lösungen; Anbieter umfassender Web-Shops samt Backoffice-Logistik und B2B-Lösungen.
Vorgehens-Frameworks und Methodiken für diese Konstellation müssen insbesondere auch das strategische Portfoliomanagement für die verschiedenen langfristig existierenden Produktlinien umfassen. Von zentraler Bedeutung sind bei dieser Aufgabenkonstellation einerseits die fortlaufende Pflege der kundenneutralen Lösungsplattform und andererseits die rasche Realisierung auch sehr spezieller – später auch zu betreuender – Kundenlösungen, ohne dabei die generelle Lösungsplattform zu verkomplizieren oder mit separaten Speziallösungen zu unterlaufen. Die konsequente Einhaltung und fortlaufende Optimierung einer modularen, serviceorientierten Gesamtarchitektur ist hier unabdingbar.
Es müssen also drei Arten von Vorgehensweisen in Einklang gebracht werden:
Erstens das kontinuierliche, als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenneutralen Plattform. Zweitens das zeitlich begrenzte projektartige Entwickeln kundenspezifischer Lösungen unter weitestgehender Nutzung dieser Plattform. Und drittens das wiederum als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenspezifischen Lösungen.
Unternehmen dieser Aufgabenkonstellation umfassen mehrere Hundert oft bis viele Tausend (weltweit) kooperierende Informatikspezialisten in Hunderten verschiedenen Teams. Nicht das Vorgehen und die Methodik in einem kleinen Team, das ein Produkt innerhalb eines Projekts realisiert, ist hier die Herausforderung, sondern die Koordination all dieser Spezialisten und Teams auf Programm- und Portfolioebene.
Für eine agile Form des Portfoliomanagements sind SAFe oder andere Varianten von Portfolio-Kanban denkbar. Das agile Management von Projekten ist mit PRINCE2 oder DSDM möglich. Die agile Kooperation vieler Teams innerhalb einer Produktlinie kann als „Release Train”, z. B. auf der Basis von SAFe auf der Programmebene erfolgen. Und für das agile Arbeiten im Team eignen sich Kanban (insbesondere bei fortlaufenden Wartungsarbeiten), Scrum, Scrumban oder DSDM. In jedem Fall müssen auf Teamebene Praktiken des Clean Code Development genutzt werden.
2. Entwicklung und Unterhalt umfassender Individuallösungen:
Umfassende Individuallösungen
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) umfassender individueller SW-Lösungen und SW-Services für spezifische Kunden oder für den Eigenbedarf des Unternehmens. Typische Beispiele: Anbieter und Betreiber firmenspezifischer Spezialsoftware und -services; unternehmensinterner IT-Bereich.
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) umfassender individueller SW-Lösungen und SW-Services für spezifische Kunden oder für den Eigenbedarf des Unternehmens. Typische Beispiele: Anbieter und Betreiber firmenspezifischer Spezialsoftware und -services; unternehmensinterner IT-Bereich.
Vorgehens-Frameworks und Methodiken auch dieser Konstellation müssen das strategische Portfoliomanagement für die verschiedenen langfristig zu unterstützenden individuellen SW-Lösungen und SW-Services umfassen.
In diesen Unternehmen müssen zwei Arten von Vorgehensweisen in Einklang gebracht werden:
Erstens das zeitlich begrenzte projektartige Neuentwickeln oder grundlegende Überarbeiten kundenspezifischer Individuallösungen. Und zweitens das als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenspezifischen Lösungen.
Bei Unternehmen dieser Aufgabenkonstellation, insbesondere bei unternehmensinternen IT-Bereichen, besteht die Herausforderung sehr oft im Umgang mit der ohne „Überbauungsplan” historisch gewachsenen und sehr heterogenen System- und Anwendungslandschaft mit vielen, oft schlecht dokumentierten und undurchsichtigen Altsystemen.
Auch diese Art von Unternehmen kann mehrere tausend weltweit kooperierende Informatik-Spezialisten in vielen verschiedenen Teams umfassen. Auch hier ist die Herausforderung nicht primär das Vorgehen und die Methodik in einem kleinen Team, das ein Produkt innerhalb eines Projekts realisiert, sondern die Koordination all dieser Spezialisten und Teams auf Programm- und Portfolioebene.
Für eine agile Form des Portfoliomanagements sind – wie bereits vorher erwähnt – SAFe oder andere Varianten von Portfolio-Kanban denkbar. Das agile Management von Projekten ist mit PRINCE2 oder DSDM möglich. Die agile Kooperation vieler Teams innerhalb einer Produktlinie kann, wie schon erwähnt, als „Release Train”, z. B. auf der Basis von SAFe auf der Programmebene, erfolgen. Und für das agile Arbeiten im Team eignen sich Kanban (insbesondere bei fortlaufenden Wartungsarbeiten), Scrum, Scrumban oder DSDM. In jedem Fall müssen auf Teamebene auch hier Praktiken des Clean Code Developments genutzt werden.
Für das Bereinigen der historisch gewachsenen und sehr heterogenen System- und Anwendungslandschaften kann im SAFe all das nützlich sein, was sich auf „Architektur” (z. B. „Architectural Epics” auf Portfolioebene oder „Architectural Runway” auf Programmebene) bezieht.
3. SW-Entwicklung als Dienstleistung:
SW-Entwicklung als Dienstleistung
Anbieten von SW-Entwicklungskapazität (Spezialisten samt Entwicklungsinfrastruktur) im Rahmen unterschiedlichster Kundenprojekte bis zur Inbetriebnahme der Lösung mit nur seltenen – separat beauftragten – anschließenden punktuellen Wartungs-, Anpassungs- und Erweiterungsarbeiten. Typische Beispiele: Als Agenturen auf Projektbasis arbeitende „Softwareschmieden” für kundenspezifische Individual-SW, etwa im Bereich Web-Lösungen.
Anbieten von SW-Entwicklungskapazität (Spezialisten samt Entwicklungsinfrastruktur) im Rahmen unterschiedlichster Kundenprojekte bis zur Inbetriebnahme der Lösung mit nur seltenen – separat beauftragten – anschließenden punktuellen Wartungs-, Anpassungs- und Erweiterungsarbeiten. Typische Beispiele: Als Agenturen auf Projektbasis arbeitende „Softwareschmieden” für kundenspezifische Individual-SW, etwa im Bereich Web-Lösungen.
Die Vorgehens-Frameworks und Methodiken sind vom Anbieter der SW-Entwicklungskapazität dann selbst bestimmbar, wenn mit dem Auftraggeber nur der funktionale Umfang der SW, die Kosten und die Termine vereinbart werden. Da solche Aufträge typischerweise als jeweils autonome Projekte mit einem klar definierten Ende von einem oder höchstens einer Handvoll kooperierender Teams bearbeitet werden, können Vorgehensweisen und Methodiken gewählt werden, die die Arbeit im Team und für ein Projekt ohne herausfordernde teamübergreifende Abstimmungen ins Zentrum rücken. Oft aber arbeiten Anbieter von SW-Entwicklungskapazitäten innerhalb von größeren und vom Auftraggeber gemanagten Projekten mit auftragsspezifischen Vorgaben für das Vorgehen und die Methodik.
Erfolgsentscheidend für solche Anbieter ist, dass sie sich in verschiedensten Vorgehens-Frameworks und Methodiken professionell bewegen können. Und zwar so, dass sie gegenüber dem Auftraggeber dessen Vorgehen nicht nur als „Fassade” bedienen und dahinter in ihrer gewohnten Art agieren, sondern effektiv im Sinn dieses Frameworks/dieser Methodik arbeiten. In jedem Fall – und kaum im Widerspruch zu vorgegebenen Frameworks – müssen auf Teamebene Praktiken des Clean Code Development als „die” Kernkompetenz des Dienstleisters genutzt werden.
Herausfordernd für diese Anbieter ist, dass sie einerseits in der Regel an mehreren solcher Projekte gleichzeitig arbeiten und andererseits bestimmte Spezialisten wie z. B. GUI-Designer mit nur einem Projekt allein nicht ausgelastet sind. Das erfordert eine projektübergreifende mittelfristige Einsatzplanung auf Personenebene, was allerdings die kurzfristige Flexibilität erschwert und der Idealvorstellung eines personell stabilen interdisziplinären Teams mit Personen, die nur in einem Team arbeiten, widerspricht.
Wenn Vorgehens-Frameworks und Methodiken vom Anbieter der SW-Entwicklungskapazität frei wählbar sind, dann sind auf der Ebene des agilen Projektmanagements – auch bei sehr kleinen Projekten – mit „Tailoring” angepasste Formen von PRINCE2 oder DSDM möglich und das agile Arbeiten auf Teamebene kann z. B. mit Kanban, Scrum, Scrumban oder DSDM erfolgen, kombiniert mit der Nutzung der Praktiken des Clean Code Development. Für die projektübergreifende mittelfristige Einsatzplanung auf Personenebene sind alle bekannten Methoden denkbar. Sie sollten im Interesse der Flexibilität und Transparenz jedoch möglichst einfach gestaltet sein und von den Betroffenen selbst (und nicht von einer zentralen Planungsinstanz) gepflegt werden können.
Je nach Konstellation eine andere Agilität
Es gibt also nicht „das eine” Vorgehens-Framework und „die eine” Methodik für alle diese unterschiedlichen Konstellationen. Und daher gibt es auch nicht „DIE” Agilität und „DEN EINEN” Weg in Richtung Agilität, sondern ganz verschiedene Ausprägungen von Agilität und der Wege dorthin. Selbst innerhalb eines Unternehmens können sich diese Ausprägungen und die Wege dorthin je nach aktueller Situation im und rund um das Unternehmen immer wieder ändern.
„Agilität” für ein Unternehmen bedeutet also nicht, sich einer der als „agil” bezeichneten Vorgehensweisen zu verpflichten, sondern je nach Situation das angemessene Vorgehen zu praktizieren, solange es passt, und rasch zu einem anderen Vorgehen zu wechseln, wenn es sich als passender anbietet.
Wichtig!Erfolgsentscheidend ist eine agil genutzte Agilität, nicht das dogmatische und schmerzhafte Verfolgen irgendeines Frameworks. |
„Agile Agilität”, keine normierte
Führt diese „agile Agilität” nicht zu einer überfordernden Vielfalt? Sollte Agilität nicht eher zu einer markanten Vereinfachung führen?
Führt diese „agile Agilität” nicht zu einer überfordernden Vielfalt? Sollte Agilität nicht eher zu einer markanten Vereinfachung führen?
Ja – Vereinfachung, aber im Sinn eines drastischen Abbaus des zentralistischen Mikromanagements überall dort, wo es nicht passt, zugunsten des Vertrauens in die Selbststeuerungsfähigkeit sozialer Systeme.
Keine Simplifizierungen!
Vereinfachung jedoch nicht in dem Sinn, dass die Gesamtheit der unterschiedlichsten internen Steuerungsformen insgesamt betrachtet einheitlicher und einfacher wird. Vereinfachung darf nicht als Simplifizierung verstanden werden, dass z. B. alle Organisationseinheiten eines Unternehmens die identischen und einfachen Arbeitsregeln anwenden. Das wäre unangemessen.
Vereinfachung jedoch nicht in dem Sinn, dass die Gesamtheit der unterschiedlichsten internen Steuerungsformen insgesamt betrachtet einheitlicher und einfacher wird. Vereinfachung darf nicht als Simplifizierung verstanden werden, dass z. B. alle Organisationseinheiten eines Unternehmens die identischen und einfachen Arbeitsregeln anwenden. Das wäre unangemessen.
Dieses Dilemma beschreibt der Philosoph Paul Valéry gut mit dem Satz: „Alles Einfache ist falsch, alles Komplizierte unbrauchbar.”
4 Wie beginnt ein Unternehmen seine ganz individuelle Reise zu seiner eigenen Art von Agilität?
Zentrale Frage
Zu Beginn dieser Reise ist es wichtig zu klären, was denn diese „unternehmensindividuelle Art der Agilität” bedeutet.
Zu Beginn dieser Reise ist es wichtig zu klären, was denn diese „unternehmensindividuelle Art der Agilität” bedeutet.
Mithilfe der „Zeitmaschine” konnten Sie ja die „besten Hoffungen” für ein an Ihr Unternehmen angepasstes Vorgehens-Framework für eine optimale SW-Entwicklung als konkrete Ziele formulieren. Um diese Ziele zu erreichen, wird die Reise ziemlich sicher durch diese zwei Kontinente führen:
• | den Kontinent der Vorgehensweisen: Arbeitsergebnisse/Arbeitsschritte/Arbeitsmethoden |
• | den Kontinent der Unternehmenskultur: Kommunikations-/Kooperations-/Führungsmethoden |
4.1 Der Kontinent der Vorgehensweisen: Arbeitsergebnisse/Arbeitsschritte/Arbeitsmethoden
Dieser Kontinent umfasst die „Mechanik” der SW-Entwicklung und bildet den größten Teil dessen, was in den Beschreibungen der Tätigkeiten, Koordinationsgefäße (Meetings), Rollen und Ergebnisse der diversen Vorgehensmethoden dokumentiert ist.
Vorgehensweisen: polymorph und situativ
Dieser Kontinent ist höchst polymorph: Je nach Aufgabenstellung nimmt er eine andere Gestalt an. Wenn versucht wird, seine Gestalt trotz geänderter Aufgabenstellung gewaltsam beizubehalten, dann können seine Lavaströme die SW-Entwicklung erheblich stören oder gar verunmöglichen.
Dieser Kontinent ist höchst polymorph: Je nach Aufgabenstellung nimmt er eine andere Gestalt an. Wenn versucht wird, seine Gestalt trotz geänderter Aufgabenstellung gewaltsam beizubehalten, dann können seine Lavaströme die SW-Entwicklung erheblich stören oder gar verunmöglichen.
Das sind die drei polymorphen Landschaften dieses Kontinents:
Arbeitsergebnisse
• | Ergebnisse, die innerhalb der SW-Entwicklung von einem Arbeitsgebiet als Grundlage für andere Arbeitsgebiete erzeugt werden und nach der Realisierung der SW nicht mehr relevant sind,
| ||||
• | Software, die effektiv benutzt werden kann. | ||||
• | Weitere Ergebnisse (Modelle, Benutzungs- und Betriebsanleitungen, Auslegungsdaten, Begründungen von Algorithmen, Qualitätsnachweise, …), die auch nach der Realisierung der SW für deren Nutzung/Betrieb/Wartung/Veränderung unverzichtbar sind. |
Arbeitsschritte
• | Entweder im Detail festgelegte Abfolge der Ergebniserarbeitung, soweit dies festlegbar ist und festgelegt werden muss, |
• | oder als so weit wie möglich Raum bietende Rahmenregeln, sodass sich der jeweilige Arbeitsprozess situativ passend und empirisch navigierend ergibt. |
Arbeitsmethoden
• | Modellierungsmethoden |
• | Designpatterns |
• | Programmiertechniken |
• | Clean Code Development und (einige) XP-Praktiken |
• | Testmethoden/Testwerkzeuge |
• | … |
4.2 Der Kontinent der Unternehmenskultur: Kommunikations-/Kooperations-/Führungsmethoden
Dieser Kontinent hat bei jedem Unternehmen seine eigene, unverwechselbare und recht stabile Gestalt. Sie ist das Ergebnis jahrelanger Prozesse der Organisations-, Personal- und Führungsentwicklung, geprägt von der permanenten Kommunikation und Kooperation aller am Unternehmen in irgendeiner Form beteiligten Menschen.
Kultur: längerfristig stabil
Seine drei augenfälligsten Landschaften sind:
Seine drei augenfälligsten Landschaften sind:
• | Kommunikationsmethoden |
• | Kooperationsmethoden |
• | Führungsmethoden |
Es sind altbekannte Landschaften, oft jedoch unwirtlich und ungepflegt. Mangel an Methoden, um diese Landschaften lebensfreundlich zu machen, herrscht nicht. Es mangelt sehr oft jedoch daran, sie auch einzusetzen. Erfolgreich eingesetzt wurden sie u. a. bei SEMCO, der Morning Star Company und in Firmen, die „Beyond Budgeting” bzw. den „Beta Codex” verfolgen (3.4 in [3] ). Hinzuzurechnen sind auch die Arbeit in sich selbst steuernden teilautonomen Gruppen (etwa bei Daimler-Benz in den 1920ern und bei Volvo und Saab in den 1980er- und 1990er-Jahren) und die verschiedenen Formen partizipativer Führung und Organisationskonzepte wie Soziokratie und Holacracy, auf die in Kap. 08A03 eingegangen wird.
Kulturveränderungen sind schwierig
Der Versuch, diese Methoden im Rahmen etablierter Führungsprinzipien und der heute üblichen Kommunikations- und Kooperationsweisen im Unternehmen einzuführen ist schwierig: Es erfordert ein grundsätzlich verändertes Denken und Handeln. Diese Forderung nach einem neuen Denken und Handeln wird jedoch bereits seit Jahrzehnten erhoben.
Der Versuch, diese Methoden im Rahmen etablierter Führungsprinzipien und der heute üblichen Kommunikations- und Kooperationsweisen im Unternehmen einzuführen ist schwierig: Es erfordert ein grundsätzlich verändertes Denken und Handeln. Diese Forderung nach einem neuen Denken und Handeln wird jedoch bereits seit Jahrzehnten erhoben.
Neues Denken gefordert
Dieses veränderte Denken und Handeln setzt voraus, dass beginnend bei der Unternehmensspitze
Dieses veränderte Denken und Handeln setzt voraus, dass beginnend bei der Unternehmensspitze
• | das „Alles-im-Griff-haben” ersetzt ist durch ein „vertrauensvolles Loslassen”. Also: „Kontrolle ist gut – Vertrauen ist besser”; |
Vertrauen ist besser als Kontrolle | |
• | die Einsicht vorherrscht, dass ein Unternehmen erst durch die fortlaufende Kommunikation aller vom Unternehmen umfassten Mitarbeitenden und Stakeholder entsteht, nicht durch von oben verkündete Visionen oder verordnete Strukturen. |
Mit Kommunikation zur Organisation
Die beiden Kontinente sind im Wesentlichen unabhängig voneinander – mit Ausnahme einer entscheidenden Verbindung – allerdings nur als Einbahnstraße:
Wichtig!Die beiden Kontinente sind im Wesentlichen unabhängig voneinander – mit Ausnahme einer entscheidenden Verbindung – allerdings nur als Einbahnstraße:
Der etablierte Kontinent der Unternehmenskultur bestimmt, wie polymorph der Kontinent der Vorgehensweisen sein kann oder muss, nicht aber umgekehrt. |
So kann es sein, dass der Kontinent der Vorgehensweisen eben nicht oder nicht schnell und konsequent genug eine zur jeweiligen Aufgabenstellung der SW-Entwicklung passende Gestalt annehmen kann, weil die Unternehmenskultur das nicht zulässt.
Es kann aber auch sein, dass der Kontinent einer sehr experimentierfreudigen Unternehmenskultur vom Kontinent der Vorgehensweisen immer wieder neue und modische Gestalten verlangt, obwohl sich die Aufgabenstellung der SW-Entwicklung nicht essentiell verändert hat.
In beiden Fällen führt das zu „erdbebenartigen Konflikten” an diesen Berührungspunkten:
• | Sind alle entwicklungsinternen und nur temporären Zwischenergebnisse im Detail vorzudefinieren oder werden sie situativ in Absprache mit den jeweils Beteiligten vereinbart? |
• | Ist die Abfolge der Ergebniserarbeitung im Detail festgelegt oder nur in Form so weit wie möglich Raum bietender Rahmenregeln, sodass sich der jeweilige Arbeitsprozess situativ passend und empirisch navigierend ergibt? |
Diese zwei „Erdbebenzonen” hängen direkt mit dem Erfüllungsgrad der o. e. zwei kulturellen Voraussetzungen zusammen:
• | Inwieweit ist das „Alles-im-Griff-haben” ersetzt durch ein „vertrauensvolles Loslassen”? |
• | Inwieweit ist bewusst, dass ein Unternehmen durch die fortlaufende Konversation und nicht durch definierte Strukturen entsteht? |
Kultur prägt die Vorgehensweisen, nicht umgekehrt
Also: Die Unternehmenskultur prägt die Vorgehensweisen, nicht umgekehrt. Wenn in einem Unternehmen mit enger operativer Steuerung, einem hohen Maß formeller Regeln und dem Zwang zu detaillierter Dokumentation des Arbeitsprozesses begonnen wird, Methoden der SW-Entwicklung einzuführen, die auf einer sich selbst steuernden Arbeit in teilautonomen Teams und auf spontaner und informeller Kommunikation und Kooperation mit den Benutzern beruhen, dann verändert das nicht die Unternehmenskultur. Im Gegenteil: Diese neuen Methoden der SW-Entwicklung werden so lange „verbogen”, bis sie zur etablierten Unternehmenskultur passen – und verlieren damit ihre erhoffte Wirkung.
Also: Die Unternehmenskultur prägt die Vorgehensweisen, nicht umgekehrt. Wenn in einem Unternehmen mit enger operativer Steuerung, einem hohen Maß formeller Regeln und dem Zwang zu detaillierter Dokumentation des Arbeitsprozesses begonnen wird, Methoden der SW-Entwicklung einzuführen, die auf einer sich selbst steuernden Arbeit in teilautonomen Teams und auf spontaner und informeller Kommunikation und Kooperation mit den Benutzern beruhen, dann verändert das nicht die Unternehmenskultur. Im Gegenteil: Diese neuen Methoden der SW-Entwicklung werden so lange „verbogen”, bis sie zur etablierten Unternehmenskultur passen – und verlieren damit ihre erhoffte Wirkung.