IVGM – Integriertes Vorgehensmodell

ISB AG hat ein neues, zeitgemäßes und an die aktuellen Herausforderungen angepasstes Projektvorgehensmodell entwickelt und eingeführt. Es ist in der Lage, sowohl die Aspekte klassischer wie auch agiler Projektabwicklung zu adressieren. In diesem Artikel möchten wir Ihnen die Motive für einen solchen Schritt und zwei grundlegende Bausteine des IVGM vorstellen. In späteren Artikeln werden wir weitere Elemente des IVGM vertiefen.

ISB AG führt seit nunmehr vier Jahrzehnten erfolgreich Projekte zur Erstellung, Pflege und Erweiterung individueller Software-Anwendungen für ein breites Spektrum an Kunden durch. Die heutigen Anforderungen sind dabei außerordentlich vielfältig:

Einerseits müssen wir mit einer rasanten technologischen Entwicklung Schritt halten und in diversen Projekten Neuland betreten; dazu erscheint der Einsatz agiler Verfahren auch aus Kundensicht definitiv sinnvoll, wenn nicht sogar notwendig. Typisch für agile Methodiken ist u.a. eine kurze Zeittaktung von Entwicklungs- und QS-Schritten. Man spricht von sog. Sprints mit einer Dauer zwischen ein und vier Wochen. Mancher Kunde ist allerdings aus Kapazitätsgründen nicht in der Lage, die notwendige intensive und kontinuierliche Zusammenarbeit mit einem agilen Team, das in so kurzer Zeittaktung arbeitet, zu gewährleisten. Andererseits wünscht ein signifikanter Anteil von Kunden explizit den Einsatz konventioneller phasen- und meilenstein-orientierter Management-Verfahren. Umfang, Dauer und Komplexität der Herausforderungen in unseren Projekten variieren zudem stark. Das Gleiche gilt für die Einbettung eines Projekts in kundenspezifische Organisationsstrukturen.

In jedem Fall muss die Erstellung der gewünschten Software-Anwendungen aber effizient und nach ökonomischen Gesichtspunkten erfolgen. Letztere führen in der Regel zu vertraglich fixierten Rahmenbedingungen (z.B. bzgl. Zeit und Budget), die die ISB AG als Auftragnehmerin einhalten muss. Unsere Erfahrung zeigt: Unabhängig von Details eines ggf. agilen Managementansatzes wollen unsere Kunden den zwischenzeitlich erreichten Projekt- und Qualitätsstatus als auch den Ressourcen- und Budgetverbrauch über ein systematisches Reporting verfolgen, um ggf. auch Einfluss auf die Projektentwicklung nehmen zu können. Dabei wird oft in definierten Phasen gedacht, die agile Verfahren per se aber nicht vorsehen.

Ein Unternehmen wie ISB AG muss deshalb mit seinen Verfahren zur Projektdurchführung gleich einen mehrfachen Spagat zwischen folgenden Ankerpunkten leisten:

• Betriebswirtschaftliche Effizienz bei der Erstellung von Gewerken, an die vom Kunden Leistungs- und Akzeptanzkriterien angelegt werden.
• Einsatz agiler Verfahren in der Software-Entwicklung in Kombination mit Rahmenbedingungen, die teils Elemente konventioneller Managementverfahren erfordern.
• Systematische Führung und Kontrolle des Entwicklungsfortschritts und der Qualität der neuen oder modifizierten Anwendungskomponenten.
• Kooperation mit dem Kunden in dem Maße und auf Zeitskalen, in dem bzw. auf denen er zur Projektdurchführung und vor allem zur Qualitätssicherung faktisch beitragen kann und will.

ISB AG hat in den letzten Jahren immense Erfahrung mit dem Einsatz agiler Verfahren in unterschiedlichen Abteilungen und Projekten gesammelt. Insgesamt sind wir heute der Meinung, dass agile Verfahren sich sehr bewährt haben – gerade dann, wenn neue Technologien eingesetzt werden müssen oder der Kunde die Struktur vorhandener Anwendungen ändern oder auf neue Architekturen umstellen will. Das agile Framework „Scrum“ hat sich zudem zu einem anerkannten Marktstandard, aber auch Ausbildungsstandard für Software-Entwickler entwickelt: Entwickler wünschen sich heute meist schon im Einstellungsgespräch ein agiles Umfeld, in dem Teams ihre Arbeit selbst organisieren.

