WIE SCHÄTZT MAN IN AGILEN PROJEKTEN. oder wieso Scrum-Projekte erfolgreicher sind. boris GLOGER

Transkript

1 boris GLOGER»Boris gibt mit diesem Buch einen ausgezeichneten Überblick über die Herausforderungen und Rahmenbedingungen bei der Vorbereitung eines ScrumProjektes.«Sven Röpstorff, Agile Coach und Autor von»scrum in der Praxis«WIE SCHÄTZT MAN IN AGILEN PROJEKTEN oder wieso Scrum-Projekte erfolgreicher sind

2 2.2 Was macht agile Produktentwicklung aus? 7 (...), ba can be thought of as shared space for emerging relationships. This space can be physical (e. g., office, dispersed business space), virtual (e. g., , teleconference), mental (e. g., shared experiences, ideas, ideals), or any combination of them. What differentiates ba from ordinary human interaction is the concept of knowledge creation. Ba provides a platform for advancing individual and/or collective knowledge. (...) Thus, we consider ba to be a shared space that serves as a foundation for knowledge creation. (Nonaka/Konno 1998, S. 40) 2.2 Was macht agile Produktentwicklung aus? Die perfekte Welt würde so aussehen: Eine agile Organisation befindet sich in einem Netzwerk aus anderen agilen Organisationen, die alle zum Beispiel nach Scrum arbeiten und gemeinsam ständig neue, inkrementelle Produktteile liefern. Leider ist das noch immer eine Illusion und mein persönliches Wunschdenken. Fakt ist: Wenn man agil arbeiten will, hilft es zu verstehen, wie die umgebenden Organisationen agieren sollten. Warum? So kann man besser erkennen, wofür man neue Praktiken finden muss. Praktiken, die im traditionellen Umfeld nicht gefordert waren. Die agile Organisation agiert stets mit dem Blick nach außen, statt sich in überbordendem Maß mit internen Prozessen zu beschäftigen. steht ständig im Kontakt mit ihrem Netzwerk aus Kunden und Lieferanten. verbessert dabei ständig die eigene Lösungskompetenz für die Probleme des eigenen Netzwerks und erschafft auf diese Weise neue Produkte. betrachtet ihre Produkte als Lösungen für die Probleme ihrer Kunden. optimiert nicht lokale interne Prozesse, sondern optimiert aus der Sicht des Kunden und hat dabei die gesamte Wertschöpfung im Blick. gestaltet die Arbeit menschengerecht: also kreativ, anregend und sozial. Stellt man bestehende Organisationen dieser Auflistung gegenüber, ergeben sich in vielen Fällen einige Diskrepanzen (Tabelle 2.1).

3 8 2 Was ist agil? Tabelle 2.1 Agile vs. traditionelle Organisation Agile Organisation agiert stets mit dem Blick nach außen, statt sich in überbordendem Maß mit internen Prozessen zu beschäftigen steht ständig im Kontakt mit ihrem Netzwerk aus Kunden und Lieferanten verbessert dabei ständig die eigene Lösungskompetenz für die Probleme des eigenen Netzwerks und erschafft auf diese Weise neue Produkte betrachtet ihre Produkte als Lösungen für die Probleme ihrer Kunden optimiert nicht lokale interne Prozesse, sondern optimiert aus der Sicht des Kunden und hat dabei die gesamte Wertschöpfung im Blick gestaltet die Arbeit menschengerecht: also kreativ, anregend und sozial. Traditionelle Organisation Verfahren des Qualitätsmanagements, Richtlinien und Prozesse erschweren die Kommunikation mit dem Kunden draußen. In der Projektrealität verhindern Abteilungen innerhalb der Organisation den direkten Kontakt mit Kunden und Lieferanten. Die traditionelle Organisation ist nicht auf Lernen und ständige Verbesserung ausgerichtet. Die regierende Null-Fehler-Mentalität führt ironischerweise zu vielen Fehlern. Es gibt keinen Druck, das Funktionierende zu verändern und daher hängt die traditionelle Organisation zu lange an ihren existierenden Produkten. Der Kunde soll ein Produkt kaufen, das nicht auf ihn ausgerichtet ist. Einzelne Prozesse werden optimiert und verschlankt. Das gelingt nur wenigen traditionellen Organisationen. Stattdessen steigt die Zahl der Burn-out- und Bore-out-Opfer. 2.3 Das Problem der klassischen Projektorganisation Wo liegt der grundlegende Unterschied zwischen Vorgehensweisen wie jenen von Lockheed Martin oder IDEO und den klassischen Projektmanagement-Methoden, wie sie von der IPMA oder vom PMI favorisiert werden? Meine Antwort darauf: Es gibt einen eklatanten Unterschied zwischen den Sichtweisen auf das Wesen der Herausforderung. Klassische Projektmanagementverfahren basieren auf einem linearen Modell der Wissensverarbeitung. Sie gehen von der grundlegenden Annahme aus, dass man die Herausforderung in allen Details kennt und die Lösung daher einfach nur erzeugen muss. Das impliziert, dass sich keine der getroffenen An - nahmen während der Laufzeit des Projekts grundlegend ändert. Demgegenüber basieren agile Verfahren auf der klaren Überzeugung:

