Hi, herzlich willkommen in dieser Lektion, in der wir die bisher besprochenen Methoden und Frameworks noch einmal kurz repetieren und dann entscheiden, welche davon wir in den Folgekursen im Rahmen eines simulierten Projektablaufs vertiefen werden.

Wir haben in den letzten Lektionen gesehen, wie die gemeinsam betrachteten Projekt- und Prozessmanagement-Methoden miteinander harmonieren – und in der Praxis auch kombiniert angewendet werden können.

Lass uns die Kombination noch einmal von vorn rekapitulieren:

Wofür wird die Meilenstein-Trendanalyse verwendet?

Die Meilenstein-Trendanalyse finden wir in der Praxis der Softwareentwicklung auf jeden Fall in der Release-Planung, in der vom Release-Datum aus die zeitliche Planung

• des Exit-Gateway,
• des Build-Freeze,
• des Code-Freeze,
• des Release-Train,
• der Product Inkremente
• und der darin befindlichen Sprints gemacht wird.

Der Release Train Engineer braucht dabei eine immer aktuelle graphische Übersicht, ob alle Teams mit ihren Sprintinhalten und die nachfolgenden Tests sowie der Build- und Deploy-Prozess im Plan liegen, um bei einem Auseinanderdriften rechtzeitig korrigierend eingreifen zu können.

Wir finden Meilensteine aber auch bei Portfolio-getriebenen Projekten, bei denen das Management den Projektfortschritt zu fest vereinbarten Meilensteinen überprüft, um damit die Kosten-Nutzen-Rechnung zu aktualisieren oder das Projekt gegebenenfalls an sich inzwischen veränderte Rahmenbedingungen anzupassen. Brauchen wir also und wird in unseren Einkaufskorb eingepackt.

Wo wird die Wasserfallmethode eingesetzt?

Die Wasserfallmethode möchten wir ja wegen der behandelten Nachteile so weit wie möglich vermeiden. Wir wollen flexibel sein und schnell zu nutzbaren Ergebnissen kommen. Diese Schnelligkeit hat nur einen Nachteil: wenn das Datenmodell einer neuen Softwarelösung ebenfalls konstant überarbeitet und angepasst wird, dann muss auch der Großteil der darauf aufbauenden Arbeiten immer und immer wieder neu erledigt oder angepasst werden. Je weiter ein Projekt fortgeschritten ist, desto aufwendiger und teurer wird dieser konstante Neuanfang. Um diese Unwirtschaftlichkeit zu vermeiden, hat es sich in der Praxis durchgesetzt, etwas mehr planerischen Aufwand in die Definition des Datenmodells zu investieren und hier tatsächlich eine wasserfalltypische Arbeitsweise mit Grobkonzept, Feinkonzept und IT-Konzept auf Basis einer vorhergehenden Anforderungsermittlung anzuwenden. Die Abgrenzung zum kompletten Wasserfallmodell bildet hier die Art der Anforderungsermittlung, die sich ausschließlich auf die strategischen Ziele und die Entwicklung eines Grundmodells beschränkt und nicht auf die detaillierten Anforderungen aus den Fachbereichen eingeht. Das dabei entwickelte Datenmodell ist grundsätzlich mit den Fachbereichsleitern abgesprochen und für die weitere Verwendung relativ fix. Jedem Beteiligten ist bewusst, dass eine nachträgliche Veränderung des Datenmodells einen erheblichen Mehraufwand verursacht, der ein Projektbudget und die Zeitplanung mit Leichtigkeit sprengt. Natürlich wird ein Datenmodell im Verlauf eines Projekts, und auch danach im Laufe der Weiterentwicklung der Software, erweitert – aber bitte immer ohne große Umbauarbeiten der Basis, die in der Folge eine Bestandsdatenmigration notwendig machen würde. Denn die ist immer sehr aufwendig, damit teuer, ein großes Risiko für Bugs und damit mit Risiken für den Datenbestand und die weitere Nutzung der Softwarelösung behaftet. Es macht also wirklich Sinn, das Datenmodell mit etwas mehr planerischem Aufwand zu entwickeln und damit eine gut vorbereitete, mit dem Kunden abgeklärte und für die Entwickler nutzbare Grundlage zur Verfügung zu stellen. Brauchen wir also auch und wird damit in unseren Einkaufskorb gepackt.

