Wann lohnt sich agile Softwareentwicklung, und wie geht es besser?

Agilität – Wie dynamisch sind Sie?

Eberhard Wolff

©iStockfoto.com/RomanOkopny

Agile Softwareentwicklung hat einen beispiellosen Siegeszug hinter sich. Scrum hat Wasserfall als den Standardprozess abgelöst. Mittlerweile setzt aber Ernüchterung ein – und es wird auch zunehmend Kritik laut. Dieser Artikel zeigt auf, wo Agilität angebracht ist und welche Auswirkungen agile Softwareentwicklung auf das Geschäft hat – und wie sich auch das Geschäft ändern muss.

Ein mittlerweile typisches Beispiel für einen agilen Prozess ist Scrum:

• Im Product Backlog wird alles aufgenommen, was für das zu entwickelnde Produkt relevant ist. Dazu zählen Features oder auch nicht funktionale Anforderungen.
• Aus dem Product Backlog werden die Elemente in das Sprint Backlog übernommen, die im nächsten Sprint bearbeitet werden sollen.
• Ein solcher Sprint dauert typischerweise zwei bis vier Wochen. In dieser Zeit wird das Sprint Backlog bearbeitet.
• Während des Sprints werden in täglichen Scrum-Meetings die aktuellen Aufgaben und Herausforderungen besprochen.
• Am Ende des Sprints wird ein auslieferbares Produktinkrement geliefert. Die Software könnte also installiert werden und ist ablauffähig. Oft wird sie dem Kunden aber lediglich in einem Review vorgestellt.

Abb. 1: Scrum als agiler Prozess

Abb. 1: Scrum als agiler Prozess

JAX 2015Agile Methoden sind ein zentrales Thema der Business Technology Days (20.-22. April 2015). Gemeinsam mit der JAX und der BigDataCon präsentieren die BT Days innovatives Wissen für Business- und IT-Entscheider. Bis 19. März gelten noch die Frühbucherpreise. Mehr Informationen unter btdays.de.

Warum ist diese Vorgehensweise nun sinnvoll? Ein Grund ist Feedback. Die Software kann bereits genutzt werden und so kann das Feedback aus der Nutzungserfahrung direkt in die weitere Entwicklung einfließen. Wenn beispielsweise neue Software für ein E-Commerce-System implementiert werden soll, kann zunächst eine verbesserte Produktsuche, eine Unterstützung für Expressbestellungen und schließlich eine Funktion zum Empfehlen von Produkten geplant werden. Nehmen wir an, dass in einem Sprint die Produktsuche implementiert wird und diese Suche im Shop einen großen Erfolg hat. Dann kann zunächst eine weitere Verbesserung der Suche umgesetzt werden, statt die beiden anderen Features zu implementieren. Ebenso können völlig neue Ideen eingeplant werden, denn oft entstehen Ideen erst, wenn der Kunde das Feature in Produktion sieht – gleiches gilt beispielsweise für Features, die Mitwettbewerber an den Markt gebracht haben. Anforderungen sind eben nie stabil. Daher sind schnelles Feedback und die Möglichkeit, den Plan zu ändern, sehr wichtig.

Ein weiterer Vorteil von agilen Ansätzen ist, dass der Fortschritt des Projekts sehr gut nachvollziehbar ist. Während eines Sprints kann die Abschätzung, wie viel Arbeit noch getan werden muss, mit der tatsächlich verfügbaren Zeit abgeglichen werden. Außerdem wird am Ende jedes Sprints Software ausgeliefert. Dadurch ist jederzeit klar erkennbar, welche Funktionalitäten tatsächlich schon implementiert sind und in Produktion gehen können. Es ist ausgeschlossen, dass es zu Überraschungen kommt, bei denen am Ende der Projektlaufzeit viel zu wenig tatsächlich implementiert worden ist. Auf diese Weise kann das Risiko minimiert werden. Zudem kann die Software bereits frühzeitig ausgeliefert werden. Dadurch ergibt sich nicht nur ein Marktvorteil, sondern die Software kann auch früher ihre Funktion erfüllen und so Wert generieren – sie beginnt früher, sich zu rentieren.

