In ihrem Artikel „Achieving success in large, complex software projects“ schreiben McKinsey über die Besonderheiten komplexer Entwicklungsprojekte.
In einem der Schaubilder kann man sehr gut erkennen, welchen eigentlichen Vorteil die agile Entwicklungsmethode bietet.
In dem bereits erwähnten Artikel (siehe „weiterführende Informationen“ weiter unten) benennt der Autor eine interessante Größenordnung. Demnach läuft ein sehr großer Prozentsatz der komplexen Projekte schlecht bis sehr schlecht:
„A joint study by McKinsey and Oxford University found that large software projects on average run 66 percent over budget and 33 percent over schedule; as many as 17 percent of projects go so badly that they can threaten the very existence of the company.“
Die Autoren gehen im Rahmen der Lösungssuche auf zwei Entwicklungsmodelle ein. Das erstgenannte Modell beschreibt eine Organisation, die nach der Wasserfallmethode arbeitet. Das zweite Modell behandelt eine Organisationsform, die man auch in agilen Organisationen so findet.
Die Bewertung ist, wie ich sie erwarten würde.
Die erstgenannte Methode fördert demnach die Bildung von Silos, und (interessant für das Produktmanagement) sie erfordert, daß Requirements definiert sind, bevor die Entwicklung überhaupt startet:
„We have found that for many large, complex application-development projects, functionally organized team structures are counter-productive. Each function takes ownership only of its part of the software-development life cycle instead of delivering working functionality to the end user.“
Im agilen Modell verwendet cross funktionale Teams, d.h hier sind Entwickler, Tester oder Produktexperten Teil desselben Teams. Dies bietet sehr viele Vorteile, wie die Autoren schreiben:
„When applied well, cross-functional units can have multiple benefits, including increased individual and collective accountability, better communication and coordination, and shorter iterations.“
Ich habe in beiden Modellen gearbeitet, und kann die Ergebnisse der Studie genau so unterschreiben. Allerdings denke ich, daß man die agile Methode auch bei Projekten verwenden kann, die nicht sehr strukturiert sind, man muss sie nur „hierarchisch“ (im Sinne der Inhalte) verwenden.
Ein visueller Grund für den Nutzen der agilen Methode springt den Leser des erwähnten Artikels förmlich an.
Schauen Sie sich dort einmal die Pfeile an, mit denen gezeigt wird, wie der Business User eingebunden wird.
Zwei Ergänzungen sind in der Praxis wichtig:
Alles in allem sind die Vorteile der agilen Methodik aber sehr gut auf den Punkt gebracht.
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Folgeartikel zum Thema gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen.
In der Online Version des Artikels finden Sie hier die versprochenen weiterführenden Links: