Die agile Denkungsart und HERMES 5.1

Inhaltsverzeichnis

Abkürzungsverzeichnis und Glossar

Abstract / Management Summary

1 Einleitung
1.1 Hinführung und Problemstellung
1.2 Frage- und Zielstellung
1.3 Abgrenzung
1.4 Relevanz
1.5 Aufbau der Arbeit

2 Theorie
2.1 Einleitung und Stand der Forschung
2.2 Der Begriff
2.3 Agile Werte, - Prinzipien und - Praktiken
2.4 HERMES
2.5 Lean Management
2.5.1 Begriff
2.5.2 Kategorien und Gestaltungsprinzipien des Lean Managements
2.5.2.1 Qualität
2.5.2.2 Raum und Zeit
2.5.2.3 Kosten
2.5.2.4 Muda
2.5.2.5 Wertschöpfung
2.5.2.6 Arbeit
2.5.2.7 Organisationskultur
2.5.2.8 Visuelles Management (VM)
2.6 Agile Softwareentwicklung
2.6.1 Lean Development (LD)
2.6.2 Extreme Programming (XP)
2.6.3 SCRUM
2.6.4 KANBAN
2.6.5 Weitere Quellen für agile Werte und Prinzipien

3 Das Vorgehen
3.1 Die Untersuchungskriterien
3.2 Die Operationalisierung
3.3 Die analytische Herangehensweise

4 Die Untersuchung
4.1 HERMES Werte und Prinzipien
4.2 Integration oder Verbindung?
4.3 HERMES und Agilität
4.4 Analyse des Szenarios IT-Individualentwicklung agil
4.4.1 Das Szenario «IT-Individualentwicklung agil»
4.4.2 Projektsteuerung und Projektführung
4.4.3 Eine Zwischenbilanz
4.4.4 Projektplanung
4.4.5 Anforderungen, Phasenkonzept und Änderungsmanagement
4.4.6 Testen und Risikomanagement
4.4.7 Organisationskultur und Rollen
4.5 Die Ergebnisse
4.6 Was bedeuten die Ergebnisse?
4.7 Lösungsansätze

5 Fazit und Ausblick

6 Quellenverzeichnis
6.1 Literatur
6.2 Internet

7 Verzeichnis der Darstellungen
7.1 Abbildungsverzeichnis
7.2 Tabellenverzeichnis

Eigenständigkeitserklärung

8 Anhang
8.1 Werte, Prinzipien, Praktiken des Lean Management
8.2 Werte, Prinzipien, Praktiken des Lean Development
8.3 Werte, Prinzipien, Praktiken von XP
8.4 Werte, Prinzipien, Praktiken aus dem agilen Manifest (AM)
8.5 Werte, Prinzipien, Praktiken in SCRUM (zusätzlich zum AM)
8.6 Werte, Prinzipien, Praktiken in KANBAN (und zusätzlichen Quellen)

Abkürzungsverzeichnis und Glossar

Tabelle 1: Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abstract / Management Summary

Die Verifikation bzw. Falsifikation der Hypothese, «beim Einsatz der agilen Projektmanage- mentmethode HERMES gibt es Verbesserungspotential in Bezug auf die Umsetzung der agi- len Denkungsart», teilt die Arbeit logisch in zwei annährend gleichgewichtige Teile. Zum einen die Herleitung und Definition der agilen Denkungsart, und zum anderen die Untersuchung der Projektmanagementmethode HERMES 5.1 in Bezug auf ihre agile Substanz.

Die Suche nach den Merkmalen, die die agile Denkungsart ausmachen, wird im Lean Manage- ment aufgenommen. Gemäss der Fachliteratur haben die heutigen agilen Softwareentwick- lungsmethoden dort ihren Ursprung. Das Lean Management seinerseits mit seinem Ansatz, unter Einsatz von immer weniger Ressourcen zum perfekten Produkt zu gelangen (Womack, 2007), geht auf die Entwicklung des Toyota-Produktionssystems nach dem zweiten Weltkrieg zurück und wurde, in Gestalt der «ganzheitlichen Produktionssysteme» (Dombrowski & Mielke, 2015) an europäische Verhältnisse angepasst, bis heute weiterentwickelt. Die Unter- suchung seiner Gestaltungsprinzipien führen zu einer für diese Arbeit gültigen Definition des Lean Management, bei der der durch den Kunden bestimmte «Wert» (im ökonomischen Sinne), die Kosteneffizienz und die auf intensiver Kommunikation basierte Arbeit in der Gruppe im Mittelpunkt stehen.

Die Darstellung der «Lean»-Gestaltungsprinzipien macht deren Prinzipien und Techniken ver- ständlich und zeigt durch die Zuordnung von Analogien aus der agilen Softwareentwicklung, dass diese berechtigterweise in die Definition der agilen Denkungsart eingehen.

Der Bogen zu den agilen Methoden wird über die Darstellung von Lean Development, XP, SCRUM und KANBAN gespannt. Das Exzerpt ihrer Werte und Prinzipien aus der Fachliteratur komplettiert den Wertekatalog der agilen Denkungsart und erlaubt nach dessen Konsolidie- rung die Vorlage einer Definition.

Diese gründet sich auf die Werte Kundenzufriedenheit, Mitarbeiterzufriedenheit, Exzellenz des Produkts und (agile) Organisationskultur. Sie wird ergänzt durch 11 Prinzipien, die teils tech- nischer Natur sind, vor allem aber den Umgang der Menschen untereinander in der Organisa- tion betreffen. Es wird gezeigt, dass die agile Denkungsart nicht nur einen Wechsel von plan- getriebenen zu adaptiven Methoden darstellt, sondern dass ihr ein verändertes Menschenbild zugrunde liegt.

Die Projektmanagementmethode des Bundes, ursprünglich auf die Bereiche Systementwick- lung und Systemadaption beschränkt, ist, gemäss ihren Autoren, seit der Version HERMES 5.1. (ab jetzt HERMES) für alle Projekttypen einsetzbar und hat durch Aufnahme zweier agilen Szenarien, die jeweils ein Modul «Entwicklung agil» auf SCRUM basierend enthalten, den Schritt zur Agilität gemacht.

Ihre agile Substanz wird mittels der agilen Denkungsart untersucht.

Da HERMES sich als nicht «wertegetrieben» herausstellt, wird die Untersuchung des Szena- rios «IT-Individualentwicklung agil» auf Ebene der Praktiken durchgeführt. Diese sind haupt- sächlich durch Aufgaben, Ergebnisse und Rollen bestimmt.

Die Untersuchung zeigt, dass HERMES durch seinen auf Kontrolle fokussierten Ansatz weit von der agilen Denkungsart entfernt ist. Das SCRUM-Team kommt erst in der Konzeptphase und als reines Entwicklungsteam zum Einsatz, das einzig die durch andere Mitarbeiter erstellte Systemarchitektur und Systemanforderungen in sog. Realisierungseinheiten in Programm- code umsetzt. Iterationen und inkrementelle «Reifung» des Produkts, die bei agilen Methoden den gesamten Entwicklungszyklus (von den Anforderungen über das Design und die Umset- zung zum Feedback) umfassen, bleiben in HERMES auf die Realisierungseinheiten be- schränkt. Agile Entwicklung in einem nicht-agilen Kontext kann es nicht geben. Eine fortbeste- hende Anpassungsfähigkeit des Produkts, ein Kerninhalt der Agilität, kann in dieser Weise nicht erreicht werden. Ausserdem wird nachgewiesen, dass HERMES durch die Trennung von Verantwortung und Ausführung und die Durchgängigkeit der hierarchischen Strukturen gegen die Prinzipien der selbstorganisierten Teams und ihrer intensiven Kommunikation durch Ver- netzung verstösst. Eine Organisation, die agil ist oder sich auf dem Weg dorthin befindet, würde HERMES nicht einsetzen.

Entsprechend kann die Hypothese dieser Arbeit verifiziert werden.

Mit HERMES 5.1 wurde nichts als eine «agile Fassade» aufgebaut, die, sollte der Anspruch auf Agilität fortbestehen, einem grundsätzlichen Neuausbau weichen müsste. Hierzu gehören Etablierung und Zusammenarbeit des SCRUM-Teams im Modus der Selbstorganisation von Projektbeginn an, die Zusammenlegung der Phasen (spätestens ab Konzept) in einem die Gesamtheit der Aufgaben betreffenden iterativen, inkrementellen Vorgehen mit schnellem Feedback. Hierdurch wären wesentliche Inhalte des agilen Mindset, wie Anpassungsfähigkeit, Selbstorganisation und die mit ihnen verbundene Werte und Prinzipien realisiert.

1 Einleitung

1.1 Hinführung und Problemstellung

