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.
…
Maurice Taake
04.03.2015
Das eigentliche Kernproblem ("IT aus heutiger Sicht ist nicht in der Lage komplexe Projekte vorherzusagen") löst es nicht. Scrum versuchte das Problem "zu verdauen", indem man sich eben auf vorhersehbare Zeiträume beschränkt (2-3 Sprints/grooming/known velocity), aber gelöst ist das Problem damit natürlich nicht.
Andererseits versucht "Waterfall" vorhersehbar zu sein und stellt sich damit in direkten Konflikt zu "Wir haben es aufgegeben" (Scrum).
Interessanterweise löst sich das Problem mit der eher philosophischen Frage "Müssen wir eigentlich IT Projekte immer vorhersagen?". Für die weitaus meisten "kleineren" IT Projekte kann man diese Frage nämlich durchaus verneinen und dann ist der eher wagemutig anmutende Scrum Ansatz durchaus praktikabel. Für die grossen Projekte halte ich es auch eher wie sie: Waterfall im Grossen und "wie auch immer" Entwicklung im Kleinen ... hauptsache es wird geliefert (da bin ich eher agnostisch).
Ihrem Fazit würde ich mich vollumfänglich anschliessen (in dem eben dort beschriebenen Kontext), aber wie gesagt, ich fürchte das eigentliche Problem lösen wir damit auch nicht. Aber das war denke ich auch nicht das Ziel, wenn ich Sie richtig verstehe ... aber falls jemand eine "endgültige" Lösung für das Problem kennt, wäre ich _sehr_ interessiert :-)
Vielen Dank!