Der Business Case für Agilität

2 Kommentare

Auf der OOP 2011 habe ich heute im Rahmen des Scrum Executive Briefing einen Vortrag zum Business Case für Agilität gehalten. Die Idee dahinter war einmal nicht die typischen agilen „Evangelisten“ Statements für den Business Case zu verwenden, sondern echte Finanz-Kennzahlen zu vergleichen, um den höheren Nutzen von agilen Methoden im Vergleich zum Wasserfall Modell nachzuweisen. Sprich: Einmal nicht nur zu behaupten, dass der Business Case schon alleine daraus resultiert, dass agile Projekte 300% produktiver sind, sondern den Wert aus den Grundwerten abzuleiten: Interatives, inkrementelles Vorgehen und Fokussierung auf den wirtschaftlichen Nutzen. Als Kennzahlen werden Kapitalrendite, Kapitalwert und Gewinnschwelle genommen. Was denkt Ihr, wo liegt der Business Case für Agilität noch? Und wie kann man ihn finanziell quantifizieren? Wir denken beispielsweise gerade noch darüber nach, wie man am die finanziellen Unterschiede für den Zeitpunkt der fachlichen, manuellen Tests und den Business Case für automatisierte Regressionstests quantifizieren kann. Das kommt dann im Business Case für Agilität 2.0!

Als Mitbegründer und Advisor der codecentric AG berät Mirko bei der strategischen Ausrichtung des Unternehmens. Er ist Geschäftsführer und Mitgründer der Startups CenterDevice und Instana – beides disruptive Geschäftsmodelle auf Basis von Big-Data- und Cloud-Technologien.

Seine Interessen liegen im Bereich der Veränderung von Geschäftsmodellen durch moderne Technologien und Software, also der zunehmenden Digitalisierung der Welt und den daraus resultierenden Veränderungen und Potential für Unternehmen.
Im Privatleben widmet er sich am liebsten seiner Familie, zum sportlichen Ausgleich fährt er Mountainbike.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Bernhard H. Schmitz

    Um ehrlich zu sein, für meinen Geschmack geht der Business Case von zu vielen Annahmen aus, es wird zuviel an Vorannahmen reingesteckt, bei denen das spätere Ergebnis schon im Voraus klar sein müßte.

    1.A) Für den Business Case sollte man den kompletten Life-Cycle nehmen (evtl. bis zu 10-15 Jahren oder rmehr) und mit entsprechenden Anwendungen, die mit einem V-förmigen Vorgehensmodell entwickelt wurden, und die auch Jahre später noch weiterentwickelt und geändert werden müssen, vergleichen, wozu auch die vorliegende Dokumentation gehört.
    1.B) Oder man vergleicht kurzlebige, agil entwickelte Anwendungen mit ebenfalls kurzlebigen, V-förmig entwickelten Anwendungen,
    1.C) oder einigen Fällen dazwischen.
    2. Gemäß Frederic Brooks sollte man auch zwischen einer Individual-Applikation, einem Standard-Produkt und einem Produktions-System unterscheiden. Gibt es eigentlich schon agil entwickelte Standard-Produkte?
    3. Um nicht 1 Anwendung 2 Mal zu entwickeln, also agil und V-förmig, benötigt man dringend noch eine objektive Kenngröße für die Komplexität der Anwendung, um ähnliche Projekte miteinander zu vergleichen.
    4. Dann muss man eine Langzeitstudie machen oder finden, die echte Zahlen aus der Realität vergleicht: „Wie lange haben die Projekte denn wirklich gedauert? Wie teuer waren und wie lange dauerten spätere Änderungen (also über die nächsten 10 Jahre)? Bei welchen Lebensdauern lohnt sich welches Vorgehen?“

  • Mirko Novakovic

    10. Februar 2011 von Mirko Novakovic

    Hallo Bernhard,

    vielen Dank für den Kommentar. Hier meine Anmerkungen dazu:

    1) Sehe ich genauso. Habe ein Excel Sheet mit dem man die verschiedenen Szenarien abbilden kann. (schicke ich gerne zu) Und natürlich stellen sich die Szenarien unterschiedlich dar – insbesondere der Life-Cycle ist dabei interessant. Wobei es natürlich auch unrealistisch ist, dass nach der initialen Entwicklung keine Investition mehr stattfindet. Eine Anwendung die 15 Jahre im Betrieb ist, wird i.d.R. kontinuierlich weiter entwickelt.

    2) Ich bin mir sicher, dass jede Menge Standardsoftware gibt, die mit Scrum entwickelt wird (jetzt müsste man vielleicht noch spezifizieren, welche Art von Standardsoftware). Eine sehr interessante Story gibt es von Salesforce (Standardsoftware im CRM Bereich, allerdings im SAAS Modell), die sehr schön beschreiben, wie man von 0 auf 500 Entwickler skaliert ist und wie man dann mit Scrum und kurzen Zyklen einen „echten“ Business Case erreicht hat: http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference – das schöne an den Folien: Sie kommen vom Kunden selbst.

    3.) Wie sieht es mit Function Points aus? Boris Gloger hat auf der OOP beispielsweise präsentiert, dass ImmobilienScout24 die Produktivität seiner Scrum Teams auch in Function Points misst. Salesforce hat die Produktivität in „Anzahl Features“ gemessen – wobei Feature dann natürlich genormt sein muss. Die Präsentation zeigt ja auch, wie sich die Anzahl der Features erhöht hat.

    4.) Ein entscheidender Punkt. Die Frage geht hier aber aus meiner Sicht weit über den PM-Ansatz (Scrum, V, …) hinaus. Die Kosten der Änderungen hängen aus meiner Sicht von vielen Faktoren ab, die mir Scrum nicht viel zu tun haben: Architektur, Qualität des Teams, Änderungshäufigkeit, etc. etc.

    Zusammengefasst: Die Präsentation hat keinen wissenschaftlichen Anspruch und beleuchtet auch nur 2 Fassetten (Iterationslänge, Priorisierung) der Entwicklung in nur einem fiktiven Szenario. Meine Idee dahinter war nicht einfach nur zu sagen: „Der Business Case für Agilität ist doch eh klar: Man ist produktiver“, sondern auf Basis von Zahlen zu zeigen, wie ein konkreter Business Case aussehen könnte. Bei vielen Kunden wo wir zurzeit beratend tätig sind, gibt es immer noch Projekte, die jahrelange Projektlaufzeiten haben, bevor überhaupt etwas in Produktion ist – meistens haben sich die Anforderungen dann schon mehrfach selbst überholt.

    Interessant wäre aber wirklich mal eine TCO Betrachtung über 10-15 Jahre zu machen – inkl. automatischer Regressionstests vs. manueller Regressionstest, usw. – mache mir dazu mal Gedanken und bin für Idee offen.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.