Agile Prinzipien a la Scrum zu vertreten und sie in der Praxis bei der Entwicklung von Gewerken unter betriebswirtschaftlichen und vertraglichen Bedingungen auch umzusetzen, sind allerdings oft zwei verschiedene Paar Stiefel: So muss auch ein agiles Projektteam in die Lage versetzt werden, zielorientierte Selbstorganisation mit einem „Controlling“ der Einhaltung vertraglicher wie ökonomischer Rahmenbedingungen in Einklang zu bringen. Neben dem Kunden hat nicht zuletzt auch die Unternehmensführung der ISB AG hohe Ansprüche, was die Überprüfung und die Steuerung des Ressourcenverbrauchs in Relation zum Projektfortschritt anbelangt. Auch die Erkenntnis, dass Qualität durch einen kontinuierlich geführten Prozess unter frühzeitiger Kundenbeteiligung entsteht, reift paradoxerweise selbst in agilen Teams oft zu spät: Ein Team kann organisatorisch agil unterwegs sein und dennoch in ein risikobehaftetes Fahrwasser gelangen, wenn die Qualitätssicherung durch den Kunden (oft ungewollt) immer weiter oder gleich ganz ans Ende eines Projekts verschoben wird.

Unsere Erfahrung zeigt: Gerade in komplexen oder längerfristigen Projekten müssen gezielt zwischenzeitliche Interaktionspunkte mit dem Kunden vorgesehen werden. Das schließt neben der Qualitätskontrolle der jeweils erreichten Produktstände eine konsequente Fortschrittskontrolle, aber auch definierte Eskalationsverfahren ein.

Agile Modelle müssen an dieser Stelle erweitert werden – das liegt weniger an Scrum als vielmehr an Vertragsbedingungen, den Wünschen von Kunden oder deren begrenzter Mitwirkungskapazität. Ein sog. „Proxy-Product Owner“, d.h. ein Mitarbeiter der ISB AG, der Kundenansprüche im agilen Projekt vertritt, kann allein auf Dauer eine fehlende direkte fachliche Kooperation des Kunden mit dem Team und vor allem ein fehlendes kontinuierliches Qualitätsfeedback des Kunden nicht kompensieren.

Nun scheinen jedoch bereits die oben erwähnten Wörter „Kontrolle und Controlling“ mit agilen Grundprinzipien (u.a. der viel beschworenen Selbstorganisation) ein Stück weit in Konflikt zu stehen.

Das Thema angeblicher Widersprüche zwischen agilen Methodiken und konventionellen Steuerungs- und Controlling-Verfahren ist relativ alt. Eine Brücke wurde von Experten aber schon vor Jahren im sog. agilen „Release-Management“ erkannt – dieses sorgt für eine pragmatische, strategische Ausrichtung des agilen Handelns auf definierte Zwischenziele: Das agile Release-Management sieht eine Abfolge geplanter Zwischenstände des zu erzeugenden Produkts – und zugehöriger Software-Releases – auf deutlich längeren Zeitskalen als Sprints vor. Releases entsprechen im Projektverlauf Meilensteinen, an denen bislang fertig gestellte Komponenten des Endprodukts geprüft und einer funktionalen Qualitätssicherung durch den Kunden unterworfen werden können – parallel zu einer Feststellung des Arbeitsfortschritts und Ressourcenverbrauchs. Ein solches Release genügt immer dem Anspruch, dass die bereits entwickelten Komponenten zusammengehörige Funktionen oder Funktionsgruppen unterstützen, die vom Kunden anhand (begrenzter) fachlicher Szenarien getestet werden können.

Aber auch im Lager etablierter konventioneller ProjektmanagementFrameworks wurden in den letzten Jahren erhebliche Anstrengungen unternommen, agile Methodiken zu integrieren. Wir haben einen überzeugenden Ansatz in „Prince2 Agile®“ gefunden – hier wird ein pragmatischer, praxisorientierter Kompromiss zwischen Agilität, einem notwendigen Maß an Fortschrittskontrolle wie Steuerung und der Möglichkeit zum Tailoring erreicht. Ein Projekt wird dabei in Phasen unterteilt; diese werden dann mit der Auslieferung geplanter Releases verbunden, welche z.B. über agile Verfahren gemäß Scrum erzeugt werden.

Wir als Software-Entwicklungs- aber auch Beratungshaus verfolgen das Ziel, die genannten unterschiedlichen Ansprüche und Ansätze durch ein zeitgemäßes und einheitliches Rahmenwerk abzudecken,