4 2.3 Das Problem der klassischen Projektorganisation 9 Wir kennen die Herausforderung beim Start des Projekts nur ungefähr. Daher werden wir sowohl das Problem als auch die Antwort auf dieses Problem erst zur Laufzeit des Projekts erarbeiten können. Erfahrene Projektmanager stimmen diesen zwei Sätzen immer vorbehaltlos zu. Und trotzdem wickeln sie Projekte im klassischen Umfeld weiterhin nach den vier Phasen Start, Organisation und Vorbereitung, Durchführung und Abschluss ab. Folgerichtig führt die traditionelle Denkweise zu dem Schluss, dass Fehlannahmen zu Beginn eines Projekts billiger auszugleichen seien als am Ende des Projekts, wie die Autoren des PMBOK schreiben: Ability to influence the final characteristics of the project s product, without significantly impacting cost, is highest at the start of the project and decreases as the project progresses towards completion. (Project Management Institute 2008, S. 17) Auf den ersten Blick erscheint diese Annahme logisch, allerdings beweist die Praxis immer wieder das Gegenteil. Das zeigen zum Beispiel die Zahlen des Chaos Manifesto 2013 der Standish Group, einer fortlaufenden Studie zum Erfolg von IT-Projekten (siehe Tabelle 2.2 und Tabelle 2.3). Tabelle 2.2 Veränderung der Erfolgsquote von IT-Projekten zwischen 2004 und 2012 (Quelle: Standish Group 2013, S. 1) Successful 29 % 25 % 32 % 37 % 39 % Failed 18 % 19 % 24 % 21 % 18 % Challenged 53 % 46 % 44 % 42 % 43 % Tabelle 2.3 Überschreitung von Zeit und Kosten sowie Anteil der gelieferten Features (Quelle: Standish Group 2013, S. 2) Zeit 84 % 72 % 79 % 71 % 74 % Kosten 56 % 47 % 54 % 46 % 59 % Features 64 % 68 % 67 % 74 % 69 % Die Krux ist, dass niemand zu Beginn eines Projekts alle Eventualitäten bedenken kann. Manchmal ist noch nicht einmal sicher, ob die angestrebte Umsetzung tatsächlich die richtige Lösung zum vorhandenen Problem sein wird. Je größer und länger Projekte sind, desto schwieriger wird es, diesen Überblick zu behalten, und daher häufen sich die meisten Probleme gegen Ende eines Projekts an wenn man über die Veränderungen kaum mehr hinwegsehen kann. Die Folge der traditionellen Annahme: Der Analyseaufwand bei Projekten wird immer größer. Problematisch ist dabei, dass diese Analyse selbst nichts zum endgültigen Produkt beiträgt. Sie liefert zu Anfang einzig die Klärung, was der Umfang des Projekts sein soll. Es wird also nicht zum Beispiel durch einen Test (Prototyp) herausgefunden, ob die Ergebnisse der Analyse zielführend sind. Selbstverständlich ist es auch

