Im Projektgeschäft gibt es verschiedene Wege, zum Ziel zu kommen. Vorausgesetzt, man kennt das Ziel. Viele große Unternehmen sind im Grunde ihres Herzens noch immer sehr klassisch aufgestellt, versuchen allerdings mehr und mehr, in die agile Welt hineinzuschnuppern.
Ob man mit seinem Projekt erfolgreich ist, hängt von vielen Faktoren ab. Eine nette Übersicht gibt die folgende Abbildung:
Projekterfolg
So geschehen in einem meiner letzten Projekte. Eigentlich ein nettes Projekt. Es gab ein festes, sinnvolles Ziel, es waren wirklich gute Entwickler am Start und viele wussten, wie der richtige Weg zum Ziel aussehen sollte, und auf jeden Fall war Scrum als Vorgehensmodell gesetzt. Leider war das Projekt-Setup äußerst schwierig: Zu Projektbeginn gab es nur einen ScrumMaster, der dies eigentlich nicht sein wollte und vier Product Owner, die sich häufig genug nicht einig waren. Und das waren erst die Rollen! Es gab keine Vision, die irgendwo aufgeschrieben war, und das Backlog war äußerst spärlich und nicht priorisiert. Für ein Multi-Millionen-Mehrjahres-Projekt nun wirklich zu wenig. Noch dazu war das Projekt eher technisch motiviert, so dass die fachlich ausgerichteten Geldgeber kein echtes Interesse am Projekt hatten.
Mein Auftrag bestand nun darin, diese verfahrene Situation zu klären. Die erste Problemstellung, die ich mir vorgenommen hatte, war die Formulierung der Anforderungen. Doch bereits hier bin ich auf extremen Widerstand gestoßen. Die ersten Stories waren schnell geschrieben, nachdem wir uns auf einen (Ober-)Product Owner geeinigt hatten, aber die Geldgeber stritten sich dauerhaft über den eigentlichen Sinn und Zweck des Projekts. Auch nach Einzelgesprächen und guten Argumentationen ließen sie sich nicht von der agilen Verfahrensweise und den inhaltlichen Schwerpunkten überzeugen, obwohl der Product Owner gut vorgearbeitet hatte. Sie bestanden auf ausführlichen Konzepten, die zunächst von allen abgesegnet werden sollten, bevor sie in die Entwicklung gehen. Als die ersten Konzepte dann vorlagen, war natürlich keine Einigung zu erzielen. In der Zwischenzeit beschäftigten sich die Entwickler mit „Dingen, die ohnehin getan werden müssen“, mit anderen Worten, sie waren von einer visionsgerichteten iterativen agilen Entwicklung weit entfernt. Der natürliche Weg wäre hier nun gewesen, die Entwickler aus dem Projekt zu entlassen, bis eine Einigung über den groben Funktionsumfang erzielt und ein Product Backlog erstellt wurde, das seinen Namen verdient. Die überwiegend externen Entwickler wurden aber behalten, weil man das Risiko nicht eingehen wollte, dass sie in einigen Monaten nicht mehr zur Verfügung stehen würden.
Da war dann für mich der Zeitpunkt gekommen, den agilen Ansatz in dieser Firma als gescheitert zu erklären. Es ist nun mal so – einige Firmen sind in ihrer Organisationsstruktur einfach nicht reif für agile Denkweisen. Das ist nichts Schlechtes, sondern einfach eine Tatsache. Das Gute daran ist allerdings, dass wir den Quadranten des schnellen Scheiterns getroffen haben. Wir haben recht schnell festgestellt, dass der eingeschlagene Weg der falsche ist und verhindert, dass 30 Entwickler monatelang entwickeln und sich erst am Ende herausstellt, dass die Geldgeber sich noch gar nicht darüber einig sind, was sie eigentlich wollen.
So gesehen hilft Scrum tatsächlich, schlecht aufgesetzte Projekte zu entlarven und zu beerdigen.
Hallo,
ein interessanter Artikel, der – wie mir scheint – den Nagel der Wirklichkeit (leider nur zu häufig) auf den Kopf trifft. Aus eigener Erfahrung kann ich von einem ähnlichen Projekt berichten, welches aber immerhin 9 (!) Jahre beim Kunden lief mit unterschiedlichen IT-Dienstleistern und welches dann just aus obigen Gründen Ende letzten Jahres abgebrochen wurde.
Über eine Sache habe ich mich allerdings gewundert: Sie schreiben, dass es zu Beginn des Projekts nur ein spärlich gefülltes Backlog und viele POs gab, die sich untereinander uneinig waren. Zudem war das Projekt hauptsächlich technisch und nicht fachlich motiviert.
Ehrlich gesagt, klingeln bei der Schilderung dieser Umstände bei mir alle Alarmglocken.
Bevor dieses Projekt mit Entwicklern an Bord überhaupt starten sollte, ist m. E. doch zunächst eine intensive Beratungsphase vonnöten. Als Berater arbeiten wir doch _für_ den Kunden und das bedeutet m. E., dass für das Management der Geschäftswert des Projekts klar und deutlich in Heller und Pfennig zu erkennen sein muss. Erst wenn der geklärt ist, kann man sich mit den POs hinsetzen und gemeinsam eine Vision erarbeiten. Diese muss natürlich von allen mitgetragen werden. Wenn es da immer wieder „Querschiesser“ gibt, dann müssen die entweder glaubhaft darlegen, weswegen ihrer Meinung nach bestimmte Dinge anders gemacht werden sollten und man einigt sich dann darauf oder sie müssen sich der Mehrheit beugen. Wie sollen denn später die Entwickler mit konfligierenden Anforderungen umgehen? Dadurch kommt das ganze Projekt nur in Verzug und die Entwickler werden nur noch mehr gefrustet sein.
Wenn sich dann alle geeinigt haben und sich das Backlog beginnt mit vernünftigen Stories zu füllen, _dann_ kommt doch erst die Phase des Entwickelns. Selbstredend macht es Sinn, die Entwicklermannschaft schon vorher an Bord zu haben, so dass die sich mit der Umgebung und mit der „Fachlichkeit“ bereits vertraut machen können.
Mir schienen die Entwickler in diesem Projekt allerdings deutlich zu früh an Bord gegangen zu sein, kann das sein?
Sollten sich die POs nun überhaupt nicht einigen können und so das Projekt permanent torpedieren, dann fände ich es richtig, wenn man als Dienstleister den ThoughtWorks-Weg einschlägt und sagt „Wenn ihr euch nicht einigen könnt, dann gehen wir. Das sind wir dem Projekt und uns schuldig. Wir wollen ein Projekt zum Erfolg führen und sind hier nicht einzig und allein des Geldes wegen.“
Es stimmt mich sehr nachdenklich, wenn Sie schreiben, dass selbst eine offensichtlich „harmlose Aktion“ wie Aufnahme von Anforderungen auf extremen Widerstand stösst. Hier gibt es anscheinend firmeninterne Querelen, die durch das Projektvorhaben in der Vergangenheit ausgelöst worden sind – vielleicht schon früher latent vorhanden waren, ich weiß es nicht. Möglicherweise verlieren Fachbereiche durch die Etablierung dieses Projekts Einfluß und Macht. Dann ist es kein Wunder, dass die etwas gegen dieses Projekt haben. Das sind aber Aufgaben, die muss das Management klären und ggf. mit Beratungshilfe lösen.
Ich glaube, Scrum kann nur dann wirklich befriedigend für alle Projektbeteiligten funktionieren, wenn alle am selben Strang ziehen. M. E. kann man die oben geschilderten Probleme mit Scrum nicht lösen. Scrum ist perfekt, aber zu einem späteren Zeitpunkt.
Hallo,
vielen Dank für den ausführlichen Kommentar!
Alle Ihre Anmerkungen sind wichtig und richtig. Das Projekt lief schon, als ich hinzustieß. Der vorige Projektleiter war klassisch aufgestellt, deshalb gab es auch kein ordentliches Backlog. Meine erste Reaktion war natürlich tatsächlich sofort, die Entwicklung einzustellen, bis die fachlichen Anforderungen klar sind, das wurde aber aus politischen Gründen angelehnt.
Und natürlich habe ich alle erkannten Probleme sofort offen und ehrlich angesprochen, aber die problematische Struktur um das Projekt herum konnte ich nur bedingt beeinflussen.
Und so bin ich dann am Ende tatsächlich freiwillig gegangen, nicht ohne den Kunden über die Gründe ausführlich aufzuklären. Wenn sich die Auftraggeber (man beachte den Plural!) aus politischen Gründen nicht einigen können oder wollen, sollte immerhin nicht das Projekt darunter leiden müssen.