• das einerseits einen einheitlichen Leitfaden darstellt, an dem sich Projektleiter, Mitarbeiterinnen und Mitarbeiter aber auch Kunden ausrichten können und
• das andererseits aber auch Möglichkeiten zu einer kunden- und projektspezifischen Anpassung der Projektverfahren gibt, ohne essentielle und übergreifende Grundelemente der Projektsteuerung aufzugeben.

Das IVGM greift dabei strukturelle Elemente auf, die „Prince2 Agile“ vorschlägt, und modifiziert diese. Verschiedene verbindliche „Prinzipien“ sorgen dafür, dass sämtliches Handeln auf den vom Kunden erwarteten Nutzen und damit primär auf die Qualität der Software ausgerichtet wird. Tailoring erlaubt, dass wir bestimmte Verfahren „passend“ zum Vorhaben wählen oder anpassen; wir betonen dabei klassische Steuerungselemente, wo erforderlich. Bzgl. der Verbindung von „Agilität“ und Controlling half uns die Tatsache, dass Agilität historisch vor allem mit dem Anspruch einer „Adaption an die Faktenlage“ verbunden ist. Adaptivität selbst verlangt somit ein Monitoring der Entwicklung eines Projekts und seiner Kenngrößen.

Um die angesprochenen Grundkonzepte besser zu verstehen, bemühen wir ein Analogon: Ein Projekt lässt sich mit einem Unterfangen vergleichen, bei dem auf dem Weg zu einem Ziel Unwägbarkeiten auftreten können, zu deren Meisterung man vor Ort und situationsgerecht (agile) Entscheidungen und Maßnahmen treffen muss. Ein Beispiel ist etwa eine längere Bergtour oder Fernwanderung, etwa eine Alpenüberquerung, auf einer bislang nicht erprobten Route mit Kletter- und Gletscherpassagen für erfahrene Bergwanderer. Die Route soll später kommerziell durch eine Agentur für geführte Erlebnisreisen vermarktet werden. Erprobt wird die neue Route mit einem Team, in dem sich unterschiedliche Leute um die Zelt- und Kletterausrüstung, andere wiederum um den Proviant, die Verpflegung und die Routenplanung kümmern. Man rechnet von vornherein damit, dass die eine oder andere Passage ggf. wegen des Wetters, Lawinengefahr, zu hohem Schwierigkeitsgrad und Risiko oder anderen Dingen geändert oder verlegt werden muss. Der ursprüngliche Zeitplan ist während der Tour sukzessive an die Bewältigung unerwarteter Hindernisse anzupassen, etc.. Für Notfälle wird regelmäßig mit einer „Zentrale“ (Bergwacht, Koordinationszentrum) kommuniziert, die Empfehlungen bzgl. der Wetterlage oder einer neuen Routenwahl geben, bei Bedarf aber auch Rettungsfahrzeuge oder Proviant an definierte Standorte schicken kann.

Ein solches Vorhaben erfordert schon aus Motivationsgründen eine Ausrichtung auf Zwischenziele und entsprechende Etappen. Dort wird man die Ankunft mit der ursprünglichen Planung vergleichen und den Zustand des Teams, des Proviants etc. überprüfen. Ggf. wird man auch einen Abstieg, eine Verkürzung oder Verlegung der Gesamtroute erwägen. Die einzelnen Etappen erfordern je nach Gelände- und Wetterbedingungen taktische (= agile) Maßnahmen. Der Bergführer wird aus seiner Erfahrung aber regelmäßig den Blick auf das Gesamtziel (eine neue kundengerechte Route) richten und in Vergleich zu dem bisherigen Verlauf und den Fähigkeiten des Teams setzen. In Kooperation mit dem Routenplaner werden wetter- und risikobezogen Alternativen abgestimmt, der Proviant und Zustand des Equipments eingeschätzt, Kräfte eingeteilt und manchmal auch gezielt Ruhepausen eingeplant.

Die Zwischenziele, die erreicht werden sollen, entsprechen in einem Software-Projekt den diskutierten vorab geplanten Releases, die einen überprüfbaren, also testbaren Zwischenstand der Software-Anwendung mit (noch) begrenztem Leistungsumfang darstellen. Analog zur Tour wird das Projekt in Phasen unterteilt, die mit strategischen Zielen, nämlich den Releases, verbunden werden. Die täglichen, taktisch geplanten Touren des Teams entsprechen den Sprints eines agilen Projekts oder aber konventionellen Arbeitspaketen. Die Zentrale korrespondiert zu einem Lenkungsausschuss, ein erfahrener Bergführer zu einem Projektmanager und der Routenverantwortliche zum sog. „Product Owner“.