5 10 2 Was ist agil? bei klassisch geführten Projekten prinzipiell möglich, in der Anfangsphase Prototypen zu entwickeln und Tests durchzuführen. Es wäre kein Problem einzuplanen, dass man in einer frühen Phase Prototypen haben möchte. Aber das eigentliche Prinzip des Lernens durch die Prototypen, die den Projektverlauf rigoros ändern können, ist in diesem Denkschema nicht explizit vorgesehen. Dieses Lernen, das laut Nonaka erst durch gemeinsames Arbeiten, Experimentieren und Ausprobieren entsteht, diese Erkenntnisse werden beim traditionellen Gedankenmodell des Projektmanagements nicht implizit mitgedacht, sondern müssen erst erklärt werden (wenn es gewollt wird). Die Folgen für die traditionelle Produktentwicklung Die Folge dieses Denkens sind in der traditionellen Produktentwicklung immer die gleichen: Am Ende des Projekts sind die Kosten für das Produkt immer höher als zunächst angenommen. Die Projekt-Endtermine werden regelmäßig überschritten und die Zahl der gelieferten Funktionalitäten ist immer geringer als ursprünglich geplant. Obwohl mir Projektmanager und Abteilungsleiter immer wieder berichten, dass ihre Projekte natürlich genaue Ziellandungen hinlegen, muss man sich dennoch den Fakten des großen Bildes stellen: Bent Flyvbjerg und Alexander Budzier liefern in ihrem Artikel Why Your IT-Projects May Be Riskier Than You Think (Flyvbjerg/Budzier 2011) die Daten: Eines von sechs Projekten artet in einen sogenannten Black Swan aus, also in eine totale Projektkatastrophe, die unter Umständen das Ende eines Unternehmens besiegeln kann. Aber nicht nur IT-Projekte sind betroffen. Meskendahl et al. von der Technischen Universität Berlin untersuchten das Multiprojektmanagement von über 200 multinationalen Unternehmen in Deutschland. Die Best-Performer brachten es auf einen Anteil von 80 Prozent wirtschaftlich erfolgreicher Projekte, bei den Bad-Performers liegt dieser Prozentsatz bei erschreckenden 50 Prozent. Allein die Teilnehmer der Studie verschwenden so jedes Jahr rund 10 Milliarden (!) Euro für gescheiterte Projekte. (Meskendahl et al. 2011) Flyvbjerg und Budzier raten deshalb: Any company that is contemplating a large technology project should take a stress test designed to assess its readiness. Leaders should ask themselves two key questions as part of IT black swan management: First, is the company strong enough to absorb the hit if its biggest technology project goes over budget by 400 % or more and if only 25 % to 50 % of the projected benefits are realized? Second, can the company take the hit if 15 % of its medium-sized tech projects (not the ones that get all the executive attention but the secondary ones that are often overlooked) exceed cost estimates by 200 %? These numbers may seem comfortably improbable, but, as our research shows, they apply with uncomfortable frequency. Welche Lösung könnte es für dieses Problem geben? Wie gehen wir damit um? Sind kleinere Projekte die Lösung? Wenn man diese Zahlen liest, kommt man zu dem Schluss, dass man nur kleine Projekte durchführen sollte. So empfiehlt es die Standish Group folgerichtig in ihrem Chaos Manifesto Auf diese Weise reduziert ein Unternehmen dramatisch das Risiko

6 2.4 Scrum in aller Kürze 11 eines Fehlschlags und der daraus resultierenden Kosten. Das macht auf den ersten Blick Sinn. Wir zerstückeln einfach die Projekte und dann wird alles gut. Kleinere Projekte statt der großen Megaprojekte ist das wirklich der Ausweg? Die Antwort darauf lautet eindeutig Nein. Dieser Weg kann nur ein Notausstieg sein. Sie mag für das eine oder andere Vorhaben, wenn die Teilziele sehr genau bekannt sind, erfolgreich sein, wie mir Projektmanager immer wieder versichern. Aber es ist eine schlechte Lösung, ein schaler Versuch, mit dem falschen Werkzeug doch noch etwas zu gewinnen. Ob ein Projekt groß oder klein ist: Es startet immer ohne genaue Kenntnis der Herausforderung und der tatsächlich passenden Lösung. Eine Management-Methode, die das Lernen im Projekt schon aufgrund ihrer Grundannahmen nicht berücksichtigt, kann in komplexen Umfeldern dem Management einer Organisation nicht die notwendigen Informationen zur Steuerung der Projekte liefern sie erzeugt diese Informationen zur Laufzeit des Projekts nämlich gar nicht. Fehlsteuerung 1: Das Managen von Projekten ist als Funktion grundsätzlich nicht auf das Wesentliche ausgerichtet: den Kunden. Projekte sind Verwaltungseinheiten, die ein Projekt verwalten. Dabei ist das Projekt selbst ja nichts wert, sondern nur das Produkt, das dabei entstehen soll. Der zielführendere Ansatz wäre aber: die Verbindung von Produkt und Kunde ernst nehmen und das Produkt so designen, dass der Kunde es nutzen will und sein Problem gelöst wird. Fokus des gesamten Managements und aller Aktivitäten ist somit das Produkt, nicht das Projekt. Fehlsteuerung 2: In klassischen Projekten geht man noch immer davon aus, dass man einen vom Projektmanager (gemeinsam mit allen Beteiligten) entworfenen Plan abarbeitet. Der Projektmanager koordiniert die Projektbeteiligten untereinander. Anders bei den agilen Methoden: Die Projektbeteiligten steuern sich selbst. Wie man das sinnvoll managen kann, hat Ikujiro Nonaka schon in The New New Product Development Game beschrieben. Seine ersten Ideen sind in Scrum als Management-Framework und das Design Thinking als Problemlösungsprozess eingeflossen. Wie bringt man die beiden Ideen Scrum und Design Thinking zu einer validen Kombination für den Product Owner zusammen? Sehen wir uns zunächst zur Orientierung die absoluten Basics für den Product Owner an. 2.4 Scrum in aller Kürze Scrum ist heute der De-facto-Standard der agilen Softwareentwicklung. Es hat sich in den letzten Jahren aus einer (agilen) Projektmanagementmethode zu einem neuen Verständnis darüber entwickelt, wie man dysfunktional arbeitende Teams, Abteilungen, ganze Organisationseinheiten und Firmen agil und lean managt. Meist wird Scrum von Firmen zunächst auf Team- oder Projektebene als Projektmanagementmethode einge-