Der Autor war während fast zweieinhalb Jahren als Projektleiter in einem Informatik-Programm des Bundes tätig, in dem als Projektführungsmethode HERMES 5.1, wie vom ISB für IKT- Vorhaben des Bundes vorgesehen, eingesetzt wurde. Mit Beginn der Realisierungsphase ei- nes Projekt-Clusters kam zusätzlich die «SAFe»-Methode zum Einsatz, wobei in Bezug auf Projektphasen und Lieferobjekte an HERMES festgehalten wurde. Nach Ansicht des Autors wurden die agilen Werte in diesem Programm nicht gelebt, doch dies ist hier nicht von Bedeu- tung. Interessant war die Kombination von HERMES mit einer agilen Methode, wie dies seit der HERMES Version 5.1 (2014), die zusätzlich zwei optionale agile Szenarien vorsieht, mög- lich ist. Allerdings birgt diese «out of the box» Agilität einige Fragestellungen in sich.

HERMES als Projektmanagementmethode wird unter den PM-Methoden dem sog. «Wasser- fall»-Modell zugerechnet, d.h. einem sequentiellen, phasenweisen Vorgehen vom Konzept über die Realisierung zur Einführung, und gehört damit zu den Modellen, die durch ihre Miss- erfolge, wie SCRUM-Autoren betonen (bspw. Schwaber & Sutherland, 2014, S.3ff.), dieses «auf den Plan» gerufen haben.

Mit Einführung der agilen Szenarien «IT-Individualentwicklung agil» und «Dienstleistung/ Pro- dukt agil», beide mit « […] agiler Steuerung der Entwicklung» (Mourgue d´Algue, Eicher, Kru- schitz, 2014, S.6) erhebt HERMES den Anspruch «Agiles Projektmanagement mit HERMES und SCRUM» (ibid., S.165) zu betreiben, d.h. in der Kombination HERMES und SCRUM zu den agilen Methoden gerechnet zu werden.

Steht ein traditionelles (sequentielles) Vorgehen nicht in krassem Gegensatz zum agilen Vor- gehen? Ist es, unter dem Aspekt Agilität, sinnvoll und zweckmässig, beide Vorgehens-«Philo- sophien» in einem Vorgehensmodell zu vereinen? Kann hierbei in der Folge überhaupt noch von Agilität gesprochen werden, oder werden lediglich die in SCRUM gängigen Begriffe, ohne von Kernpraktiken und Werten gestützt zu werden, übernommen und damit lediglich eine Art «Fassaden-SCRUM» aufgebaut (Maximini, 2013, S.6)?

Sind ein Variantenentscheid schon während der Initialisierung, die Vielzahl von Pflichtdoku- mentation, die Zuweisung von Arbeitspaketen über das Rollenkonzept, um nur einige Aspekte herauszugreifen, kompatibel mit den Schlüsselbegriffen der Agilität wie empirischem Prozess- modell und selbstorganisierten Teams? Und, um ein weiteres Schlüsselelement der Agilität zu nennen: Wie flexibel kann auf Änderungen reagiert werden?

Hier kommt ein weiteres Thema ins Blickfeld. Was ist eigentlich genau Agilität? Sie soll ihre Tradition im sog. Lean Management, genauer in den Toyota Produktionssystemen, haben.

Was hat dies mit Softwareentwicklung zu tun, die immer neu und kaum repetitiv ist? Und dann sei Agilität im Rahmen der Softwareentwicklung eher eine Haltung, eine persönliche Einstel- lung und nicht einfach eine Methode, Software zu produzieren? Wie passen diese Dinge zu- sammen?

Die Fragestellung wird im nächsten Abschnitt präzisiert.

1.2 Frage- und Zielstellung

Eine Zielsetzung diese Arbeit ist es, herauszufinden, ob die Projektmanagement Methode HERMES, mit ihrer Ergänzung durch agile Szenarien, die Anforderungen, die an ein agiles Vorgehen gestellt werden, erfüllt. Basis für die Beurteilung dieser Anforderungen ist die agile Denkungsart, ein Mindset, das bestimmte Werte und Prinzipien beinhaltet, aus dem die agilen Praktiken abgeleitet werden. Die Herleitung und Definition dieser Denkungsart ist die zweite Zielsetzung dieser Arbeit.

Die Hypothese lautet:

Beim Einsatz der agilen Projektmanagementmethode HERMES gibt es Verbesserungspoten- tial in Bezug auf die Umsetzung der agilen Denkungsart.

Ausgehend von der Tatsache, dass HERMES lediglich zwei Szenarien, die beide auch in «nicht-agiler» Form vorliegen, in die ansonsten unverändert belassene Projektführungsme- thode einfügt, geht der Autor davon aus, dass HERMES in dieser Form nicht als agile Methode gelten kann. Die Autoren des HERMES Referenzhandbuchs konstatieren selbst, dass HER- MES und SCRUM bezüglich der Führung des Teams «ein grundsätzlich unterschiedliches Verständnis» aufweisen (Mourgue d´Algue et al., 2014, S.168). Es existieren Konflikte zwi- schen den Modellen und es wird im Folgenden zu untersuchen sein, ob und wie die Autoren diese gelöst haben.

Die Zielstellung als Frage formuliert lautet:

Gibt es beim Einsatz der agilen Projektmanagementmethode HERMES Verbesserungspoten- tial in Bezug auf die Umsetzung der agilen Denkungsart?

Aus dieser Fragestellung lassen sich weitere ableiten:

- Was sind agile Werte, was agile Prinzipien?
- Aus welchen Bereichen leiten sich diese ab?
- Wie kann «Agilität» definiert werden und was macht das Wesen der agilen Denkungs- art aus?
- Wie wird diese in die Praxis umgesetzt?
- Welche Werte und Prinzipien vertritt HERMES agil?
- Wie wird die agile Denkungsart in HERMES agil umgesetzt?
- Existieren Konflikte zwischen der agilen Denkungsart und HERMES agil?
- Falls diese existieren, wie können sie gelöst werden?

Kann obige Hypothese im Rahmen dieser Arbeit verifiziert werden, erarbeitet der Autor Emp- fehlungen, wie die Agilität von HERMES verbessert werden könnte.

Diese Arbeit basiert auf der vorhandenen Fachliteratur. Werte, Prinzipien und Praktiken der Agilität als Untersuchungskriterien werden, wie die Werte, Prinzipien und Praktiken von HER- MES agil, von dort her abgeleitet, eine darüberhinausgehende Datenerhebung findet nicht statt.

1.3 Abgrenzung

Die Fragestellung bezieht sich ausschliesslich auf die Projektführungsmethode HERMES in der Version 5.1, da hier die beiden agilen Szenarien eingeführt wurden.

HERMES agil (von nun ab nur HERMES) kennt zwei agile Szenarien: «IT-Individualentwick- lung agil» und «Dienstleistung/ Produkt agil», jeweils mit agiler Steuerung der Entwicklung. Untersucht wird ausschliesslich das erst genannte Szenario.

Eine Diskussion der einzelnen Werte und Prinzipien im Sinne einer Kritik oder Bewertung kann im begrenzten Rahmen dieser Arbeit nur ansatzweise geleistet werden.

Vorgehensmodelltypen, wie das «Wasserfall»-Modell oder das V-Modell, werden weder un- tereinander, noch werden Anwendungsmöglichkeiten oder Anleitungen zur Ausführung dieser Modelle im Gegensatz zu agilen Methoden dargestellt. In gleicher Weise werden auch die verschiedenen agilen Methoden (wie SCRUM oder KANBAN) weder untereinander verglichen noch bewertet.

Als Annahme gilt, dass die Autoren von HERMES die agilen Szenarien eingearbeitet haben, weil sie mit dieser zusätzlichen Komponente die Wahrscheinlichkeit eines Projekterfolges beim Einsatz von HERMES vergrössern wollten. Dieser Ansatz entspricht dem der «Begründer» der agilen Softwareentwicklung und soll nicht in Frage gestellt werden. Auch werden keine Krite- rien für einen Einsatz der einen oder anderen Methode erarbeitet. Dies wurde in genereller Form bereits durch die agile Fachliteratur oder in spezifischen Untersuchungen anhand von Praxisbeispielen, vorwiegend von Autoren aus dem universitären Bereich, geleistet (bspw. Dippon, 2015).

Einführungsszenarien von agilen Methoden in Organisationen werden nicht behandelt. Kombinierte Ansätze agiler Methoden wie «SCRUMBAN» werden nicht thematisiert.

Diese Arbeit behandelt wesentlich die agilen Werte (und nicht die Methoden) und wendet diese auf den Untersuchungsgegenstand an.

Die wichtigsten Begriffe und Aspekte des Projektmanagements und der Softwareentwicklung werden als bekannt vorausgesetzt und weder erläutert noch diskutiert.

1.4 Relevanz

