Innovationen am Rande des Chaos

Das Entwicklungsprozesse - vor allem bei Software, aber nicht nur dort - heute überall agil und lean sein müssen, liegt daran, dass unzählige Unternehmen die Grenzen des guten alten Plan-Build-Run kennengelernt haben. Softwareentwicklung ist ein Geschäft, das im Wesentlichen aus Unwägbarkeiten besteht. Angefangen von der Tatsache, dass einige Module partout nicht so funktionieren wollen wie geplant, über den Umstand, dass neue Kundenanforderungen Teile des Pflichtenhefts schreddern, bis zu dem Problemchen, dass während der (zu) langen Projektlaufzeit Wettbewerber plötzlich mit einem genialen Konkurrenzprodukt um die Ecke kommen können.

Den meisten Unternehmen kennen die Problematik, weil sie sie schon am eigenen Personal erfahren haben. Im Rahmen einer IBM-Studie über aktuelle Software-Trends äußerten lediglich 25 Prozent der 400 befragten Executives, dass in ihrem Haus Softwareentwicklung und -auslieferung effizient gemanagt wird. Und Unternehmen sind der Meinung, dass ihnen dadurch Business-Chancen entgehen.

Was DevOps von Scrum unterscheidet

IBM empfiehlt, um dieser Situation abzuhelfen, "nachhaltige Softwareentwicklung mit DevOps". DevOps ist ein Kunstwort, das sich aus Teilen der Begriffe Development und Operations zusammensetzt. Einfach gesagt steht es für eine bessere Zusammenarbeit zwischen dem Entwicklungsteam und dem Betrieb, nach Auffassung von IBM gehen die Möglichkeiten des Ansatzes allerdings noch darüber hinaus. "DevOps bedeutet, dass alle Stakeholder, das heißt alle, die das Entwicklungsprojekt tangiert, eng zusammenarbeiten. Gemeint sind dabei neben den Entwicklern und dem Management auch Fachabteilungen, Lieferanten und sogar Kunden", sagt Thomas Bueck, Manager im technischen Vertrieb im IBM Geschäftsbereich Rational-Entwicklungssoftware.

DevOps bezeichnet im Kern nichts anderes als Scrum ("Gedränge"), nur in einem größeren, auf die gesamte Organisation bezogenen Zusammenhang. Scrum, auch ein Begriff, der seit etwa zwei Jahren immer wieder durch die IT-Presse geistert, bezieht sich dagegen stärker auf die Kooperation zwischen Entwicklungsabteilung und Marketing/Vertrieb.

Die Ziele von Scrum und von DevOps sind allerdings identisch: Es geht darum, die Entwicklungszeit insgesamt zu verkürzen, schneller und flexibler auf veränderte Anforderungen zu reagieren, Feedback des Kunden und der eigenen Marketingabteilung schneller und konsequenter zu integrieren.

Sequenzielles Arbeiten dauert zu lange

Kernproblem der klassischen Softwareentwicklung ist die streng sequenzielle Arbeitsweise: Abteilung B fängt erst mit der Arbeit an, wenn Abteilung A mit ihrem Teil fertig ist. Innovativ und agil ist anders. Gerade wer Internettechnologie auf einem sich rasant verändernden Markt verkaufen will, hat mit so einer klassischen Planung keine Chance. Niemand kann zum Start eines mehrmonatigen Projekts genau vorherberechnen, wie sich alle Faktoren, die man berücksichtigen muss, im Laufe von Monaten entwickeln werden.

Dementsprechend gleichen alle Versuche, genau vorherzusehen, wie viel Ressourcen für Arbeitsschritt A oder B nötig sind, einem Schuss in den Himmel. Wenn man dazu noch streng sequenziell vorgeht - also unbedingt abwarten muss, bis Arbeitsschritt A erledigt ist, bevor man mit B auch nur anfangen kann - sind lange Verzögerungen unvermeidlich.