Prinzipien der Agiliät

Agilität basiert auf einigen wenigen Prinzipien, die die agile Community im agilen Manifest zusammengefasst hat. Sie geben konkrete Verhaltensweisen an – beispielsweise die Priorisierung von Individuen und Interaktionen über Prozesse und Werkzeuge. Noch weiter lässt sich Agilität auf einige grundlegenden Werte kondensieren, die aus dem Manifest auch abgeleitet werden können und das Fundament der Agilität darstellen:

• Feedback: Kunden müssen zur Steuerung des Prozesses implementierte Features bewerten und auf dieser Basis neue Features priorisieren und planen. Um diese Art der Steuerung zu ermöglichen, werden die Aufgaben in Iterationen aufgeteilt.
• Transparenz: Der aktuelle Stand der Implementierung und der dafür bisher investierte Aufwand sind für alle jederzeit erkennbar. Der Projektfortschritt ist also unmittelbar nachvollziehbar.
• Vertrauen: Transparenz schafft Vertrauen, weil es eben weniger Geheimnisse und daher weniger Misstrauen gibt. Gleichzeitig kann Transparenz nur dann funktionieren, wenn sich alle Beteiligten vertrauen und nicht beispielsweise aufgrund von Problemen in einem Projekt das Projekt einfach beendet wird.

Damit hat Agilität Einfluss auf die Firmenkultur und kann nur in bestimmten Firmenkulturen funktionieren. Wenn bei einem Problem in einem Projekt sofort personelle Konsequenzen gezogen werden oder das Team nicht unterstützt wird, sondern nur einfach mehr arbeiten muss, kann es sein, dass die Transparenz eines agilen Prozesses überhaupt nicht im Interesse des Teams liegt und so dessen Vorteile nie zum tragen kommen.

Und der Wasserfall?

Agile Prozesse werden oft als Gegenentwurf vom Wasserfallmodell abgegrenzt. Leider ist aber genau dieser Prozess missverstanden worden. Es lohnt sich, einen Blick auf das ursprüngliche Paper zu werfen, in dem das Wasserfallmodell zum ersten Mal erläutert worden ist – damals noch nicht unter diesem Namen. Dieses Paper hat einige Überraschungen zu bieten:

Am Anfang werden tatsächlich verschiedene Phasen – wie beispielsweise das Erheben der Anforderungen, die Analyse, das Design und die Implementierung – als auf einanderfolgende Phasen beschrieben. Das ist genau der Ansatz, der üblicherweise unter dem Begriff „Wasserfall“ verstanden wird. Allerdings ist in dieser Publikation schon die Rede davon, dass es notwendig sein kann, einen bereits abgeschlossenen Schritt noch einmal zu tun. Das kann beispielsweise sinnvoll sein, wenn bei der Implementierung ein Problem auftaucht und daher das Design überarbeitet werden muss. Weiter wird ausgeführt, dass es durchaus notwendig sein kann, mehrere Phasen zurückzugehen – also von Design zurück zum Erheben der Anforderungen.

Schließlich wird sogar empfohlen, die Schritte ab dem Design bis hin zur Nutzung mindestens zweimal zu durchlaufen. Dabei geht es nur um die Umsetzung – im Gegensatz zu agilen Methoden werden also keine neuen Anforderungen in der zweiten Iteration implementiert. Außerdem wird der Prozess nur zweimal durchlaufen – nicht beliebig oft wie in modernen agilen Vorgehensmodellen. Um es noch einmal klar zu sagen: Das, was heute Wasserfall genannt wird, hat mit dem, was in diesem Beitrag beschrieben wird, nicht viel gemeinsam. Einige Punkte sind sicher diskutabel – aber schon dieses mittlerweile 44 Jahre alte Paper, das den Grundstein für den Wasserfall darstellt, empfiehlt ein iteratives Vorgehen – wenn auch in sehr engen Grenzen. Auf der anderen Seite nimmt der beschriebene Ansatz agile Softwareentwicklung, wie wir sie heute kennen, nicht vorweg – die Anforderungen werden als konstant über die Projektlaufzeit begriffen. Dennoch wird dieses Vorgehen oft fälschlich als der erste Versuch eines agilen Prozesses gewertet – was ein Mythos ist, denn es wird zwar der Sinn von Iterationen schon erkannt, aber das ist bei Weitem noch kein agiles Modell. Beispielsweise legt der Autor sehr viel Wert auf umfangreiche Dokumentation und empfiehlt bei einer Schieflage, dass genau auf diesen Punkt fokussiert wird und alle anderen Aktivitäten im Projekt ruhen sollen. Den Mythos rund um dieses Paper und viele andere Missverständnisse der modernen Softwareentwicklung klärt ein sehr lesenswertes Buch von Laurent Bossavit auf, das aber noch im Entstehen ist.

