Controller Magazin 6/2019

19 Elemente – Gruppen, Rollen, Hierarchien und Richtlinien oder allgemeiner das Organisations- system nicht geändert haben, werden sich Ver- halten und Denkweise nicht ändern.“ 1 In der Übergangszeit von klassisch auf agil gibt es ne- beneinander in den Unternehmen beide „Welt- anschauungen“ in Paralleldimensionen. „Con- ways Law“ kann zu Reibungsverlusten führen 12 , insbesondere, wenn in den Führungsetagen ein Generationenwechsel ansteht. Eine Kultur der Offenheit und Unvoreingenommenheit ist hier unumgänglich. Ich hoffe, in diesem Artikel konnten wir einige Gedankengänge bereitstellen, denen Sie für Ihre Projekte nachgehen und die Sie überprüfen und anpassen können, unabhängig davon, ob Sie bereits Scrum, Kanban oder Scrum mit Kanban, usw. verwenden, oder ob Sie gerade erst agil beginnen oder ein klassisches Projekt durchführen wollen. Am Ende zählt nur der ROI. Fußnoten 1 http://www.spiegel.de/politik/deutschland/ gorch-fock-warum-die-kosten-fuer-die-renovie- rung-so-explodierten-a-1247801.html 2 https://www.standishgroup.com/sample_re- search_files/CHAOSReport2015-Final.pdf 3 https://www.gpm-ipma.de/fileadmin/user_ upload/GPM/Know-How/Studie_Status_Quo_ Agile_2017.pdf; 4 https://www.koelsch-woerterbuch.de/das- koelsche-grundgesetz 5 Boehm, B (1981). Software Engineering Eco- nomics, Prentice-Hall 6 https://www.swr.de/swraktuell/baden-wuert- temberg/Hintergrund-Chronologie-der-Kosten- Explosion-bei-S21,chr onologie-kosten-stuttgart- 21-100.html 7 https://www.focus.de/regional/duesseldorf/ duesseldorf-neue-stadtbahn-zu-breit-fuer-duis­ burger-u-bahntunnel-der-rheinbahn-super-gau-von-wedau_id_9719304.html 8 https://www.scrumguides.org/scrum-guide.html 9 https://agilemanifesto.org 10 https://www.agilealliance.org/what-is-hyb- rid-agile-anyway/ 11 https://www.craiglarman.com/wiki/index. php?title=Larman%27s_Laws_of_Organizati- onal_Behavior 12 https://de.wikipedia.org/wiki/Gesetz_von_ Conway Agilität als Ziel? Soll jetzt ein globales Change-Management al- les auf Agilität setzen? Glaubt man den teils missionarisch auftretenden Vertretern der agi- len Welt, ist die Antwort ein klares „Ja!“, glaubt man den Vertretern der klassischen Seite, ist die Antwort meist ein klares „Nein!“, eine dritte Seite verweist auf einen Mittelweg: „Hybrides Scrum 10 . Aber m. E. wäre ein „Es kommt darauf an!“ angebrachter, und im Vorfeld sollten die Umgebungsvariablen im Projekt berücksichtigt werden, z. B.: Kann ich als Firma (AG und/oder AN) überhaupt auf eine agile Vorgehensweise wechseln? Können mein Team und mein Mana­ gement das? Und agile Technik ist nicht das Ziel. Ziel ist es, mit den richtigen Techniken die richtigen Ge- schäftsergebnisse zu erreichen. So könnte der agile Ansatz als Framework bei komplexen Pro- jekten mit hohem Risikoprofil Sinn machen und ein plangesteuerter Wasserfall-Ansatz bei ein- facheren, überschaubaren Projektstrukturen. Eine ERP-Einführung in einem Handelsunter- nehmen ohne weitere Modifikationen, rein im Standard, sollte auch klassisch erfolgreich durchführbar sein. Ein agiler Ansatz könnte dann nur den benötigten Overhead gegenüber einem eingespielten „Wasserfall-Team“ vergrö- ßern. Zur besseren Übersicht sind die Vor- und Nachteile in Abbildung 7 gegenübergestellt. Letztendlich muss der Kunde entscheiden, wel- che Vorgehensweise er präferiert. Was mache ich dann, wenn der Kunde ein klassisches Pro- jekt haben will und ich nicht, oder umgekehrt? Lasse ich z. B. 5 Millionen Euro Umsatz laufen? Eine der größten Projektsünden sollte aber m. E. vermieden werden: „Water-Scrum“, ein „Projekt- Wolpertinger“: ein fest definiertes Werk zu ver- kaufen und es agil umsetzen zu wollen. Und we- sentlich für das Gelingen eines agilen Projektes ist der Agile Mindset: Ein „Klassischer Wolf“ im „Agilen Schafsfell“ bleibt ein „Klassischer Wolf“! In der „Transition-to-Agile“ könnte in der Über- gangszeit ein hybrider Ansatz den Teams und Managern helfen. Nicht jeder kann oder will über Nacht den agilen Wechsel schaffen. „Larman’s Laws of Organizational Behavior“ gilt auch in Projektmanagement- und Beratungs- gesellschaften: „Solange sich die strukturellen anlegen können, um sofort einen Auftrag zu erfassen.“ Die weniger wichtigen Stories ste- hen unten und sind nicht so fein aufgegliedert, dies geschieht erst dann, wenn sie für den nächsten oder übernächsten Sprint vorgese- hen sind. Die für den Product Owner wichtigs- ten Einträge stehen in der Reihenfolge ganz oben und werden vom Development Team als erstes in ihr Sprint Backlog (Arbeitsplan für ei- nen Sprint) gezogen (Pullprinzip) und mit tägli- cher Kontrolle durch das Entwicklungs-Team priorisiert produziert. Am Ende eines jeden Sprints steht für alle (in- klusive der Kunden) das „review“. Hier stellt das Development Team das produzierte funktions- fähige Inkrement vor, das im letzten Sprint erar- beitet wurde, integriert in den Sprintergebnis- sen der vorherigen Sprints. Der Product Owner stellt aufgrund der bisherigen Entwicklungsge- schwindigkeit und des Product Backlogs die Prognose für die nächsten Sprints und den Pro- jektfortschritt. Sprint-Backlog-Einträge, die nicht „Done“ sind, d. h. nicht den Qualitäts- und Abnahmekriterien entsprechen, wandern zu- rück ins Product Backlog, werden neu priori- siert oder verkleinert. Sie gehen also auf keinen Fall in das teilfertige Produkt ein. Das Team Das Team selbst ist nach scrumguides.org eine feste Einheit, und besteht aus folgenden Rollen: 8 · · Der Product Owner ist als einziger verant- wortlich für das Product Backlog und dessen Transparenz. Er ist die Schleuse, über die In- formationen der Stakeholder (Kunden, End User, Budgetverantwortliche, usw.) zum Team gelangen. Er behält den Kontakt zum Markt. · · Der Scrum Master ist zuständig für das Einhal- ten der Regeln, der Beseitigung externer „im- pediments“ (Hindernisse und Störungen), der Zusammenarbeit mit dem Management und der Förderung der Agilität im Unternehmen. Er unterstützt den Product Owner und erleichtert die Durchführung der Scrum Events. · · Das Development Team besteht aus mindes- tens 3 und höchstens 9 Mitgliedern. Es ist selbstorganisierend und crossfunctional und es ist absolut unabhängig zur Erreichung des Projektziels. CM November / Dezember 2019