IT-Projekte mit Scrum-Techniken retten

Teil 2: Endlich belastbare Planungen und starke Teams
In seinem zweiteiligen Beitrag beschreibt Frederik Dahlke, wie sich typische Krisensituationen in traditionell durchgeführten IT-Projekten bewältigen lassen – und das mithilfe von Scrum-Techniken. Auch wenn dieses Vorgehen zunächst seltsam klingen mag, bietet der Einsatz agiler Techniken im traditionellen Umfeld vielfältige Möglichkeiten. In diesem abschließenden Teil erfahren Sie unter anderem, wie Sie belastbare Aufwandsschätzungen erhalten und eine effizientere Zusammenarbeit im Team erreichen können.

In Projekten gehören Probleme und deren Lösung zur Tagesordnung; IT-Projekte bilden dabei keine Ausnahme. Neu ist hingegen der Ansatz, typische Probleme in IT-Projekten durch den punktuellen Einsatz von Scrum-Techniken in den Griff zu bekommen. Das mag auf den ersten Blick absurd erscheinen, da vielerorts die Meinung vorherrscht, Scrum können nur dann funktionieren, wenn es zu 100% in einer Organisation eingeführt ist. Setzt man sich jedoch über dieses puristische Denken einmal hinweg, bietet der Einsatz von Scrum-Techniken völlig neue Möglichkeiten, um Krisensituationen in IT-Projekten effizient zu bewältigen.

In diesem zweiten und abschließenden Teil erfahren Sie u.a., wie Sie in IT-Projekten mit einem ausgeklügelten Vorgehen eine belastbare Aufwandsschätzung erhalten und Grundcharakteristika von Scrum, wie Sprints oder Reviews, einfach in einer Organisation einführen können.

Das "Der Glaube an die Aufwandschätzung"-Problem

Im Gespräch mit Frau Müller (Leiterin Fachkonzeption in unserem Beispielprojekt „HelloWorld“) hat Herr Wolf (Berater und Spezialist für Projektrettung) ein weiteres typisches Problem entdeckt. Das Entwicklungsteam ist immer überplant. Im schlimmsten Fall liefert das Team zum vereinbarten Liefertermin nur einen Bruchteil der Funktionalität. Ein weiteres Zeichen für eine Überplanung ist auch, wenn jedes Mal zum Ende des Releases sehr hart gekämpft werden muss, z.B. mit Wochenendarbeit und vielen Überstunden.

Wie wurde bisher bei "HelloWorld" geplant? Zum einen schätzte das Entwicklungsteam den Entwicklungsaufwand für jedes angeforderte Thema in Personentagen. Zum anderen ermittelte der Entwicklungsleiter, wie viele Personentage das Entwicklungsteam im Zeitraum bis zum Release erbringen kann. Dann sagte der Entwicklungsleiter so viele Themen zu, bis die Summe des Entwicklungsaufwands für die zugesagten Themen gleich der Personentage war, die das Team bis zum Release leisten konnte.

Tatsächlich hatten die Entwickler für das Release so viele Personentage gearbeitet wie geplant. Dennoch wurden einige Themen nicht geliefert. In der Konsequenz waren die Aufwandsschätzungen offensichtlich fehlerhaft. Dies bedeutet, dass die Entwickler wohl mehr Personentage für die gelieferten Themen benötigten, wodurch ihnen nicht mehr genügend Zeit für die restlichen Themen zur Verfügung stand. Zudem hatten sie ggf. an Themen gearbeitet, die nicht rechtzeitig fertig gestellt wurden und somit erst (evtl.) im nächsten Release ausgeliefert werden können.

Ohne Zeiterfassung keine belastbaren Daten

Der tatsächlich benötigte Aufwand pro Thema war dem Entwicklungsleiter nur ungefähr bekannt, da die Entwickler es mit der Zeiterfassung nicht so genau nahmen. Damit lässt sich auch aus dem Vergleich des Ist-Aufwands mit dem Plan-Aufwand kein zuverlässiger Faktor errechnen, um den die Entwickler sich typischerweise verschätzten. Es blieb ihm nur, einen Faktor

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 9 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link