Iterationen? Immer!

Wie kann also ein sinnvolles Vorgehen in einem Softwareprojekt aussehen? Wie erwähnt sind für Agilität Feedback, Vertrauen und Transparenz notwendig – aber die sind nicht immer gegeben. Dann ist es auch nicht möglich, einen vollständig agilen Prozess umzusetzen, wodurch nicht alle Vorteile realisiert werden können. Eine Implementierung in Iterationen ist aber auf jeden Fall sinnvoll. Dabei wird der Prozess von der Anforderungsanalyse bis zur Implementierung mehrfach durchlaufen und jedes Mal wird lauffähige Software ausgeliefert. So kann das Risiko reduziert werden, das spät im Projekt Überraschungen auftreten. Und wir erinnern uns – schon im ursprünglichen Paper für das Wasserfallmodell wurde ein solches Vorgehen vorgeschlagen. Dieses Vorgehen ist auch dann sinnvoll, wenn die Anforderungen „fest“ sind. Einen Fall, den es eigentlich gar nicht gibt – denn jedes Softwareprojekt ist so komplex, dass die gesamten Anforderungen nie am Anfang vollständig bekannt sein können. Daher ist die Diskussion über diesen Fall eigentlich akademisch. Aber selbst wenn es diesen Fall gäbe, hätte das Vorgehen in Iterationen den Vorteil, dass Teams Risiken und Probleme im Projekt frühzeitig erkennen, aus ihnen lernen und schließlich die Hindernisse beseitigen könnten, weil die Iterationen zu solchen Verhaltensänderungen Raum gäben und der aktuelle Zustand der Implementierung jederzeit nachvollziehbar wäre.

Der Wert der Software

Ein Problem bei der Implementierung von Software können Budgets und vor allem Budgetüberschreitungen sein. Das ist bemerkenswert: Denn die Software wird nicht implementiert, um ein bestimmtes Budget zu erfüllen, sondern um einen Wert für den Kunden zu erzeugen – was eigentlich das Ziel sein sollte. In einigen Situationen ist dieser Wert aber kaum erkennbar. Ein typisches Beispiel: Ein neues System soll implementiert werden und zwar so, dass es sich genauso verhält, wie das alte System, das es ersetzt. Da die Funktionalitäten identisch sind, kann das Projekt eigentlich keinen Wert schaffen. Gegebenenfalls kann der Umstieg auf eine neue Technologie oder die leichtere Wartbarkeit durch höhere Codequalität einen Vorteil darstellen – aber rechtfertig der die Neuimplementierung auf Basis alter Vorgaben? Letztendlich ist ein solches Projekt eine verpasste Chance, Geschäftswerte zu schaffen, indem bei den im alten System implementierten Geschäftsprozessen Optimierungen umgesetzt werden. Agile Ansätze haben bei einem solchen Vorhaben noch das Problem des Feedbacks: Wenn der Kunde lediglich daran interessiert ist, dass das neue System genau so funktioniert wie das alte, wird er sich kaum Zwischenstände anschauen oder dazu Feedback geben – schließlich ist ja durch die Anforderung „wie das Altsystem“ schon alles gesagt. Dadurch ist es schwierig, das Projekt wirklich zu steuern, denn Fragen, beispielsweise zu der Priorisierung einzelner Features, können so kaum geklärt werden. Ebenso werden kaum Diskussionen über Verbesserungen gegenüber dem alten System entstehen, denn das alte System ist das Vorbild für das neue. Daher ist ein solches Projekt kaum agil umsetzbar – vielleicht ist es sogar überhaupt nicht sinnvoll, das Projekt umzusetzen.