Gemäss den Literarturrecherchen des Autors ist das Thema HERMES und Agilität bisher nicht in der hier angestrebten Tiefe behandelt worden. Die existierenden Arbeiten befassen sich einerseits eher mit technischen Aspekten, wie der agilen Anforderungserstellung (Schär, 2015), oder der Projektsteuerung bei kombiniertem Methodeneinsatz (Bachmann, 2011), an- dererseits werden dort lediglich Teilaspekte des agilen (Werte-) Konzepts betrachtet.

Der Nutzen dieser Arbeit für die Praxis ergibt sich zum einen aus dem möglichen Verbesse- rungspotential. Sollte ein solches erkannt werden, wird dies die Definition von Massnahmen, d.h. konkreten Vorschlägen in Bezug darauf, wie die Agilität entsprechend gesteigert werden kann, nach sich ziehen. Akzeptiert man die direkte Proportionalität von Agilität und Projekter- folg aus der Fachliteratur für komplexe Projekte, d.h. für Projekte mit unklaren Anforderungen und unsicherer Technologie (Schwaber & Sutherland, 2014, S.11), würde die Erfolgsquote von HERMES-Anwendern gesteigert werden können. Dies führte zu direkten Einsparungen der öffentlichen Hand. Ausserdem haben agile Ansätze direkte Auswirkungen auf die Organisati- onen selbst (Nowotny, 2017, S.327f.), die insgesamt von einer gesteigerten Mitarbeiterzufrie- denheit und Produktivität profitieren könnten.

Viele nutzen den Begriff «Agilität», wenige, wie sich beispielsweise aus Diskussionsbeiträgen in der Fachzeitschrift «Projekt Magazin» (Ausgabe 05/17) erkennen lässt, verstehen das Glei- che darunter. In der beispielhaft angeführten Diskussion geht es darum, dass bestimmte PM- Techniken wie Planung den «nicht-agilen» PM Methoden zugeordnet werden. Andere vertre- ten den Standpunkt, dass Planung mit dem «agilen Mindset» durchaus in Einklang stünde, allerdings würde anders geplant, da das agile Mindset ein anderes Menschenbild beinhalte. Agilität könnte demnach nicht nur Paradigmenwechsel, sondern auch ein umfassender intel- lektueller und emotionaler Ansatz sein.

Aus Sicht der Forschung wird der Versuch unternommen, die agile Denkungsart durch das Herausarbeiten von Werten und Prinzipien (und nicht Arbeitsanweisungen, wie sie selbst im agilen Manifest teilweise daherkommen) darzustellen und somit, über die Ansätze technischer Definitionen hinaus, eine das Wesen der «Agilität» erfassende Einordnung und Definition des Begriffs zu liefern. Hieraus könnten sich, über das Mindset, Ansätze für eine Veränderung in Bezug auf Dynamik und Offenheit, auch für eher stark reglementierte Organisationen ergeben.

Hinweis: Die Begriffe «Mindset» und «Denkungsart» werden in dieser Arbeit synonym verwen- det. Der erste Begriff ist moderner, der Autor zieht allerdings den letzteren wegen der im Deut- schen damit verbundenen Konnotationen vor.

In der Literatur zur agilen Softwareentwicklung wird häufig auf deren Wurzeln im Lean Ma- nagement (LM) hingewiesen. Diese werden allerdings, abgesehen von der Zuordnung von SCRUM Praktiken (Gloger, 2006) zu den Toyota Managementprinzipien (Liker, 2004), nie im Detail hergeleitet. Auch Mary & Tom Poppendieck zeigen in ihren Büchern (2003; 2014) die Ursprünge ihrer «Lean Software Development» Methode im LM auf, die jedoch für den nicht mit «Lean Manufacturing» vertrauten Leser schwer nachvollziehbar bleiben. Befasst man sich hingegen mit den «Lean» Pionieren wie Takeuchi, Nonaka und Ohno, sowie später Womack und Liker (als deren «Chronisten») und den Gestaltungsprinzipien des LM, wird klar, dass diese direkt in den agilen Softwareentwicklungsmethoden aufgehen. Die Kontinuität von «Lean» zu «Agil» bis in die heutige agile Denkungsart wird in dieser Arbeit greifbar gemacht.

1.5 Aufbau der Arbeit

Im ersten Teil wird aufgezeigt wie unklar der Begriff «Agilität» bisher in der Fachliteratur ge- fasst wird. Zwar gibt es im Bereich der agilen Softwareentwicklung ein weites Feld von Hand- lungsanweisungen, die alle für sich genommen «agil» sein sollen, oder zumindest doch in irgendeiner Weise zur «Agilität» gehören wollen, der Begriff als Eigenschaft «etwas ist agil» wird dabei nicht definiert. Existieren Definitionen, so sind sie technisch geprägt.

Entsprechend wird der Begriff, ausgehend von seinem Ursprung im Lean-Management, her- geleitet und von dort der Bogen zur agilen Softwareentwicklung gespannt. Aus der Fachlitera- tur werden die strukturbildenden Werte und Prinzipien der «Lean-» und «Agil-» Ansätze extra- hiert und jeweils in einem «Wertekatalog» zusammengestellt.

Im agilen Bereich werden hierzu gängige Methoden der Softwareentwicklung, Lean Develop- ment (LD) als Brücke zwischen «Lean« und «Agil», «Extreme Programming» (XP), KANBAN und, als meist verbreiteter Vertreter dieser Gruppe, SCRUM, untersucht.

Die agilen Werte und Prinzipien liegen nun in einer Ausprägung vor, dass das «agile Mindset» konkret gefasst werden kann, um es im Fortgang der Untersuchung zur Prüfung der Projekt- führungsmethode HERMES einzusetzen.

Anhand des HERMES Referenzhandbuchs, «HERMES online» und unter Zuhilfenahme wei- terer Quellen wird ein agiles Szenario analysiert und allfälliges Verbesserungspotential aufge- zeigt.

Nach Thesenüberführung und der Erörterung der Ergebnisse, schliesst die Arbeit mit einem Fazit und dem Ausblick auf weitere Forschungsvorhaben.

Hinweise:

1. Zur Verbesserung der Lesbarkeit wird in dieser Arbeit auf die Darstellung des gram- matikalischen Unterschiedes der Geschlechter verzichtet. Für Personengruppen oder Berufsbezeichnungen, die beide Geschlechter umfassen können, werden alternierend das eine oder das andere grammatikalische Geschlecht verwendet. Mit jeder Erwäh- nung ist das jeweils andere Geschlecht entsprechend inbegriffen.
2. Englischsprachige Texte werden zitiert. Um Übersetzungsfehler zu vermeiden, werden diese nicht ins Deutsche übersetzt, allerdings wie deutschsprachige Zitate behandelt.

2 Theorie

2.1 Einleitung und Stand der Forschung

Die Beantwortung der Forschungsfrage «gibt es beim Einsatz der agilen Projektmanagement- methode HERMES Verbesserungspotential in Bezug auf die Umsetzung der agilen Denkungs- art? » setzt eine diskursive Auseinandersetzung mit der «agilen Denkungsart» voraus. Woher stammt dieser Begriff? Wie hat er sich entwickelt und - was macht ihn aus?

Zu Beginn soll ein Blick auf den Ursprung der agilen Denkungsart stehen, die Erfindung des Lean Management. Dass es sich bei der «Agilität» nicht um eine weitere Methode handelt, die durch definierte Arbeitsanleitungen beschrieben und bei Befolgung derselben umgesetzt wer- den kann, um angestrebte Effizienz- und Kostenziele zu erreichen, sondern um eine Den- kungsart, ein «Mindset», das auf definierten Werten und Prinzipien gründet, soll im Verlaufe dieser Untersuchung gezeigt werden. Die Herausarbeitung dieser Werte und ihre Anwendung auf den Untersuchungsgegenstand HERMES 5.1 macht den Kern dieser Arbeit aus.

Die Suche nach dem Begriff «agil» in der Literatur (bspw. NEBIS, books.ch, Google Scholar) oder auf Plattformen für Diplomarbeiten wie «GRIN» führt zu einer überwältigenden Anzahl von Ergebnissen. Die agilen Methoden sind im Trend, mit einer Steigerungsrate von ca. 15% zum Vorjahr, und machen zwischenzeitlich mehr als die Hälfte aller angewandten Projektvor- gehen aus. (SwissQ Consulting AG, 2017, S.10).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Trends & Benchmark Report Schweiz – Projektvorgehen (Quelle: Darstellung entnom- men aus SwissQ Consulting AG, 2017)