Brauchen wir Agiles Projektmanagement?

Agiles Projektmanagement ist sowieso gesetzt, weil wir flexibel, effizient und schnell zu nutzbaren Ergebnissen kommen wollen. Natürlich könnten wir jetzt sagen, dass man über die Entscheidung ob agil oder durchgeplant diskutieren könnte. Und da gibt es auch verschiedene Meinungen und gute Argumente für beide Seiten. Im Bereich der Softwareentwicklung wiegen die Vorteile der Agilität, wie bereits in den Vorlektionen besprochen, einfach sehr schwer – und deshalb verkneife ich mir an diesem Punkt die Diskussion. Agiles Projektmanagement wird also auch in den Einkaufskorb gepackt.

Wofür wird die Kanban-Methode eingesetzt?

Die Aufgabenverfolgung mit Kanban-Boards ist in Großunternehmen so verbreitet, dass wir auch auf diese Methode nicht verzichten können – und ich persönlich auch nicht verzichten möchte. Zu groß wiegen mir die Vorteile dieses Pull-Konzepts, auch was die Übergabe von Aufgaben in andere Teams und das Real-Time-Monitoring durch das Management betrifft. Landet also auch in unserem Einkaufskorb.

Warum wird Scrum praktiziert?

Scrum, das nackte Scrum, Hardcore – ja, darüber lässt sich in der Tat vortrefflich streiten. Und ich widme diesem Thema deshalb auch noch eine extra Lektion. Aber verzichten können wir in der Softwareentwicklung darauf kaum, weil uns die Methode eine ganze Latte passender Werkzeuge und Events liefert. Und es ist nun einmal nicht ohne Grund die mit Abstand meistgenutzte Methode in der Softwareentwicklung. Sich davon abzukoppeln würde bedeuten, dass die Zusammenarbeit mit anderen Entwicklungsteams nicht mehr reibungslos wäre und auch neu einzubindende Teammitglieder nicht mehr so schnell in den Ablauf integriert werden könnten. Wir würden auch auf das konsequente Aufdecken von Schwächen und Fehlern verzichten, was ein Projekt doch sehr schwächen und zurückwerfen würde. Wir wären ohne Scrum nicht mehr wirklich wettbewerbsfähig. Also wird auch Scrum mit in den Einkaufskorb gelegt.

Wofür wird das Scaled Agile Framework (SAFe) eingesetzt?

SAFe erweitert agiles Projektmanagement mit Scrum und Kanban von der Teamebene auf die Strukturen eines Großunternehmens. SAFe nimmt dabei sowohl die Elemente von Scrum, als auch von Kanban auf. Und da wir uns hier mit Großprojekten in Großunternehmen beschäftigen, brauchen wir auch diesen Baustein ohne große Worte in unserem Einkaufskorb.

Wofür wird Lean Management eingesetzt?

Ach was kennen wir doch alle für tolle Projekte, bei denen hervorragende technische Lösungen entwickelt wurden – nur leider zu einem Aufwand und damit Preis, der nie und nimmer rentabel werden kann. Diese Selbstzwecke und Liebhabereien gilt es zu vermeiden, indem wir jedem Aufwand eine wirtschaftliche Betrachtung gegenüberstellen und bestehende Abläufe konstant auf Optimierungspotenzial überprüfen. Erst das macht uns im Projekt wettbewerbsfähig und damit auch profitabel. Und weil ohne Geld kein Projekt, legen wir auch das Lean Management in den Einkaufskorb.