Wer braucht schon ein Budget?

Die Orientierung an den geschaffenen Werten lässt sich schwer mit der Idee eines festen Budgets und der Planung anhand von Budgets vereinen. Wichtiger als der Aufwand ist das erreichte Ergebnis und die kontinuierlich geschaffenen Werte. Darauf weist auch die Idee von „Software is never done“ hin. Ein Projekt kann so lange weiterlaufen, wie es mehr Wert generiert als es an Aufwand kostet. Das Denken in Produkten statt Projekten entspricht auch dieser Idee: Ein Produkt kann ständig weiterentwickelt und verbessert werden – so lange sich das lohnt. Dass sich dieser Perspektivenwechsel schwer mit Budgetierung oder gar Festpreisprojekten vereinbaren lässt, ist offensichtlich. Ansätze wie „Beyond Budgeting“ bzw. „Beta-Kodex“ formulieren hierzu einen Lösungsansatz, bei dem das jährliche Festlegen eines Budgets durch einen kontinuierlichen und integrativen Prozess abgelöst wird. Damit werden Prinzipien aus dem agilen Modell auf die gesamte Firma ausgeweitet. Es gibt noch zahlreiche weitere Merkmale des Beta-Kodex:

• Die Koordinierung erfolgt marktlich-dynamisch und nicht über Planungszyklen.
• Ressourcen werden dann bereitgestellt, wenn sie benötigt werden – und nicht durch eine jährliche Zuteilung und Allokation.
• Kontrolle erfolgt über relative Indikatoren, Trends oder Soll-Ist-Vergleiche und nicht auf Basis der Planungsabweichung.

Diese und die restlichen Prinzipien des Beta-Kodex werden von zahlreichen Firmen umgesetzt. Eine der ersten war die norwegische Firma Statoil, die im Bereich der Ölförderung aktiv ist und wesentlich zum Wohlstand in Norwegen beigetragen hat. Der Ansatz ist also nicht etwa nur bei Start-ups oder IT-Unternehmen verbreitet, sondern auch in der klassischen Industrie und auch bei sehr großen Unternehmen. Weitere Beispiele sind Aldi, dm-drogerie markt, Dell, Toyota, Ikea oder Google. Es handelt sich also um einen über verschiedene Branchen erfolgreichen Ansatz. In einem solchen Umfeld funktioniert Agilität besonders gut, da die Ideen zur Planung und Budgetierung sich in agilen Prozessen wiederfinden und mit Beyond Budgeting agile Softwareentwicklung sich dann ganz natürlich im Unternehmen ergibt.

Post-Agil?

Agilität ist sicher noch nicht das Ende der Innovation für Softwareentwicklung. Eine mögliche Optimierung dazu bietet das Ergebnis einer Iteration: Bei vielen agilen Prozessen ist dies nur ein potenziell auslieferbares Produktinkrement – mit anderen Worten das Ergebnis eines Sprints, das ein Kunde im Extremfall nie wirklich zu sehen bekommt. „Fertig entwickelt“ bedeutet eben noch lange nicht „in Produktion“. Besser wäre es, wenn das fertige Inkrement sofort in die Produktion ausgeliefert wird. Software öfter auszuliefern ist das Ziel von Continuous Delivery. Dabei wird die Software durch mehrere Phasen geführt:

• Nachdem der Entwickler den Code geändert hat, laufen Entwicklertests durch und der Code wird gegebenenfalls einer statischen Codeanalyse unterzogen.
• Im nächsten Schritt werden automatisierte Akzeptanztests ausgeführt. Sie sollen sicherstellen, dass in der Software keine fachlichen Fehler sind.
• Schließlich wird die Software automatisierten Kapazitätstests unterzogen. Dadurch wird die Performance der Software überprüft.
• Neue Features werden durch exploratives Testen abgedeckt. Dabei testen fachliche Experten die Software, sodass fachliche Fehler gefunden werden können, die in den anderen Phasen übersehen worden sind.
• Schließlich wird die Software in Produktion gebracht. In den Phasen davor wurde die Software schon auf zahlreichen Umgebungen installiert, sodass dieser Schritt nur ein weiterer Durchlauf durch dieselben Schritte sind – die zudem automatisiert sind.