Wie Ken Schwaber in seinem Vorwort zu D. Maximinis Buch über die Einführung von SCRUM in Unternehmen (Maximini, 2013) schrieb, gab es damals bereits 571 Bücher (allein bei Ama- zon) zum Thema SCRUM, der wohl bekanntesten agilen Methode. «Diese repräsentieren eine Galaxie von Sichtweisen, Verbesserungen, Verkörperungen und Verunstaltungen des SCRUM-Prozesses» (Schwaber, ibid. Vorwort). Neben der Vielzahl der Veröffentlichungen wird hier das Spektrum der Ansätze und Interpretationen und die verbreitete Konkurrenz um die besten Erweiterungen des SCRUM Ansatzes deutlich. Entsprechend gibt es neben den Informationen und Literaturhinweisen, die den verschiedenen «Homepages» der «SCRUM» Organisationen entnehmen werden können, eine Vielzahl von Veröffentlichungen zum agilen Projektmanagement (vgl. bspw. Pries, 2011; Vigenschow, 2015; Oestereich & Weiss, 2008). Diese stellen die grundsätzlichen agilen Konzepte vor, geben Anleitungen, wie agile Projekte aufgesetzt und durchgeführt werden können und bieten Anleitungen zur Einführung agiler Kon- zepte in die Unternehmenspraxis (vgl. bspw. Maximini, 2013). ZU SCRUM existieren eine Viel- zahl von Veröffentlichungen (vgl. bspw. Schwaber, 2014; Gloger, 2011; Pichler, 2009). Eine Gruppe von Arbeiten, vorwiegend aus dem universitären Bereich, beschäftigt sich mit der Ge- genüberstellung der traditionellen mit den agilen Methoden, wobei es hier vor allem um Krite- rien für die Wahl der einen oder anderen Methode geht (vgl. bspw. Marro, 2014; Dippon, 2015). Neben SCRUM spielen in der Literatur auch andere agile Methoden eine Rolle. Hier finden zwei Methoden besondere Beachtung: «KANBAN» und «XP» (Extreme Programming) (vgl. bspw. Kniberg & Skarin, 2010; Beck, 2012; Anderson, 2011). Wie erwähnt, sollen sich die agilen Methoden vom «Lean Management» herleiten, einer in der japanischen Autoindustrie angewandten Methode, die die Produktionssteuerung («Lean Production Management») «re- volutionierte». Zwischenzeitlich spricht man bereits von der «Super Lean» Produktion, und die Literatur zum Thema «Lean» ist entsprechend umfangreich (vgl. bspw. Brunner, 2008; Kojima, 1995; Zollondz, 2013).

Die Brücke vom Lean Management zum Lean Development schlagen Mary und Tom Poppen- dieck (2003), die von den plangetriebenen zu den agilen PM Methoden Sliger & Broderick (2008).

Zum engeren Themenkreis dieser Arbeit, der Untersuchung von HERMES 5.1, ist ausser dem HERMES Referenzhandbuch (2014) und einer Broschüre der HERMES-Benutzergruppe «eco HERMES» (Roth M., Kobi D., Ritz F., Kleine H., Lang P., 2015) kaum Literatur verfügbar. Das Praxishandbuch «Public Management» (Bergmann et. al, 2016, S.762ff.) bezieht sich noch auf eine HERMES Version von 1995. Die «Studie HERMES und Agilität» (2010) einer Arbeits- gruppe unter der Leitung von Mourgue d´Algue, der Projektleiterin und Mitautorin von HER- MES, entstand vier Jahre vor Veröffentlichung der HERMES agil Version. Auf die dort skiz- zierten Ideen wird noch zurückzukommen sein.

Daneben existieren noch einige Fachartikel, die im PM Magazin (2015) und in der Computer- woche (2015) veröffentlicht wurden, die die Einführung von HERMES 5.1 zum Thema haben. Die schon erwähnten Ansätze von Bachmann (2011) und Schär (2015) legen ihre Schwer- punkte auf die Bereiche Projektführung bzw. das «Requirements Engineering».

2.2 Der Begriff

Nähert man sich den Begriffen «agil sein» oder «Agilität», fällt auf, dass der Begriff für sich in der Fachliteratur, obwohl in unzähligen Büchern und Artikeln benutzt, kaum fassbar ist. Neben der etymologischen Herleitung des Begriffs «beweglich» von franz. «agile», bzw. lat. «agilis» (Kluge, 1995, S.19) ist keine Definition, gemäss Duden die «genaue Bestimmung eines Be- griffs durch Auseinanderlegung, Erklärung seines Inhalts» (Duden, 2003, S.360), auffindbar. Im Gabler Wirtschaftslexikon (2014) sind die Begriffe für sich nicht gelistet. Agile Softwareent- wicklung hingegen bezeichnet «Ansätze im Softwareentwicklungsprozess, die die Transpa- renz und Flexibilität erhöhen und zu einem schnelleren Einsatz der entwickelten Systeme füh- ren sollen […]. Die Kernidee besteht darin, Teilprozesse möglichst einfach und somit beweg- lich (=agil) zu halten» (Gabler, online). Demnach kann für die Softwareentwicklung festgestellt werden, dass Agilität Transparenz, Flexibilität und Einfachheit beinhalten soll.

Die Erfinder von SCRUM, einem «Entwicklungsprozess für Software, der Softwarefunktionali- tät in 30-Tage Inkrementen liefert» (Schwaber & Sutherland, 2014, S.xvii) und gemeinhin als DIE agile Methode rezipiert wird, definieren Agilität wie folgt: «Agilität ist die Fähigkeit, Vorteile aus Chancen zu ziehen oder Herausforderungen mit beherrschbarem Risiko zu meistern» (ibid., S.32). Als umfassende Definition der Agilität kann diese Aussage nicht gelten. Am ehes- ten drückt sie aus, dass die Fähigkeit, flexibel auf geänderte Situationen (wie Anforderungen), reagieren zu können, als Chance in Bezug auf die Verbesserung der Softwarequalität gesehen wird. Hierzu passt auch, dass die Autoren Flexibilität und Agilität synonym verwenden (ibid.). Auch Cockburn nähert sich dem Begriff «Agilität» über den Softwareentwicklungsprozess, in- dem er ausführt, dass «core to agile software development is the use of light-but-sufficient rules of project behaviour and the use of human- and communication-oriented rules» (Cock- burn, 2007, S. XXVI), um dann zu ergänzen, dass er die Beschreibung von Goldman für »Agi- lität» für die beste hält: «Agility is dynamic, context-specific, aggressively change-embracing, and growth orientated. It is not about improving efficiency, cutting costs […]. It is about suc- ceeding and about winning […] » (Goldman, 1997, zitiert nach Cockburn, ibid.). Cockburns Ausführungen bringen neue Aspekte, wie den Hinweis auf ein unkompliziertes (light), aber dennoch genügend ausgeprägtes (sufficient) Regelwerk, zu dem auch der Umgang mit den Mitarbeitern und die Kommunikation im Projekt gehören. Jedoch können weder diese Ausfüh- rungen noch die genannte Beschreibung von Goldman als Definition der «Agilität» gelten. Während erstere sehr allgemein bleiben, stellt letztere eine plakative, sehr emotional und in gleicher Weise allgemein gehaltene Beschreibung dessen dar, was zur «Agilität» (auch) ge- hören kann bzw. was diese zu bewirken verspricht. Highsmith charakterisiert «Agilität» durch zwei Aussagen: «Agility is the ability to both create and respond to change in order to profit in a turbulent business environment» (Highsmith, 2013, S.12) und «Agility is the ability to balance flexibility and stability» (ibid.). Hier klingt der Wandel («embrace change») und die flexible Re- aktion darauf an, wobei neu Agilität auch Beständigkeit, im Gegensatz zu Wandel, in einem austarierten Verhältnis enthalten soll. Es werden wichtige Aspekte genannt, jedoch als Defini- tion in obigem Sinne, können auch diese Aussagen nicht gelten.

Sliger & Broderick (2008) beschreiben im Glossar ihres Buches agil als:

an iterative and incremental approach to developing software that adheres to the Agile Man- ifesto and its associated principles […] done using small, dedicated, co-located, self-organ- izing teams who work in close cooperation with a business customer. Agile is value-driven both in the focus on delivering the most important features first and in the ways the teams choose to work together to develop the software» (S.321).

Sie kommen damit einer Definition am nächsten. Hier treten mehrere Elemente neu hervor: Die Eigenschaften des Teams, seine Zusammenarbeit mit dem Kunden und der Bezug auf die Werte. Der wichtigste Aspekt ist, dass Agilität „value driven“ ist, was so verstanden werden kann, dass ein Mindset zugrunde liegt. Dessen Werte werden nicht genauer gefasst, sondern durch den Bezug auf das agile Manifest pauschalisiert. So verfahren andere Autoren auch: «In der einschlägigen Literatur wird Agilität in der Regel anhand des Agilen Manifests erläutert» (Marro, 2014, S.22). Bisher bleibt es dabei: «Agilität ist […] schwer greifbar und es gibt keine ultimative Definition dafür» (ibid.).

