So agil wie möglich (Teil 1/2)

Da dies mein erster Beitrag hier ist möchte ich mich kurz vorstellen. Mein Name ist Eberhard Huber, meine ersten Programmiererfahrungen habe ich in einer Zeit gesammelt als ein Massenspeicher noch etwas Besonderes war und der Begriff „hart verdrahtet“ noch echte Bedeutung hatte. Seit einigen Jahren programmiere ich eigentlich nur noch experimentell (auch PHP) um den Anschluss nicht ganz zu verlieren. Mein Kerngeschäft ist inzwischen das Projektmanagement in Forschung, Lehre und Praxis.  Zu diesem Thema werde ich künftig hier den einen oder anderen Beitrag als Gastautor verfassen.

Nun aber zum Thema des Beitrages. „So agil wie möglich“ lautet eine der Empfehlungen, die sich aus einer Untersuchung von 190 Softwareentwicklungsprojekten im Jahre 2008 ableiten ließ. Im agilen Manifest wird das Team und die Menschen im Team stärker ins Bewusstsein gerückt als zuvor. In den letzten Jahren rückten auch die sogenannten weichen Faktoren wie beispielsweise Kommunikation, Vertrauen, Konfliktmanagement und Teamentwicklung  im Projektmanagement zunehmend in den Blickpunkt. Wie letztendlich jedoch diese weichen Faktoren, die sich als „Faktor Mensch“ zusammenfassen lassen, mit agilem Projektmanagement und dem tatsächlichen Projekterfolg, der als Ergebnis hinten rauskommt, zusammenhängen ist noch nicht geklärt. Um diesen Zusammenhang besser zu verstehen wurde eine Online Befragung durchgeführt in der erstmalig Daten zu  Projekterfolg, Teamqualität und (agilem) Methodeneinsatz abgefragt wurden.

Insgesamt wurden mit der Umfrage 190 Projekte verschiedener Größe erfasst. Teilnehmer der Umfrage waren überwiegend erfahrene Projektmanager, Entwickler, Architekten und andere Spezialisten. Zuerst ein Blick auf die gesamte Erfolgsbilanz, die gewohnt ernüchternd ausfällt.

Als erfolgreich wurden Projekte definiert, die ihre jeweiligen Ziele erreicht haben, ohne Zeit und Budget (bzw. nur geringfügig) zu überziehen. Die nicht erfolgreichen Projekte haben trotz deutlicher Budget- und Zeitüberschreitung ihre Ziele nicht vollständig erreicht.

Ein Blick auf die Erfolgsquoten der Projekte aufgeschlüsselt nach Teamgröße zeigt ebenfalls nichts grundlegend Neues. Kleine Projekte sind deutlich erfolgreicher als große.

So weit so gut. Wie sieht es aber mit dem Methodeneinsatz in den Projekten aus. Die nächste Grafik zeigt den Einsatz verschiedener Methoden aufgeschlüsselt für erfolgreiche, eingeschränkt erfolgreiche und nicht erfolgreiche Projekte. In der linken Hälfte sind die agilen Methoden, in der rechten Hälfte Methoden, die eher aus dem klassischen Software-Engineering stammen, dargestellt.

Es fällt auf, dass die Methoden bzw. Praktiken „kurze Releasezyklen“, „Tägliche Meetings“ und „Retrospektive“, die quasi das Grundgerüst agiler Vorgehensweisen darstellen, ein gleichmäßiges Gefälle von erfolgreichen zu nicht erfolgreichen Projekten zeigen, diese also in erfolgreichen Projekten häufiger eingesetzt werden. Hier bereits den Schluss zu ziehen, dass die „Agilität“ zum Erfolg führt, wäre verfrüht. Hier muss die alte Statistik-Weisheit bemüht werden, dass eine Korrelation nicht mit Kausalität verwechselt werden darf. Wie ich dennoch zur in der Überschrift genannten Empfehlung komme wird im zweiten Teil verraten, wenn ich die Ergebnisse zu Teamqualität und Projekterfolg vorstelle, hier werden die agilen Methoden dann eine wichtige Rolle spielen.