Dieser Prozess kann im Idealfall mehrmals pro Tag durchgeführt werden. Das Geheimnis ist die weitgehende Automatisierung der verschiedenen Schritte, damit diese schneller durchgeführt werden können und die Ergebnisse reproduzierbar sind. Ein automatisierter Test sollte immer dasselbe Ergebnis bringen – wie auch die automatisierte Installation der Software. Durch Continuous Delivery ändert sich der Charakter der Softwareprojekte. Am Ende steht mehr als nur Software. Die Software muss auch ausgerollt werden. Das ist ein Prozess, der normalerweise im Betrieb angesiedelt ist. Also müssen für Continuous Delivery Entwicklung (Dev) und Betrieb (Ops) zusammenarbeiten. Dazu dient die DevOps-Organisationsform, in der Teams aus Entwicklern und Betriebsmitarbeitern besteht.

DevOps zielt nicht nur darauf ab, das Ausrollen der Software zu optimieren. Ebenso wichtig sind beispielsweise Maßnahmen, durch die Software besser überwacht werden kann oder beim Ausfall von einzelnen Komponenten sinnvoll weiter betrieben werden können. Die Entwickler bekommen durch die engere Zusammenarbeit mit dem Betrieb eine neue Perspektive auf die Software und können sie so besser für den Produktionseinsatz optimieren. Gleichzeitig hat Continuous Delivery eine Auswirkung auf den Prozess: Iterationen, deren Länge sich in Wochen bemessen, können kaum sinnvoll sein, wenn neue Features praktisch ständig ausgerollt werden können. Hier bieten sich Ansätze wie Kanban an. Sie basieren auf dem Kanban-Board, wie es auch bei Lean Production genutzt wird (Abb. 2). Ein Feature ist immer einem der Zustände zugeordnet und wird jeweils in den nächsten Zustand weitergegeben, wenn der Status sich ändert. Dabei wird die Anzahl der Features, die in einem bestimmten Zustand sein dürfen, begrenzt (Limited Work in Progress). Dadurch werden Flaschenhälse in der Pipeline offensichtlich und können dann schrittweise beseitigt werden. Daher ist Kanban eigentlich auch ein Ansatz zur Optimierung von Softwareentwicklungsprozessen. Zusammen mit Continuous Delivery können so tatsächlich neue Versionen der Software nahezu ständig in Produktion gebracht werden. Außerdem kann ein sehr wichtiges Feature oder ein Bugfix mit hoher Priorität durch alle Phasen gebracht werden.

Abb. 2: Ein Kanban Board – erstellt mit http://trello.com

Abb. 2: Ein Kanban Board – erstellt mit http://trello.com

IT zu schnell

Continuous Delivery und Kanban ergeben einen sehr hohen Durchsatz an Features, ein gutes Time-to-Market für neue Funktionalitäten und einen sehr flexiblen Prozess. Eigentlich würde man erwarten, dass die Businessseite erfreut über diese Entwicklung ist und noch schnellere Prozesse von der IT fordert. In vielen Fällen kann man jedoch genau das nicht beobachten. Manchmal werden schnelle Releasezyklen sogar von der Geschäftsseite abgelehnt, weil sie mit den ständigen Änderungen nicht Schritt halten kann. Dann scheint die Einführung von Continuous Delivery und Ansätzen wie Kanban sinnlos – schließlich ergibt sich kein Vorteil für das Geschäft. Aber Continuous Delivery löst auch in diesen Szenarien für die IT ein Problem: Ein großes Releases an einem Wochenende in Produktion zu bringen, ist für IT-Mitarbeiter sehr stressig. Wenn es bei der Einführung des Releases zu Problemen kommt oder das Release gar fehlschlägt, kann das dramatische Auswirkungen haben. Continuous Delivery löst das Problem durch die höhere Zuverlässigkeit wegen der Automatisierung und den umfangreichen Tests in der Pipeline.