Wofür wird Six Sigma eingesetzt?

Der zweite Hebel zur Wirtschaftlichkeit ist das Fehler- und Qualitätsmanagement. Damit beschäftigt sich Six Sigma. Um Six Sigma kommen wir in Großunternehmen aufgrund der hohen Verbreitung sowieso nicht herum. Die Methode ist sozusagen zwangsweise zu akzeptieren, deshalb packen wir auch die, wenn auch etwas widerwillig, in unseren Einkaufskorb.

Welche Methoden und Frameworks werden für Projekte in Großunternehmen eingesetzt?

Welch Wunder, wir haben tatsächlich alle behandelten Methoden und Frameworks eingepackt. Nun ja, ein Wunder ist es nicht unbedingt. Es sind die Hauptzutaten für ein erfolgreiches Softwareprojekt in Großunternehmen. Wir haben damit in den vorhergehenden Lektionen auch keine wertvolle Zeit vergeudet. Weitere Methoden und Frameworks gibt es schon, und interessant wären die sicherlich auch gewesen. Aber eben auch ein Stück Zeitverschwendung in einer Kursreihe, die sowieso schon sehr umfangreich ist.

Gibt es die eine perfekte Methode für Projekte in Großunternehmen?

Anfang des Kurses habe ich auf eine Erfahrung verwiesen, wie sich die Befürworter ihrer bevorzugten Methode teilweise Rede- und Argumentationsduelle liefern, wessen Methode denn jetzt die beste Lösung bietet – die natürlich immer zu 100% einzuhalten ist. Ich präsentiere Dir dagegen einen Mix von allem und möchte Dir in der Folge gerne zeigen, wie wir das Beste aus allem an der geeigneten Stelle nutzen. Und das geht halt nur, wenn Du (bitte verzeihe mir diesen Ausdruck) nicht nur Fachidiot für einen begrenzten Teilbereich bist. Was nützt mir ein isolierter Scrum-Spezialist, oder ein Kanban-Spezialist, oder ein Wasserfall-Spezialist, oder ein Lean-Spezialist, oder ein Six Sigma-Spezialist? Isoliert bieten sie mir nur für Teilbereiche spezieller Situationen Antworten. Packe ich sie aber alle zusammen, dann ist das nicht nur sehr teuer, sondern frisst mir unnötig Zeit, weil sie sich in Diskussionen verlieren, welche Vorgehensweise denn die für diese Situation passende wäre. Und eine Lösung habe ich dann noch immer nicht. Erfahrung schlägt hier dann doch jegliche Theorie, bzw. nutzt die Theorien im aktuellen Kontext. Dazu braucht es dann eben auch eine gewisse Grundkenntnis über alle in Frage kommenden Methoden. Und die haben wir in den letzten Lektionen grundsätzlich kennengelernt.

Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:

• wir haben uns alle bisher besprochenen Methoden und Frameworks noch einmal grob angeschaut,
• und dann überlegt, ob wir die im Verlauf eines Großprojekts in Großunternehmen brauchen.
• Wir haben letztendlich alle behandelten Methoden und Frameworks eingepackt und dabei bemerkt, dass wir in den vorherigen Lektionen keine Zeit verschwendet haben.
• Ich hoffe mit meiner Einstellung überzeugen zu können, dass Projekte immer individuell sind und deshalb die individuell geeignete Kombination aus den besprochenen Methoden und Frameworks den Projekterfolg maßgeblich beeinflusst.
• Wir sind uns darüber im Klaren, dass wir einige Methoden mögen und dringend haben wollen, einige brauchen und zumindest auf eine nicht verzichten können, weil wir im Großunternehmensumfeld nicht darum herumkommen.

In der folgenden Lektion möchte ich die Vor- und Nachteile von Scrum – vor allem dem nackten Hardcore Scrum – und die damit verbundene Zu- und Abneigung unter Teammitgliedern behandeln. Bis gleich also.