Im Agilen Manifest wird, wie bei den meisten Autoren (vgl. bspw. Beck, 2012; Vigenschow, 2015), zwischen agilen Werten und agilen Prinzipien unterschieden.

Im Folgenden werden die Begriffe «agile Werte und Prinzipien» erläutert und gegeneinander abgegrenzt. Ausserdem wird erläutert, wie sie zur agilen Denkungsart beitragen.

2.3 Agile Werte, - Prinzipien und - Praktiken

Generell werden Werte, oder auch Wertvorstellungen, in den Bereichen Philosophie, Psycho- logie und Wirtschaft definiert. Demnach sind Werte «erstrebenswerte und moralisch als gut befundene Eigenschaften, Qualitäten oder Glaubenssätze. Aus festgelegten und gewichteten Werten (Normen) resultieren Denkmuster, Handlungsmuster und Charaktereigenschaften so- wie Ergebnisse mit gewünschten Eigenschaften» (Freies Wörterbuch der Werte, online, o.J.). Gemäss den Psychologen Gerrig und Zombardo kann ein Wert ein Lebensprinzip sein oder etwas, das man erreichen bzw. erhalten möchte. «Unsere Werte bilden damit eine Art Leitlinie für unsere Entscheidungen und unser Handeln» (Gerrig & Zimbardo, 2007, zitiert nach Vigen- schow, 2015, S.16). Das Wirtschaftslexikon definiert Werte als «Sammelbegriff für die Ge- samtheit aller Normen, denen sich Individuen oder Gruppen von Personen verpflichtet fühlen» (Gabler, 2014, S.3552).

Gemeinsam ist allen drei Definitionen das auf Normen basierte Handeln zur Erreichung von Zielen («Ergebnisse mit gewünschten Eigenschaften»).

Definition: Werte sind Grundsätze, auf die Individuen oder Gruppen ihr Handeln stützen, um den Werten entsprechende Ziele zu erreichen.

In dieser Weise wird der Begriff «Werte» im Rahmen dieser Arbeit verstanden und benutzt. Werte wie beispielsweise Einfachheit, Kommunikation und Rückmeldung wurden zuerst im Bereich XP definiert und später in den Wertekatalog des APM übernommen (vgl. Beck, 2012; Vigenschow, 2015).

Gemäss Duden ist ein Prinzip eine «feste Regel, die jemand zur Richtschnur seines Handelns macht, durch die er sich in seinem Denken und Handeln leiten lässt» (Duden, 2003, S.1240). Betrachtet man obige Definition der Werte, so fällt es schwer, den Unterschied zwischen Wer- ten und Prinzipien zu erkennen. Offensichtlich tun sich auch die Fachautoren schwer, Werte und Prinzipien abzugrenzen. Entweder der Zusammenhang wird überhaupt nicht dargestellt und man geht von der Liste der Werte zu der der Prinzipien über (vgl. bspw. Röpstorff & Wiech- mann, 2012, S.22) oder es wird, unter Vermeidung einer Definition, dargelegt, dass Prinzipien helfen, die agilen Werte umzusetzen. «Sie wirken wie Leitlinien für unser Handeln» (Vi- genschow, 2015, S.18). Ähnlich argumentiert Beck: «Because of the distance between values and practises, we need a way to bridge the gap between them. Principles are the tool we need» (Beck, 2012, S.22). Zwar werden mit diesen Ausführungen Werte und Prinzipien nicht voneinander abgegrenzt, jedoch sind sich die Autoren darüber einig, dass mit den agilen Prak- tiken die agilen Prinzipien und schliesslich die Werte abgebildet werden. «Daily SCRUM», «time boxing», und andere agile Praktiken setzen die agilen Prinzipien in konkrete Handlungs- anweisungen um.

Nach obigen Ausführungen würde man eine hierarchische Beziehung zwischen Werten, Prin- zipien und Praktiken (in dieser Reihenfolge) erwarten, in der das Abstraktionsniveau von unten nach oben zunimmt. Ausserdem steht zu erwarten, dass zwischen den Hierarchiestufen je- weils eine 1: n-Beziehung besteht und somit umgekehrt jedes Prinzip genau einem Wert und jede Methode genau einem Prinzip zugeordnet werden kann. Da dieser Zusammenhang Aus- wirkungen auf das weitere Vorgehen in dieser Untersuchung hat, seien im Folgenden die Zu- ordnungen der beiden ersten Hierarchiestufen auf der Grundlage der am weitesten verbreite- ten Darstellung derselben, des agilen Manifests, untersucht.

Die Werte sind jeweils auf der linken Seite der folgenden Abbildungen angeordnet, die Prinzi- pien auf der rechten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Zuordnung Prinzipien zu Werten (Quelle: Eigene Darstellung Teil 1)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zuordnung Prinzipien zu Werten (Quelle: Eigene Darstellung Teil 2)

Wie aus obigen Abbildungen ersichtlich, können von 12 Prinzipien 2, aus Sicht des Autors, nicht eindeutig, d.h. ohne Zusatzannahmen zugeordnet werden. Bestätigt wird dieser Befund durch Beck (2012, S.17ff.), der «Simplicity» als eigenständigen Werte aufführt. Das erste nicht zugeordnete Prinzip erscheint in diesem Rahmen insgesamt etwas deplatziert, denn Qualität ist nicht auf die Agilität beschränkt.

Ausserdem lässt sich feststellen, dass die Werte «Individuals and interaction […] » und «wor- king software […] » die meisten Zuordnungen aufweisen, entsprechend als Kandidaten gelten können, die die agile Denkungsart (mit) ausmachen.

Schlussfolgerung: Werte und Prinzipien werden in der Literatur nicht klar abgegrenzt. Es herrscht im Gebrauch der Begriffe (Werte, Prinzipien, Praktiken) keine durchgängige hierar- chische Beziehung, da Prinzipien nicht immer eindeutig Werten zugeordnet werden können und von manchen Autoren selbst als Werte eingeschätzt werden. Die Hierarchie trifft lediglich auf die Praktiken zu, die als konkrete Arbeits- oder Handlungsanweisungen den Prinzipien und Werten untergeordnet sind.

Für das Ziel dieser Arbeit, die agile Denkungsart aus der Menge der als «agil» bezeichneten Ansätze heraus zu präparieren und die gefundene «Substanz» zur Untersuchung der Projekt- managementmethode HERMES anzuwenden, bedeutet dies: sowohl Werte wie auch Prinzi- pien werden bei der Bestimmung der agilen Denkungsart mit einbezogen.

Schliesslich werden im Laufe der Untersuchung, wenn Werte oder Prinzipien nicht eindeutig genannt, sondern nur über die Praktiken zu erschliessen sind, auch die Praktiken näher be- trachtet, wobei der Einsatz einer oder mehrerer agilen Praktiken nicht heisst, dass auch «agil» vorgegangen wurde. Diese Beurteilung kann nur in der Betrachtung «inwiefern durch die agi- len Praktiken die agilen Prinzipien im Sinne der agilen Werte wirklich erreicht bzw. umgesetzt werden» (Vigenschow, 2015, S.16), geleistet werden.

Zuerst soll jedoch der Untersuchungsgegenstand HERMES kurz umrissen werden, um das Ziel nicht aus den Augen zu verlieren. Eine detaillierte Analyse erfolgt im Rahmen der Unter- suchung.

2.4 HERMES

HERMES - das Akronym steht für « H andbuch der E lektronischen R echenzentren des Bundes, M ethode zur E ntwicklung von S ystemen» -, ist international wenig verbreitet und wird insbe- sondere im Rahmen der Schweizerischen Eidgenossenschaft im öffentlichen Sektor einge- setzt. Die Methode wird daher auch als die «Schweizer Projektführungsmethode» (Duwe & Tschanz, 2015, S.1) bezeichnet. Die etwas schwerfällige Namengebung weist zurück in die 70er Jahre des 20. Jahrhunderts. Sie wurde damals für IT-Projekte entwickelt und standardi- siert und enthielt zwei grundlegende Vorgehensmodelle: HERMES SE für Systementwicklung und HERMES SA für Systemadaption. Mit der 2014 publizierten Version 5.1 wurde HERMES überarbeitet (ibid.) und ist gemäss Referenzhandbuch nun «eine Projektmanagementmethode für Projekte im Bereich der Informatik, der Entwicklung von Dienstleistungen und Produkten sowie die Anpassung der Geschäftsorganisation» (Mourgue d´Algue et. al., 2014, Einleitung).

HERMES folgt dem sog. Wasserfallmodell, d.h. die Projektphasen werden kaskadenförmig abgewickelt, wobei die Ergebnisse der Vorphase in der Folgephase weiterverarbeitet werden. HERMES ist frei und kostenlos zugänglich und kann den jeweiligen Organisations- oder Pro- jektgegebenheiten angepasst werden. Es sind Pflichtelemente definiert, die bei Anwendung der Methode berücksichtigt werden sollen.