Warum kann die Geschäftsseite den Vorteil des schnelleren Deployments und der flexiblen Prozesse nicht ausnutzen? Typischerweise ist die Entwicklung von neuen Features oder Geschäftsideen ein langwieriger Prozess. Die Planung dauert Monate oder Jahre. Marketingaktionen müssen auf Produkte abgestimmt werden, Kunden müssen befragt werden, verschiedene Abteilungen müssen koordiniert werden – die Liste lässt sich fortsetzen. Nehmen wir das Beispiel des E-Commerce-Shops wieder auf: Es soll ein „Shop 2.0“ entstehen. Dazu sind verschiedene Features geplant – eine erweiterte Suche, Expressbestellungen, ein breiteres Warenangebot und schließlich ein Bonusprogramm für Kunden. Abbildung 2 könnte den aktuellen Stand dieses Projekts zeigen – einige Features sind noch in der Entwicklung, andere schon fertig entwickelt. Flankiert wird die neue Version des Shops durch Marketingmaßnahmen und verschiedene andere Aktivitäten. Am Ende wird dann der „Shop 2.0“ zu einem bestimmten Stichdatum den Kunden zur Verfügung gestellt. Vorher sind Releases neuer Features in Produktion nicht geplant, weil das der geschäftlichen Planung – wie den Marketingaktionen – widersprechen würde.

Lean Startup – nicht nur für Start-ups

Eine Alternative zu diesem Ansatz ist Lean Startup. Der Name ist irreführend – denn der Ansatz ist nicht nur für Start-ups sondern für jede Art von Unternehmen geeignet. Im Kern geht es darum, Hypothesen am Markt zu verifizieren und durch iterative Produktreleases in einen Modus von validiertem Lernen zu kommen. Konkret könnte beispielsweise statt einem „Shop 2.0“ zunächst ein Feature ausprobiert werden – beispielsweise Expressbestellungen. Dabei muss das Feature noch nicht einmal zwangsläufig implementiert werden. Interviews mit Kunden können schon einen Eindruck davon vermitteln, wie erfolgversprechend das Feature ist, alternativ kann z. B. auch Werbung geschaltet werden. Wenn viele auf die Werbung klicken, ist es wahrscheinlich, dass das Feature am Markt gut ankommt. Nun stellt sich heraus, dass Expressbestellungen bei Weitem nicht so interessant sind, wie gedacht. Also beauftragt man zunächst die bessere Produktsuche – die sich auch bewährt und zu einem Umsatzwachstum führt. Also wird die Suche weiter verbessert. Um die Chancen eines Features am Markt zu bewerten, ist es also gar nicht notwendig, das Feature zu implementieren – es gibt genügend andere, billigere Methoden.

Dieses Vorgehen auf der Geschäftsebene ist eine ideale Ergänzung zu einem agilen Vorgehen und Continuous Delivery: Auch die Geschäftsseite arbeitet an einzelnen Features und bewerte sie – statt große Änderungen an dem System zu planen. Eine große Änderung am System passt übrigens nicht zu einem Lean-Startup-Ansatz: Wenn viele Features gleichzeitig neu eingeführt werden, kann der Erfolg nicht oder nur schwer auf ein einzelnes Feature zurückgeführt werden. Statt einem „Shop 2.0“ würden also entsprechend Lean Startup einzelne Feature schrittweise implementiert und ausgewertet werden.

Lean Startup orientiert sich also vor allem an dem Wert der Features. Das ist vor allem interessant, da in klassischen Projekten der Erfolg oder Wert eines Features oft noch nicht einmal gemessen werden kann. In einer Lean-Startup-Organisation wird hingegen ein Mechanismus zum Bewerten eines Features von vorneherein in das Feature integriert. Das können einfache Zähler sein, die anzeigen, wie oft beispielsweise Expressbestellungen genutzt werden. Oder eine Produktsuche kann durch A/B-Tests ausgewertet werden: Ein Teil der Kunden bekommt die alte Suche, ein Teil die neue Suche und es wird ausgewertet, welche Gruppe mehr Umsatz generiert. Wenn das Ergebnis bekannt ist, war das Experiment bezüglich der Suche ein Erfolg – unabhängig davon, ob das Feature ausreichend beliebt war oder nicht. Das Ziel des Experiments war die Evaluierung des Features und die liegt nun vor. Durch Experimente mit möglichst wenig Aufwand wird vermieden, dass Geld in Features investiert wird, die später niemand benutzt. Die Geschäftsseite kann so schneller Features ohne großes Risiko ausprobieren, da die Kosten mindestens für die ersten Experimente gering sind. So kann die Geschäftsseite auch mutiger werden und viel mehr ausprobieren.

