Mit wenig Aufwand viel erreichen Wie sich die Entwicklung Erfahrungen der IT zu Nutze machen kann

Seit den 1960er Jahren hat sich in der Softwareentwicklung das Wasserfallmodell etabliert. Die Projekte werden in Phasen eingeteilt, welche wie die Kaskaden eines Wasserfalls dargestellt werden.

Es bewährt sich, wenn Anforderungen und Abläufe zu Projektbeginn schon präzise beschrieben werden können und während der Umsetzung stabil bleiben. Dann lassen sich Aufwand und Kosten von Anfang an gut abschätzen. Doch in der Praxis hat sich gezeigt, dass die geplanten Ergebnisse meist nicht so eintreten. Die Phasen, die sequentiell abgearbeitet werden sollen, lassen sich nicht immer klar voneinander trennen. Das frühe Festschreiben der Anforderungen kann zu teuren Änderungen führen. Fehler werden unter Umständen erst spät erkannt. Probleme potenzieren sich, wenn der Kunde seine Anforderungen während der Softwareentwicklung ändert, was nicht selten vorkommt. Zudem unterliegt auch die Softwareentwicklung einem stetig steigenden Kostendruck.

Deshalb hat sich die agile Softwareentwicklung zum Ziel gesetzt, den bürokratischen Aufwand zu verringern und weniger Regeln vorzuschreiben. Seit 2013 werden die Prinzipien in über 80 % der Unternehmen genutzt. Im Manifest heißt es:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Menschen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Eine Vorgehensweise ist Scrum. Scrum beansprucht, hochwertige Produkte schnell und kostengünstig zu entwickeln, indem die Entwickler Vorgängerprodukte im Einsatz sehen und die Kundenanforderungen permanent mit Zwischenergebnissen abgleichen. An Stelle der Entwicklungsphasen mit ihren Lasten- und Pflichtenheften treten eine Liste der Kundenanforderungen, das sog. Product Backlog, und als Sprints bezeichnete Entwicklungsintervalle. Jeder Sprint soll ein fertiges, auslieferungsfähiges Teilprodukt liefern. Die Scrummer Gloger und Margetich [1] veranschaulichen die Ergebnisse der Sprints am Beispiel der Entwicklung eines Flugzeugsitzes: vom Hocker in Sprint 1 über den Stuhl in Sprint 2 zum Pilotensitz am Ende des Projektes. Der Kunde mit seiner zu Anfang häufig diffusen Produktidee steht im Mittelpunkt und wird permanent einbezogen. Auf diesem Wege nähert sich die Entwicklung den Lösungen der tatsächlichen Kundenbedürfnisse iterativ.

In Scrum gibt es drei Rollen ohne disziplinarische Verantwortung: Der Product Owner ist für für die Eigenschaften und den Projekterfolg verantwortlich und pflegt den Kontakt zu den Stakeholdern. Der Scrum Master ist für die Durchführung und die Effizienz verantwortlich und arbeitet als Coach eng mit dem Entwicklungsteam zusammen. Letzteres besteht aus drei bis neun Mitgliedern, das häufig interdisziplinär mit Architekten, Entwicklern, Testern und Dokumentatoren besetzt und gemeinsam für die Zielerreichung in den Sprints verantwortlich ist. Es schätzt auch den Umfang der Arbeiten in den Sprints ein. Zu den Stakeholdern gehören Kunden, Anwender und Manager. Die Manager greifen möglichst nicht direkt in das operative Geschäft ein. Sie sind verantwortlich für die Rahmenbedingungen, die Infrastruktur, die personellen Besetzungen und unterstützen den Scrum Master dabei, Hindernisse aus dem Weg zu räumen.

Die Probleme, die in der Softwareentwicklung zur Einführung agiler Vorgehensweisen führten, treffen wir auch bei der Entwicklung anderer Produkte: Am Anfang steht nur ein Bedürfnis des Kunden. Die Produktidee wird erst im Laufe der Entwicklung konkreter. Insbesondere Automobilzulieferer beklagen dieses Problem. Der Kostendruck steigt und die Zeit von der ersten Idee bis zur Markteinführung soll immer kürzer werden. Deshalb bietet es sich an, den Vorgehensrahmen von Scrum auf die Entwicklung anderer Produkte zu übertragen. Weil es sich um eine anpassbare Vorgehensweise und nicht um eine strikte Methode handelt, ist dies gut möglich. Die Vorteile sind eine steigende Transparenz, regelmäßige Überprüfungen von Funktionalitäten und Vorgehen sowie einfachere und kostengünstigere Möglichkeiten, die Entwicklung sich ändernden Kundenwünschen anzupassen.

Betrachten wir das Beispiel eines mittelständischen Messmittelherstellers. Vor 10 Jahren war die Entwicklungsabteilung in Produktgruppenteams organisiert, entsprechend der Geräte zur Messung von Dimensionen, Oberflächen und Formen. Die Nachteile wurden vor ein paar Jahren erkannt: Jedes Team hatte eigene Softwaremodule entwickelt. Es gab Redundanzen und die Effizienz passte nicht mehr zum Kostendruck des Marktes. Wie in der Branche nicht unüblich, führte der Messmittelhersteller eine Matrixorganisation ein. Deren Vorteil lag eindeutig in Synergieeffekten und einheitlichen Entwicklungswerkzeugen. Eine Projekt-Pipeline und ein einheitliches Projektmanagement mit einem Stage/Gate-Prozess wurden eingeführt.

Heute stößt auch die Matrixorganisation an ihre Grenzen. Sie hinkt der Marktdynamik deutlich hinterher. Die Kunden sind unzufrieden mit den Entwicklungszeiten und –kosten, in Einzelfällen sogar mit der Qualität der Produkte. Zwischen den beiden Standorten gibt es Reibungsverluste auf Grund von Mängeln in der Transparenz und der Kommunikation. Der Dokumentationsaufwand bindet zu viel Kapazität der Entwicklungsabteilung. Deshalb hat der Messmittelhersteller ein neues Veränderungsprojekt angestoßen. Ziel ist eine agile Produktentwicklung.

Wie ein agiles Entwicklungsprojekt abläuft, wo es Fallstricke gibt und wie sie beseitigt werden können, das alles wird Thema eines Artikels im nächsten Newsletter Innovation sein. 
ak-t

Referenz
[1] B. Gloger, J. Margetich: Das Scrum-Prinzip. Stuttgart 2014



Zurück