Wirtschaftlichkeit ständig im Blick Agile Controlling – aussagekräftiges Berichtswesen für agile Organisationen

Agiles Vorgehen und klassisches Projektcontrolling lassen sich nicht so ohne weiteres unter einen Hut bringen. So besteht z.B. oft Unklarheit über den Fertigstellungszeitpunkt, wenn das Team selbst entscheidet, wie viel es im jeweiligen Sprint umsetzen möchte. Dr. Stefan Barth beschreibt, wie es einem mittelständischen Software-Entwickler gelang, die Vorteile des agilen Vorgehens und die Erwartungen an ein aussagefähiges Berichtswesen zu vereinen.

Wirtschaftlichkeit ständig im Blick Agile Controlling – aussagekräftiges Berichtswesen für agile Organisationen

Agiles Vorgehen und klassisches Projektcontrolling lassen sich nicht so ohne weiteres unter einen Hut bringen. So besteht z.B. oft Unklarheit über den Fertigstellungszeitpunkt, wenn das Team selbst entscheidet, wie viel es im jeweiligen Sprint umsetzen möchte. Dr. Stefan Barth beschreibt, wie es einem mittelständischen Software-Entwickler gelang, die Vorteile des agilen Vorgehens und die Erwartungen an ein aussagefähiges Berichtswesen zu vereinen.

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.

Die Umstellung unseres Vorgehens begann Anfang 2013. Bereits nach Ablauf dieses Jahres ließ sich ein erstes zufriedenstellendes Fazit ziehen: Innerhalb von zwölf Monaten wurde kein defizitäres Gewerksprojekt mehr umgesetzt und die Auslieferungsqualität stieg. Gegenüber unseren Kunden gelang es, unser agiles Vorgehen bereits im Vertriebsprozess als effizientes Leistungsmerkmal zu platzieren, was dem Kunden erhöhtes Vertrauen in die Umsetzungskompetenz der Entwicklungsorganisation vermittelte. Darüber hinaus stellten wir fest, dass auch die Softwareentwickler selbst es schätzen lernten, regelmäßig einen externen, wirtschaftlich…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
3 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 11
Kommentare 3

Alle Kommentare (3)

Maurice
Taake
Ein richtiger Weg, es bringt Scrum/Agile näher an Waterfall ... wenn man das will und ich halte es für legitim das im Zweifel zu wollen.
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!

 

Ernst
Affolter
Dr.
Die von Ihnen geschilderte Thematik kann ich gut nachvollziehen. Ein kritischer Aspekt ist aus meiner Erfahrung eine belastbare Aussage zum Fertigstellungsgrad. Worauf basiert diese? Ist es einfach eine Auflistung der bereits abgearbeiteten Story Points im Vergleich zu den geplanten? Das wäre in meinen Augen nicht korrekt, da Story Points ja eher zum Aufwand in Beziehung stehen als zum Reifegrad. Oder wie beurteilen Sie sonst den Reife- bzw. Fertigstellungsgrad des Produktes? Wenn Sie dazu noch eine Ergänzung machen könnten, würde dies die Aussagekraft des Artikels in meinen Augen noch markant steigern.

 

Maurice
Taake
Das sehe ich ähnlich, Story Points sind im Grunde ausschliesslich aufwandsgebunden und geben keinen Anhalt für den tatsächlichen Reifegrad.
Den Reifegrad kann man IMHO agile eigentlich nur nachvollziehen, wenn es gelingt die Anforderungen so zu schneiden, dass continuous agile deliveries tatsächlich einen sichtbaren Eindruck geben. Dieser ist dann durchaus mächtiger als "kontrollierter Aufwand vs. Schätzung" und bietet einen sehr guten Eindruck "wo wir stehen". Rein psychologisch übrigens auch sehr viel beruhigender als blanke Zahlen, aber das nur am Rande. Gleichzeitig ist es mit tatsächlich erstellten Teillösungen einfacher und besser die "verbleibende Problematik" abzuschätzen, was wohl der bessere Entfernungsmesser als der verbleibende (meist nur initial) geschätzte Aufwand darstellt, weil er einen Gutteil Risikomanagement implizit beinhaltet. Fail Early erweist sich hier wieder einmal als fundamental positive Eigenschaft. Als Nebeneffekt sähe ich hier auch noch, dass aus den bereits erstellten Teillösungen viel einfacher ein Minimal Viable Product abgeleitet werden kann (das entsteht hier "natürlich" und ist nicht wie so oft bei Waterfall künstlich aus der Not geboren). Dieser Nebeneffekt entschärft Eskalationsproblematiken allerdings erheblich, was Ruhe in Projekten schafft.
Leider sehe ich das Schneiden und Liefern sinnvoller und sichtbarer Teillösungen auch viel zu selten. Das Sprint Backlog wird viel zu selten nach dieser eigentlich fundamentalen Eigenschaft von Agile Development geschnitten.
Meine Lösung zum Problem "Fertigstellungsgrad und Vorhersagbarkeit" geht immer weiter zu "weniger Zahlen" und zu mehr "fassbarer Lieferung". Nicht unbedingt eine Lösung für jeden, aber für Softwareprojekte durchaus ein Schritt zu weniger Eskalation. Zum Glück muss ich ja auch nicht den Berliner Flughafen bauen (meine ausdrückliche Hochachtung an dieser Stelle für Hr. Amann!) ;-)
Und auf die Gefahr hin, jetzt ausgelacht zu werden: ich habe _sehr_ gute Erfahrung im Zusammenhang mit oben mit einer gutgemeinten %-Schätzung gemacht (ergibt sich aus Story Points, gemachten Teillieferungen und Restrisiko/-aufwand). Wenn man das durchzieht und transparent hält ist es tatsächlich ein sehr guter Anhaltswert, auch wenn man mal ins Stocken gerät, so wird das durchaus sichtbar (mithin handhabbar ...). Auch hier ziehe ich es wieder vor eine Schätzung vorzulegen und diese auch als Solche zu bezeichnen. Bitte keine falschen Sicherheiten, basierend auf irreführenden "Zahlen" ...
... und sorry für das schauderhafte Deutsch/Englisch Gemenge ;-)