Mit der Antwort auf die Frage, wer eigentlich die Rechnung bezahlt, sollte auch geklärt sein, wer das Sagen bei der Software-Entwicklung hat.

Am Ende geht es darum, dass die neue Anwendung einen konkreten Zweck erfüllt, der idealerweise zum Erfolg eines Unternehmens beiträgt. Dafür Sorge tragen müssen die Geschäftsbereiche wie beispielsweise Marketing, Produktmanagement oder Vertrieb. Sie bestellen die Software oder deren Anpassung bei ihrer IT-Abteilung oder ihrem IT-Dienstleister. Damit werden sie quasi zu Kunden der IT. Doch das scheint in der Praxis vielen Entwicklern nicht ganz klar zu sein.

Die Vorwürfe:

• Fachabteilungen üben ständig Druck auf die IT-Abteilung aus.
• Sie ändern oft ihre Wünsche oder wollen kurzfristig neue Features ergänzen.
• Sie haben kein Verständnis für die Arbeit, die IT-Entwickler leisten.

Das denken sich immer noch viele Entwickler und schaffen damit ihrerseits eine Abwehrhaltung gegenüber Anforderungen aus den Fachabteilungen.

Dabei sollte ihnen bewusst sein, dass „ihr Kunde“ das Recht hat, Aufträge zu ändern. Denn letztendlich ist er für den daraus resultierenden Erfolg verantwortlich.

Wir in der IT sind Ingenieure. Wir sollten wissen, wie man mit Veränderungen und hohen Ansprüchen umgeht. Denn auch wenn die Ideen ursprünglich aus den Geschäftsbereichen kommen – denn das ist ihr Job – so sind wir doch diejenigen, die diese realisieren.

Genau diese Symbiose macht IT und Business zu einem unschlagbaren Team. Sobald alle das verinnerlicht haben, können sie Großes schaffen.

Hier geht es um die persönliche Einstellung: Die IT-Abteilung hat nicht das Recht, sich mit den Fachabteilungen anzulegen, wie wir das insbesondere im agilen Umfeld immer wieder erleben. Wir sind Profis und sollten in der Lage sein, denen Feedback zu geben, die die Komplexität unserer täglichen Arbeit nicht kennen und nicht einschätzen können.

Und wir sollten auch nicht vergessen, wer uns am Ende bezahlt. Schließlich entwickeln wir Software und Erlebniswelten für die Kunden des Unternehmens.

Nachdem jetzt geklärt ist, wer die Rechnung bezahlt, lassen Sie uns jetzt einmal einen Blick auf die unterschiedlichen Arten werfen, mit denen wir unsere Entwicklungsleistung bezahlen lassen.

Festpreis versus Time & Material

Es gibt viele unterschiedliche Abrechnungsmodelle, angefangen von mehrstufigem Festpreis über Aufwand mit Obergrenze bis hin zum Anforderungseinheitspreis. Wir betrachten hier die zwei gängigsten Preismodelle: Agiler Festpreis und Time & Material.

Time & Material

Für Scrum, mittlerweile die am häufigsten genutzte Agile-Methode, eignet sich Time-and-Material als Preismodell perfekt.

So war es auch gedacht, zumindest in seiner Ausführung innerhalb der IT. Der in Story Points gemessene Aufwand war von Anfang an eher ein Indikator als ein festes Versprechen. Die Idee war, dass die Teams im Laufe der Zeit besser werden, auch in Bezug auf die Bewertungen, und so hoffte man, dass das so genannte „Burn-Down-Diagramm“ eine stetige Verbesserung in Bezug auf den abgeschlossenen Aufwand bringen würde. Ein sehr flexibles Instrument, das anfangs weitgehend jede objektive Bewertung vermied.

Der Auftraggeber erhält dabei einfach das, was am Ende eines Sprints fertig ist – egal, ob es dem erwarteten Ergebnis entspricht oder nicht. Sie können sich das so vorstellen, dass Sie ein Auto mit Ihren individuellen Extras zu einem Festpreis und zu einer vereinbarten Zeit bestellen. Am Ende bekommen Sie Ihr Auto entweder mit allen bestellten Features, aber teurer und verspätet, oder zum vereinbarten Zeitpunkt, aber nicht ganz fertig und vielleicht noch teurer. Zu Recht würden Sie das nicht akzeptieren. Aber genau das passiert oft in agilen Projekten.

