Der Business Case für Agilität

Kommentare

• 

  10. Februar 2011 von 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?“

  Antworten
• 

  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.

  Antworten

Kommentieren