Scrum sorgt dafür, dass jede Abteilung in der Lage ist, parallel zu einer anderen am selben Projekt zu arbeiten. Schlüssel dazu ist die Reduzierung von Komplexität. Das geschieht erstens durch ständige Feedbackschleifen, die alle Beteiligten kontinuierlich auf den gleichen Stand bringen. Zweitens werden die angestrebten Funktionalitäten eines Programms ständig überprüft und die Frage gestellt: 'Brauchen wir dieses oder jenes Feature Stand heute wirklich noch?' Drittens liegen sämtliche Anforderungen an das Produkt nicht schon zu Beginn und für immer fest, sondern sie werden mit jeder Teillieferung neu bewertet und wenn erforderlich angepasst.

Ein solch agiles Vorgehen hat gar nicht den Anspruch, alle Eventualitäten im Vorhinein zu planen, sondern es geht von ständigen Anpassungen als Normalfall aus. Agil mit Scrum zu entwickeln bedeutet anders gesagt, die Menschen in den Mittelpunkt zu stellen. Und zwar erstens den Kunden, der ein optimales Produkt bekommen soll, und zweitens das Entwicklungsteam, für das so effizientes und zugleich kreatives Arbeiten ermöglicht werden soll. Unterstützt werden kann das ganze durch Automatisierung von Prozessen und durch die Verwendung von standardisierten Entwicklungstools.

Cars.com scheiterte fast

Cars.com zum Beispiel, eine Online-Autohandelsplattform aus Chicago mit mehr als elf Millionen Nutzern monatlich, hat in Zusammenarbeit mit IBM seinen Entwicklungsprozess komplett umgestellt. Zuvor lief es hier wie überall: Monatelange Planung für jedes Projekt, endlose Meetings mit entsprechenden Verzögerungen bei der Umsetzung. Zudem enthielt der Prozess viele manuelle Schritte, was nicht nur zeitaufwändig, sondern auch extrem fehlerträchtig ist. Entwicklergruppen konfigurierten Softwaremodule von Hand, nutzten dabei für die Dokumentation ganz unterschiedliche Programme wie Word oder Excel.

Durch diese ineffizienten Prozesse dauerte jede Konfiguration tagelang, Entwickler arbeiten phasenweise auch nachts und am Wochenende. Um hier einen Schritt voran zu kommen, engagierte Cars.com IBM und sein Partnerunternehmen Ascendant Technology. Mit Hilfe des 'IBM Rational Automation Framework' und anderer Tools entstand eine automatisierte Entwicklungs-Architektur, die Cars.com ein agiles Vorgehen bei zukünftigen Entwicklungsarbeiten ermöglicht.

Der größte Teil der manuellen Schritte entfällt, Tests können jetzt automatisiert an verschiedenen Stellen des Prozesses ohne großen Aufwand durchgeführt werden. Dadurch und durch eine Fülle weitere Maßnahmen brauchen Entwicklungsprozesse nur noch ein Viertel der vorherigen Zeit, Cars.com ist in der Lage, 300 Verbesserungen in seinen Anwendungen pro Jahr umzusetzen statt den früheren 40.

Agile Entwicklung erfordert Kulturwandel

Abgesehen von diesem Beispiel, bei dem die Automatisierung vieler kleiner Schritte im Mittelpunkt stand, bedeutet agile Softwareentwicklung bei größeren Projekten einen kompletten Kulturwandel. Die Beteiligten müssen sich von dem Konzept verabschieden, am Ende genau das Ergebnis erzielen zu wollen, das am Anfang, beim Formulieren der Roadmap, ins Auge gefasst worden war. Stattdessen sollte das Motto lauten: Pläne sind dazu da, sie mehrfach zu ändern. Funktionieren kann das nur, so paradox es klingt, mit maximaler Disziplin. Denn Agilität funktioniert nur, wenn Feedbackschleifen und Test genau geplant werden und sich jeder an diese Pläne hält.