Wie gesagt wird der Aufwand in der IT in Story Points kalkuliert. Es handelt sich dabei um eine Art Währung, welche die Fachabteilungen per se schwer einschätzen können. Der geschätzte Aufwand hängt von Parametern ab, die von außen nicht leicht zu bewerten sind. Dazu gehören unter anderem das Skillset und die Einstellung des Teams zur Selbst-Verbesserung (Self-Improving) sowie die Zuordnung der Story Points zu den anfallenden Aufgaben. Den Story Points wird ein monetärer Betrag entgegengesetzt wird. Allerdings bleibt ungewiss, was genau der Gegenwert dafür ist.

Unsere Meinung

Scrum erlaubt zwar explizit die zeitliche Bewertung eines Features oder einer User Story, dies wird aber sehr selten genutzt. Wir sind ein Freund von Zeitschätzungen. Um der Komplexität gerecht zu werden, kann man z.B. auch bei unbekannten Aufgaben mit „von-bis“-Werten arbeiten, d.h. einen Rahmen setzen, der zumindest eine Indikation darstellt. Das hilft bei der Kommunikation mit den Stakeholdern. Wir sind auch Freunde von Schätzungen durch Architekten oder Tech-Leads, aber nicht durch das gesamte Team, so dass das Business im Vorfeld eine Rückmeldung bekommt, was es zu zahlen hat, damit es entscheiden kann, ob sich der Aufwand lohnt.

Dies sind also alles Ansätze für den Umgang mit Time-and-Material. Unsere Erfahrung hat gezeigt, dass das Vertrauen in den Umgang mit T&M umso größer ist, je zuverlässiger ein Team die Kostenvoranschläge einhält.

Operatives Risiko

Ein wichtiger Faktor, der funktionieren muss, ist die Interaktion zwischen Dienstleister und Auftraggeber. An der Schnittstelle braucht es Personen, welche die Komplexität der Aufgabe beurteilen können. Fehlt diese Funktion, dann kann die Arbeit des IT-Teams (sei es intern oder ein externer Dienstleister) nicht richtig beurteilt werden. Dadurch kann schnell Misstrauen entstehen. Der Auftraggeber trägt hier eine Mitverantwortung bei der Einschätzung der Aufwände.

Agiler Festpreis

Nicht lange nach der Einführung von Scrum mit all seinen Instrumenten stellte sich die Frage, wie man diese neue Offensive wieder einfangen und in einen Rahmen mit festen Preisen integrieren kann.

Es gibt verschiedene Ansätze, um agile Projekte wieder in das Korsett eines Festpreises zu zwingen.

1. Man kann einzelne Arbeitspakete so übersichtlich aufschlüsseln, dass man sie viel leichter abschätzen und dann einen Festpreis anbieten kann. Solange diese Pakete iterativ erarbeitet werden, kann man zwar noch von agil sprechen. Aber wenn sie komplett oder sukzessive aus dem Scope des Gesamtprojekts heraus vergeben werden, sind wir wieder ganz nah an Wasserfallprojekten, bei denen man zunächst den Gesamtumfang kennen muss.
2. Ein anderes Modell besteht darin, eine Anzahl von User Stories (je nach Erfahrung oder Schätzung) entlang von Fibonacci-Zahlen zu definieren (1,3,5,8,13 entspricht dann XS, S, M, L, XL), die den Aufwand in 5 verschiedenen T-Shirt-Größen entsprechend ihrer Komplexität bewerten. Dabei geht man von einer Gesamtschätzung über alle User Stories aus, die während der gesamten Projektlaufzeit anfallen können und kommt so zu einem Gesamtpreis.

Natürlich ist dieser Ansatz mit einem hohen Maß an Ungenauigkeit behaftet, da man im Vorfeld nicht weiß, wie viele User Stories in der vorab angenommenen T-Shirt-Größe am Ende tatsächlich anfallen werden. Außerdem erfordert ein solcher Ansatz in der Regel die Einbindung eines Change Managers. Letztlich bleibt die eigentliche Schätzung immer in den Händen der IT, die natürlich dazu neigen wird, die nächstgrößere T-Shirt-Größe zu verwenden, um effektiv und profitabel zu sein.

Unsere Meinung

Um es kurz zu machen: Man kann es auf diese Weise machen, aber es ist nicht unproblematisch. Es vermittelt den Eindruck von Kontrolle, birgt aber so viele Risiken für beide Seiten, dass wir eher von agilen Festpreisen abraten. Sie sind de facto nahe dran an Wasserfall und kleiden sich nur anders.

Außerdem werden hier einige Grundsätze der agilen Idee völlig untergraben, wie beispielsweise das self-improving Team. Das kümmert den Einkauf aber überhaupt nicht, denn für ihn geht überwiegend um wirtschaftliche Aspekte.

Nur um das klarzustellen: Wir sind große Freunde von planbaren Aufwänden und Kosten. Aber dafür braucht man erfahrene Mitarbeiter – idealerweise auf beiden Seiten.