Und das zentrale Team besteht auch im Software-Projekt aus kooperierenden Personen, die ihre unterschiedlichen Fähigkeiten in die Entwicklung einbringen. Das Entwicklungsteam teilt sich seine tägliche Arbeit und Sprints zur Erstellung eines Releases selbst ein; es stellt sich an strategischen Punkten aber einer Gesamtwürdigung – auch durch den Kunden. Liegen wir im Plan, ist die erreichte Qualität hinreichend, müssen wir bestimmte vor uns liegende schwierige Abschnitte durch einfachere ersetzen, weil sie uns gemäß bisher gewonnener Erfahrungen zu viel Zeit kosten werden? Welche Alternativen sieht ein Lenkungsausschuss aufgrund der Berichte und wo kann er unterstützend eingreifen? Der Projektmanager wird hier seine Erfahrung einbringen, Lageberichte verfassen und im Ernstfall auch gegenüber einem Lenkungskreis eskalieren. Er tut dies aber auch unter Einbeziehung einer kontinuierlich erfolgenden und auch toolgestützten Selbsteinschätzung des Teams.

Unser Analogon macht plausibel, dass wir für eine Kombination aus taktischer Agilität und längerfristiger strategischer Steuerung eines komplexen Vorhabens mehrere Steuerungsebenen benötigen.

Unser IVGM sieht drei Steuerungsebenen für ein Projekt vor:

• Eine übergreifende, die vor allem das Gesamtziel des Projekts (den Kundennutzen) im Auge behält. Wir sehen hier typischerweise einen Lenkungskreis am Werk.
• Eine strategische Steuerungsebene, die vorab vor allem Phasen und definierte Zwischenziele, also Releases, in den Fokus nimmt. Hier engagiert sich ein Projektmanager. Dieser kooperiert eng mit einem „Product Owner“, welcher die funktionalen Produkteigenschaften, Produktkomponenten und deren Qualität im Blick hat. Die strategische Steuerung arbeitet auf die Auslieferung zwischenzeitlicher Releases an den Kunden zur Qualitätssicherung hin.
• Eine taktische Ebene, die sich um die Organisation der täglichen Entwicklungsarbeit zur Erreichung der Zwischenziele kümmert. Hier organisiert sich ein Team in Kooperation mit einem Product Owner und einem erfahrenen Software-Architekten. Es wirkt intensiv an der Definition und Planung zur Erreichung der Zwischenziele und zugehörigen Produkt-Releases mit. Die Entwicklungsarbeit kann – so sinnvoll und möglich – durch den zyklischen Scrum-Prozess gesteuert werden.

Ein Eckpfeiler der Entwicklungsarbeit und damit des gesamten Vorgehensmodells ist die Festlegung der Zwischenziele – also der Produktstände, die einem Test durch den Kunden zugeführt werden sollen. Dies erfordert eine Analyse und Planung, die auf die Umsetzung geeigneter funktionaler Komponenten ausgerichtet ist (Komponentenschnitt). Das gewünschte Software-Produkt wird letztlich in wohldefinierten Schritten erzeugt, bei denen fachlich-funktional testbare Zwischenstände der Software entstehen und der Leistungsumfang immer weiter anwächst. Das entspricht dem Prinzip eines schrittweisen, sog. inkrementellen Vorgehens – in Scrum auf der Sprint-Ebene, im IVGM aber vor allem auch auf der Release-Ebene. Wir binden den Kunden in qualitätssichernde Maßnahmen zu den Releases ein. Im IVGM stellt sich das Team also gezielt und schon während des Projektverlaufs dem Qualitätsurteil des Auftraggebers – auf einer für den Kunden verträglichen Zeitskala. Die Vorteile für beide Seiten liegen auf der Hand.

Wir hoffen, wir haben Sie ein wenig neugierig gemacht. Im nächsten Artikel zum IVGM werden wir das Thema zentraler Prozesse sowie der agilen Release- und Projekt-Planung ein wenig genauer unter die Lupe nehmen. In späteren Artikeln gehen wir auch auf die Rollen genauer ein – im Besonderen auf die des Projektmanagers, die „Agilisten“ sicher mit kritischen Augen sehen.