Ähnliche Problemstellungen, wie sie oben für das Controlling beschrieben wurden, sind auch in anderen Managementfunktionen wie Marketing oder Human Ressources aufgetreten. Zunächst wurden sie aber im Bereich F&E und hier insbesondere in der IT-Industrie seit Ende der 1970er Jahre beschrieben.
Seit den 1960er Jahren lag dem Softwareentwicklungsprozess das sogenannte Wasserfallmodell zugrunde. Typisch für das Wasserfallmodell ist, dass der Kunde vor Beginn des Softwareentwicklungsprojektes seine Anforderungen in einem Lastenheft fest definiert. Auf dieser Basis gibt der Softwareentwickler als Dienstleister ein Festpreisangebot für eine Software-Applikation, die den Anforderungen des Lastenheftes entspricht. Es wird ein Werkvertrag über das Endprodukt, die Software-Applikation, geschlossen.
Am Ende des Projektes erfolgt eine Abnahme auf Basis des Vergleichs der fertigen Software-Applikation mit den im Lastenheft dokumentierten und beauftragten Anforderungen. Erfüllt die Software die dokumentierten Anforderungen nicht, muss der Softwareentwickler auf seine Kosten Nachbesserungen vornehmen. Ist alles in Ordnung, erfolgt die Zahlung des vereinbarten Preises. Verändert der Kunde über die Projektlaufzeit seine Anforderungen, weil sich neue Kundenaspekte oder neue Technologien ergeben, muss der Kunde diesen Zusatzaufwand beauftragen und vergüten, da der Werkvertrag auf den Anforderungen des Lastenheftes beruht und per se keine Änderungen vorsieht.
Bei Projekten wie z. B. dem Projekt HERKULES der Bundeswehr zur Standardisierung und Modernisierung ihrer nichtmilitärischen Informations- und Kommunikationstechnologie, das 2006 begann und 2016 abgeschlossen wurde, sind solche Änderungen unvermeidbar. Im Laufe von zehn Jahren wurden insgesamt 140.000 Computerarbeitsplätze, 7.000 Server, 300.000 Festnetztelefone und 15.000 Mobiltelefone an 1.500 Standorten in Deutschland ausgeliefert. Die Anforderungen wurden bereits vor dem Jahr 2000 spezifiziert. Zu dieser Zeit war z. B. das führende Mobiltelefon das Nokia 7110 – im Jahr 2016 gab es bereits das iPhone 7. Es ist offensichtlich, dass Projekte mit dieser Laufzeit sich nicht vor Beginn sinnvoll in einem Lastenheft spezifizieren lassen. Es fehlt an Agilität.
Zudem ist ein wesentlicher Nachteil des Wasserfallmodells, dass Kunde und Softwareentwickler sich in einem ständigen Streit darüber befinden, was beauftragte Anforderungen sind und was Zusatzaufwand. Kunde und Softwareentwickler streiten, wer die sich erhöhenden Kosten und Zeitaufwände für die Anpassung der Software tragen muss.
Zusammenfassend kann festgehalten werden, dass das Ergebnis des Entwicklungsprozesses, das Software-Produkt, beim Wasserfallmodell weitgehend fix ist, hingegen sind der Zeitaufwand zu dessen Entwicklung und die damit zusammenhängenden Kosten der Entwicklung variabel. Die Verantwortung für die Variabilität ist meist ungeklärt und führt zu Auseinandersetzungen im Projektteam zwischen Software-Entwickler und Kunde. Dieser dem Wasserfallmodell inhärente Streit behindert eine konstruktive Zusammenarbeit im Projektteams.
Dieses Problem hat mehr als zwanzig Softwareentwickler und -manager um Kent Beck zu einem Umdenken und im Jahr 2001 zur Verabschiedung des agilen Manifests bewogen.
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge,
- Funktionierende Software mehr als umfassende Dokumentation,
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,
- Reagieren auf Veränderung mehr als das Befolgen eines Plans.
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Auf Basis des agilen Manifests wurden die für die agile Softwareentwicklung essenziellen agilen Prinzipien entwickelt:
- Zufriedenstellung des Kunden durch frühe, kontinuierliche Auslieferung von wertvoller Software.
- Agile Anpassungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden.
- Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen.
- Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes.
- Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird.
- Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht.
- Als wichtigstes Fortschrittsmaß gilt die Funktionsfähigkeit der Software.
- Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern.
- Ständiges Augenmerk auf technische Exzellenz und gutes Design.
- Einfachheit ist essenziell.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.
- Selbstreflexion der Teams über das eigene Verhalten zur Steigerung der Effektivität.
Die oben aufgeführte Liste stellt die wichtigsten Unterschiede zwischen dem agilen Projektmanagement im ...