Wann gilt ein Softwareentwicklungsprojekt als erfolgreich? Gängige und plausible Bewertungsparameter sind u.a. Budgeteinhaltung, Realisierung innerhalb der geforderten Termine und die Umsetzung der gewünschten Anforderungen. Legt man diese Parameter allerdings für eine Bewertung zugrunde, stellt man in vielen Fällen fest, dass die überwiegende Zahl der Software-Entwicklungsprojekte im Hinblick auf mindestens eines der drei Kriterien scheitert.

Das Grundproblem

Dieser Missstand führt sowohl auf Seiten des budget-tragenden Kunden als auch auf Seite der Lieferanten zu unterschiedlichen Ansätzen bezüglich der Projektdurchführung: Die Lieferanten wenden sich mehr und mehr agilen Entwicklungsmethoden zu (favorisiert Scrum, deswegen im Folgenden so benannt), der Auftraggeber hingegen baut ein wachsendes Kontrollbedürfnis zur frühen Erkennung von Fehlentwicklungen auf.

Die hierdurch entstehenden Reibungen sind häufig erheblich, da die Steuerungs- und Berichtserwartungen auf Kundenseite nach Maßstäben des klassischen Projektcontrollings nicht so ohne Weiteres mit den Ansätzen von Scrum zu vereinbaren sind. Das Konfliktpotenzial entsteht hierbei unabhängig davon, ob die Beziehung zwischen Auftraggeber und Aufragnehmer innerhalb eines Unternehmens besteht oder es sich um einen externen Entwicklungsdienstleister handelt.

Wenn Kulturen aufeinanderprallen

Ursächlich für den Konflikt sind im Kern unterschiedliche unternehmenskulturelle Ansätze. Wo klassische Controlling-Methoden deutlich organisationszentriert sind, ist Scrum ein menschenzentriertes Vorgehensmodell. Softwareentwicklung wird hier nicht als ein Produktionsvorgang betrachtet, der sich nach ingenieurwissenschaftlichen Kriterien steuern lässt, sondern als ein kreativer Prozess, der bestimmt ist durch kleine Teams mit herausragenden Entwicklern. Scrum lässt so – in seiner Reinform – wesentliche Aspekte missen, die ein Controller erwartet:

• ein eindeutiges Verantwortungskonzept (Verantwortung ist unteilbar – wie kann ein Team Verantwortung übernehmen?)
• ein dokumentiertes Risikomanagement (Impediments sind ja schon eingetreten – wie gehe ich mit potenziellen Impediments um?)
• eine langfristige Planbarkeit der Herstellungszeitpunkte von Ergebnisartefakten (das Team entscheidet über die Fortschrittsgeschwindigkeit im Sprinttakt – wie kann ich ermitteln, wann ich voraussichtlich fertig bin?)
• eine Klarheit darüber, was das Ergebnisartefakt ist und idealerweise einen Festpreis hierfür (das Backlog entwickelt sich im Laufe der Zeit – woher weiß ich, dass ich am Ende auch das für mein Geld bekomme, was ich wirklich benötige?)

Auch wenn Scrum tatsächlich die eine oder andere Methode bereithält, um solchen Fragestellungen zu begegnen, lassen sich diese typischerweise weder in die geübten Projektcontrolling-Verfahren einer internen IT-Steuerung noch in die normalen Steuerungsmechanismen eines Dienstleisters implementieren.

Der Lösungsansatz

Als Softwareentwicklungs-Haus sind wir bei der tarent solutions GmbH in den vergangenen Jahren sowohl in der internen Entwicklung eigener Produkte als auch als Dienstleister in kundenindividuellen Projekten mit diesen Herausforderungen konfrontiert worden. Darüber hinaus haben wir in beratender Funktion den einen oder anderen Umstellungsprozess von klassischen Entwicklungsvorgehen zu Scrum praxisnah begleitet – und auch hier immer wieder vergleichbare Beobachtungen gemacht. Nach und nach wurde es für uns zwingend notwendig, eine Lösung für die oben geschilderte Problematik zu finden.

Unsere Grundphilosophie ist die einer agil operierenden Entwicklungsorganisation. So suchten wir eine Lösung, die dies nicht in Frage stellt. Wir wollten weiterhin ein flexibles Anforderungsmanagement, kurze Entwicklungszyklen, kleine Entwicklungsteams, die typischen Kommunikationsregularien und ein durchgängiges Verständnis des Entwicklungsziels bei allen Beteiligten erhalten. Daneben galt es aber auch, eine organisationsdurchgängige Transparenz des Entwicklungsfortschritts, mittel- bis langfristige Planbarkeit, eine Sicherung der Wirtschaftlichkeit und die aktive Einbindung des Managements (sowie der Auftraggeberseite) zu gewährleisten.

Ein schützender Kokon

Unsere Lösung bestand darin, einen schützenden Kokon um die agil operierenden Entwicklungsteams zu legen, der nach außen dem Auftraggeber ein Vorgehen nach klassischen Steuerungsprinzipien suggeriert. Gleichzeitig implementierten wir aber auch Scrum-untypische Mechanismen, die es dem mittleren Management ermöglichten, Einfluss bei bestimmten Entwicklungen zu nehmen, ohne dabei die kreative Freiheit der Entwickler zu behindern. So konnten wir im Kern die Vorteile eines agilen Entwicklungsvorgehens erhalten, nach außen hin aber den Erwartungen der Anfordererseite hinsichtlich eines aussagefähigen Berichtswesens genügen und uns gleichzeitig so aufstellen, dass wir in der Lage waren, aus den Berichten auch selber zügig Konsequenzen abzuleiten und entsprechende Maßnahmen umzusetzen.