Der Artikel ist eine Einführung in das Thema Agile-Projektmanagement. Hier finden Sie die Grundprinzipien, Methoden, Verantwortlichkeiten und Tipps aus der Praxis.
Inhaltsverzeichnis
Für wen ist dieser Artikel?
| Ziele des Artikels: | Einführung in das Thema: Agile-Projektmanagement |
| Artikelzielgruppe: | Interessenten aus Automotive-Umfeld, Projektmanagement-Interessenten |
| Sprache: | technisch und Automotive, mit vielen spezifischen Begriffen |
| Empfohlene Vorkenntnisse / Kommentare: | Agile-Projektmanagement Grundkenntnisse |
| Hilfsmittel: | Vokabular, *1) |
| Lesedauer: | ca. 25 Minuten |
*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.
Definition
Das Wort „Agile“ stammt aus dem Lateinischen und bedeutet so viel wie „beweglich“ oder „anpassungsfähig“. Daraus entstand die Definition:
Agile-Softwareentwicklung bezeichnet Ansätze im Softwareentwicklungsprozess, die die Transparenz und Veränderungsgeschwindigkeit erhöhen und zu einem schnelleren Einsatz des entwickelten Systems führen sollen, um so Risiken und Fehlentwicklungen im Entwicklungsprozess zu minimieren. [1].
Die Theorie:
Die traditionellen Projektmanagementmethoden werden zunehmend mit Agile-Projektmanagementmethoden ersetzt, weil die „alten“ Methoden nicht so schnell auf die Änderungen im Entwicklungsumfeld reagieren können und an ihre Grenzen stoßen.
Die Agile-Methode konzentriert sich viel mehr auf die schnelle Anpassung an die ständig ändernden Projektgegebenheiten. Das Ziel ist, das Produkt schnell anzupassen, die Projektstakeholder und Teammitglieder auf dem Laufenden zu halten sowie die nötige Produktqualität zu liefern.
Ein Projekt, das klassisch abläuft, hat von Anfang an einen detaillierten Plan mit Projektphasen und Aufgaben, der über die Projektlaufzeit verfolgt wird. Falls es zu einer Änderung kommt, muss der Plan abgeändert werden, somit entstehen Aufwände.
Bei der agilen Vorgehensweise wird ein Projekt in kleinen Abschnitten geplant, mit vielen Iterationen (Sprints), die als Output ein kleines, fertiges Ergebnis dem Kunden liefern.
Damit stellt man sicher, dass die Projektstakeholder und das Team schnell auf die Anpassungen reagieren können und die nötigen Schritte während der Projektentwicklung möglichst schnell umsetzen. Es werden nur grobe Ziele für das Projekt definiert und die Details werden während des Projekts konkretisiert.
Der Kunde nimmt dabei unmittelbar teil am Projekt und liefert seinen Input schnell und auf einfache Weise. Der Kunde steht im Projekt im Mittelpunkt und kommuniziert mit dem Entwicklungsteam ständig und direkt.
Die regelmäßigen Runden helfen, die nötige Information zwischen dem Team und den Stakeholdern zu sammeln und die Rückmeldungen in die nächsten Sprints einzuplanen.
Bitte richten Sie Ihre Aufmerksamkeit auf die Vorgehensweise im agilen Projektmanagement: Das Agile-Projektmanagement versucht, den Dokumentationsaufwand eines Projekts zu reduzieren. Das ist das Gegenteil davon, was nach ISO 26262 [2] und ASPICE [3] verlangt wird. Hier ist die logische Kette von Konsequenzen: keine Dokumentation → keine Prozesse → kein ASPICE-Level → keine Zulassung des Produkts.
Geschichte des Agile-Projektmanagements
Auf der untenstehenden Abbildung sind die wichtigsten Meilensteine der Agile-Projektmanagement-Entwicklung erläutert.
Die Geschichte fängt in der Mitte der 1950er Jahre an, in denen die ersten formellen Ernennungen zu dieser Vorgehensweise stattgefunden haben.
In den 1990er Jahren hat man die ersten größeren Softwareprojekte mithilfe dieser Methode bewältigt.
Der große Durchbruch fand statt, als im Jahr 2001 mehrere bekannte Software-Entwickler aus den USA das sogenannte „Agile Manifesto“ [4] formuliert haben (siehe unten). Nach diesem Zeitpunkt wurde das agile Projektmanagement mehr und mehr in unterschiedlichen Projekten und Branchen eingesetzt.
Laut der Analyse [5] haben im Jahr 2015 79 % der Projekte die Scrum-Agile-Methode und 64 % die Continuous-Integration-Methode in Projekten verwendet.
Grundprinzipien des agilen Projektmanagements – “Agile Manifesto”
Im Jahr 2001 wurden die Werte und Grundprinzipien des Agile-Projektmanagements durch eine Gruppe von Softwareentwicklern festgelegt, das sogenannte „Agile Manifesto“. Diese Prinzipien werden in modernen Automotive-Projekten angewendet.
Leider wird die Methode in Automotive-Projekten meistens „zu direkt“ integriert und tatsächlich werden viele Dokumente aus dem Projektfokus weggelassen, was dazu führt, dass die wichtigen Anforderungen aus Standards und Normen nicht entsprechend umgesetzt sind.
Dazu gibt es mehr Informationen in den folgenden Kapiteln und in Lessons Learned.
Daher ist es zu empfehlen, beim Einführen des Agile-Projektmanagements die aktuellen Prozesse so anzupassen, dass der Projektfokus nicht verschwommen wird und die Anforderungen aus den Standards und Normen nicht vernachlässigt werden.
4 Werte des agilen Projektmanagements
Das “Agile Manifesto” basiert auf vier zentralen Werten:
Individuen und Interaktionen über Prozesse und Werkzeuge:
- Der Punkt besagt, dass der Schwerpunkt bei der Entwicklung auf die Menschen im Team gelegt wird. Es wird darauf geachtet, dass zwischen den Teammitgliedern und anderen Projekt-Stakeholdern die Kommunikation und Zusammenarbeit im Vordergrund stehen, dagegen nehmen Prozesse und Tools die zweite Rolle.
Funktionierende Software über umfassende Dokumentation:
- Auch wenn dies zunächst stark auf die Softwareentwicklung abzielt, lässt sich dieses Prinzip auch auf andere Bereiche übertragen. Der Fokus liegt darauf, dass man Ergebnisse liefert, die funktionieren. Man plant zwar weiter, aber die Priorität liegt auf dem, was tatsächlich nutzbar ist. Man möchte, dass das Team kontinuierlich vorzeigbare Ergebnisse liefert, statt sich in endlosen Planungen und Dokumentationen zu verlieren.
Hier bitte merken, dass dieser Ansatz nicht direkt im Automotive eingesetzt werden kann, da er den ASPICE- und ISO 26262-Methoden widerspricht.
Zusammenarbeit mit dem Kunden über Vertragsverhandlungen:
- In traditionellen Projekten sind die Beziehungen zu den Kunden oft durch starre Verträge und Vereinbarungen geregelt. Im agilen Projektmanagement achtet man jedoch darauf, dass die Kunden kontinuierlich in den Prozess eingebunden sind. Der Kunde wird als wichtiger Stakeholder gesehen, dessen Feedback kontinuierlich in das Projekt einfließt.
- Reagieren auf Veränderungen durch das Befolgen eines Plans: Anstatt sich an einen starren Plan zu halten, achtet man im agilen Projektmanagement darauf, flexibel zu bleiben. Veränderungen sind nicht nur eine Störung, sondern eine Chance, das Projekt zu verbessern.
Diese Punkte stellen die Interaktion zwischen Projektteilnehmern und den Stakeholdern in den Mittelpunkt. Damit versucht man die langen ziehenden Prozesse zu überwinden und schnell und auf einfache Weise auf die Veränderungen zu reagieren.
12 Prinzipien des Aglie-Projektmanagements
Neben den Werten gibt es noch zwölf Prinzipien, die das Agile-Projektmanagement auszeichnen.
In dem untenstehenden Diagramm erhalten Sie einen Überblick über die zwölf Prinzipien, und weiter unten findet man die Kommentare dazu.
Kundenzufriedenheit hat oberste Priorität
„Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software (bzw. Produkte) zur Verfügung zu stellen.“
Willkommen von Veränderungen
„Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Die Agile-Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.”
Lieferung von funktionierender Software
„Liefern Sie funktionierende Software (bzw. Produkte) regelmäßig, in einem Zeitraum von wenigen Wochen bis zu wenigen Monaten, mit einer Präferenz für die kürzere Zeitspanne.“
Fachspezialisten und Entwickler
„Fachleute und Entwickler müssen während des Projekts täglich zusammenarbeiten.“
Motivation und Unterstützung des Teams
„Schaffen Sie ein Umfeld, in dem motivierte Individuen arbeiten können. Geben Sie denen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Aufgabe erledigen.“
Direkte Kommunikation
„Die effizienteste und effektivste Methode, Informationen in einem Entwicklungsteam auszutauschen, ist persönliche Ansprache.“
Fortschritt durch funktionierende Software
„Funktionierende Software (bzw. Produkte) ist das primäre Maß für den Fortschritt.“
Nachhaltige Entwicklung
„Auftraggeber, Entwickler und Benutzer behalten ein gleichmäßiges Tempo auf unbegrenzte Zeit.“
Technische Exzellenz und gutes Design
„Hohe Aufmerksamkeit für technische Exzellenz und gutes Design fördert Agilität.“
Einfachheit
„Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.“
Selbstorganisierte Teams
„Die Teams organisieren sich selbst, für die besten Arbeitsergebnisse.“
Regelmäßige Reflexion und Anpassung
„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“
Agile-Methoden im Detail: Scrum, Kanban und Extreme Programming (XP)
Scrum: Struktur und Flexibilität
Scrum [6][7][8][10] ist eine der bekanntesten agilen Methoden und wird oft im Automotive-Bereich in Softwareprojekten eingesetzt. Als Erstes wird das Projekt in sogenannten Sprints geplant. Die Sprints dauern meistens eine, zwei oder vier Wochen und haben das Ziel, einen Teil der Produktsoftware an einen Kunden auszuliefern.
Nach einem Sprint werden die Arbeitsergebnisse analysiert und kritisch überprüft. Die Mängel werden für den nächsten Sprint eingeplant und umgesetzt.
Für Scrum definiert man im Projekt folgende Rollen:
- Product Owner: Er legt die Prioritäten für die umgesetzten Anforderungen im Product Backlog und legt somit die Umfang für die Auslieferungen fest
- Scrum Master: Er überprüft, dass das Team nach Scrum-Prinzipien arbeitet und versucht, die Hindernisse für die Teamarbeit zu beseitigen
- Entwicklungsteam: Das Entwicklungsteam arbeitet an der Implementierung des Arbeitsumfangs in einem Projekt
Die täglichen Stand-up-Meetings helfen den Teammitgliedern, eng zusammenzuarbeiten und den Projektfortschritt täglich abzugleichen
In den letzten Projekten habe ich diese Methode öfter als Softwarearchitekt erlebt und kann bestätigen, dass diese Methode unter bestimmten Umständen zum Erfolg führen kann.
Die wesentlichen Nachteile dieser Methode sind:
- meistens ist die Integration von Scrum nicht 100 % transparent, die Rollen sind nicht 100 % klar und Verantwortungsbereiche sind verschwommen
- häufiger wird die ASPICE-Dokumentation zusammen mit Anforderungen aus anderen Normen verdrängt und vergessen
Für die erfolgreiche und einfache Umsetzung von Scrum ist es aus meiner Sicht nötig::
- Die Prozesslücken möglichst schlüssig zu vervollständigen und zu schließen,
- im Auge behalten, dass es auch ASPICE, ISO 26262, Cyber Security ISO/SAE 21434 [9] und andere Standards und Normen gibt, die eigene Anforderungen zum Umsetzen haben
- Meistens ist das Projekt in führenden Rollen unterbesetzt (man hat eine falsche Vorstellung, dass Product Owner, Scrum Master und Team sich selbst organisieren und „mal so“ komplexe, bisher nicht vorhandene Prozesse umsetzen können)
Kanban: Visualisierung und kontinuierliche Verbesserung
Eine weitere Methode, die in der Automobilindustrie häufig eingesetzt wird, ist Kanban. Kanban basiert auf der Idee, dass man die Arbeit und Arbeitsschritte visualisiert. Die Arbeitspakete werden in unterschiedlichen Blöcken dargestellt, sodass eine bestimmte Reife des Vorgangs gezeigt werden kann (z. B. „Backlog“, „In Progress“, „Implemented“, „Tested“, „Done“).
Als Erstes kommen die Arbeitspakete nach „Backlog“. Danach werden die Aufgaben von Teammitgliedern implementiert und sobald dieser Schritt fertig ist, ändert sich der Status eines Arbeitspaket auf „Implemented“. Dieses Arbeitspaket wird danach getestet und nach dem Test ändert sich der Status vom Arbeitspaket auf „Tested“. Abschließend werden die dazugehörigen Dokumente fertiggestellt und das Arbeitspaket ist somit für die Auslieferung an den Kunden fertig. Der Status des Elementes wechselt sich zu „Done“.
Dieses Prinzip erlaubt nicht mehr in festen Sprints zu arbeiten sondern kontinuierliche Fortschritte im Projekt zu erleben. Das Team sorgt dafür, dass es keine Engpässe im Arbeitsablauf gibt und bearbeitet die auf dem Kanban‑Board dargestellten Aufgaben.
Die Methode erlaubt es, die Flexibilität beizubehalten, und das Team weiß genau, welche Aufgaben zu erledigen sind. Auch werden die Ergebnisse aus den durchgeführten Retrospektiven analysiert. Ein Optimierungspotenzial wird erarbeitet und in die Entwicklung integriert.
In der Tat wird diese Methode auch bei modernen Projekten eingesetzt. Ich hatte in den vergangenen Jahren ein paar Projekte, die solche Vorgehensweise angewendet haben. In meiner Erfahrung ist diese Methode einfach und hat einige Vorteile, aber auch viele Nachteile (wie Scrum auch):
- Meistens ist die Integration von Kanban nicht 100 % transparent; die Rollen sind unklar; die Verantwortungsbereiche sind verschwommen,
- Öfter wird die ASPICE Dokumentation zusammen mit Anforderungen aus anderen Normen verdrängt und vergessen,
- Wenn es zum Showstopper kommt, wird die Aufgabe erst auf die Seite geschoben und man läuft die Gefahr, dass 1) das Arbeitspaket aus dem Fokus verloren wird und 2) dass damit zusammenhängende Aufgaben, welche in der Zukunft realisiert werden müssen, nachteilig beeinflusst werden
Es ist daher notwendig, die folgenden Maßnahmen durchzuführen:
- Die Prozessdokumente zu vervollständigen, damit alle Lücken geschlossen werden (siehe Nachteile oben)
- Die Meilensteine und begleitenden Dokumente sind so zu planen (das ist eine Rückkehr zum V-Model), dass wichtigste Arbeitspakete ausreichende Input-Information haben, damit diese Arbeitspakete rechtzeitig abgearbeitet werden können.
Extreme Programming (XP): Qualität durch technische Exzellenz
Extreme Programming (XP) ist eine agile Methode, die speziell für die Softwareentwicklung ausgelegt, aber im Automotive-Bereich nicht weitverbreitet ist. Hier wird besonders auf technische Exzellenz geachtet, um die Qualität der Arbeit stetig zu steigern. Die technische Exzellenz bedeutet, dass die Software nach der bestmöglichen Qualität entwickelt wird. Nachfolgend sind die Schlüsselwörter des Extreme Programming (XP) aufgeführt:
- Kontinuierliche Verbesserung des Codes
- Testgetriebene Entwicklung
- Einfaches Design
- Paarprogrammierung (2 Entwickler am gleichen Platz)
- Kollektive Code-Verantwortung (jeder im Team ist für den ganzen Code im Projekt verantwortlich)
- Kontinuierliche Integration
Wie schon aus dem letzten Absatz erkennbar ist, legt Extreme Programming (XP) einen großen Wert auf großen Wert auf ständige Verbesserung und hohe Codequalität. Die wesentlichen Schlüsselpunkte des Extreme Programming (XP) sind: Paarprogrammierung und Testgetriebene Entwicklung.
In der Automobilbranche ist diese Methode
(nach meiner Erfahrung) nicht weitverbreitet. Vor allem deswegen vermute ich, weil es einfach zu großer Aufwand ist, den vorhandenen und funktionierenden Code umzuprogrammieren, nur weil besser aussehender oder schnellerer Code entstehen soll. Eine solche Vorgehensweise wird bei aktueller Komplexität des Codes einen riesigen Mehraufwand bedeuten. Auch die Flexibilität, die das Modell bietet, deckt sich nicht mit ASPICE und ISO 26262-Vorgaben.
Wahl der richtigen Methode
Die Erfahrungen aus vielen Projekten der vergangenen Jahre haben gezeigt, dass es nicht wirklich auf die einzelne Methode ankommt, sondern eher auf die Bereitschaft des Managements und des Teams, sich anzupassen, sowie auf die nötige Vorbereitung vor dem Projektstart.
Es geht um die Integrationsreife der jeweiligen Methoden in der Prozesslandschaft. Schließlich geht es um Disziplin, damit die nötigen Prozesse umgesetzt werden können.
Die Rollen im agilen Projektmanagement (Scrum)
An dieser Stelle möchte ich die Scrum-Rollen kurz ansprechen. Die Scrum-Methode ist die meistverwendete Agile-Projektmanagementmethode im Automotive-Bereich. Im Rahmen dieses Dokuments möchten wir kurz die Rollen im Scrum ansprechen.
In Agile-Scrum-Projekten wird darauf geachtet, dass das Team und die Stakeholder gut und eng zusammenarbeiten und jeder seine spezifischen Verantwortlichkeiten kennt. Somit sorgt man dafür, dass die Arbeit effizient abläuft und Missverständnisse vermieden werden.
Product Owner: Stimme des Kunden
Der Product Owner ist die Schnittstelle zwischen dem Kunden und dem Projekt. Die Informationen, wie Implementierungswünsche und zeitliche Abläufe für die Auslieferungen zwischen Auftragsgeber und Projekt, fließen über den Product Owner. Der Product Owner ist auch dafür verantwortlich, dass die bestimmten Anforderungen zu den jeweiligen Zeitpunkten implementiert werden können (sollen).
Das Ziel von agilen Methoden ist, möglichst schnell die Arbeitsergebnisse in Form einer Auslieferung zu generieren und an einen Kunden auszuliefern.
Die Auslieferung soll einem Kunden einen bestimmten Mehrwert bieten. Damit das Vorgehen problemlos läuft, erstellt der Product Owner die Planung für die Aufgaben, die im Rahmen eines Sprints implementiert werden sollen. Er achtet darauf, dass die Sprint-Ergebnisse eingehalten werden und mit Projektzielen und Kundenerwartungen übereinstimmen. Somit spielt der Product Owner eine zentrale Rolle im Projekt und legt den Fahrplan für die Arbeitsergebnisse und Zeitpläne fest.
Scrum Master
Der Scrum Master ist nicht der Chef des Teams, sondern eine Art Coach mit der Rolle eines technischen Mentors. Er achtet darauf, dass das Team die Agile-Prinzipien befolgt und sorgt dafür, die Hindernisse während der Entwicklung möglichst schnell zu beheben. Des Weiteren übernimmt der Scrum Master eine Rolle des Moderators, der tägliche Meetings organisiert und durchführt.
Er achtet darauf, dass das Team kontinuierlich Verbesserungen Schritt für Schritt in die „täglichen Aufgaben“ integriert. Durch regelmäßig durchgeführte Retrospektiven wird erkannt, was in Prozessen für bessere Ergebnisse optimiert werden muss.
Das Entwicklungsteam
Das Team organisiert sich selbst und übernimmt die Verantwortung für die Implementierung des Arbeitsumfangs für einen Sprint.
Das Agile-Team ist disziplinübergreifend aufgestellt, damit Know-how zwischen einzelnen Disziplinen problemlos ausgetauscht werden kann.
Stakeholder
Im Agile-Projekt übernehmen die Stakeholder (Kunde, Management oder andere Abteilungen wie Qualitätsmanagement) die Rolle von projektmitwirkenden Einheiten, die die Projektarbeit beeinflussen und an dem Projekterfolg interessiert sind. Durch regelmäßige Meetings und Reviews wird Feedback über Arbeitsergebnisse gesammelt und an das Team weitergegeben.
Die externen Stakeholder (z. B. der Kunde) überwachen den Projektfortschritt und tragen zur weiteren Vorgehensweise bei.
In einem Agile-Projekt muss geachtet werden, dass die Kommunikation mit Stakeholdern klar definiert und transparent ist, damit die Arbeitsergebnisse den Kundenwünschen entsprechen.
Die Zusammenarbeit und Abstimmung im Team
Die Rollen in einem agilen Projekt sind nicht voneinander isoliert. Alle Projektbeteiligten einschließlich:
- Product Owner,
- Scrum Master,
- Entwicklungsteam,
- Stakeholder,
- Mitarbeiter von anderen Disziplinen
müssen eng miteinander zusammenarbeiten und kommunizieren. Die enge Zusammenarbeit ist das Schlüsselwort in Agile-Projekten.
Notwendig für das Agile-Projekt ist die Tatsache zu beachten, dass alle Rollen und Verantwortlichkeiten klar definiert sind und jeder Projektmitarbeiter seiner Aufgaben und Verantwortungen bewusst ist.
Agile-Projektmanagement in der Praxis
Herausforderungen bei der Einführung Agile-Methoden
Es wird öfter aus Projekten berichtet, dass die unternehmerische Kultur oft nicht ausreichend flexibel ist, um neue Trends in die Prozesse zu integrieren. Somit gehen meistens Aussagen in die Richtung, dass es für die Teams und Führungskräfte schwerfällt, sich vom herkömmlichen V-Modell zu trennen und auf das Agile-Projektmanagement zu wechseln.
Es wird behauptet, dass der kulturelle Wandel schwerfällt, weil man an die vorgeschriebenen Pläne und Projektumfänge gewöhnt ist.
Man ist auch gewohnt, die klaren Prozesse zu befolgen. Das Agile-Projektmanagement hat aber ganz andere Ideologien. Dort wird flexibel geplant und implementiert, somit wird eine gewisse Unsicherheit in ein Projekt gebracht. Es wird behauptet, dass das Problem darin besteht, dass es schwerfällt, die Kontrolle über das Team und das Projekt loszulassen.
1) Teams
Des Weiteren gibt es die Meinung, dass die Teams im Umfeld des Agile-Projektmanagements sich unsicher fühlen. Die Ursachen für die Unsicherheit interpretiert man aber meiner Meinung nach falsch.
Es wird erwartet, dass die Teams sich selbst organisieren. Man erwartet, dass die Teammitglieder sich proaktiv und eigenverantwortlich verhalten. Die Aufgaben werden entsprechend den Wünschen der Teammitglieder aufgeteilt und umgesetzt.
Es gibt die Aufgaben, die von jedem Teammitglied gerne und welche, die nicht gerne umgesetzt werden. Was regelmäßig mit diesen Aufgaben passiert, ist, dass diese Aufgaben beiseitegeschoben und gerne vergessen werden. Das Zwingen, diese Aufgabe an ein Teammitglied zuzuordnen, funktioniert nur teilweise und meistens nicht langfristig.
2) Management
Es fällt dem Projektmanagement schwer, die Kontrolle über das Team und Arbeitspakete zu übergeben und loszulassen. Man erwartet vom Projektmanagement eine Kulturwandlung, die in der strengen Hierarchie verankert ist.
In der Agile-Vorgehensweise wird vom Projektmanagement erwartet, dass es nicht jeden Schritt im Projekt überwachen muss, sondern sich darauf verlassen soll, dass das Team die Aufgaben selbstständig erledigen kann. Der Scrum Master soll die Vermittlungsrolle zwischen dem Projektmanagement und dem Team übernehmen.
3) Technische Herausforderungen
Eine der größten Herausforderungen im agilen Projektmanagement ist die konsistente technische Realisierung. Die Automotive-Projekte werden in einer hochkomplexen, infrastrukturellen Umgebung entwickelt. Diese Umgebung ist nicht so flexibel, dass sie sich mit einfachen Methoden auf Agile-Projektmanagement umstellen kann.
Es gibt viele definierte Prozesse und Abläufe, die nicht von heute auf morgen umgestellt werden können, ohne einen größeren Aufwand zu betreiben.
Meine Kommentare zu Herausforderungen im Agile-Projektmanagement
In diesem Abschnitt möchte ich ein paar Kommentare für die oben stehenden Punkte abgeben, da ich glaube, dass die Herausforderungen in agilen Projekten andere Gründe haben, als es häufiger berichtet wird.
Zum Punkt: 1) Widerstand in den Teams
Ein Team, das sich selbst organisieren soll, muss bestimmte Eigenschaften haben, die nicht immer selbstverständlich sind. Z. B. entstehen neue Teams mit Kollegen aus unterschiedlichen Firmen. In solchen Teams fehlt häufig der nötige Zusammenhalt.
Oder wenn ein Team in sehr engen Zeitvorgaben arbeiten muss, kann man nicht von Mitarbeitern verlangen, immer mehr Arbeitspakete zu bearbeiten.
Die Erfahrung besagt, dass die Teammitglieder oft unsicher sind, weil die Abläufe nicht transparent und klar sind. Im Team gibt es unterschiedliche Meinungen zu bestimmten Lösungswegen und Prozessen. Dies trägt dazu bei, dass unnötige Arbeitsschritte mehrmals durchgeführt werden. Die Entscheidungen, die früher beschlossen waren, werden kurzfristig rückgängig gemacht.
Zum Punkt: 2) Die Rolle des Managements
Das Loslassen von täglichen Tätigkeiten gelingt nur dann, wenn die Tätigkeiten durchgeführt werden und wenn der Kunde und das Management nicht täglich unterschiedliche Richtungen vorgeben.
Es gab häufig Situationen, in denen kurz vor der Softwareauslieferung ein Kunde klingelte und unbedingt für die Vorstandsfahrt neue Features im ECU wünschte. Das ist sehr verständlich, hilft aber dem Projekt nicht, schneller fertig zu werden.
Oder man kommt nicht mit der Implementierung nach voran, weil die nötige Dokumentation fehlt und es keine klaren Kommunikationskanäle und keine Verantwortlichen gibt, um die Information rechtzeitig zu bekommen.
In komplexeren Projekten können zwei Rollen – Product Owner und Scrum Master – nicht die Lösung für alle Herausforderungen sein. Alleinige Zuordnung von den Rollen trägt nicht automatisch zum Erfolg bei.
Zum Punkt: 3) Technische Herausforderungen
Hier kann man nur zustimmen und vielleicht noch ergänzen, da die Aufwände für die Prozessanpassung und nötigen Schulungen leicht übersehen werden.
Im Gegensatz dazu werden in vielen Projekten nicht die Prozesse ausführlich beschrieben – weil man an den Prozessen sparen möchte – sondern man verweist auf ASPICE und andere Normen. Das kann nur fehlschlagen, weil die Prozesse in jedem Projekt unterschiedlich sind und ASPICE die Vorgaben und nicht die Lösungswege beschreibt, die unterschiedlich gelöst werden können.
Zusammengefasst spielen meiner Meinung nach folgende Herausforderungen eine höhere Rolle:
- Oft werden die Prozesse eingeführt und verändert, ohne die Mitarbeiter zu informieren, ohne die Prozesse eindeutig zu beschreiben, in der Hoffnung, dass die Teams sich eigenständig organisieren. Meistens schlagen solche Aktionen fehl.
- Die nötigen Tätigkeiten im Bereich der Prozesse werden gerne vernachlässigt.
- Die Teams werden ins kalte Wasser geschmissen, anstatt schrittweise das Agile-Projektmanagement einzuführen.
- Bei Einführung des Agile-Projektmanagements werden die Tools nicht sorgfältig ausgewählt, sondern man nimmt das, was gerade angeboten wird – damit keine Toolbrüche entstehen, sollte man im Voraus eine Tool-Strategie planen.
Meine Erfahrung sagt, seit der Einführung des Agile-Projektmanagements in 2010er Jahren gab es kein einziges Projekt, welches „besser lief“ als das vorherige. Aber es muss keinen falschen Eindruck aus diesen Aussagen entstehen. Es muss nicht heißen, dass kein Projekt besser laufen kann. Ich sehe eher, dass die Schwierigkeiten von Agile-Vorgehensweise anderer Natur sind, wie es meistens behauptet wird. Ich zähle mich nicht zu Gegnern des Agile-Projektmanagements, mehr versuche ich, anderen Sichtpunkten zu geben, damit die Herausforderungen im Fokus bleiben.
Die Integration des Agile-Projektmanagements in die bestehenden Strukturen
In diesem Kapitel werden Ansätze beschrieben, wie das Agile-Projektmanagement im Automotive-Umfeld integriert werden kann.
Die Anpassungen auf der Prozessseite sowie technische Anpassungen und Ansätze für die Integration werden hier angesprochen.
Maßnahmen für die erfolgreiche Integration des Agile-Projektmanagements
Maßnahme Nr. 1 – Schrittweise Integration
Nach Möglichkeit sollte man die Einführung des Agile-Projektmanagements schrittweise einführen. Man könnte als erstes kleinere Projekte mit dieser Methode realisieren. Während der Entwicklungsphase sollte man sich auf die Klarstellung seitens der Prozesse festhalten und sich ständig verbessern. Sobald die Agile-Vorgehensweise in kleineren Projekten erfolgreich ist, lässt sie sich einfach in größeren Projekten anwenden.
Maßnahme Nr. 2 – Anpassung der Prozesse
Für das Agile-Projektmanagement relevanten Prozesse sollten vor Projektbeginn angepasst, überprüft und getestet werden. D. h., die geänderten Prozesse müssen realitätsnah sein und dem Team bekannt sein.
Maßnahme Nr. 3 – Schulungen
Die Teams sollten die Prozesse kennen und in den Prozessen geschult sein.
Maßnahme Nr. 4 – Mitwirken des Projektmanagements
Durch ständiges Feedback der Teams sollte das Projektmanagement eine Strategie ausarbeiten, wie die Umsetzungsprobleme und organisatorische Fragen effektiv gelöst werden können. Wie schon erwähnt wurde, kann sich nur ein eingespieltes Team selbstständig organisieren.
Maßnahme Nr. 5 – Infrastruktur und Tools
Die Tools sollen sorgfältig gewählt werden, da spätere Komplikationen mit zusätzlichen Toolkosten verbunden sein können. Auch die Strategie für die Toolanwendung darf nicht vernachlässigt werden. Diese Maßnahme bezieht sich auf Traceability (Nachverfolgbarkeit), Pflegeaufwand, Benutzerfreundlichkeit und wie die einzelnen Tools in die gesamte Toolkette integriert werden können.
Maßnahme Nr. 6 – Ganzes Team im Spiel
Die Integration vom Agile-Projektmanagement insbesondere in der Anfangsphase soll durch das gesamte Team zusammen mit dem Management der höheren Ebene unterstützt werden. Es sollen alle Teammitglieder in die Prozesse eingebunden sein. Und es darf die Entscheidungsfähigkeit bei Prozessänderungen in höheren Unternehmensetagen nicht fehlen.
Jedoch muss man sich immer im Klaren darüber sein, dass „reines“ Agile-Projektmanagement nicht für Automotive-Projekte geeignet ist, da die Besonderheiten der Branche, wie schon früher besprochen, viele Einschränkungen auf der Prozessseite bringen – insbesondere durch Vorgaben aus ASPICE, ISO 26262 und anderen Normen. Des Weiteren spielt hier die bereichsübergreifende Entwicklung mehrerer Disziplinen und die Fahrzeugarchitektur eine Rolle. Alles zusammen deutet darauf, dass die Arbeitsergebnisse nicht ohne Dokumentation auskommen können.
Als eine Lösung bietet sich eine Hybrid-Vorgehensweise für die Automotive-Entwicklung an. Das V‑Modell in Kombination mit Elementen des agilen Projektmanagements kann die oben genannte Herausforderung lösen.
Wenn Sie weitere Beratung im Bereich Agile-Projektmanagement benötigen:
Zukunft des Agile-Projektmanagements
Die Automotive-Branche entwickelt sich sehr rasant, und die Technologien werden komplexer. Speziell das autonome Fahren und die Digitalisierung von Fahrzeugfunktionen im ADAS-Bereich bringen für das Projektmanagement neue Herausforderungen.
Wenn man über die Entwicklung des Agile-Projektmanagements im Konsumbereich spricht, sehen die Möglichkeiten für mich eher positiv aus. Insbesondere bei Software-Projekten, die nicht sicherheitskritisch sind und in denen das Endprodukt (ohne Dokumentation) wichtig ist. Besonders gut sehe ich die Chancen für die Entwicklung der Web-Anwendungen, Apps für Smartphones, Games etc.
Wenn man aber über die Zukunft des Agile-Projektmanagements im Automotive-Bereich redet, sollte man retrospektiv die Vergangenheit und Aktualität in Betracht nehmen. Durch viele Herausforderungen hat das Agile-Projektmanagement im Automotive-Bereich noch keinen einfachen Weg gefunden, und es wird noch einige Zeit dauern, bis Agile-Projekte reibungslos durchlaufen werden können.
Quellenangaben:
- [1] Agile Softwareentwicklung (wiki)
- [2] ISO 26262-1:2018 Road vehicles — Functional safety
- [3] Automotive SPICE® Process Reference Model Process Assessment Model Version 4.0
- [4] The Agile Manifesto (agilemanifesto.org)
- [5] “Agile in Automotive – State of Practice”, by Kugler Maag CIE (2015)
- [6] “Scrum: The Art of Doing Twice the Work in Half the Time”, by Jeff Sutherland
- [7] Scrum Alliance (scrumalliance.org)
- [8] “A Brief History of the Agile Movement”, by Alistair Cockburn
- [9] ISO/SAE 21434:2021Road vehicles — Cybersecurity engineering
- [10] “Agile Project Management with Scrum”, by Ken Schwaber
Autor: Dipl.-Ing. Nachrichtentechnik (FH) Oleg Czaikowsky, den 31.03.2025