HERMES kennt die Phasen Initialisierung, Konzept, Realisierung und Einführung, wobei die Phasen Realisierung und Einführung iterativ durchlaufen werden können. Zwischen den Pha- sen werden Meilensteine durchlaufen, die die Abnahme von definierten Lieferobjekten durch definierte Rollen verlangen, deren Ergebnisse entscheidend für die Freigabe der jeweiligen Folgephase sind. Die fünf Strukturelemente Szenarien, Module, Aufgaben, Rollen und Ergeb- nisse ermöglichen verschiedene Sichten (s. Abb.7) auf das Projekt, die auf den zeitlichen Ab- lauf, die Partner und auf die Hierarchieebenen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Sichten (Quelle: Darstellung entnommen HERMES online -Sichten auf das Projekt

Szenarien: Ein Szenario stellt den gesamten Lebenszyklus eines charakteristischen Projektes dar, beispielsweise eines Beschaffungsprojekts. HERMES beschreibt acht Szenarien wie IT- Individualanwendung, IT-Infrastruktur, Dienstleistung/ Produkt und andere. Seit der Version 5.1 existieren auch zwei agile Szenarien «IT-Individualanwendung agil» und «Dienstleistung/ Produkt agil» (HERMES online, Szenarien).

Module: Module sind Bausteine, die innerhalb eines Szenarios Verwendung finden. Sie um- fassen Managementaufgaben und Fachprozesse (s. Abb.5).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Zuordnung von Modulen im Szenario IT-Individualentwicklung agil (Quelle: Darstellung entnommen HERMES online – Module)

Bestimmte Module, wie Projektsteuerung und Projektführung, werden als Managementtätig- keiten in allen Szenarien benötigt, andere, wie bspw. das Modul «Produkt» sind spezifisch und nur im Szenario Dienstleistung/ Produkt verfügbar. Insgesamt werden in HERMES 13 Module beschrieben.

Rollen: Bei den Rollenprofilen wird zwischen Stamm- und Projektorganisation unterschieden. Jede der insgesamt 18 Rollen ist einer der Hierarchieebenen Steuerung, Führung oder Aus- führung zugeordnet. Rollen werden ausserdem auf Partner bezogen, wobei (s. Abb.6) Anwen- der (nutzt das System), Ersteller (entwickelt und integriert) und Betreiber (Betrieb) unterschie- den werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Rollenübersicht und Zuordnung (Quelle: Darstellung entnommen HERMES online – Rol- len)

Weitere Rollen wie Risikomanager und Qualitätsverantwortlicher werden nicht explizit aufge- führt und können der Ebene Steuerung implizit zugeordnet werden.

Aufgaben: Jedem Modul sind Aufgaben zugeordnet, wie verantwortliche Partner zu deren Durchführung (s. Auszug in Abb.10). Aufgaben können sowohl Aktionen, wie die Erstellung von Dokumentation sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Aufgaben pro Modul und Partnerzuordnung (Quelle: Darstellung entnommen HERMES online – Aufgaben)

Zuletzt sind den Modulen Ergebnisse zugeordnet, die von den genannten Partnern erbracht werden. HERMES definiert über alle Module 43 Pflichtergebnisse (Abb.8 mit * gekennzeich- net) aus 71 Ergebnissen gesamt, das sind 60,5%. Pflichtergebnisse müssen erbracht werden, um den Anforderungen der «Governance» zu genügen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Modulen sind (Pflicht-) Ergebnisse zugeordnet – Auszug (Quelle: Darstellung entnommen HERMES online – Ergebnisse)

Im nächsten Kapitel wird die Entwicklung der agilen Methoden, die heute in der Softwareent- wicklung bzw. dem Projektmanagement Anwendung finden, aus dem Lean Management auf- gezeigt.

Die Darstellung des Lean Managements, wie der im Folgenden vorzustellenden agilen Vorge- hensweisen, erfolgt zum Verständnis des methodischen Rahmens. Der Fokus liegt nicht auf den Praktiken, sondern auf den agilen Werten.

2.5 Lean Management

2.5.1 Begriff

Eine klare Definition des Begriffs «Lean» zu finden, bereitet Schwierigkeiten. Der Begriff sei «inflationär […] vieldeutig und bewusst so geprägt, um Wirkung zu erzielen […] ihn als eindeu- tigen terminus technicus zu bestimmen wird nur schwer gelingen» (Zollondz, 2013, S.XIX). Der Konzern (Toyota), dessen Produktionssystem «als Ursprung der «Lean Production» ge- sehen werden kann» (Dombrowski & Mielke, 2015, S.14) kennt den Begriff nicht (Zollondz, 2013, S.XIX).

Gablers Wirtschaftslexikon charakterisiert «Lean Management» als «Managementansatz, nach dem bes. durch die Grundprinzipien Dezentralisierung und Simultanisierung (verbunden mit kooperativen Verhaltensweisen) die Ziele Kundenorientierung und Kostensenkung für die gesamte Unternehmensführung realisiert werden […] » (Gabler, 2014, S.1980).

Diese sehr allgemeine Beschreibung wird durch die Präzisierung der Begriffe Dezentralisie- rung und Simultanisierung verständlicher. Der Kernpunkt der Dezentralisierung ist die Organi- sation der Arbeit in den primären Leistungsbereichen der Wertschöpfungskette in hochqualifi- zierten Teams mit intensiven Kommunikationsbeziehungen. Die Aufgabe der Funktionsspezi- alisierung (einzeln zugewiesene, detaillierte Arbeitsanweisungen) zugunsten einer integrierten Produkt-, Prozess- und Kapazitätsplanung machen den Kern der sog. Simultanisierung aus (ibid.). Im Gegensatz zu Gabler, die «Lean Production» und «Lean Marketing» separat und nicht als Teile des Lean Managements aufführen, sehen Womack & Jones (2013) die «Lean Production» als Teil eines übergreifenden Denkansatzes, dem «Lean Thinking» (S.10). Als die fünf Schlüsselprinzipien des «Lean Thinking» nennen sie: «genaue Spezifikation des Wertes [im ökonomischen Sinne] durch das spezifische Produkt, Identifikation des Wertstroms durch jedes Produkt, Flow des Wertes ohne Unterbrechungen, Pull des Wertes durch den Kunden […], Streben nach Perfektion» (Womack & Jones, 2013, S.16). Diese Beschreibung erscheint auf den ersten Blick noch abstrakter zu sein als die bei Gabler. Sobald der Leitbegriff «Wert» geklärt ist, werden die Aussagen klarer.

Wert «kann nur vom Endverbraucher her definiert werden […] er [wird] über ein spezifisches Produkt definiert, welches den Bedarf des Kunden zu einem bestimmten Preis befriedigt» (Womack & Jones, 2013, S.24). Im Mittelpunkt steht beim Lean Management also der Kunde bzw. seine Anforderung, deren Umsetzung «Wert» produziert, nämlich den, den der Kunde bereit ist, für das entsprechende Produkt zu bezahlen. Dieses Produkt muss identifiziert und spezifiziert werden und ohne Unterbruch, nur von der Kundenbestellung «gezogen» (Pull - also nicht im Voraus produziert), durch die Produktion «fliessen» (Flow), wobei die Produkti- onsprozesse und schliesslich das Produkt fortwährend verbessert werden sollen (Perfektion).

Um diese Prinzipien zu implementieren, muss die bisherige Organisation grundsätzlich über- dacht werden; Vermögenswerte und Technologien werden infrage gestellt, um den Kunden- wunsch in den Mittelpunkt zu stellen (Womack & Jones, 2013, S.28). Die genaue Definition von Wert ist der entscheidende erste Schritt beim «Lean Thinking» (ibid.).

Bisher wurde noch nicht auf den Begriff «Lean» in seiner nicht attributiven Form eingegangen. Womack & Jones (2013) fassen ihn als «Lean Thinking ist Lean, weil es einen Weg aufzeigt, immer mehr mit immer weniger zu erreichen […], während man dem Ziel immer näherkommt, den Kunden genau das zu bieten, was sie wirklich wollen» (S. 23). Hier wird erneut der Fokus auf den Kunden bzw. seine Wünsche (gleich Wert gleich Produkt) gesetzt.

Zu erreichen ist die Kundenzufriedenheit «Lean», d.h. mit «immer weniger» Ressourcen wie Arbeit, Betriebsmitteln, Raum, Zeit. Diese Verknüpfung zwischen «Kundenwert» und ange- strebter Reduktion der Ressourcen zur Erreichung desselben greift auch das «Lean Enterprise Institute» auf seiner Homepage auf: «The core idea is to maximize customer value while mini- mizing waste. […] Lean means creating more value for customers with fewer resources» (Lean Enterprise Institute, o.J., online). Diese Ausführungen stimmen inhaltlich völlig überein mit de- nen von John Krafcik, einem Wissenschaftler am MIT, der Ende der Achtziger Jahre den Be- griff «Lean Management» im Anschluss an eine vergleichende Untersuchung des Toyota-Pro- duktionssystems mit denen der europäischen Konkurrenz prägte und feststelle, dass Toyota «mit der Hälfte an Mitarbeitern eine dreimal höhere Produktivität und viermal kürzere Liefer- fristen» erreichte (Krafcik zitiert nach Zollondz, 2013, S.6).

Anders erklärt Zollondz den Begriff «Lean»: «Lean bedeutet nicht einfach schlank, [sondern] […] steht in unserem Zusammenhang viel eher für fragil, zerbrechlich, anfällig […]. Lean ist ein Systembegriff, kennzeichnet kein gegenständliches Objekt […] » (Zollondz, 2013, S.XIX). Besonders gefährdet ist das System, d.h. die (Prozess-) Organisation eines Unternehmens dann, wenn es gilt, «die Fragilität sämtlicher Wertschöpfungsströme in Balance zu halten» (Zollondz, 2013, S.XIX), während alle «Aktivitäten, die keinen Kunden haben und deren Leis- tung nicht in der Wertschöpfungskette weiterverarbeitet wird, aufgelöst [werden]» (Brunner, 2008, S. 58). Konzentration auf die Kundenwünsche, Abbau von Überflüssigem – in dieser Interpretation des Begriffs wiederholt sich schon Bekanntes, aber es klingt auch ein weiteres Charakteristikum des Lean Management an, die Vermeidung von Verschwendung.

Auf der Grundlage der von den Fachautoren benannten Charakteristika kann der Begriff «Lean Management» für diese Arbeit, wie folgt, definiert werden.

Definition:

«Lean Management» bezeichnet einen unternehmensweiten Managementansatz, als dessen zentraler Wert der Kundenwunsch und dessen physische Entsprechung, das Produkt, gilt, das unter Einsatz zunehmend weniger Ressourcen und der Vermeidung jeglicher Verschwendung, durch hochqualifizierte Teams mit intensiven Kommunikationsbeziehungen, in einem stetigen, Perfektion anstrebenden Verbesserungsprozess, hergestellt wird.

Nachdem der Begriff definiert wurde, werden im nächsten Kapitel die wesentlichen Kategorien und Gestaltungsprinzipien des Lean Managements dargestellt.

2.5.2 Kategorien und Gestaltungsprinzipien des Lean Managements

Exkurs: Zur Erfassung des Lean Managements (ab jetzt LM abgekürzt) in einem übergeord- neten Zusammenhang entwickelt Zollondz Kategorien, die «als Bezugspunkte fungieren» (Zol- londz, 2013, S.8) und für die Beschreibung des LM eine Art «top down Ansatz» bilden. «Kate- gorien sind dadurch gekennzeichnet, dass sie voneinander abgegrenzt und unterschieden werden […]. Sie sind sich auf die Wirklichkeit beziehende angewandte Formen des Denkens und Handelns» (ibid.).

In ihrem Buch «Ganzheitliche Produktionssysteme» (ab jetzt GPS), die sie als europäisches Pendant zum Toyota Produktionssystems und als Weiterentwicklung der «Lean Production» sehen (Dombrowski & Mielke, 2015, S.4), führen die Autoren den Begriff «Gestaltungsprinzi- pien» ein. Gemäss VDI Richtlinie 2870 handelt es sich bei einem GPS um «ein unternehmens- spezifisches methodisches Regelwerk für die kontinuierliche Ausrichtung sämtlicher Unterneh- mensprozesse am Kunden, um die von der Unternehmensführung vorgegebenen Ziele zu er- reichen» (VDI, o.J., online). «Durch die Auswahl der Gestaltungsprinzipien werden die anzu- wendenden Methoden und Werkzeuge strukturiert und es wird sichergestellt, dass ein aufei- nander abgestimmtes Gesamtsystem entsteht» (Dombrowski & Mielke, 2015, S.29). Ange- strebt wird ein «Lean Enterprise», das neben den Produktions-, Vertriebs- und Servicesyste- men auch sog. indirekte Bereiche, wie Lean Development, Lean Leadership und Lean Admi- nistration umfasst (vgl. Dombrowski & Mielke, 2015, S.VII).

Dieser Exkurs war notwendig geworden, um die Grundlage für das Verständnis des weiteren Vorgehens in dieser Arbeit zu schaffen. Zuerst kann anhand der Definitionen festgestellt wer- den, dass

- ein GPS ein Lean Managementsystem darstellt und
- die Begriffe Kategorien sowie Gestaltungsprinzipien als strukturierende Elemente der Gesamtsysteme synonym verwendet werden können.

Im Folgenden werden diese Gestaltungsprinzipien, und ihre gemäss LM angestrebten Aus- prägungen, beschrieben und durch Hinzuziehen weiterer Literatur ergänzt. Aus ihnen werden anschliessend die Werte d.h. «die Denkweise, mit der die Unternehmensprozesse nach dem Lean Ansatz gestaltet werden sollen» (Dombrowski & Mielke, 2015, S.7) extrahiert. Diese bil- den schliesslich zusammen mit den aus den agilen Ansätzen gewonnen Werten die «agile Denkungsart».

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Gestaltungsprinzipien des LM (Quelle: eigene Darstellung in Anlehnung an Zollondz, 2013, S.9)

Die zu beschreibenden Gestaltungsprinzipien sind Raum und Zeit, Qualität, Kosten, «Muda» (Verschwendung), Arbeit, Wertschöpfung und Kultur.

2.5.2.1 Qualität

Nach Umsetzung aller Einzelanforderungen an die Beschaffenheit ist «Qualität die realisierte Beschaffenheit einer Einheit» (Zollondz, 2013, S.10). Mit der Qualität untrennbar verbunden, im Rahmen des LM, ist der kontinuierliche Verbesserungsprozess (KVP) oder gemäss seiner Bedeutung im TPS japanisch «Kaizen» benannt. «Kaizen ist nicht eine Methode […] vielmehr als prozessorientierte Denkweise [fett im Original] im Sinne einer Geisteshaltung zu begreifen, die gleichzeitig Ziel und Verhaltensweise […] darstellt» (Brunner, 2008, S.11). KVP lässt sich als übergeordnetes Prinzip begreifen, denn alle Aktivitäten dienen letztlich der Steigerung der Kundenzufriedenheit, woraus sich die mittelbaren Sub-Ziele Qualitätsverbesserung, Kosten- senkung und Liefertreue ableiten (Imai 1997 zitiert nach Dombrowski & Mielke, 2015, S.52).

Demnach bestimmt der Kunde die Qualität, denn Zufriedenheit desselben ist nur erreichbar, wenn seine Qualitätsanforderungen erfüllt sind. Im Gegensatz dazu steht die Auffassung von Zollondz, der die Formulierung der Qualitätsanforderungen beim Management der produzie- renden Unternehmen sieht (vgl. Zollondz, 2013, S.11).

Die Bestimmung der Qualität durch das Management widerspricht dem oben dargestellten Begriff von «Wert», denn der ist, wofür der Kunde bereit ist zu bezahlen. Vom Management bestimmte Qualität entspricht dem ursprünglichen, plangetriebenen Vorgehen und ist mit LM nicht vereinbar. Denn, wenn Pläne umgesetzt werden, statt dem, was wirklich benötigt wird, ist dies ohne Verschwendung nicht möglich. Verschwendung ist allerdings mit LM unvereinbar.

Festzuhalten ist, dass ein Teil der Kundenzufriedenheit auf den vom Kunden selbst definierten Qualitätsanforderungen fusst, was allerdings dessen direkte oder repräsentierte Mitarbeit er- fordert.

Um die erwartete Qualität zu erreichen, wird iterativ vorgegangen, d.h. als übergeordnete Me- thode wird der PDCA-Zyklus angewandt, der über schnelle Verbesserungsschleifen eine ste- tige Qualitätssteigerung ermöglicht (Dombrowski & Mielke, 2015, S.54). Diese Methode ist auch als Deming-Kreis bekannt, wobei PDCA für «Plan», «Do», «Check» und «Act» steht (eine Problemlösung wird geplant, der Plan wird umgesetzt, sein Erfolg geprüft und im Erfolgs- falle wird die Massnahme als neuer Standard definiert). In der «Lean Production» setzt man (Prozess-) Standards, um diese dann zu hinterfragen und zu verbessern, was Taiichi Ohno, einer der Toyota «Pioniere» so ausdrückt: « without standards there can be no kaizen» (zitiert nach Womack et al., 2007, S. 294). Dies entspricht in etwa dem Vorgehen bei der agilen Soft- wareentwicklung, die technisches Vorgehen oder Werkzeuge standardisiert, Prozesse laufend verbessert, am Produkt selbst aber die Anpassungsfähigkeit schätzt.

Eine Organisation hebt also im KVP ihren Standard kontinuierlich auf eine höhere Stufe der Kundenzufriedenheit. Neben der Standardisierung als Gestaltungsprinzip des LM thematisie- ren Dombrowski & Mielke (2015) das Null-Fehler-Prinzip des LM, das «die fehlerfreie Produk- tion ohne Nacharbeiten» (S.80) zum Ziel hat. Im Rahmen des KVP werden Fehler frühzeitig erkannt und können entsprechend kostengünstig behoben werden. Auch hier drängen sich die Prinzipien häufiges Feedback und Transparenz der agilen Softwareentwicklung auf.

«Setzt sich die Organisation konstruktiv und lernend mit dem Auftreten von Fehlern auseinan- der, wird in der Belegschaft ein Bewusstsein für Fehlervermeidung geschaffen» (ibid.) und kann die von Womack dem LM als Prinzip zugeschriebene Perfektion erreicht werden (Womack & Jones, 2013, S.36). Das «Bewusstsein zur Fehlervermeidung» weist in Richtung einer «lernenden Organisation», ein mit Gestaltungsprinzip «Kultur» verknüpfter Aspekt des LM. Der Begriff «lernende Organisation» impliziert Eigeninitiative, Bewegung, Zusammenar- beit aller Beteiligten und unterstützt die oben formulierte Auffassung, dass Qualität im LM nicht durch Managementpläne, sondern durch Kundenwünsche bestimmt wird.

Es erscheint notwendig, hier kurz innezuhalten und den letzten Abschnitt unter dem Aspekt der Einordnung in den Gesamtzusammenhang dieser Arbeit zu betrachten.

Ziel des Kapitels «Lean Management» ist es, den Ursprung der agilen Projektführungsmetho- den bis in den Anfang der Neunziger-Jahre des vergangenen Jahrhunderts zurückzuführen, in denen das Buch von Womack, Jones und Ross «The Machine that changed the World» (deutsche Ausgabe: «Die zweite Revolution in der Autoindustrie») die neuen Produktionsan- sätze der japanischen Autoindustrie weltweit bekannt machten. Schon 1995 propagierte der der Japaner Takeshi Kojima die «Super-Lean-Revolution», die die Herausforderung einer «Fabrik, die den Menschen wichtig nimmt» angenommen hat (S.7).

Im Kapitel «Qualität» wurden schon Bezüge zur agilen Softwareentwicklung hergestellt. Auch das Kojima-Zitat erinnert an den agilen Wert «individuals and interactions over processes and tools» aus dem agilen Manifest. Kann der Nachweis der nahen Verwandtschaft zwischen LM und agilen Methoden belegt werden, können die Werte des LM gleichberechtigt mit «agilen» Werten behandelt werden. Ihre Darstellung trägt dazu bei, die agile Denkungsart besser zu verstehen und zu präzisieren, und dies neben den Prinzipien auch von den Praktiken her. In der Beschreibung der weiteren Gestaltungsprinzipien wird, ohne der Beschreibung der agilen Methoden vorzugreifen, weiterhin auf Gemeinsamkeiten hingewiesen.

2.5.2.2 Raum und Zeit

Raum und Zeit als Gestaltungsprinzipien zusammen zu behandeln, ist sinnvoll, da beide lo- gisch und auch technisch-praktisch zusammengehören. Am Anfang soll ein ausführliches Zitat von Norbert Elias zur grundsätzlichen Darlegung der Zusammengehörigkeit der beiden Di- mensionen stehen: «Was wir Raum nennen, bezieht sich auf positionale Relationen zwischen bewegten Ereignissen […] jede Veränderung im Raum ist eine Veränderung in der Zeit, jede Veränderung in der Zeit ist eine Veränderung im Raum […] » (Elias, 1984, zitiert nach Zollondz, 2013, S.24). Assoziiert man Raum und Zeit unter profaneren, d.h. Managementaspekten, drängen sich Begriffe wie das «magische Dreieck» (Zeit, Kosten, Qualität) oder «time-to-mar- ket», «just in time», oder der KVP, ein Beispiel für den beschriebenen Zusammenhang zwi- schen den Dimensionen, auf. Um «time-to market» herauszugreifen, soll diese durch den Lean Ansatz verkürzt werden, um (zusätzlich zur Stärkung der Marktposition) den Wert des Pro- dukts möglichst schnell (durch dessen Verkauf) zu realisieren. Die Geschwindigkeit soll trotz des Einsatzes von zunehmend weniger Ressourcen gesteigert werden. Hier rücken die Prin- zipien «Flow» und «Pull» ins Bild, die im Folgenden beschrieben werden.

Flow: Gemäss VDI Definition bezeichnet das Fliessprinzip «eine umfassende Unternehmens- gestaltung, die darauf ausgerichtet ist, einen schnellen, durchgängigen und turbulenzarmen Fluss von Materialien und Informationen über die gesamte Wertschöpfungskette zu ermögli- chen» (VDI, o.J., zitiert nach Dombrowski & Mielke, 2015, S.96). Hatte man früher in Abteilun- gen und Losgrössen gedacht, so fordert das Fliessprinzip die Aufgabe des «Stapeldenkens» (Womack & Jones, 2013, S.42), und die Objekte werden nach einem Arbeitsgang direkt zum nächsten transportiert, ohne auf die Fertigstellung des gesamten Loses warten zu müssen (Dombrowski & Mielke, 2015, S.97). Unter Los wird der «geschlossene Posten einer Pro- duktart […], der ohne Unterbrechung durch die Produktion anderer Produktarten erzeugt wird» (Gabler, 2014, S.2054), verstanden. Somit werden Wege (Raum) und Wartezeiten minimiert und eine minimale Durchlaufzeit erreicht. Womack & Jones (2013) sprechen anhand eines Beispiels nach der Umstellung von Abteilungen und Losen auf kontinuierlichen Ablauf von einer «Verdoppelung der Produktivität und einem dramatischen Rückgang von Fehlern und Ausschuss» (S.33). Ein weiterer wichtiger Punkt: Durch den «one piece flow» (Losgrösse 1) werden Fehler in der Fertigung frühzeitig erkannt und können kostengünstiger behoben wer- den. Das Fliessprinzip ermöglicht ausserdem eine höhere Flexibilität, da auf Varianten gemäss den Kundenwünschen leichter reagiert werden kann, und eine bessere Prozessqualität insge- samt, da durch die Reduktion von Pufferzeiten Unzulänglichkeiten im Prozess schneller auf- fallen (Dombrowski & Mielke, 2015, S.96f.). Fehlererkennung und -behebung sind wiederum ein Teil des kontinuierlichen Verbesserungsprozesses.

Die Analogie zur Softwareentwicklung: Kontinuierlicher «Fluss» mit der Losgrösse 1, frühes Feedback und kontinuierliche Verbesserung entsprechen dem agilen Vorgehen (SCRUM) im Sinne der Lieferung eines funktionsfähigen Inkrements, hergestellt in kurzen Iterationen, zur Erlangung eines möglichst schnellen Kundenfeedback, um entsprechend adjustieren zu kön- nen. Die Reduktion der Pufferzeiten entsprechen der Begrenzung des WIP Limits bei KANBAN oder «time boxing» bei SCRUM.

Pull: Mit dem Pull-Prinzip wird «eine Materialversorgung angestrebt, die sich an den Bedarfen des Kunden ausrichtet und dabei einen geringstmöglichen Steuerungsaufwand und geringe Bestände erreichen soll» (VDI-Richtlinie 2870, zitiert nach Dombrowski & Mielke, 2015, S.322). Im Zentrum steht der Kundenwunsch, und die Methoden zur Durchführung des Pull- Prinzips sind die bekannten «Just- in-Time» und «KANBAN». Die Lagerbestände werden mi- nimiert, der ROI beschleunigt, wenn die Unternehmen, wie es Womack & Jones etwas informal formulieren « […] einfach nur das produzieren, was der Kunde nachfragt. Das heisst, Sie kön- nen den Kunden das Produkt bei sich abrufen lassen, statt, […] ihm an[zu]bieten, was er oft gar nicht will » (2013, S.35). Die «Just-in-Time» Methode lässt neben den Lagerbeständen an die Zulieferprozesse denken, deren konstitutives Merkmale die Zeit ist. In einer «Lean orien- tierten Logistik […] werden kleinere Einheiten, in höheren Frequenzen, über kürzere Distanzen transportiert, angeliefert, umgeschlagen und bereitgestellt» (Klug 2008, zitiert nach Zollondz, 2013, S.19).

[...]