Design Thinking

Für diesen Ansatz ist eine Kooperation zwischen Geschäftsbereichen und IT notwendig. Denn schließlich sollen die Geschäftsansätze schnell evaluiert und neue Ideen generiert werden. Dazu bietet sich beispielsweise der Ansatz von Design Thinking an: Dabei entwickeln sich interdisziplinäre Gruppen, die beispielsweise neben IT-Experten auch Mitarbeiter aus Bereichen wie Marketing oder Vertrieb umfassen. Sie können dann ganzheitlich Konzepte und Produkte entwickeln und sie gleich am Markt ausprobieren. Design Thinking basiert auf einer nutzerzentrierten Herangehensweise und nutzt Techniken aus dem Design. Es hat auch Überdeckungen mit Lean Startup: Großer Wert wird auf die Überprüfung der Produkte und der Hypothesen gelegt, die der Entwicklung des Produkte zugrunde liegen. Continuous Delivery und Agilität erleichtern dann die Umsetzung in IT-Systemen. Design Thinking wird durch den SAP-Mitgründer und Milliardär Hasso Plattner gefördert und ist ein wesentlicher Bestandteil der Arbeit des Hasso-Plattner-Instituts in Potsdam.

Fazit

Projekte in Iterationen aufzuteilen, ist aufgrund der Risikominimierung und der besseren Transparenz des aktuellen Stands des Projekt auf jeden Fall sinnvoll – und in ersten Ansätzen war dieser Fakt schon bekannt, bevor das Wasserfallmodell überhaupt seinen Namen bekommen hat. Der Erfolg agiler Prozesse hängt ganz wesentlich davon ab, wie die Firmen organisiert sind, für die Software entwickelt wird. In Zukunft kann Agilität daher nicht mehr nur auf Softwareentwicklung begrenzt werden. Abbildung 3 zeigt noch einmal die verschiedenen Techniken und die Beziehung zu Agilität:

• Besonders sinnvoll ist der Einsatz agiler Ansätze, wenn Budgets flexibel aufgrund der erzeugten Werte allokiert werden. Genau das ist das Ziel von Beyond Budgeting.
• Der Fokus auf Iterationen und die Entwicklung von Produkten und Produktideen ist der Inhalt von Lean Startup. Daher trägt Lean Startup diesen Ausschnitt des agil-iterativen Vorgehens in die Produktentwicklung im Unternehmen.
• Während einige agile Prozesse nur auslieferbare Software als Produkt liefern, geht Continuous Delivery einen Schritt weiter und liefert die Software tatsächlich aus. Dadurch kann Feedback aus der Produktion in den Prozess einfließen und Features können viel schneller ausgeliefert werden.
• Continuous Delivery kann nicht von Entwicklern alleine umgesetzt werden – die Zusammenarbeit von Entwicklern und Betrieb durch DevOps wird wichtiger.
•´Design Thinking geht noch weiter als DevOps und setzt interdisziplinäre Teams um, bei denen Vertrieb, Marketing usw. zusammenarbeiten. Sie können beispielsweise im Sinne von Lean Startup Produkte und Produktideen am Markt evaluieren.

Die Ideen aus der Agilität sind also dabei, sich auf den Rest der Unternehmen auszudehnen und dort ebenfalls adaptiert zu werden. Die IT ist hier ein Pionier, während andere Abteilungen eher Nachzügler sind. Es wird sicher spannend zu sehen, ob sich die Ansätze dort auch bewähren.

Geschrieben von
Eberhard Wolff
Eberhard Wolff
Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenz vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: