Agil vs Wasserfall
Projekte der zwei Geschwindigkeiten managen
Christoph Lixenfeld, seit 25 Jahren Journalist und Autor, vorher hat er Publizistik, Romanistik, Politikwissenschaft und Geschichte studiert.
1994 gründete er mit drei Kollegen das Journalistenbüro druckreif in Hamburg, schrieb seitdem für die Süddeutsche Zeitung, den Spiegel, Focus, den Tagesspiegel, das Handelsblatt, die Wirtschaftswoche und viele andere.
Außerdem macht er Hörfunk, vor allem für DeutschlandRadio, und produziert TV-Beiträge, zum Beispiel für die ARD-Magazine Panorama und PlusMinus.
Inhaltlich geht es in seiner Arbeit häufig um die Themen Wirtschaft und IT, aber nicht nur. So beschäftigt er sich seit mehr als 15 Jahren auch mit unseren Sozialsystemen. 2008 erschien im Econ-Verlag sein Buch "Niemand muss ins Heim".
Christoph Lixenfeld schreibt aber nicht nur, sondern er setzt auch journalistische Produkte ganzheitlich um. Im Rahmen einer Kooperation zwischen Süddeutscher Zeitung und Computerwoche produzierte er so komplette Zeitungsbeilagen zu den Themen Internet und Web Economy inklusive Konzept, Themenplan, Autorenbriefing und Redaktion.
- Eine Bimodal-IT nach Gartner steuert Projekte agil und klassisch
- Die Wasserfall-Methode lässt sich nicht "agilisieren"
- Wer Budget und Inhalt eines Projekts gleichzeitig verantwortet, trifft oft falsche Entscheidungen
- Gartner rät CIOs zu mehr Mut bei der Wahl der Methodik
Der Trick funktioniert immer: Wer in der IT Lösungen verkaufen oder auch nur überzeugend propagieren will, muss der Zielgruppe zunächst ein Problem bescheinigen. In diesem Sinne schrieb Gartner in seinem Paper "Effective Governance of Bimodal IT Projects": "Projektmanagern und andere IT-Verantwortlichen fällt es schwer, Prozesse aufzusetzen, mit denen sich agile Methoden und traditionellesProjektmanagementProjektmanagement unter einen Hut bringen lassen." Alles zu Projektmanagement auf CIO.de
Foto: Rawpixel - Fotolia.com
Die Analysten aus Stamford beziehen sich auf die "Bimodal IT", ein Begriff, den Gartner aus der Mathematik entlehnt und für die eigenen Zwecke umgedeutet hat. Gemeint ist eine IT-Organisation, in der Projekte sowohl nach dem klassischen Wasserfallmodell gemanaged als auch - teilweile gleichzeitig - agil gesteuert und abgewickelt werden.
Die Kernfrage der Gartners lautet: Wie kriegt man beides zusammen? Wie nutzt man die Vorteile beider Ansätze, obwohl die Abläufe höchst unterschiedlich sind?
Mode 2 verzichtet auf Routinen
Die klassische Vorgehensweise, von Gartner als "Mode 1" bezeichnet, ist hierarchisch und sequenziell, will sagen das Projekt entsteht wie ein Haus: Erst wenn der Keller fertig ist, fängt man mit dem Bau des Erdgeschosses an. "Mode 2" dagegen verläuft mehr experimentell, mit möglichst wenig festgelegten Routinen, Projektteile entstehen parallel zueinander, werden durch Feedbackschleifen laufend nachjustiert.
Dabei will und kann sich das Gros der Unternehmen nicht über Nacht von der klassischen Methode trennen, sucht aber nach Möglichkeiten, die Entwicklungszeiten für neue Produkte und Services zu verkürzen und ihre Qualität verbessern.
Foto: violetkaipa - Fotolia.com
Was allerdings nicht funktioniert, ist laut Gartner, Methode 1 durch Optimierung von Abläufen und Strukturen zu 'agilisieren'. Stattdessen gelte es, zu entscheiden, wann welcher Ansatz der Richtige ist.
Der Vertrieb definiert die Anforderungen
Bei der klassischen Methode würden die Verantwortlichen zunächst eine "Business Capability Road Map", also eine Roadmap der Business-Anforderungen, entwerfen. Am Beispiel der Entwicklung einer CRM-Software verdeutlicht: Basis der Roadmap sind die Wünsche der Vertriebsorganisation, also die Frage: "Was will der Kunde?"
Anschließend werden diese Ansprüche Schritt für Schritt abgearbeitet. Nachteil: Das sequenztielle Vorgehen lässt vergleichsweise wenig Feedback zu. Und: Gerade Softwareentwicklung dauert oft so lange, dass sich die zu Beginn definierten Anforderungen des Marktes schon wieder drastisch geändert haben, wenn das Produkt fertig ist. Außerdem lässt sich anhand einer Liste von Kundenwünschen nicht agil entwickeln.
- Prüfen von Anforderungen in agilen Projekten
Ohne die Priorisierung der Anforderungen des IT-Projekts drohen hohe Folgekosten in einzelnen Sprintphasen. - Verzögerungen durch exportierte Probleme
Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden. - Zeitverluste durch fehlende Aufgabenzuordnung
Zunächst lassen sich nicht ausreichend gut definierte Anforderungen durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints. - Anforderungen treffen ungesteuert auf das Projektteam
Bei agilem Projektmanagement stehen viele Unternehmen noch immer auf der Bremse. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen. - Anforderungen laufen beim Product-Owner-Team zusammen
In einem Projektteam aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Das Product-Owner-Team besteht aus maximal drei Personen. Der Product Owner managed alle an das Team herangetragenen Anforderungen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten.