Kullmann, Longmuß, Bullinger, Spanner-Ulmer (Hrsg.)...erforderliche Verbindung von Vorgehensweisen...

Agiles Projektmanagement in der Praxis der Produktentwicklung

1

Kullmann, Longmuß, Bullinger, Spanner-Ulmer (Hrsg.)


Ergebnisbericht zum Verbundprojekt „StabiFlex-3D Systemvertrauen und Innovationsfähigkeit durch stabil-flexible Systemstandards und partizipatives Change Management“, Teil 3 von 3

Förderkennzeichen: 01FH09130

Projektlaufzeit: 01.08.2009 bis 30.04.2013

Erstellt durch:

Technische Universität Chemnitz Professur Arbeitswissenschaft und Innovationsmanagement Prof. Dr. habil. Angelika C. Bullinger

Erfenschlager Str. 73 Gebäude C 09125 Chemnitz Tel: 0371 531 35 208 Fax: 0371 531 8 35 208 www.tu-chemnitz.de/mb/ArbeitsWiss/ [email protected]

ISBN-Nr.: 978-3-944192-02-4


2

Ausgangspunkt dieser Publikation ist das Verbundprojekt „Systemvertrauen und Innovations- fähigkeit durch stabil-flexible Systemstandards und partizipatives Change Management – StabiFlex-3D“ (http://www.stabiflex-3d.de), das mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) und des Europäischen Sozialfonds (ESF) der Europäischen Union innerhalb des Förderschwerpunkts „Balance von Flexibilität und Stabilität in einer sich wan-delnden Arbeitswelt“ gefördert und vom Projektträger Deutsches Zentrum für Luft- und Raum-fahrt (DLR), Fokusgruppe Inner- und überbetriebliche Kooperationsstrategien, betreut wird. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Projektträger Unternehmenspartner Forschungspartner

Verlagaw&I Wissenschaft und Praxis Technische Universität Chemnitz

Design, Grafik, Herstellung PrintDesign | Dr. oec. Kerstin Loth, Florastr. 4, 09131 Chemnitz

Druck Oskar Görner GmbH, D-09126 Chemnitz

Gefördert vom:


3

Inhaltsverzeichnis

1. Einleitung ......................................................................................................................... 32. Warum agile Methoden in der Produktentwicklung? .................................................. 83. Ergebnis-Blitzlicht: Zu Besuch in der Entwicklungsabteilung ................................. 104. „Scrum“ als Methode für agiles Projektmanagement ............................................... 11 In Kürze: Stabil-flexible Standards .................................................................................. 12 „Scrum“ – eine „agile Methode“ ....................................................................................... 13 Abläufe von „Scrum“ ....................................................................................................... 17 „Scrum“ als eine Form stabil-flexibler Standards ............................................................ 195. Potenziale und Effekte von „Scrum“ ........................................................................... 20 Betriebliche Erfahrungen ................................................................................................ 20 Was bewirkt „Scrum“? ..................................................................................................... 206. Was ist wichtig bei der Durchführung? 7 goldene Regeln ........................................ 24 1.„Scrum“ kann produktorientiert, aber auch kompetenzorientiert sein........................... 24 2.„Scrum“ braucht eine definierte Anforderungsliste ....................................................... 26 3.„Scrum“ muss auf einem definierten Produktentstehungsprozess aufsetzen .............. 29 4.„Scrum“ hat einen unverzichtbaren Kern ..................................................................... 29 5.„Scrum“ braucht definierte Rückmeldeschleifen und Eskalationswege ....................... 30 6.„Scrum“-Teams müssen abgestimmt arbeiten ............................................................. 31 7.„Scrum“-Teams brauchen Vertrauen ........................................................................... 327. Ein Blitzlicht auf den Veränderungsprozess .............................................................. 348. Der Einführungsprozess .............................................................................................. 36 Besonderheiten von „Scrum“ in der physischen Produktentwicklung ............................. 36 Partizipatives Change Management ............................................................................... 37 Der Weg zu einem angepassten Konzept ....................................................................... 39 Von der Idee zum Umsetzungserfolg: Das Vorgehen an einem praktischen Beispiel .... 409. Sieben Prozessweisheiten in der Einführung ............................................................ 46 1. Jedes Unternehmen kann und muss „sein“ „Scrum“ entwickeln ................................. 46 2. Sicherheit durch Verfahren: ein partizipatives Vorgehen mit transparenten Regeln ... 46 3.Rollenklarheit und -schärfung ...................................................................................... 47 4. Besonders in Entwicklungsabteilungen können Standards im laufenden Einführungsprozess entwickelt werden ....................................................................... 47 5. Führung mit Vertrauensbereitschaft ............................................................................ 48 6. Auch Teammitglieder müssen Vertrauen aufbringen können ..................................... 49 7. Die Einführung ist nie endgültig abgeschlossen ......................................................... 4910. Transfer .......................................................................................................................... 50 Direkte Transferveranstaltungen ..................................................................................... 50 Fachgruppe zu agilem Projektmanagement in der GPM ................................................ 51 Integration in die Beratungspraxis der GITTA mbH ........................................................ 52 Ausblick für die Forschung .............................................................................................. 5211. Literaturverzeichnis ...................................................................................................... 5412. Autoren- / Herausgeberverzeichnis............................................................................. 5713. Abbildungsverzeichnis ................................................................................................. 58


4

1. Einleitung

Vertrauen ist ein zentrales Element im menschlichen Leben und Arbeiten. Ohne ein gewisses Maß an Vertrauen sind weder ein gesellschaftliches Miteinander noch Zusam-menarbeit denkbar. Bereits im alltäglichen Leben ist auch zu erfahren, dass der Aufbau von Vertrauen sehr viel Zeit, Kraft und Geduld erfordert. Dagegen lässt sich Vertrauen schnell zerstören. Ein solcher Vertrauensverlust kann nicht nur starke psychische Belas-tungen für die Beteiligten mit sich bringen. Die Folgen, mit denen ein Unternehmen im Falle eines Vertrauensverlustes bei Mitarbeitern, Lieferanten oder Kunden zu rechnen hat, können auch wirtschaftlich enorm bedeutsam sein (Thomas, 2005).

Vertreter der Wissenschaft und Betriebspraxis sind sich zudem einig, dass Vertrauen eine der Hauptkomponenten einer innovationsförderlichen Unternehmenskultur darstellt (Geißler & Sattelberger, 2003; Hurtz & Flick, 2002; Götz, 2006; Osterloh & Weibel, 2006). Treiber und Träger aller innovativen Handlungen ist demnach der Mitarbeiter, der allein und im Team Ver-änderungspotenziale identifiziert, Lösungen entwickelt und diese nachhaltig umsetzt. Kommt es hier zu einem Vertrauensverlust, liegen die negativen Folgen für Innovationsentwicklung und Unternehmenserfolg auf der Hand. Es gilt also, das Vertrauen der Mitarbeiterinnen und Mitarbeiter zu stärken und gleichzeitig innovationsförderliche Arbeitsumfelder zu entwickeln.

Vor diesem Hintergrund verfolgte das durch das Bundesministerium für Bildung und Forschung (BMBF) und den Europäischen Sozialfond (ESF) geförderte Verbundprojekt „Systemvertrauen und Innovationsfähigkeit durch stabil-flexible Systemstandards und partizipatives Change Management“ (kurz: StabiFlex-3D) folgendes Ziel:

Entwicklung eines auf „Systemvertrauen“ aufbauenden Konzepts zur Unterstützung von Unternehmen, Führungskräften und Mitarbeitern zum gemeinsamen Aufbau einer belast-baren Vertrauenskultur. Dabei sollte „Systemvertrauen“ als Vertrauen in institutionalisier-ten, betrieblichen Beziehungen ausdrücklich von persönlichem Vertrauen unterschieden werden, welches im Alltagshandeln und in persönlichen Beziehungen existiert.

Im Verbundprojekt StabiFlex-3D wurde dazu Systemvertrauen in drei Dimensionen differen- ziert (vgl. Abbildung 1): Die erste Dimension fokussiert auf die Vertrauenskultur innerhalb eines Teams. Bei dieser interpersonalen Dimension wird die Zusammenarbeit der Organisationsmitglieder untereinander in den Blick genommen. Hierzu zählen beispiels-weise die Beziehungen der Teammitglieder untereinander und zu Abteilungs- oder Gruppen- leitern. Des Weiteren ist für den betrieblichen Alltag wie auch für Veränderungsprozesse die intraorganisationale Dimension von immenser Bedeutung, welche die Zusammenarbeit

1 Aus Gründen der besseren Lesbarkeit wird im Text verallgemeinernd das generische Maskulinum verwendet. Diese Formulierungen umfassen gleichermaßen weibliche und männliche Personen; alle sind damit selbstverständlich gleichberechtigt angesprochen.


5

und das gegenseitige Verständnis der verschiedenen Organisationseinheiten eines Unternehmens umfasst. Zudem darf die unternehmensübergreifende interorganisatio- nale Dimension nicht vernachlässigt werden. Sie beschreibt beispielsweise die Kooperations- beziehungen mehrerer Niederlassungen eines Unternehmens und die Zusammenarbeit unterschiedlicher Unternehmen im Produktentstehungsprozess, in der „Supply Chain“ oder in der Abwicklung komplexer gemeinsamer Projekte.

Abbildung 1: Drei Dimensionen von Vertrauenskultur

Diese drei Dimensionen der Vertrauenskultur gilt es bei der Planung und Gestaltung von Alltagsprozessen wie auch der Durchführung von Veränderungsprojekten zu berücksich- tigen. Ausgangspunkt des Projekts StabiFlex-3D war die Hypothese, dass in wieder- kehrenden Prozessen stabil-flexible Standards durch ein optimiertes Verhältnis von Verlässlichkeit und Regelhaftigkeit besonders vertrauensstiftend und –erhaltend wirken. Diese Standards ermöglichen es den Mitarbeitern, sich im Alltag zu orientieren und schaffen die Möglichkeit einer situativen Anpassung. In Veränderungsprozessen ist dem-entsprechend ein partizipatives „Change Management“ erforderlich, um durch Einbindung der Beteiligten auch in betrieblichen Umbruchsituationen mit unsicheren oder gar bedroh-lichen Perspektiven Systemvertrauen zu erhalten (vgl. u.a. Zink et.al, 2009).


6

Das in diesem Rahmen entwickelte Konzept „Systemvertrauen“ zielt in seinen verschie-denen Facetten darauf ab, Unternehmen dabei zu unterstützen,

» die konkreten Potenziale und Risiken vertrauensbasierter Unternehmensführung so einschätzen zu können, dass sie für ihre Situation das rechte Maß im Spannungsfeld von Vertrauen und Kontrolle/Misstrauen finden sowie

» den Vertrauensprozess im Unternehmen darüber hinaus so zu gestalten bzw. zu beein-flussen, dass die Wahrscheinlichkeit von vertrauenswürdigem Verhalten (z. B. der Abgabe von belastbaren Versprechen, des Schließens von tragfähigen Vereinbarungen und des offenen, vertrauensfördernden Umgangs mit Abweichungen und Störungen) steigt und damit die Entstehung einer Kultur der Offenheit und des angemessenen Vertrauens gefördert wird.

Die nun vorliegenden Resultate des Projektes StabiFlex-3D lassen sich in drei Teilergeb-nissen bündeln. Diese können jeweils für sich stehen, sind aber auch in ihrer Gesamtheit interessant zu lesen. Um gerade interessierten Betriebspraktikern und internen wie externen Organisationsberatern den Zugang zu erleichtern, sind die Teilergebnisse einzeln als Publikation verfügbar.

Die Publikation „Das Konzept Systemvertrauen“ richtet sich vor allem an interne Organi-sationsberater, stellt aber auch einen Beitrag zur wissenschaftlichen Diskussion dar und thematisiert folgende Schwerpunkte:

» Klärung des Begriffs „Systemvertrauen“ und Überblick über die wissenschaftliche Diskussion. Dies soll ermöglichen, die Arbeiten im Projekt und die Ergebnisse in einem übergreifenden Kontext verorten zu können.

» Vorstellung des „Prozessmodells Systemvertrauen“ als strukturierte Darstellung repeti-tiver Abläufe, möglicher Entscheidungsoptionen sowie von Handlungs- und Interventions- möglichkeiten.

» Vorstellung des „Vertrauensdiagramms“ als ein Werkzeug zur Erfassung von Systemvertrauen. Am Beispiel eines betrieblichen Teilprojekts wird dargestellt, wie mit Hilfe dieses Werkzeugs vertrauensorientierte Interventionen in einem partizipativen Change-Projekt entwickelt und umgesetzt wurden.


7

Die Publikation „Systemvertrauen als betriebliche Ressource, Vertrauen messen – Instru-mentarium und Fallstudien“ richtet sich zunächst an Wissenschaftler, die in diesem Bereich arbeiten. Darüber hinaus soll sie Unterstützung für Berater liefern und schluss- endlich die interessierte Öffentlichkeit informieren. In dieser Publikation werden folgende Teilergebnisse dargelegt:

» Beschreibung der betrieblichen Fallbeispiele mit der jeweiligen Problemstellung und den dazu entwickelten Lösungsansätzen.

» Darstellung der in diesem Zusammenhang entwickelten und durchgeführten empi-rischen Untersuchungen,

» Zusammenstellung der wichtigsten Ergebnisse der Erhebungen.

Mit der hier vorliegenden Publikation „Agiles Projektmanagement in der Praxis der Pro-duktentwicklung“ sollen vor allem betriebliche Praktiker mit den folgenden Teilergebnissen angesprochen werden:

» Darstellung der Bedeutung von stabil-flexiblen Standards und partizipativem Change Management als Wege zu einer effektiven, vertrauensorientierten Prozessgestaltung im Unternehmen.

» Beschreibung der „agilen“ Methode „Scrum“ als Beispiel einer weit entwickelten Form stabil-flexibler Standards.

» Schilderung einer beispielhaften Umsetzung dieser Methode im Entwicklungsbereich eines betrieblichen Projektpartners, gestaltet als partizipatives Change Management.

» Erläuterung verschiedener Ansätze zur Verbreitung bzw. Transfers der Projekt- erfahrungen in weitere Unternehmen und andere betriebliche Kontexte.

Berlin und Chemnitz, im Frühjahr 2014

Die Herausgeber


8

2. Warum agile Methoden in der Produktentwicklung?

Jörg Longmuß, Gerhard Kullmann

Auf Grund zunehmender, Ländergrenzen übergreifender Zusammenarbeit und Arbeitsteilung werden besonders für die deutsche Industrie, als Lieferant komplexer Produkte und Sys-teme, veränderte Anforderungen an Produktentwicklungsprozesse deutlich. Insbesondere wachsen die Anforderungen an Koordination und Abstimmungen innerhalb von komplexen Projekten bezüglich der Beiträge der einzelnen Fachdisziplinen. Interdisziplinäre Zusammen-arbeit ist einer der Haupt-Wettbewerbsfaktoren der Gegenwart. Aktuell ist der Wirtschafts-presse zu entnehmen, in welchem Umfang gerade Probleme an dieser Stelle zu erheblichen Verzögerungen bei Großprojekten führen. Als Beispiele seien hier nur die neuen Flugzeuge von Boeing und Airbus oder der neue Hauptstadtflughafen in Berlin genannt.

Gleichzeitig wird in den einschlägigen Foren von Personalverantwortlichen intensiv darüber geklagt, dass es viel zu wenige Mitarbeiter gibt, die die notwendigen Qualifikationen und die als zwingend unterstellte Belastbarkeit für den Job als Projektmanager mitbringen. Zudem wird scheinbar unreflektiert der Umstand akzeptiert, dass es nicht möglich sei, eine anspruchsvolle Position als Projektleiter länger als fünf Jahre ohne Unterbrechung auszu-üben. Dies wird als eine Herausforderung an die Personalentwicklung verstanden, stellt aus unserer Sicht aber eigentlich eine Krise des klassischen Projektmanagements dar. Wenn es nicht mehr möglich sein sollte, Projekte ohne Burn-Out der Mitarbeiter zu managen, dann – diese Überlegung sollte erlaubt sein – stimmt vermutlich etwas mit den Standards nicht, auf deren Grundlage die Projekte durchgeführt werden. Die Frage war deshalb, wie Prozesse gestaltet sein müssen, in denen die Beschäftigten Lernen am Arbeitsplatz und das Prinzip der „Gesunden Arbeit“ mit effizienter Bearbeitung von Projekten verbinden können.

Außerdem hat in den letzten zehn Jahren der Trend, dass sich die Wertigkeit von Elektronik und Software im Produkt im Vergleich zum „herkömmlichen“ Maschinenbau deutlich ver-schiebt, die Produktentwicklungsprozesse in vielen Unternehmen stark verändert. Auch in klassischen mittelständischen Familienunternehmen, die im Maschinenbau tätig sind, spie-len heute Mitarbeiter mit einem anderen Hintergrund und fachlichen Verständnis als bisher üblich (Software-Entwickler, Elektroniker etc.) eine immer bedeutsamere Rolle. Die deshalb erforderliche Verbindung von Vorgehensweisen der Maschinenbau-Konstruktion mit Soft-wareentwicklungsmethoden (z.B. mit dem sehr systematisch / schematisch aufgebauten V-Modell) stellt für viele Führungskräfte in der Entwicklung eine Herausforderung dar.

Insofern lag die Frage nahe, ob es möglich ist, Methoden aus der Softwareentwicklung auf die Entwicklung des gesamten Produkts anzuwenden. Im Rahmen der Diskussion über Lean


9

Management fallen dabei besonders die Methoden der agilen Entwicklung ins Auge. Dies vor allem, da sie Grundhaltungen und Vorgehensweisen beinhalten, die im Maschinenbau in den Fertigungsbereichen bereits üblich sind, wie z.B. Kaizen und selbststeuernde Teams.

In der hier vorliegenden Publikation wird zum einen beispielhaft die Anwendung der aus der Softwareentwicklung stammenden agilen Methode „Scrum“ bei einem Unternehmen des elektrischen Apparatebaus dargestellt. Zum andern wird gezeigt, welche Grundlagen und Vorgehensweisen eine erfolgreiche Übertragung von agilen Methoden in die Entwicklung physischer Produkte allgemein möglich machen.


10

3. Ergebnis-Blitzlicht: Zu Besuch in der Entwicklungsabteilung

Jörg Bahlow

Als die Leistungselektronik-Entwicklerin P. nach ihrer Elternzeitpause zum ersten Mal wieder den langen Gang im Entwicklungsbereich entlang geht, traut sie zunächst ihren Augen nicht recht: Morgen um kurz vor neun – und alle Schreibtische scheinen verwaist. Findet heute die Betriebsversammlung oder gar der jährliche Betriebsausflug statt?

Wenige Schritte weiter bleibt sie verblüfft stehen und blickt in ein Büro: Vor einer großen Magnettafel mit vielen bunten Zetteln stehen dicht gedrängt sieben Kollegen im Halbkreis, sprechen angeregt und hören einander zu: Es scheint um ganz aktuelle Dinge zu gehen – was gestern geschah, was heute anliegt und wo Schwierigkeiten aufgetreten sind. Einige Türen weiter ein ganz ähnliches Bild, offensichtlich trifft sich hier ein anderes Team und klärt aktuelle Fragen für die tägliche Arbeit. So etwas hat es hier doch sonst nicht gegeben?

Keine halbe Stunde später, als sie zum zweiten Mal den langen Gang entlang geht, hat sich das Bild gewandelt: Alle sind am Schreibtisch wieder in ihre Arbeit vertieft, es scheint, als warte niemand auf die Gelegenheit zum Gespräch.

Was hat sich hier verändert in den letzten 12 Monaten? Welche geheimnisvollen, kurzen Besprechungen im Stehen finden hier statt – kaum begonnen, schon beendet, und sofort ist jeder zurück in seiner Arbeit? Es muss etwas mit diesem „Scrum“ zu tun haben, von dem der eine oder andere Kollege schon mal am Telefon berichtet hatte.

In der Kantine trifft sie dann einen der internen Kunden des Entwicklungsbereichs, den Pro-duktmanager M. aus der Business Unit 5. Was sagt er wohl als interner Kunde der Entwicklung zu den gravierenden Veränderungen? „Am Anfang waren wir schon etwas überrascht und auch verärgert: Was jahrelang doch immer irgendwie ging, scheint jetzt mit „Scrum“ nicht mehr möglich. Wenn ich etwas dringend brauchte, die richtigen Leute anrief und ordentlich drängelte, notfalls auch ein zweites, drittes, viertes Mal, bekam ich am Ende noch immer das was fehlte. Seit einiger Zeit aber werde ich – egal wen ich anrufe – auf die aktuellen Prioritäten laut einer sogenannten „Sprint-Planung“ des Teams verwiesen. Inzwischen habe ich aber festgestellt, dass zwar das alte „Mach mal eben“ nicht mehr geht, dafür aber die zugesagten Termine eingehalten werden, und zwar verlässlich. Und das ist eigentlich besser als je zuvor.“

Was es damit auf sich hat – und was außer diesen kurzen täglichen Meetings im Team noch dazu gehört – darum soll es auf den nächsten Seiten gehen: Lassen Sie sich überraschen.


11

4. „Scrum“ als Methode für agiles Projektmanagement

Jörg Bahlow, Martin Helfer, Gerhard Kullmann, Jörg Longmuß

Herausforderungen in der Produktenwicklung und das Konzept der stabil-flexiblen StandardsDie Prozessgestaltung und das Projektmanagement in der Entwicklung physischer Pro-dukte, besonders im Maschinen- und Fahrzeugbau, sind beständig in der Diskussion und Weiterentwicklung (z.B. Longmuß, 2003; Longmuß & Buchholtz, 2004; Kötter, Kullmann & Pieper, 2009; Anderl, Eigner, Sendler & Stark, 2012). Allgemeingut ist mittlerweile die Fest-stellung, dass Entwicklungszeiten kürzer werden und der internationale Konkurrenzdruck zunimmt. Darüber hinaus wird auch eine möglichst nahtlose Integration von „klassischem“ Maschinenbau, Elektronik und Software zu einer weiteren zentralen Herausforderung (Bahlow & Kullmann, 2012).

Der Frage nach zielführenden Ansätzen im Umgang mit diesen Herausforderungen hat sich auch das Verbundprojekt „StabiFlex-3D“ gestellt und griff dabei auf das Konzept der „stabil- flexiblen Standards“ zurück. Dieses bietet einen Ausweg aus dem Spannungsverhältnis von

» komplexen, nicht vollständig erfassbaren Aufgabenstellungen (die eine vollständige Standardisierung von Abläufen unmöglich machen)

» und dem Bedarf an stabilen Ablaufstrukturen, ohne die eine übergreifende Planung und Steuerung nicht möglich ist.

Das Konzept hat sich bereits in verschiedenen Kontexten bewährt, die Einsatzgebiete reichen dabei von Kleinbetrieben bis zu großen Fertigungswerken, von innovativen Start-Up Unter-nehmen bis zu seit langem etablierten Familienunternehmen (vgl. z.B. Zink et al., 2009; Kötter & Helfer, i.A.; Kötter, 2010; Kötter, Bahlow, Kullmann & Stahlmann, 2011; Kötter, Kullmann & Stahlmann, 2012). Das Konzept „stabil-flexibler Standards“ und seine Herleitung werden im Kasten auf der nächsten Seite erläutert. Es stellt zudem eine sinnvolle Ergänzung mit dem Ansatz von Systemvertrauen als entscheidendem Faktor bei Kooperationen in betrieb-lichen Zusammenhängen dar (vgl. Band 1 dieses Forschungsberichts „Das Konzept System-vertrauen“, Longmuß et al., 2012). Im Projekt wurde es folgendermaßen definiert:

Stabil-flexible Standards beschreiben betriebliche Vorgehensweisen (und die ggf. dafür zu nut-zenden Arbeitsmittel) für einen längeren Zeitraum so eindeutig, dass deren Reproduzierbarkeit und damit die nötige Stabilität der Unternehmensprozesse gesichert ist, und erlauben gleichzei-tig hinreichende situative Flexibilität, um sich ändernden Rahmenbedingungen, Erfordernissen und Chancen angemessen gerecht werden zu können.


12

Dieses Konzept ist für den jeweiligen Anwendungsbereich zu spezifizieren. Insbesondere um eine Integration verschiedener Fachdisziplinen – und hier speziell einen Anschluss der Vorgehensweisen im Maschinenbau an in der Softwareentwicklung etablierte Methoden – zu erreichen, wurde es mit dem Ansatz der „agilen Methoden“ verbunden.

In Kürze: Stabil-flexible StandardsStandards sind bei der Arbeitsgestaltung und im Projektmanagement im Interesse von Effizienz, Transparenz und Steuerbarkeit unerlässlich. Je nach Kontext findet der Begriff „Standards“ Verwendung bei der Bezeichung:

1. „standardisierte Arbeit“ nach Standard-Arbeitsblättern, mit Standard-Vorrichtungen und Standard-Anordnungen von Arbeitsplätzen (auf der Ebene der Arbeitsprozesse, vgl. dazu ausführlich bereits Takeda, 1995)

2. eines Standard-Methodenset auf der Systemebene, wie es z.B. für Produktent- stehungsprozesse vielfach diskutiert und eingesetzt wird (vgl. dazu z.B. Longmuß, 2003)

In diesem Text soll ausschließlich auf die zweite Auffassung Bezug genommen werden. Hierbei führt die Verwendung von festen Standards zu einem potenziellen Dilemma:

» Entweder die Beschäftigten ignorieren die Standards, wenn diese die notwendige Flexibilität, auf Unvorhergesehenes reagieren zu können, behindern und verhalten sich situationsadäquat. Damit gewährleisten sie flexible Reaktionen des Betriebs, ohne die die Wettbewerbsposition gefährdet wäre. Sie geraten dadurch allerdings in Rollenkonflikte, gefährden die Reproduzierbarkeit ihres Handels und agieren als „Flexibilitätspuffer“, denn im Misserfolgsfall wird ihnen zum Vorwurf gemacht, dass sie Regeln verletzt haben. Gleichzeitig wird von den Vorgesetzten diese Regel- verletzung implizit jedoch erwartet, „damit der Laden läuft“.

» Oder die gesetzten Standards werden strikt eingehalten, was zu bürokratischen Aus-wüchsen führen kann, die unrühmlich bekannt sind: Die Unternehmen verlieren ihre Reaktionsfähigkeit gegenüber dem Nicht-Planbaren und das Potenzial qualifizierter, mitdenkende Mitarbeiter, das für die Leistungsfähigkeit deutscher Unternehmen eine wertvolle Ressource darstellt, wird nicht genutzt.


13

Als Ausweg aus diesem Dilemma bietet sich das Konzept der „stabil-flexiblen Stan-dards“ (gestützt u.a. auf arbeitspsychologische Forschungen, vergl. z.B. Volpert, 1980, 2003; Munzert, 1989) an, die sich im Verständnis des Forschungsprojektes so beschreiben lassen:

» Stabil-flexible Standards geben klare Orientierung über das geforderte Ergebnis (Was?) und über die dabei verfügbaren Arbeitsmittel und Vorgehensweisen (Womit? Wie?), eröffnen aber gleichzeitig explizite Spielräume für die konkrete Ausführung (Wie genau?) in Abhängigkeit von dem situationsspezifisch geforderten Arbeits- ergebnis (Was genau?) und den situativen Rahmenbedingungen.

» Stabil-flexible Standards setzen klare Grenzen (z. B. indem festgelegt wird, wie kom-muniziert und dokumentiert werden muss) und fördern gleichzeitig Eigenaktivität und Eigenverantwortlichkeit („Auftrags-Taktik“, nicht „Befehls-Taktik“) und geben dabei lösungsorientierte, die Eigenkompetenz und Kreativität aktivierende Unterstützung (z. B. durch Kreativitätstechniken, Verfahrensangebote etc.).

Stabil-flexible Standards verzichten auf detaillierte Festlegung von Einzelaktivitäten, Operationen etc., wo das „Wie?“ – eine entsprechende Qualifikation vorausgesetzt – durch das Ergebnis (und ggf. Zwischenergebnisse) und durch den zur Verfügung stehenden Zeitraum hinreichend genau definiert werden kann.

Das Ausmaß und die Grenzen der jeweils erforderlichen Reproduzierbarkeit und der sinnvollen Flexibilität werden für jeden Kontext spezifisch zu klären bzw. zwischen den Beteiligten zu vereinbaren sein. Stabil-flexible Standards können so dazu beitragen, eine Balance von Flexibilitätsanforderungen und Stabilitätsbedürfnissen bei der Gestal-tung von Arbeitsprozessen und Projektmanagement in Unternehmen zu erreichen.

„Scrum“ – eine „agile Methode“Bereits seit Beginn der 90er Jahre wurden in der Softwareentwicklung erste Ansätze der damals noch „leichtgewichtig“ genannten Methoden erstellt, die eine Alternative zu den vor-herrschenden, als schwerfällig gesehenen Methoden wie dem „V-Modell“ bieten sollten. 2001 formulierten Softwareentwickler das Agile Manifest, das in Abbildung 2 übersetzt und leicht verallgemeinert dargestellt ist (siehe z.B. Gloger, 2009). Seither ist die Bezeichnung „agile Methoden“ üblich.


14

Abbildung 2: Das agile Manifest (in Anlehnung an www.agilemanifesto.org, 2001)

Für die Erprobung und Weiterentwicklung im Rahmen des Verbundprojekts wurde „Scrum“ als eine agile Methode ausgewählt. Ursprünglich für die Softwareentwicklung konzipiert, gewinnt es mitt-lerweile weit darüber hinaus auch in der physischen Produktentwicklung an Bedeutung. Wie auch andere agile Methoden betont „Scrum“ Commitment, Fokussierung, Offenheit und Respekt – alle-samt Aspekte einer Unternehmenskultur, die wichtige Vorrausetzungen für Systemvertrauen darstel-len. „Scrum“ fördert dabei direkte Kommunikation und kurze Feedback-Schleifen. Es setzt außerdem, was nicht für alle agilen Methoden gilt, auf die Selbstorganisation in motivierten Teams. Der Begriff „Scrum“ stammt aus dem Rugby und bedeutet dort das „geordnete Gedränge“ zu Beginn jedes Spielabschnitts. Sinngemäß wird damit gesagt: „Vor jedem Angriff die Köpfe zusammen stecken!“.

Ziele der Anwendung von „Scrum“ sind

» Höhere Reaktionsfähigkeit auf sich ändernde Kundenanforderungen

» Kürzere “Time to Market“

» Höhere Qualität und Kundenzufriedenheit

» Bessere Nahtstellen zu Vertrieb, Engineering, Einkauf und Fertigung

Individuen undInteraktion

FunktionierendeProdukte

Zusammenarbeitmit Kunden

Offenheit für Änderungen

Prozesse und Tools

ausführlicheDokumentation

Vertrags‐verhandlungen

striktes Befolgeneines Plans

wichtigerals ...

Wir erkennen sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr.


15

Dies soll dadurch erreicht werden, dass der Entwicklungsprozess in kürzere Phasen – in „Sprints“ von 2 bis 4 Wochen – unterteilt wird, zu deren Beginn sich die Teams jeweils über Inhalte und Zeiteinteilung abstimmen (vgl. Abbildung 3). Die Teamorganisation wird dabei einfach und übersichtlich gehalten. Es gibt

» drei verschiedene Rollen,

» vier Arten von Meetings,

» drei Arten von Dokumenten und

» ansonsten wenige Regeln, auf deren Einhaltung allerdings sehr geachtet wird.

Abbildung 3: „Scrum“ im Überblick

„Scrum“ kennt nur drei klar abgegrenzte Rollen (vgl. Abbildung 4):

» den Product Owner, der die Ziele der Entwicklung, die zu realisierenden Features und ihre Prioritäten festlegt. Er repräsentiert die Erwartungen der Nutzer, der Kunden und des Managements und trägt die wirtschaftliche Verantwortung für das Projekt. Seine Aufgabe besteht weiterhin darin, das Projekt inhaltlich zu steuern, gegebenenfalls Prioritäten zu setzen und Entscheidungen zu treffen. Darüber hinaus pflegt er das Product Backlog (vgl. S. 17).

Input von Kunden,

Management, Team, ...

Team

Scrum Master

Sprint Review

Sprint Backlog

Product BacklogSprint

Planning Meeting

Product Owner2

WochenSprint

Daily ScrumMeeting

Aufgaben

Priorisierte Liste:

Was wird benötigt?

12345678

Endtermin und Ziel des Sprints

bleiben unverändert

Erledigte Aufgaben, erreichte

Arbeitsergebnisse

15 min

Auswahl, Schätzung,

Commitment

Scrum im Überblick

GITTAmbH.de


16

» das Team, das sich eigenständig organisiert und unter anderem die Aufwände für die eigenen Aufgaben schätzt. Es realisiert eigenverantwortlich die Anforderungen aus dem Product Back-log und verpflichtet sich dazu, in einem festgelegten Zeitraum bestimmte Ziele zu erreichen.

» den „Scrum“-Master, der dafür sorgt, dass das Team produktiv und störungsfrei arbeiten kann, der Verbesserungspotenziale ermittelt und die Arbeitsbedingungen des Teams opti-miert. Er coacht die Beteiligten, ist aber kein Projektleiter und hat weder Weisungsbefugnis noch inhaltliche Verantwortung.

Abbildung 4: Die „Scrum“-Rollen


17

Abläufe von „Scrum“Der Ablauf von „Scrum“ wird strukturiert durch drei Dokumente, die im Prozessverlauf entstehen, und vier verschiedene Meetings. Die Dokumente sind:

» Die User-Story beschreibt anschaulich aus Nutzersicht die Anforderungen an das Produkt. Sie dient den Entwicklern als zusätzliche Information zur Planung und Priorisierung von Anforderungen an das Produkt (vgl. Abbildung 5).

» Das Product Backlog listet die gewünschten Eigenschaften des zu entwickelnden Produkts auf. Es ist jederzeit erweiterbar und für Input von allen Beteiligten offen. Diese Punkte wer-den allerdings vom Product Owner priorisiert, niedriger bewertete Punkte werden ggf. nicht realisiert.

» Im Sprint Backlog werden die Aufgaben festgehalten, die das Team im Sprint erledigen muss, um sein Commitment zu erfüllen. Es gehört dem Team und wird separat vom Product Backlog gehalten.

Abbildung 5: „Scrum“-Dokumente


18

Meeting-Arten und deren Abfolge (vgl. Abbildung 6):

» Das Planning Meeting steht am Anfang jedes Sprints. Teilnehmer sind das Team, der Product Owner und der „Scrum“-Master. Es umfasst zum einen die inhaltliche Planung des Sprints, zum anderen das Commitment zu den jeweiligen persönlichen Ergebnissen und zur Einhaltung der Termine. Für die Planung eines 14-tätigen Sprints lässt sich als Richtwert ein zeitlicher Aufwand von vier Stunden ansetzen.

» Während des Sprints wird von Team und „Scrum“-Master ein kurzes tägliches „Scrum“-Mee-ting durchgeführt, das 15 Minuten oder kürzer dauert und immer zur gleichen Zeit am selben Ort im Stehen (anders braucht es in der Praxis immer deutlich mehr Zeit!) stattfindet. Darin berichten die Teilnehmer, was sie seit dem letzten Meeting getan haben, was sie bis zum folgenden Meeting erreichen wollen und welche Hindernisse auf dem Weg dorthin bestehen. Der „Scrum“-Master nimmt dies auf und versucht, Schwierigkeiten für das Team aus dem Weg zu räumen. Fachliche Diskussionen finden erst im Anschluss und nur zwischen den betroffenen Personen statt.

» Beim Review Meeting nimmt neben Team und „Scrum“-Master auch wieder der Product Owner teil, ggf. auch weitere Interessierte. In etwa ein bis zwei Stunden führt das Team die Ergebnisse aus der gerade abgeschlossenen Sprintphase direkt vor, ohne sie in Folien zu übersetzen.

» Nach dem Review findet in gleicher Zusammensetzung die Retrospektive statt, moderiert vom „Scrum“-Master. Dabei wird der Prozess besprochen: „Was lief gut, was können wir besser?“. Das Ergebnis sind konkrete Veränderungen für den nächsten Sprint.

Abbildung 6: Die Abfolge der Meetings

SprintSprint

Sprint PlanningMeeting

Daily Scrum MeetingSprint Review Meeting

Sprint Retrospektive


19

„Scrum“ als eine Form stabil-flexibler StandardsEs gibt zu „Scrum“ bereits ein formuliertes Set an Regeln aus der Software-Entwicklung. In den nächsten Kapiteln wird gezeigt, wie diese Regeln auch auf die Entwicklung physischer Produkte übertragen werden können. Sie sind erprobt und geben ausreichend Orientierung über Arbeitsmittel und Vorgehensweisen. Ihre positiven Effekte liegen in der Eigenverantwort-lichkeit, die den Teams übertragen wird und die zu größerer Motivation und Identifikation mit den Aufgaben führen.

Zusammenfassend heißt dies:

» „Scrum“ ermöglicht eine stabil-flexible Zielerreichung, indem das Gesamtziel im Fokus bleibt, während für die zweiwöchigen Sprints Teilziele gebildet werden, die dem Arbeits-stand, aber auch erkannten Chancen, Risiken und Herausforderungen flexibel angepasst werden können.

» Es gibt klare Rollen und damit weniger Reibungen an den Schnittstellen.

» Transparenz, Offenheit und kontinuierliche Rückmeldungen sind gesichert.

» Dadurch sind insgesamt stabilere Prozesse mit weniger Behinderungen durch unnötige Regulierungen gewährleistet.

» Es entsteht eine vertrauensvolle Zusammenarbeit innerhalb der Teams und zwischen Teams und der Leitung.


20

5. Potenziale und Effekte von „Scrum“

Jörg Bahlow, Jörg Janning, Helmut Jebenstreit, Gerhard Kullmann

Betriebliche ErfahrungenEinige Aspekte der Effekte von „Scrum“ sollen hier anhand von Erfahrungen der Autoren in verschiedenen Unternehmen, die vor vergleichbaren Herausforderungen stehen, dargestellt werden. Im Vordergrund steht dabei der Bereich Research & Development der GE Energy Power Conversion GmbH der General Electric Company, der als Praxispartner im Verbund- projekt mitgewirkt hat und zu Projektbeginn noch als Converteam GmbH firmierte.

Gekennzeichnet war dieser Unternehmensbereich durch eine Struktur aus sechs Geschäfts-feldern (Business Units) und einer übergreifenden, für alle Geschäftsfelder tätigen Ent-wicklungsabteilung. Innerhalb der Entwicklungsabteilung wurden die fachlichen Aufgaben in den Bereichen Software, Hardware und mechanische Konstruktion bearbeitet. Ihre zen-trale Aufgabe bestand darin, die Anforderungen unterschiedlicher Märkte zu verstehen und Konzepte zu deren Erfüllung zu entwickeln sowie die daraus folgenden Aufgaben angemessen zu priorisieren und effizient abzuarbeiten.

Durch die Herausforderung, Kundenanforderungen aus verschiedenen Märkten parallel zu erfüllen, war es in der Praxis nicht möglich, das sich einzelne Entwickler oder Teams über längere Zeiträume mit nur einem Projekt befassten. Dies brachte ein komplexes Management von Kapazitäten und Terminen mit sich. Außerdem waren immer dann umfangreiche Abstimmungen zu technischen Konzepten und deren Umsetzung erforderlich, wenn gleichartige oder ähnliche Fragestellungen aus verschiedenen Geschäftsfeldern vorlagen. Daraus folgten hohe Anfor- derungen an Koordination und Transparenz, denen das Arbeiten mit „Scrum“ gerecht werden musste.

Was bewirkt „Scrum“?

1. „Scrum“ schafft Transparenz

Durch » klare Kommunikationsstrukturen,

» Fokussierung auf Aufgabenpakete und

» überschaubare zeitliche Horizonte

schafft „Scrum“ Transparenz über die zu leistende Arbeit, die in Entwicklungsabteilungen häufig nicht in diesem Umfang gegeben ist.


21

Die gemeinsame Abschätzung der benötigten Kapazitäten für die Entwicklung eines Teilpro-dukts dient als guter Prüfstein, ob der Auftraggeber (Product Owner) und das Team die gleiche Vorstellung von den Inhalten einer Aufgabe haben. In der Praxis zeigte sich, dass, wenn diese Schätzungen weit auseinander lagen, in der Regel die Aufgabe nicht klar genug beschrie-ben war. Durch die Aufteilung der Entwicklungsarbeit in einzelne Pakete und die Pflicht zur Berichterstattung in festgelegten Rhythmen kann der Product Owner gut verfolgen, ob die Entwicklung noch an den Kundenbedürfnissen ausgerichtet ist. Dies verhindert auch, dass Entwickler Features für das Produkt entwickeln, die für eine Erfüllung der Anforderungen nicht zwingend notwendig sind.

Für die Mitarbeiter liegt der Vorteil der Transparenz des Entwicklungsprozesses darin, dass sie sich sicher sein können, an den jeweils wichtigsten und dringlichsten Aufgaben zu arbeiten. Gerade in Situationen, in denen mehrere Bereiche um Kapazitäten konkurrieren, können so wertvolle Ressourcen möglichst zweckmäßig eingesetzt werden. Außerdem senkt die regel-mäßige Planung die „geistigen Rüstzeiten“ und verhindert Unterbrechungen. Damit sind eine deutliche Steigerung der Produktivität und eine Senkung der persönlich empfundenen Bean-spruchung verbunden. In allen beteiligten Teams und Gruppen wurde genau dies von den Mitarbeitern als motivierend und positiv empfunden. Eine anfangs von manchen Vorgesetzten befürchtete Abwehrhaltung der Mitarbeiter gegen die Einführung von „Scrum“, weil das mit zunehmender Transparenz möglicherweise auch ihre Arbeit zu sehr kontrollierbar werden könnte, war hingegen kaum zu erkennen.

2. „Scrum“ sorgt für Entlastung

„Scrum“ schafft mit seinem klaren Rollenkonzept Entlastung der bisher üblichen Rolle eines Projektmanagers, der im Zweifelsfall für alles zuständig war. Gleichzeitig sorgt das Konzept von Aufgaben- und Verantwortungsteilung dafür, dass innerhalb der Entwicklerteams auch selbstorganisiertes Arbeiten möglich wird, dessen positive Effekte auf die Motivation hinreichend bekannt sind.

„Scrum“ wirkt hier als stabil-flexibler Standard und schafft mit der Kombination aus Hand-lungsspielraum und Leitplanken genau jenen Raum, der im klassischen Projektmanagement oft fehlt – und den sich die Mitarbeiter dann völlig losgelöst von allen Kundenanforderungen selbst nehmen (müssen). Im konkreten Fall organisierten die Mitarbeiter das „Springen“ zwischen verschiedenen Projekten eigenverantwortlich und konnten so „geistige Rüstzeiten“ und Doppelarbeit minimieren. Die Planung von Sprint zu Sprint führte zu einer wesentlich größeren Termintreue und senkte vor allem die Anzahl an störenden Nachfragen sowie an Task Force- Besprechungen und ähnlichen, extern gesteuerten Abstimmungsverfahren.


22

3. „Scrum“ schafft günstige Bedingungen für Lernen

Durch die klare Fokussierung eines Teams auf abgeschlossene Arbeitsaufgaben und die gegenseitige Präsentation der Ergebnisse im Team ergibt sich immer wieder die Möglichkeit des individuellen und kollektiven fachlichen Lernens. Eine der wesentlichen Aufgaben des „Scrum“-Masters an dieser Stelle besteht darin, die Diskussionen so zu gestalten, dass Fach-diskussionen und Arbeitsplanung getrennt bleiben und es ein definiertes Zeitfenster für fach-liches Lernen gibt, ohne dass fachliche Detaildiskussionen die gemeinsame Arbeit behindern.

„Scrum“ sorgt durch kurze Planungszyklen und gegenseitige Abstimmung dafür, dass im Ent-wicklungsprozess von Einzelnen gewonnene Erkenntnisse, in den weiteren Arbeitspaketen von allen genutzt werden können. Dabei kann es sinnvoll sein, nicht in jedem Fall den fachlich versiertesten Mitarbeiter einzusetzen (der dann auch weiter als einziger für dieses Aufgaben-gebiet qualifiziert bliebe), sondern zur Verbreiterung der Qualifikation und zur Erhöhung der Ersetzbarkeit bewusst andere mit der Aufgabe zu betrauen, die sich auf diese Weise – in einem gesicherten Rahmen – einarbeiten können.

4. „Scrum“ fordert und fördert selbstorganisiertes Arbeiten

Ein klassisches Dilemma in sehr vielen Entwicklungsabteilungen besteht darin, dass die einzelnen Entwickler fachlich hoch eigenverantwortlich arbeiten müssen und auch können, terminlich aber oft stark fremdgesteuert sind. Dies ergibt sich zum einen aus der Notwendig-keit von Kooperation und der Verschränkung eigener Ergebnisse mit denen der Kollegen. Ein weiterer Grund ist zum anderen die oft praktizierte Trennung zwischen Projektmanagement – verstanden als Verfolgung von Terminen und Budget – und fachlicher Arbeit im engeren Sinne. Dadurch müssen sich die Entwickler Vorgaben beugen, die der fachlichen Logik und der erforderlichen „Eigenzeit“ guter Ergebnisse widersprechen – mit den bekannten Folgen von Überlastung und fachlichen wie qualitativen Risiken.

„Scrum“ als festes Set an Regeln für die Selbststeuerung in der Entwicklung kann hier in Zukunft von großer Bedeutung sein. Es ermöglicht ein Zusammenführen dieser oft getrennten Perspektiven, führt zu einer ganzheitlichen Arbeitsaufgabe und damit zu mehr Motivation und einem abnehmenden Belastungsempfinden. Dilemmata zwischen den Anforderungen mehre-rer Projekte selbst zu managen und dafür auch die Verantwortung zu haben, hat im beschrie-benen Praxisfall zu einer deutlichen Verringerung der empfundenen Belastung geführt. Was in der Produktion mit der Einführung von „schlanken“ Methoden mitunter erreicht wurde – die Verbindung von Handlungsspielraum und Standards – kann so auch in der (Produkt-)Entwick-lung zu ähnlichen Effekten führen.


23

5. „Scrum“ trägt zur Gesundheitsförderung bei

Aus der Gesundheitsforschung ist bekannt, dass zu den größten Stressoren in der Projektarbeit Termindruck und Fremdbestimmtheit gehören (vgl. Becke Bleses & Schmidt, 2011). Dies kann zu psychischen und mitunter direkt zu physischen Belastungen und gesundheitlichen Schä-den führen. Die Arbeit in „Scrum“-Teams hingegen ermöglicht es den Mitarbeitern, die eigene Arbeitsorganisation gesundheitsförderlich zu beeinflussen:

» Zum einen, indem die Teams fokussiert arbeiten und sich klare Ziele setzen. Bei der Arbeit mit „Scrum“ bieten sich gute Möglichkeiten, Ziele so zu gestalten, dass sie Kriterien gesundheitsförder-licher Zielvorgaben erfüllen, nämlich realistisch, erreichbar, individuell anpassbar und beeinflussbar, messbar formuliert und terminiert, persönlich bedeutsam und kompatibel mit anderen Zielen zu sein.

» Zum anderen ist mit der ganzheitlichen Aufgabenbearbeitung (Planung – Priorisierung – Auswahl der Mittel – Durchführung – Ergebniskontrolle) im Allgemeinen ein erheblicher Lerneffekt hinsichtlich der Entwicklung einer Kompetenz zur realistischen Planung von Auf-wänden und Anforderungen bei der Aufgabenerfüllung verbunden. Erfahrungen aus ver-gangenen Planungen können direkt in die neue Planung einfließen, wodurch die Planung insgesamt treffsicherer und Stress in weiterer Folge reduziert wird.

In dieser Hinsicht wirkt „Scrum“ als Mittel zur Stressprophylaxe und trägt zum Schaffen gesünderer Arbeitsbedingungen auch in Entwicklungsabteilungen bei.

6. „Scrum“ hilft bei der Bewältigung der demografischen Entwicklung

„Scrum“ hilft innovative Formen für alternsgerechtes Arbeiten zu entwickeln und mit dem abseh-baren Ausscheiden älterer Erfahrungsträger konstruktiv umzugehen, u.a. durch die Zusammenstel-lung altersgemischter Teams. Diese erlauben es älteren Mitarbeitern, ihre Belastung schrittweise zu reduzieren. Gleichzeitig werden, durch die enge Zusammenarbeit und die regelmäßige Kommunika-tion, Lernpotentiale genutzt und ein gezielter Wissenstransfer zwischen den Mitarbeitern ermöglicht.

Erfahrungen aus der Praxis zeigen, dass der Austausch von Wissen zwischen älteren und jüngeren Mitarbeitern in beide Richtungen stattfinden: Erfahrungen aus bisherigen Projekten, wie die Realisierbarkeit unterschiedlicher Lösungsansätze oder Besonderheiten bestimmter Kunden, werden hauptsächlich von den älteren an die jüngeren Kollegen weitergegeben. Die Jüngeren bringen hingegen oft neue Methoden ein (z. B. Simulationstechniken, moderne Pro-grammiertechniken), die ihnen aus dem Studium oder anderen Lernsituationen vertraut sind, mit denen die Älteren bislang nicht in Berührung gekommen sind oder kaum Erfahrungen haben.


24

6. Was ist wichtig bei der Durchführung? 7 goldene Regeln

Gerhard Kullmann, Jörg Bahlow

1. „Scrum“ kann produktorientiert, aber auch kompetenzorientiert sein In der Literatur wird „Scrum“ in der Regel als Projektmanagementmethode beschrieben, die einen klaren Produkt- und Projektbezug hat. Für Entwicklungsbereiche, in denen eine Vielzahl von fachlich sehr unterschiedlichen Kompetenzen benötigt werden – was zumindest außerhalb der IT-Branche sehr oft der Fall ist – zeigen Erfahrungen aus der Praxis jedoch, dass auch andere Formen der Organisation möglich und sinnvoll sein können. Diese beiden grundsätzlichen Formen sind produktorientierte „Scrum“-Teams und kompetenzorientierte „Scrum“-Teams.

A. Produktorientierte „Scrum“-Teams

Entlang der Produkte, d.h. für jedes Produkt / Projekt wird ein Team eingesetzt, das sich aus ver-schiedenen Fachrichtungen / Abteilungen rekrutiert und über die verschiedenen Entwicklungs-schritte hinweg zusammenbleibt, also von der Konzeptdefinition bis zur Serienreife / Fertigungs-freigabe. Dies empfiehlt sich, wo die zentrale Herausforderung in der komplexen disziplin- bzw. bereichsübergreifenden Zusammenarbeit besteht. Diese feste Zuordnung von Mitarbeitern zu Pro-dukt-Teams bedeutet allerdings, entweder Schlüsselressourcen früh und passgenau festzulegen oder gegebenenfalls die Zusammensetzung der Teams immer wieder zu ändern – im Zweifelsfall für jeden Sprint. Diese müsste sich nach den jeweils aktuellen Aufgaben und damit erforderlichen Qua-lifikationen richten und auf Arbeitsstand und Mitarbeiterbedarf anderer Projekte abgestimmt werden.

Vorteile:

» Die Fokussierung auf ein Gesamtziel (Produktionsstart, Liefertermin etc.) ist deutlich ein-facher. Ressourcen- und Terminkonflikte lassen sich dadurch besser lösen („Braucht ihr die Messungen wirklich alle bis morgen? Welche sind kritisch? Wo sollen wir zuerst anfangen, damit ihr weiterkommt?“ etc.).

» Übergreifendes Lernen am Gesamtprozess führt dazu, dass die beteiligten Mitarbeiter ein tiefes Verständnis hinsichtlich der Produkte sowie des Entwicklungsprozesses in seiner gesamten Komplexität entwickeln.

» Für das Management und ggf. den Kunden ist eine direkte Ansprache des Entwick-lungsteams möglich.

» Es entsteht eine starke interdisziplinäre Kooperation innerhalb des Teams und es bieten sich


25

Lernchancen über das eigene Fachgebiet hinaus („Wenn ich diese Lösung wähle, haben die anderen folgendes Problem / folgenden Nutzen.“). Dies muss aber von der Führung und vom „Scrum“-Master aktiv gefördert und eingefordert werden.

Nachteile:

» Fachliches Lernen im eigenen Arbeitsgebiet findet innerhalb von produktorientierten „Scrum“-Teams weniger statt, weil die Teammitglieder im Wesentlichen mit fachfremden Kollegen zusammenarbeiten.

» Die schwere Ersetzbarkeit der Teammitglieder untereinander schränkt die Möglichkeiten zur Selbststeuerung ein (etwa wenn der Regelungstechniker krank ist, können die Mechaniker im Team nicht helfen).

» Es besteht immer die Gefahr, dass sich Subteams bilden und somit das gemeinsame Ziel und das geteilte Verständnis wie dieses zu erreichen ist, aus den Augen verloren werden. Darüber hinaus könnte aus Sicht von einzelnen Mitgliedern in den Treffen zu lange über Themen gesprochen werden, die nur einen Teil des Teams betreffen.

B. Kompetenzorientierte „Scrum“-Teams

Sie werden entlang der Kompetenzen gebildet, die in der Entwicklung des Produktes zum Einsatz kommen. Dies kann bedeuten, dass sich ein Team z.B. nur mit Hardware der Elektronikentwick-lung befasst, diese Aufgabe aber für alle einschlägigen Produkte / Projekte übernimmt. Diese Variante bietet sich dort an, wo die Herausforderung vor allem in der fachlichen Tiefe besteht.

Vorteile:

» Das „Scrum“-Team kann sich sehr gut selbst steuern, und zwar nicht nur in der Alltagsarbeit (z.B. durch wechselseitiges Zuweisen von Tätigkeiten untereinander und Tausch von Aufgaben innerhalb eines Sprints), sondern etwa auch in der Qualifizierungsplanung und -umsetzung.

» Die Treffen des „Scrum“-Teams werden auch zum fachlichen Austausch genutzt und erhö-hen so die Qualität der Lösungen und die Qualifikation des Einzelnen.

Nachteile:

» Da kein direkter Produktbezug existiert, gibt es auch keine Fokussierung auf die Produktziele.


26

» Multi-Projektmanagement ist anspruchsvoller, da jedes Projekt quer zu den „Scrum“-Teams geplant und gesteuert werden muss.

» In sich abgeschlossene Arbeitsaufgaben und direkte Rückmeldungen über die Gesamt-qualität der gefundenen Lösungen sind schwieriger zu definieren, sofern dies überhaupt möglich ist.

Abbildung 7: Orientierungsrahmen der „Scrum“-Teams

„Scrum“-Teams können entweder nach Kompetenzen (z.B. Regelungstechniker) oder nach Produkten (beteiligt z.B. an einem speziellen Umrichter) organisiert werden (vgl. Abbildung 7).

2. „Scrum“ braucht eine definierte Anforderungsliste In sehr frühen Phasen der Entwicklung, in denen eher freie Suchbewegungen gefragt sind, kann „Scrum“ explizite Kreativtechniken (z.B. Design Thinking) nicht ersetzen, auch wenn in Findungsphasen „Scrum“-ähnliche Arbeitsstrukturen genutzt werden können, etwa regelmäßige kurze Treffen und eine feste Vereinbarung von Zielen und/oder Vorgehensweisen für über-schaubare Zeiträume. Wenn aber weder ein Kundenauftrag noch ein definiertes Ergebnisziel vorliegen, sind auch Sprintziele und entsprechend Arbeitsumfänge nicht definierbar.

Regelungs-technik

Leistungs-elektronik Konstruktion

Kom

pete

nz

PRODUKT

Scru

m

Scrum Niederspannungs-Umrichter

Scrum Mittelspannungs-Umrichter

Scru

m


27

Die große Stärke von agil organisierten Projekten ist die Offenheit für Änderungen im Prozess. Wenn sich die Frage nach Änderungen aber nicht stellt, weil alle Suchrichtungen offen sind, werden andere Methoden benötigt – „Scrum“ würde ins Leere laufen. Deshalb kann „Scrum“ erst sinnvoll eingesetzt werden, wenn eine erste Anforderungsliste vorliegt, die in der Regel vom Vertrieb bzw. internen Kunden formuliert wird (vgl. Abbildung 8).

Es ist somit eine wichtige Aufgabe des Managements, den Punkt innerhalb eines Entwicklungs-prozesses zu bestimmen, ab dem „Scrum“ einzusetzen ist. Daraus ergibt sich auch die Anfor-derung, mit der Bestimmung der angewendeten Arbeitstechniken deutlich zu unterscheiden, in welcher Phase (z.B. Ideengenerierung oder Umsetzung) sich das Projekt befindet.

Abbildung 8: „Scrum“ braucht eine definierte Anforderungsliste


28

3. „Scrum“ muss auf einem definierten Produktentstehungsprozess aufsetzenIn der fachlichen Diskussion wird oftmals davon ausgegangen, dass sich klassisches Projekt-management und agile Methoden gegenseitig ausschließen (vgl. u.a. Müller, 2010; Zeitler, 2011). Dies lässt sich mit den praktischen Erfahrungen im Projekt StabiFlex-3D allerdings nicht belegen. Im Gegenteil ist ein Zusammenwirken von klassischem Projektmanagement und der agilen Methode „Scrum“ bei der Entwicklung außerhalb des IT-Umfeldes und bei komplexeren Produkten nicht nur möglich, sondern scheint sogar wesentlich für maximalen Erfolg.

Um Anzahl wie Inhalte der Sprints planen zu können, muss ein Rahmen vorhanden sein, in dem sich der „Scrum“-Prozess bewegt. Dazu gehören Budgets, Meilensteine und Schnittstel-len, die in etwas größeren Unternehmen / Projekten in einem systematischen, projektübergrei-fenden Produktentstehungsprozess (PEP) definiert sein sollten (vgl. Longmuß, 2003). In diesen PEP muss „Scrum“ eingepasst werden (vgl. Abbildung 9). Der Zuschnitt der Teams, Zahl und Dauer der Sprints etc. müssen sich an dessen Aufgabenzuschnitten und Zeitvorgaben ausrichten.

Umgekehrt kann auch aus den Anforderungen, die sich aus der Arbeit mit „Scrum“ ergeben, ein PEP entwickelt werden. So können

» die übergreifenden Meilensteine wie Abschluss der Konzeptentwicklung, Design Freeze, Abschluss Testphase etc. aus dieser Arbeit hergeleitet werden,

» die einzelnen Entwicklungsphasen sich an der zeitlichen Taktung der Sprints orientieren und

» die Möglichkeiten zur inhaltlichen Koordination verbessert werden (im Gegensatz zum herkömmlichen Projektmanagement, in dem stärker über Macht und Struktur geregelt wird).

Gleichzeitig verändert die Orientierung von „Scrum“ auf Teilergebnisse in relativ kurzen Zeiträumen auch die Art der Planung und Projektarbeit, z.B. durch

» frühe Prototypen,

» abgeschlossene Arbeitsgänge (z.B. definitive Freigabe der Stückliste im Enterprise Ressource Planning,

» Zusammenarbeit und Abstimmung im „Scrum“-Team und nicht über Projektleiter und Teil-projektleiter etc.


29

Bei mehreren parallelen Entwicklungsprojekten – in vielen Unternehmen die Regel – entfaltet „Scrum“ durch sein Rollenkonzept und die kurzen Zyklen mit klaren Zielen neue innovatonsorien-tierte Möglichkeiten des Multiprojektmanagements. Die große Herausforderung hierbei besteht in der Komplexität der Planung und Steuerung aller Entwicklungsschritte und der benötigten Ressourcen über mehrere Projekte hinweg. Die kooperative Zusammenarbeit von Product Ownern und „Scrum“- Mastern ermöglicht eine Verlagerung dieser Aufgabe näher an den Ort ihrer Erledigung. Die „Scrum“- Master können sich auf der Grundlage von viel gröberen (und damit gegen Änderungen robusteren) Plänen untereinander im Detail direkt abstimmen – und zwar angesichts der aktuell eingetretenen Situation mit den immer wieder vorkommenden Verzögerungen, Änderungen und Mehraufwänden. Die feste zeitliche Struktur über die Sprintdauer bietet solchen Abstimmungen einen verlässlichen Rahmen („Du bekommst die Ressource nicht irgendwann, sondern innerhalb dieses Sprints.“).

Abbildung 9: „Scrum“ setzt auf den PEP (Produktentstehungsprozess) auf

4. „Scrum“ hat einen unverzichtbaren Kern „Scrum“ muss in der Ausgestaltung auf das jeweilige Unternehmen mit seiner Kultur sowie seinen übergeordneten Strukturen und Prozessen angepasst werden. Gleichzeitig darf dieses Customizing den Kern der Methode nicht übergehen (vgl. Abbildung 10). Damit die „Scrum“-Prozesse die in sie gesetzten Erwartungen erfüllen, müssen

» Selbststeuerung und Eigenverantwortung, um im Entwicklungsprozess innerhalb des eigenen Gestaltungsbereichs Änderungen vornehmen zu können,

» ausreichend Kapazitäten und Knowhow, um dies auch bewältigen zu können sowie

» Orientierung auf abgeschlossene Teilaufgaben und frühe lauffähige/präsentable Teil- ergebnisse gewährleistet bleiben.


30

Abbildung 10: Unverzichtbare Kernelemente von „Scrum“

5. „Scrum“ braucht definierte Rückmeldeschleifen und Eskalationswege „Scrum“ funktioniert bis zu einer gewissen Grenze als „Black Box“ für höhere Hierarchieebenen. Durch die Selbststeuerung sind die Prozesse innerhalb der Teams nicht jederzeit nach außen transparent. Solange ein Team die gestellten Anforderungen bewältigt, ist dies auch nicht problematisch – diese Verantwortungsübergabe ist durchaus beabsichtigt. Wenn allerdings Änderungsbedarf oder Verwerfungen in einem Ausmaß auftreten, dass die übergeordneten Prozesse, z.B. die Kundenabnahme eines Prototyps, absehbar nicht mehr eingehalten wer-den können, dann sind Anpassungen des aktuellen Projektplans unerlässlich. Die Wege wie dies schnell, klar und transparent an die übergeordnete Struktur (Linienvorgesetzte, Project Management Office etc.) zurückgemeldet werden kann, sind zu klären und einzuhalten. Auch wenn der „Scrum“-Master z.B. mit der Forderung nach Ressourcen oder Handlungsspielräu-men für das Team scheitert, muss diese Information direkt weitergegeben und ggf. eine Ent-scheidung zügig getroffen werden können.

Die Notwendigkeit definierter, direkter Kommunikationswege gilt auch in umgekehrter Richtung: Wenn strategische Entscheidungen im Interesse des Gesamtunternehmens die Bedeutung einzelner Projekte, deren Priorität und/oder kapazitive Ausstattung verändern, müssen sich die „Scrum“-Teams dem unmittelbar operativ anpassen. Hier könnte jedoch in projektorientierten


31

Strukturen mit mehr Widerstand und Frustration zu rechnen sein als in herkömmlichen Struk-turen, da die damit beabsichtigte Übernahme von Verantwortung so abgebrochen wird. Deshalb müssen solche Kursänderungen sorgfältig begründet und umfassend kommuniziert werden. Außerdem müssen sie eine Ausnahme bleiben, die nur unter besonderen, nicht vor-hersehbaren Gründen eintritt. Wenn solche Änderungen häufiger auftreten, ist entweder der übergreifende Produktentstehungsprozess, dessen Schnittstelle zur „Scrum“-Organisation oder die Arbeit der „Scrum“-Teams bzw. deren Aufgabenstellungen zu revidieren.

6. „Scrum“-Teams müssen abgestimmt arbeiten In vielen Fällen werden verschiedene „Scrum“-Teams gleichzeitig an Entwicklungen oder, bei produktorientierten „Scrum“-Teams, Querschnittsaufgaben arbeiten. Hierdurch kann anfangs eine Verschlechterung der Kooperationsbereitschaft an den Rändern der Teams erlebt werden. Deshalb ist es Aufgabe des Managements, deren Kooperation und Zusammenarbeit entspre-chend zu koordinieren und zu standardisieren, u.a. durch

» gleiche Sprintlängen,

» wechselseitiges Offenlegen der Backlogs – im Idealfall sollte jedes Team die Backlogs der anderen nicht nur lesen, sondern auch Anforderungen einfügen können,

» Regelkommunikation der Product Owner, der „Scrum“-Master und einzelner Teammitglieder z.B. durch „Scrum of Scrums“ als Teil einer übergreifenden verbindlichen Struktur (vgl. Abbildung 11).

Abbildung 11: Regelkommunikation im „Scrum of Scrums“


32

7. „Scrum“-Teams brauchen Vertrauen Innerhalb eines „Scrum“-Teams ist ein ebenso hohes Maß an Vertrauen erforderlich wie zwischen den „Scrum“-Teams und der Führung. Innerhalb des Teams ist Vertrauen wichtig, damit Probleme gemeinsam gelöst werden können, insbesondere auch dadurch, dass

» Aussagen, speziell auch Bedenken anderer Teammitglieder ernst genommen werden,

» eigene Schwächen oder selbst als unbefriedigend erlebte Arbeitsfortschritte nicht kaschiert werden müssen und

» Unsicherheiten hingenommen werden können, weil das grundlegende Vertrauen vorhanden ist, sich auch dann auf die anderen verlassen zu können, wenn man selbst das Problem nicht vollständig überblickt.

Analog kann eine Führungskraft in der Rolle des Product Owners aufgrund eigener Ein- schätzungen oder wegen Vorgaben von Kundenseite die Auffassung vertreten, ein bestimmtes Pensum müsse für einen Entwicklungsschritt ausreichen, während das „Scrum“-Team aufgrund seiner Erfahrungswerte einen größeren Zeitraum für erforderlich hält. Ein tragfähiges Commitment kann aber nur dann entstehen, wenn die Entwickler bei der Vereinbarung von anspruchsvollen, aber erreichbaren Sprintzielen Vertrauen der Führung in ihre Erfahrungen und Angaben erleben.

Es gibt Unternehmen, in denen die Entwicklungsbereiche so klein sind und die Kultur so ver-trauensvoll, dass besondere Maßnahmen zur Vertrauensbildung nicht erforderlich sind. Ist dies nicht der Fall, ist zu klären, an welchen Punkten das Vertrauen zu stärken ist. Dazu wurde innerhalb des Projekts StabiFlex-3D das Analyseinstrument „Vertrauensdiagramm“ ent-wickelt (vgl. Abbildung 12). Es beschreibt in den Kategorien Beziehung, Prozess und Struktur insgesamt neun Dimensionen, die konstituierende Merkmale von Systemvertrauen sind (Helfer & Longmuß, 2012). Mit diesem Instrument kann eine gestörte Vertrauensbeziehung daraufhin untersucht werden, in welchen Dimensionen Defizite vorliegen. Diese sollten dann durch spezifische Maßnahmen ausgeglichen werden: etwa in Puncto Kompetenz ausgemachte Defizite durch Schulungen oder auch tiefgehende Fachgespräche, ungenügende Transparenz durch Verabredung von Vorgehensstandards etc.


33

Abbildung 12: Das Vertrauensdiagramm

0510152025Kompetenz

Handlungs‐spielraum

Rollenklarheit

Transparenz

KommunikationKooperation

Zuverlässigkeit

Fairness

Feed Back

Struktur

Prozess

Beziehung


34

7. Ein Blitzlicht auf den Veränderungsprozess

Jörg Bahlow

Eines Tages lag bei allen Teamleitern der Entwicklungsabteilung die Einladung des Abteilungs-leiters zu einem seltsam anmutenden Workshop im Posteingang. Von Lean Production war da die Rede und von Agilem Projektmanagement, aber auch um Stärken und Schwächen im Entwicklungsprozess aus Sicht von Teamleitern und Kunden sollte es gehen. Lean und kreative Entwicklung – wie sollte das zusammenpassen?

Nun ja, sogenannte Workshops mit klugen Vorträgen über ganz neue, vielversprechende Methoden und Standards hatte es über die Jahre hinweg immer mal wieder gegeben. Zu konkreten Veränderungen oder gar Verbesserungen in den erlebten Arbeitsprozessen hatte so etwas jedoch noch selten geführt, zumindest soweit die Erinnerung der Beteiligten zurück reichte. Doch irgendetwas schien diesmal anders zu laufen. Schon beim Betreten des Info-Centers zu Beginn des Workshops fiel die ungewohnte „Sitzordnung“ ins Auge: Statt des mächtigen, u-förmigen Konferenztisches ein Halbkreis aus drei Stuhlreihen, außerdem zahlreiche Pinnwände und Flip Charts im Raum. Sollte dies etwa ein Workshop werden, in dem die Teilnehmer nicht nur zuhören, sondern auch arbeiten (müssen)?

Tatsächlich ging es zunächst einmal darum, ein geteiltes Bild über Stärken, Schwächen und Verbesserungsbedarf in den Entwicklungsprozessen zu erarbeiten. Und da kam jeder zu Wort, nicht nur Chefs und übliche Vielredner. Auch aus Sicht der internen Kunden in Business Units und Fertigung wurde ein ungeschminktes Bild der Lage gezeichnet. Es gab nicht nur Lob und Aner-kennung zu hören, sondern auch offene, konstruktive Kritik und klare Verbesserungswünsche.

Bald sollte sich zeigen, dass dieses neue Vorgehen keine Eintagsfliege bleiben sollte, sondern den weiteren Veränderungsprozess prägen würde: klare Zielorientierung durch die Führung, konsequente Beteiligung von Teamleitern und Arbeitsebene an Konzeptentwicklung, Erpro-bung und schrittweiser Optimierung in der täglichen Praxis.

Anfangs waren auch Skepsis zu spüren und Befürchtungen zu hören, man könne zu sehr in die Mitverantwortung für die Gestaltung der künftigen Entwicklungsprozesse genommen werden – das sei doch schließlich Aufgabe der Führung. Über die folgenden Monate hinweg formte sich jedoch das Bild eines Veränderungsprozesses mit

» offenem, konstruktivem Umgang mit Kritik und unterschiedlichen Sichtweisen,

» Beratern und Prozessbegleitern, die nachfragen und nicht schon alles (besser) wissen,


35

» Führungskräften, die zuhören und selbst Position beziehen, aber sich nicht schon vorab festgelegt haben sowie

» vielfältigen Ideen für eine agile Vorgehensweise, deren Konzept noch nicht feststeht, son-dern unter Nutzung des Erfahrungswissens von Teamleitern und Mitarbeitern erst entsteht.

Wie das im Einzelnen vor sich ging, welche Herausforderungen in diesem Prozess der Vor-bereitung und Umsetzung eines agilen Vorgehens in der Produktentwicklung zu bewältigen waren und was sich daraus für künftige Vorhaben lernen lässt – darum soll es auf den nächsten Seiten gehen.


36

8. Der Einführungsprozess

Jörg Bahlow, Jörg Janning, Helmut Jebenstreit, Gerhard Kullmann

Der Einführungsprozess einer neuen Organisationsform hat entscheidenden Anteil daran, ob diese zu den Rahmenbedingung und der Unternehmenskultur passt bzw. passend gemacht werden kann. Außerdem beeinflusst er stark, ob sie von den Beteiligten (den Mitarbeitern und den verschiedenen Führungsebenen) akzeptiert und auf Dauer mitgetragen wird. Deshalb muss er sorgfältig geplant und umgesetzt werden.

Besonderheiten von „Scrum“ in der physischen ProduktentwicklungZunächst scheint es nahezuliegen – um Ressourcen zu schonen und unerwartete Schwie-rigkeiten zu vermeiden – den Einführungsprozess von „Scrum“ direkt aus der Software- Entwicklung zu übernehmen. Wie bereits in Kapitel 2 angesprochen, verschwimmen ohnehin in verschiedenen Bereichen der Produktentwicklung die fachlichen und methodischen Grenzen zwischen der Entwicklung von Software und von physischen Produkten. Allerdings zeigt bereits ein erster Blick in die einschlägige Literatur zu „Scrum“ (vgl. u.a. Schwaber, 2007; Gloger, 2009) viele Begriffe und Gedankenmodelle, die keine direkte Entsprechung in der physischen Produktentwicklung haben. Dort gibt es im Allgemeinen und besonders im vorliegenden Change- Projekt eine Reihe von Unterschieden zur Software-Entwicklung, die es erfordern, sowohl die Struktur als auch den Einführungsprozess zu verändern:

» Die Vielfalt der Fachdisziplinen, die an einem Produkt arbeiten: Es ist mehr Austausch über fachliche Inhalte notwendig, weil die Verständigung über Disziplingrenzen hinweg (Informatik, Elektrotechnik, Maschinenbau etc.) schwieriger ist als etwa innerhalb der Infor-matik – was oft schon schwierig genug ist.

» Der hohe Spezialisierungsgrad: Beispielsweise gab es Projekte, in denen zwei Leistungs-elektroniker erforderlich waren, weil sich ihr spezifisches Fachwissen zu sehr unterschied, als dass einer ausgereicht hätte. Deshalb ist eine andere Form der Ressourcenplanung erforderlich, um mit der ggf. schwierigen Verfügbarkeit spezieller Fachkräfte umzugehen.

» Die Problematik, Anforderungen zu modularisieren: Es ist häufig schwierig, teilweise sogar unmöglich, die Anforderungen des Kunden in relativ kleinteilige Module zu übersetzen, die nacheinander abgearbeitet werden können.

» Stückweise Fertigstellung als Grundelement von Software-„Scrum“: Hierbei entsteht, ermöglicht durch die Modularisierung, zum Ende jedes Sprints ein Stück fertiger Soft-ware-Code, der vom Kunden getestet und ggf. abgenommen werden kann. Dies ist in der


37

physischen Produktentwicklung in dieser Form oft nicht möglich, weil die handhabbaren Ein-heiten in der Regel sehr viel größer sind, sofern eine Unterteilung in Teilprodukte überhaupt möglich ist. Wenn eine Nutzbarkeit von Teilergebnissen wegen mangelnder Anschaulichkeit für den Kunden nicht zu beurteilen ist, muss dessen Rolle von einem internen Experten (z.B. Abteilungsleiter, Vertriebsmitarbeiter o.ä.) übernommen werden.

» Das Fachvokabular in der Literatur und die damit verbundenen Konzepte: Beispiels-weise ist die Darstellung von Anforderungen in der Form von „User-Stories“ ein etabliertes Vorgehen in der Software-Entwicklung, das nicht direkt übertragbar ist, weil der Kunde bei physischen Produkten aus o.g. Gründen zu vielen Teilfunktionen bzw. Modulen keinen direkten Bezug hat.

In Kürze: Partizipatives Change ManagementVielfältige Erfahrungen zeigen, dass Change Management dann besonders erfolg-reich ist, wenn partizipative Prozesse der Entwicklung und Implementierung von ganz-heitlichen Vorgehensweisen in Gang gesetzt werden (vgl. z.B. Zink u.a., 2009). Bei radikalen Strategiewechseln und fundamentalen Entscheidungen über die Zukunft (Geschäftsfeldverlagerungen, Werksschließungen etc.) wird ein partizipatives Vorge-hen zwar in aller Regel nicht in Frage kommen, für die Ausgestaltung der danach eingetretenen Situation aber sehr wohl. Durch einen solchen strategieumsetzenden Partizipationsprozess wird die Effizienz der Mitarbeiterbeteiligung zum entscheidenden Erfolgsfaktor für ein kontinuierlich hohes Qualitätsniveau und für die Innovationsfähig-keit von Unternehmen.

Beteiligungs-Interventionen sind vor allem dann erfolgreich, wenn ein gemeinsames Bild der Ausgangslage hergestellt werden kann, in dem alle Beteiligten ihre Sichtweise wiederfinden, und wenn es gelungen ist, sich auf ein gemeinsames Ziel und die dazu passenden Maßnahmen zu verständigen. Dann bestehen gute Aussichten, dass die Beteiligten die Realisierung und Stabilisierung der so entstandenen Veränderung zu ihrer eigenen Sache machen (vgl. z.B. Kötter, 2009). Deshalb nutzen wir folgende Definition:

Partizipatives Change-Management bezeichnet die Findung und Umsetzung von Konzepten für neue betriebliche Organisationsformen und Vorgehensweisen unter aktiver Einbeziehung der Beteiligten im Unternehmen, um eine optimale Passung die-ser Konzepte zu erreichen und die Motivation aller Mitarbeitenden zu fördern.


38

Zum Verhältnis von partizipativem Change-Management und stabil-flexiblen Standards:

Partizipatives Change Management und stabil-flexible Standards beziehen sich auf unterschiedliche Situationen in einem Unternehmen und hängen doch eng zusam-men. Während Ersteres betriebliche Umorientierungen gestaltet und in der Regel unter anderem die Etablierung (neuer) stabil-flexibler Standards zum Ziel hat, sind diese Standards ein wesentlicher Bestandteil des – regelungstechnisch gesprochen – „eingeschwungenen Zustandes“, d.h. einer stabilisierten Situation.

Dabei ergeben sich aus der Anwendung eines Standards womöglich neue Erkennt-nisse, z.B. über Belastungen für die Mitarbeiter oder über weitergehende Optimie-rungspotentiale (vgl. Abbildung 13). Deshalb sind definierte Verfahren wie z.B. KVP erforderlich, die eine kontinuierliche Weiterentwicklung der Standards gewährleisten. Die Aussicht, auch nach der Erstentwicklung eigene Erfahrungen einbringen und Einfluss auf die Weiterentwicklung der Standards nehmen zu können, kann die Akzep-tanz von Standards, die Einsicht in deren Notwendigkeit und die Motivation erhöhen, an ihnen mitzuarbeiten (Schröder & Steimle, 2009).

Abbildung 13: Das Prinzip der partizipativen Standardisierung Darstellung in Anlehnung an Schröder & Steimle, 2008

partizipative Entwicklung eines

Standards


39

Der Weg zu einem angepassten Konzept

Beteiligung des Führungskreises:

Partizipation beginnt damit, den Führungskreis einzubeziehen. Zuerst muss das Projektanlie-gen von den anderen Führungskräften verstanden, geteilt und unterstützt werden – von der Unternehmensspitze wie von den Führungskräften, die möglicherweise betroffene / beein-flusste Bereiche verantworten (auch als „Leadership Alignment“ bezeichnet). Nur wenn sich die Führung auf eine gemeinsame Linie verständigt hat, können querliegende oder gar konträre Führungsimpulse im Projektverlauf vermieden werden. Dazu gehört wesentlich eine gemein-same Zielklärung (nicht unbedingt Erarbeitung der Ziele) im Management.

Leitplanken für den weiteren Prozess:

Häufig wird Partizipation verstanden als „die Mitarbeiter mitnehmen“ – wie Fahrgäste in einem Bus mitgenommen werden. Fahrgäste können aber weder das Fahrziel des Busses bestimmen noch seine Geschwindigkeit, die Haltestellen etc. Für partizipatives Change-Management ist es hingegen wichtig, dass die Mitarbeiter auch Gestaltungsmöglichkeiten haben. Zum einen können so die Konzepte besser passend ausgerichtet werden für die spezifische Arbeitsum-gebung, zum anderen wird in der Regel nur durch Mitgestaltung eine echte Identifikation der Mitarbeiter mit dem Veränderungsprozess erreicht. Der Umfang dieser Gestaltungsmöglich-keiten muss vorab geklärt sein, um einerseits (durch die deutliche Öffnung von Spielräumen) den Gestaltungswillen der Mitarbeiter anzuregen und gleichzeitig Frustrationen zu vermeiden, wenn Gestaltungswünsche nicht erfüllt werden können. Wird etwa ein neues Konzept innerhalb eines Konzerns über mehrere Standorte ausgerollt, können diese Gestaltungsmöglichkeiten im Interesse einheitlicher Prozesse nur sehr begrenzt sein. Ist, wie im unten dargestellten Fall, das Konzept noch nicht im Einzelnen festgelegt, können die Spielräume erheblich größer sein.

Veränderungsvorhaben in die operative Führung hineintragen:

Je nach Unternehmensgröße und Zuschnitt der betroffenen Bereiche ist mit den Führungs-kräften vor Ort, z.B. Team- oder Gruppenleitern, das Konzept um eine Bestandsaufnahme zu ergänzen, ggf. auch erst im Detail auszuarbeiten, einzelne Richtungsentscheidungen sind zu treffen und Optionen der Umsetzung zu klären. Falls die Führung über die Realisierbarkeit eines Konzepts unsicher ist, kann sogar hier erst die Entscheidung fallen, ob ein Konzept überhaupt umgesetzt werden soll. Auf jeden Fall ist vor Beginn dieser Phase zu entscheiden, ob die operative Ebene die Möglichkeit hat, „nein“ zu sagen.


40

Dann erst kann die Arbeit auf der Arbeitsebene beginnen, d.h. neue Vorgehensweisen zu klären und umzusetzen. Es gilt als zweckmäßig ein neues Konzept nicht schlagartig im gesamten Unternehmen einzuführen, da dies zunächst eine sehr große Kraftanstrengung bedeuten würde. Des Weiteren ist es schwierig neue Erkenntnisse, die ggf. im Einführungsprozess gewonnen werden konnten, umzusetzen. Eine Pilotphase in einem Teilbereich ist hingegen ein guter Praxistest. Ist diese ausgewertet, kann das „Roll-Out“ in allen Bereichen gestartet werden. Dabei ist darauf zu achten, die Beobachtung und Begleitung des Prozesses nicht zu früh abzubrechen, sondern eine Stabilisierungsphase vorzusehen, in der neue Verfahrenswei-sen eingeübt werden und ggf. im Einzelnen das Konzept noch einmal verfeinert werden kann.

Von der Idee zum Umsetzungserfolg: Das Vorgehen an einem praktischen BeispielWie die Übertragung von „Scrum“-Prinzipien außerhalb der Software-Branche konkret durch-geführt werden kann und welche Meilensteine und Hürden es dabei zu meistern gilt, soll nach-folgend anhand der erfolgreichen Einführung von „Scrum“ in der Entwicklung von elektrischen Anlagen bei GE Energy Power Conversion GmbH exemplarisch verdeutlicht werden.2

Wie kam es zu der Entscheidung?

Ausgangspunkt war ein Strategieworkshop im vierköpfigen Führungsteam der Entwicklungs-abteilung mit dem Ziel, Verbesserungsmöglichkeiten im Entwicklungsprozess zu identifizieren (vgl. Abbildung 14).

Abbildung 14: Agiles Entwickeln mit „Scrum“

2 Dieses Unterkapitel entspricht weitgehend Bahlow & Kullmann, 2012

1. IST-Analyse im Führungskreis

2. Vergemein-schaftung IST-Analyse Ergebnisse Erarbeitung von

Verbesserungen und Anpassungen

1.Selbständig

2.Gemischte Gruppen

Monat 2April

1. Teammit-gliederbenennen

2. Team-Netzwerk starten

1. Scrum-Grobkonzepterstellen

2. Projekt-Spielregeln festlegen

Town-Meeting

1Leitplanken-Workshops I

+ II2

Team-Benennung+Start

3

5

5

4

Monat 3September

Monat 4-6Oktober bis Dezember

U-Team-Sitzung

wöchentlich

Monat 7Januar

Top-Workshop

Arbeit Team-Netzwerk


41

Dabei gab es in der Bestandsaufnahme eine offene Reflexionsrunde zu den Schwachstellen und Risiken jener Projekte, die schwierig verlaufen waren sowie zu den Stärken jener Projekte, die sich durch besonders gute Ergebnisse und reibungsarmen Ablauf ausgezeichnet hatten. Es wurden mehrere Handlungsfelder benannt, darunter eine Verbesserung des Kundenkontakts im Entwicklungsprozess. Als Konsequenz wurde „Agiles Entwickeln mit ‚Scrum‘ “ ein wichtiges Projekt des übergreifenden Entwicklungsvorhabens „Research & Development 20xx“.

Einige Wochen später fanden sich die Teamleiter des Entwicklungsbereiches mit ihren Abtei-lungsleitern und dem Bereichsleiter zu einem interaktiven Workshop ein. Auf der Agenda stand, neben einer Bestandsaufnahme zu Stärken und Schwächen im Entwicklungsprozess (aus Sicht der Teamleiter sowie aus Sicht relevanter Kunden und Stakeholder), die „konkrete Planung für ein Pilotvorhaben ‚Scrum‘ “. Nach Auswertung der Bestandsaufnahme und einer kritisch-konstruktiven Diskussion über Anwendbarkeit und Anpassbarkeit der vorgestellte „Scrum“-Vorgehensweise auf die eigenen Entwicklungsprojekte waren sich die Beteiligten einig: „Die Zeit ist reif, wir bilden ein Planungsteam und bereiten die konkrete Erprobung von „Scrum“ in einem Pilotbereich vor!“ Beide Optionen eines Zuschnitts von „Scrum“-Teams – entlang der Kompetenz der (Linien-)Teams und entlang der zu entwickelnden Produkte (siehe Kapitel 6) – sollten verfolgt werden.

Konzeptentwicklung: Was bietet „Scrum“ und was brauchen wir?

Das Planungsteam zeichnete sich durch eine bereichs- und hierarchieübergreifende Mischung aus Teamleitern (die zugleich als Senior Developers/Engineers tätig sind) und Bereichslei-tern aus. Allen Befürchtungen der Skeptiker zum Trotz gelang es in wenigen, hocheffizienten Meetings zunächst anhand eines transparenten Sets von Kriterien vier geeignete Pilot-Teams auszuwählen (2x Produkt- und 2x Kompetenz-„Scrum“, vgl. Abb. Abbildung 6: Die Abfolge der Meetings in Kap 6) und anschließend die Aufgaben, Kompetenzen und Verantwortung (AKV) für die Rollen Product Owner, „Scrum“-Master und Teammitglied in einer Übersichtstabelle (vgl. Abb. 4 in Kap 4) zu beschreiben. Zur Vorbereitung des Starts der Pilotphase wurden im Planungsteam die Regeltermine und -orte für Planungs- und Review-Meetings sowie „Daily Scrums“ für die vier Pilotteams festgelegt.

Die Pilotphase: Kann das denn so gehen?

Im Start-Workshop für die dreimonatige „Pilotphase Scrum“ fanden sich alle Mitglieder der vier Pilotteams für zwei intensive Workshop-Tage zusammen. Neben der Vermittlung von Basis-Know-how über das, „was bisher geschah“ und „Scrum“ als agile Vorgehensweise zur Produktentwicklung, stand bald die Frage an, welche ganz konkreten Arbeitspakete, Issues


42

und Teilaufgaben für jedes der Teams in das aktuelle Product Backlog, den „Aufgabenvorrat“ gehören. Am Ende des Start-Workshops konnte jedes Pilotteam sein vollständiges Backlog in Form der hier dargestellten Tabelle auf einer Pinnwand mit in die unmittelbar anschließende Start-Woche für den „Scrum“-Prozess nehmen.

Abbildung 15: Backlog als Tabelle (Muster)

Während der Pilotphase traf sich das „Planungsteam“ unter Beteiligung der vier Teamleiter zunächst 14-tägig, um aktuelle Fragen und Probleme aus den Pilotteams anzusprechen und sorgte so durch zeitnahe Abstimmung und Entscheidung für eine kontinuierliche Prozess- begleitung. Später fanden diese regelmäßigen Treffen sogar wöchentlichen statt und wurden zu einem übergreifenden Rahmen für Feedback, Reflexion und kollegiale Beratung, an dem auch einfache Teammitglieder teilnehmen konnten. Hier konnten praktische Probleme sofort gelöst werden, das Konzept wurde ausgebaut und weiterentwickelt.

Auswertung und Weiterentwicklung

Im Auswertungs-Workshop nach dreimonatiger „Scrum“-Praxis bewerteten Pilot-Teams und Product Owner jeweils getrennt, wie sich

» Zielorientierung und -erreichung,

» Entscheidungsprozesse und -qualität,

» Problemlösungsprozess und gegenseitige Unterstützung,

Nr. Name der Aufgabe Wichtigkeit(0-3)

Aufwand Test / Vorführung Urheber Notizen / Wünsche


43

» Zusammenarbeit mit anderen Teams und Bereichen sowie

» die Klarheit der Rollen im „Scrum“-Prozess

in ihrer Arbeit während der Pilotphase verändert hatten. Das Ergebnis fiel eindeutig aus: Durch-weg sehr gute bis gute Bewertungen mit der Einschränkung, dass Entscheidungsprozesse im Team mitunter noch zu lange dauerten. Außerdem wurde die Rolle des Product Owners als desjenigen, der eindeutige Prioritäten setzt, besonders in den kompetenzorientierten Teams nicht immer konsistent wahrgenommen. Dies hatte seine Ursache in einer Rollenüberlastung der Teamleiter: Sie fungierten teilweise in ihrer bisherigen Rolle mit fachlicher Weisungsbe-fugnis - was bei „Scrum“ die Aufgabe des Product Owners ist – und teilweise als „Scrum“- Master, der ausschließlich Prozessverantwortung hat und für hilfreiche Rahmenbedingungen sorgen soll. In diesen Fällen kam die Rolle des Product Owners den Linienvorgesetzten, d.h. den Bereichsleitern zu. Da der Trend hin zu produktorientierten Teams ging, stellte sich dieses Problem in der Folge allerdings immer weniger.

Aus diesen Erfahrungen und Bewertungen aller Beteiligten im Pilotprozess wurden im Hinblick auf die weitere Umsetzung von „Scrum“ zunächst Chancen und Risiken identifiziert (vgl. Abbildung 16).

Abbildung 16: Chancen und Risiken bei der Umsetzung von „Scrum“

Anschließend wurden konkrete Empfehlungen formuliert für die Vervollständigung des Konzepts, für eine verbesserte Kommunikation im Unternehmen und für den „Roll-Out“-Pro-zess auf alle übrigen Teams und Bereiche der Entwicklung. Wichtige Punkte waren:

Beispiele für genannte Chancen:

» effizientes Zusammenarbeiten» bessere Aufgabenerfüllung » Aufgaben beenden» bessere Zusammenarbeit auch an

Schnittstellen» zuverlässige Aufwandseinschätzung» Termine besser einhalten» besseres Teamwork

(Unterstützung)

Als Risiken wurden z.B. genannt:

» hoher Planungsaufwand (auch zwischen Teams/ Abteilungen)

» Nachlässigkeit beim „Daily-Scrum“ » Zeiten zu hoch ansetzen » zu viele Störungen zerstören das

Prinzip» „Scrum“ wird von anderen

Abteilungen nicht ernst genommen


44

Abbildung 17: Wichtige Punkte im „Roll-Out“-Prozess von „Scrum“

Als ständige Herausforderung wurde zusätzlich genannt, die Sitzungen so zu leiten, dass es für das fachliche Lernen angemessenen Raum gibt. Dabei muss immer wieder darauf geachtet werden, dass jeder Mitarbeiter die Fragestellungen des jeweils anderen wirklich verstanden hat – die Überschriften von Arbeitspaketen reichen nicht zwangsläufig aus – das Gespräch sich aber nicht in technischen Details verliert (vgl. Abbildung 17).

„Roll-Out“ und Stabilisierung

Nach Bestätigung der Empfehlungen aus dem Auswertungs-Workshop durch Entwicklungs-leitung und Geschäftsführung wurde unmittelbar die Vorbereitung des „Roll-Out“-Prozesses in Angriff genommen. Nun galt es, mit Hilfe der notwendigen Informations- und Qualifizie-rungs-Workshops innerhalb von sechs Wochen in zwei Wellen sieben weitere Entwick-lungsteams in den „Scrum“-Prozess zu schicken.

In den Start-Workshops der „Roll-Out“-Wellen I und II übernahmen ein „Scrum“-Master und zwei Teamleiter aus der Pilotphase eine tragende Rolle: Sie berichteten sehr persönlich über ihre Erfahrungen mit „Scrum“ aus den letzten Monaten und sprachen offen über Stolpersteine und die erlebten Schwierigkeiten sowie über gemeinsame Erfolgserlebnisse. Außerdem formu-lierten sie konkrete Empfehlungen für den bevorstehenden „Scrum“-Start der neuen Teams. Durch diese Erfahrungsberichte aus erster Hand stellte sich die Situation im Start-Workshop für die neuen Teams in den Wellen I und II allerdings deutlich anders dar als für die Pilot-Teams. Angesichts der Berichte aus den Pilot-Teams, die auch Probleme nicht aussparten, bedurfte es der Behandlung zahlreicher Fragen und Bedenken: Ob die Spezialisierung im eigenen Team nicht doch zu hoch sei, die Möglichkeiten zur gegenseitigen Unterstützung überhaupt gegeben wären und was passiere, wenn man entgegen aller Erwartungen nicht erfolgreich mit „Scrum“

Qualifizierung und Begleitung» Informationen über Arbeitsweise und Struktur von „Scrum“

Backlog übergreifend» konsequente Einführung von Kompetenz-„Scrums“ und ausgewählten

Produkt-„Scrums“

Rolle Product Owner / „Scrum“- Master» unabhängiger „Scrum“-Master, der nicht Product Owner oder Teammitglied ist


45

sei. Dabei wurde deutlich, dass die Pilot-Teams trotz aller Ungewissheit über den Zielzustand mit dem Gefühl gestartet waren, die Gestaltung der zukünftigen Arbeitsform maßgebend mit-gestalten zu können, während die nachfolgenden Gruppen ein im Wesentlichen festgelegtes Modell übernehmen sollten. Die Möglichkeit, das Verfahren persönlich mitzugestalten hat also mehr Vertrauen gestiftet als ein bereits erprobtes Modell übernehmen zu müssen!

Wie sich an diesem Beispiel ablesen lässt, ist es beim „Roll-Out“ einer pilothaft erprobten, neuen Organisationsform keineswegs ausreichend, die notwendigen Sachinformationen zu vermitteln. Stattdessen bedarf es einer sorgfältigen Balance aus klarer Orientierung durch die Führung (Leitplanken), authentischer Beteiligungskultur in der praktischen Umsetzung und nicht zuletzt erfahrener interner oder externer Organisationsentwickler zur Prozessbegleitung.

Erfahrungen aus dem Prozess

In Kürze lassen sich die Erfahrungen aus dem Einführungsprozess bei der GE Energy Power Conversion GmbH in folgenden Punkten zusammenfassen:

» Grundlegende Regeln und Rollen aus dem „klassischen“ „Scrum“ der IT-Branche lassen sich übernehmen.

» Für die spezielle Anwendung in der physischen Produktentwicklung werden allerdings spezifische Lösungen benötigt, insbesondere beim Sprint-Review, um dem anderen Aufga-benzuschnitt und der größeren Komplexität Rechnung zu tragen.

» Die partizipative Konzept-Entwicklung war ein Erfolgsfaktor.

» Für die Einführung waren die kompetenzorientierten „Scrum“-Teams wichtig, um die Methode zu erlernen.

» Nach mehr als einem Jahr Anwendung gewinnen die projektorientierten „Scrum“-Teams immer mehr an Bedeutung.

» Rollenklarheit zwischen Linie, Führung und „Scrum“-Rollen ist eine elementare Voraus- setzung.


46

9. Sieben Prozessweisheiten in der Einführung

Jörg Bahlow, Gerhard Kullmann

Der Erfolg in der Umsetzung liegt vor allem darin, das Prinzip der Selbstorganisation bereits in den Einführungsprozess zu tragen. Hierzu braucht es, wie in der Umsetzung von „Scrum“ ange-wandt, klare Regeln und festes Vorgehen. Es geht darum, gemeinsam einen Weg zu gehen, jedoch nicht mit beliebigem Ziel und unvorbereitet. Bildlich gesprochen muss sich jemand Gedanken machen um das Schuhwerk, die Kleidung und die Sicherheit, ohne die Route und das Ziel für die anderen schon festgelegt zu haben. Nur dann wird, wie im vorigen Kapitel beschrieben, das Ergebnis zur Unternehmenskultur passen und von den Beteiligten mitgetra-gen werden. Dafür muss der Einführungsprozess sorgfältig geplant und umgesetzt werden.

1. Jedes Unternehmen kann und muss „sein“ „Scrum“ entwickelnDer Einführungsprozess von „Scrum“ muss spezifisch sein, dabei ist der erster Schritt das Herstellen von Rollenklarheit: Welche Hierarchieebenen und welche Personen haben welche Aufgaben, Verantwortung und (Entscheidungs-) Kompetenz? Des Weiteren ist zu klären, was die Schnittstellen zu anderen Rollen im Management und in der Projektwelt sind.

Genauso ist ein Customizing des Einführungsprozesses erforderlich: einbezogene Unter-nehmensteile, Tempo und Breite des Einführungsprozesses, Kommunikationswege etc. Ggf. wird es hier zwischen Unternehmen größere Unterschiede geben als in der Form, in der „Scrum“ hinterher durchgeführt wird, denn hier haben Unternehmenskultur, Erfahrung mit Veränderungsprozessen, Sicht auf Externe (Berater), Aufgaben und Befugnisse von Stabsstellen etc. einen großen Einfluss.

2. Sicherheit durch Verfahren: ein partizipatives Vorgehen mit transparenten RegelnBei der erstmaligen Einführung einer agilen Entwicklungsmethode wie „Scrum“ betreten alle Akteure im Unternehmen Neuland und wissen nicht, was auf sie zukommt. Das gilt für Entscheider ebenso wie für die ihnen unterstellten Führungskräfte und nicht zuletzt für die Entwickler in den „Scrum“-Teams. Sicherheit kann hier vor allem ein stabiles Verfahren stiften, das jederzeit transparent ist und bei dem für alle Beteiligten deutlich wird, wann und von wem welche offenen Fragen geklärt bzw. entschieden werden. Deshalb kommt es darauf an, bei der Anpassung des unternehmensspezifischen Konzepts und der Vorbereitung einer Erprobungs-phase von Anfang an dafür zu sorgen, dass alle Beteiligten wissen,

» was als „Leitplanken“ zur klaren Orientierung vorgegeben ist,

» nach welchen Regeln der Vorbereitungs- und Einführungsprozess abläuft und


47

» in welchem Umfang und auf welche Weise sie ihre Vorstellungen und Erfahrungen als Mitarbeiter oder Teamleiter einbringen können.

Sich für den Weg einer frühzeitigen und umfassenden Beteiligung zu entscheiden, erfordert von der Führungsebene ein erhebliches Maß an Vertrauen in die eigenen Mitarbeiter – und es zahlt sich aus in Form von spürbarer Entschlossenheit und geteilter Motivation, das ungewisse Neuland gemeinsam zu erkunden.

3. Rollenklarheit und -schärfungWie das Fallbeispiel aus dem elektrischen Anlagenbau im vorigen Kapitel deutlich zeigt, kann erst im Laufe der praktischen Arbeit mit den neuartigen Rollen schrittweise Klarheit gewonnen werden, z.B. was im Einzelnen zu den Rechten und Pflichten eines „Scrum“-Masters gehört oder wo ein Product Owner klare Prioritäten setzen muss und wo er sich besser im Hintergrund hält. Als Prozess verstanden, bedarf die Klärung und Schärfung dieser neuen und veränderten Rollen im „Scrum“-Prozess einer besonderen und anhaltenden Aufmerksamkeit: Hier ergeben sich regelmäßig Rollenkonflikte und enttäuschte Erwartungen. Diese bedürfen einer unverzüg-lichen Bearbeitung im Rahmen der Prozessbegleitung durch Führungskräfte oder Berater, um die gemeinsame Linie im Einführungsprozess zu verdeutlichen. Gerade in der Fähigkeit und Bereitschaft, den erreichten Stand der Umsetzung immer wieder kritisch zu reflektieren, liegt der Schlüssel zur kontinuierlichen Verbesserung und Weiterentwicklung einer Entwicklungs- organisation, die den Namen „agil“ auch auf lange Sicht verdient.

4. Besonders in Entwicklungsabteilungen können Standards im laufenden Einführungs-prozess entwickelt werden Jeder Einführungsprozess ist gleichzeitig ein Entwicklungsprozess. Wenn die Beteiligten eine ausreichend hohe Toleranz gegenüber Unsicherheiten haben sowie viele Freiheitsgrade und hohe Komplexität gewohnt sind, ist es in der Regel erfolgreicher, das Umsetzungskonzept nicht erst fertigzustellen und dann einzuführen. Es kommt der Prozessqualität wie der Passgenau-igkeit in der späteren Durchführung zu Gute, wenn Konzeptphase und Pilotphase nicht scharf getrennt werden. Ggf. können auch mehrere Lösungsvarianten separat vorangetrieben werden. Die Entscheidung über die langfristig gültige Variante muss dann erst getroffen werden, wenn ausreichend Erfahrungen mit diesen Varianten vorliegen.

Die Erfahrung zeigt, dass Entwickler ein solches offenes Vorgehen schätzen und dass sie auch in der Lage sind, es konstruktiv mitzutragen. Dies unterscheidet Entwicklungsabteilungen häufig von anderen Bereichen, etwa der Fertigung oder der Buchhaltung.


48

5. Führung mit VertrauensbereitschaftAls Schlüsselfrage im Einführungsprozess erwies sich immer wieder das Verhalten der Führungskräfte, wenn es etwa im Meeting zur Planung der nächsten Sprintaufgaben um die Frage ging, wie viel Aufwand zur Bearbeitung eines konkreten Arbeitspakets realistischer Weise notwendig sein würde. Hier ist Vertrauen der Führung insofern erforderlich, als dass die „Scrum“-Teams im Sinne des Unternehmens verantwortlich planen und arbeiten. Eine ent-scheidende Frage für den gesamten weiteren Prozess ist, ob dieses Vertrauen vorhanden ist.

Wenn deutlich werden sollte, dass dies nicht ausreichend der Fall ist, wird vorzugsweise ein Beobachtungszeitraum vereinbart, in dem das Verhalten der Beteiligten unter den neuen Bedingungen erprobt werden kann. Empfehlenswert ist es, zunächst mit einem Vertrauens-vorschuss zu beginnen und dann auszuwerten, ob dies im Wesentlichen zu den erhofften Prozessen und inhaltlichen Ergebnissen geführt hat. Wenn sich längerfristig zeigt, dass entweder dieses Vertrauen nicht gerechtfertigt scheint oder ein noch vertrauensvollerer Umgang möglich ist, sind ggf. Veränderungen vorzunehmen (vgl. Abbildung 18). Dies wird im ersten Teil dieses Forschungsberichtes näher ausgeführt (nach Bahlow, Longmuß & Spanner-Ulmer 2012).

Abbildung 18: Ausschnitt aus dem Prozessmodell Systemvertrauen nach Bahlow, Longmuß & Spanner-Ulmer, 2012


49

6. Auch Teammitglieder müssen Vertrauen aufbringen könnenDie Mitarbeiter in den „Scrum“-Teams müssen für die Sprintplanungen offenlegen, wie viele Stunden sie im nächsten Sprint tatsächlich für das „Scrum“-Team zur Verfügung stehen und wie viele Aufgaben sie schaffen. Unproduktive Zeiten oder aufwändige Nebenarbeiten wie z.B. die Einrichtung von Entwicklungstools und Prüfplätzen werden deutlich sichtbar – gegenüber Kollegen, unter Umständen auch gegenüber Vorgesetzten. Es wird ebenfalls aufgedeckt, wo Mitarbeiter ggf. noch „heimliche Puffer“ haben, mit deren Hilfe sie übergroßen Belastungen ausweichen können. Geringe Transparenz kann die Mitarbeiter so auch vor unangenehmen Fragen und Überlastung schützen.

Diese intransparenten Bereiche in der „Scrum“-Einführung aufzugeben erfordert ebenfalls Vertrauen – gegenüber den Kollegen wie gegenüber „Scrum“-Master und Vorgesetzten. Dafür sind ggf. Schutzangebote (z.B. Verbesserungen im Prozess, wertschätzender Umgang mit all-täglichen Unzulänglichkeiten, Ressourcenverschiebungen etc.) nötig, damit diese Transparenz nicht gegen den jeweiligen Mitarbeiter gewendet wird.

7. Die Einführung ist nie endgültig abgeschlossenEs gibt bei der Gestaltung von Prozessen in Organisationen nie einen Endzustand, der beliebig lange beibehalten werden kann, und dies trifft in besonderem Maße auf die Einführung agiler Methoden in einem Bereich zu, der so dynamisch ist wie eine Entwicklungsabteilung. Die Randbedingungen ändern sich, ebenso die Erfahrungen im Unternehmen. Deshalb müssen Reviews, Weiterentwicklungen und Standards aus dem Einführungsprozess weiter genutzt werden.


50

10. Transfer 3

Die Ergebnisse und Erkenntnisse aus dem Projekt StabiFlex-3D sind von der GITTA mbH und anderen Projektpartnern auf verschiedene Weise in die Praxis vieler Unternehmen getragen worden. Dabei spielten direkte Transfervorhaben wie Seminare und Schulungen eine genau so große Rolle wie die Entwicklung einer Fachcommunity zu agilem Projektmanagement und die explizite oder implizite Integration in unterschiedliche Beratungsvorhaben. Der Ergebnistransfer begann bereits während der Projektlaufzeit, wodurch Erfahrungen sowie Feedback und Ideen von Seminar- und Schulungsteilnehmern sowie betrieblichen Anwendern wiederum direkt in die Projektarbeit einfließen konnten. Er wird aber auch nach Ende der Laufzeit fortgesetzt, da das Interesse von Praktikern an den Projektresultaten nach wie vor groß ist.

Direkte TransferveranstaltungenVon 2011 bis 2013 haben drei Seminare des „Management Circle“, einem Anbieter von Fortbildungen für das oberste Management, zu agilen Methoden stattgefunden. Zielgruppe waren Entwicklungsleiter sowie technische Leiter von mittelständischen Unternehmen und internationalen Konzernen. Insgesamt nahmen an diesen ein- bis zwei-tägigen Seminaren etwa 100 Personen teil. Darin wurden wesentliche Projektergebnisse vorgestellt und gemeinsam mit den Teilnehmern an einer Übertragung auf deren betriebliche Situation gearbeitet.

Im gleichen Kontext fand im Mai 2011 das „Trendforum Multiprojektmanagement“ des Manage-ment Circles statt, auf dem ebenfalls Ergebnisse von StabiFlex-3D vor etwa 200 Personen vorgestellt und intensiv diskutiert wurden. In all diesen Veranstaltungen sind die Projektpartner GITTA mbH und GE Energy Power Conversion GmbH gemeinsam aufgetreten, was die Erfah-rungen sehr plastisch gemacht und so den Transfer in die Praxis der Teilnehmer vereinfacht hat. Die so veranschaulichte enge Zusammenarbeit trägt dazu bei, den Ansatz der Verbund-projekte mit Forschungseinrichtungen und Unternehmen als sehr erfolgreich auszuweisen.

Seit 2012 besteht eine intensive Kooperation der GITTA mbH mit dem „BWI – Management Weiterbildung“, einem Weiterbildungsanbieter an der ETH Zürich, der Forschungsergebnisse in die Praxis vermittelt. Mittlerweile haben drei Seminare stattgefunden, in denen die Themen agile Methoden und Systemvertrauen im Hinblick auf Innovationsfähigkeit und das Manage-ment von Innovationsprozessen vermittelt wurden. In diesen Seminaren wurden die Projekt- ergebnisse vertieft und in einem neuen Kontext weiterentwickelt. Weitere Veranstaltungen sind geplant.

Die Projektergebnisse sind auch in die Seminare integriert, die im führenden österreichi-schen Weiterbildungsinstitut für Führungskräfte, dem „Hernstein-Institut für Management und

3 (Stand: April 2014)


51

Leadership“, von Mitarbeitern der GITTA mbH durchgeführt werden. Kleine Seminargrup-pen und praxisbezogenes Arbeiten ermöglichen die direkte Implementierung von Projekt- ergebnissen aus StabiFlex-3D in die strategische Planung und Steuerung der Unternehmen des Teilnehmerkreises. Bisher haben vier Seminare stattgefunden, weitere sind angekündigt.

Insgesamt lässt sich resümieren, dass die direkten Transferveranstaltungen zur Vermittlung von Ergebnissen aus dem Verbundvorhaben sehr erfolgreich waren. Sie haben deutlich dazu beigetragen, agile Methoden und vertrauensbasierte Ansätze in der Firmenkultur deutsch- sprachiger Unternehmen voranzubringen. Dieses Potential wird weiterhin entwickelt.

Fachgruppe zu agilem Projektmanagement in der GPMDie Ergebnisse des Projekts StabiFlex-3D sind in der Fachöffentlichkeit auf großes Interesse gestoßen. So entstand in der Diskussion mit Praktikern aus der US-amerikanischen Automobil-industrie die Idee, ein Forum für die Anwender von vertrauensbasierten, agilen Projektmanage-ment-Methoden zu schaffen. Anfang 2013 haben die Unternehmen SAP, Johnson Controls und GITTA mbH dazu gemeinsam die Initiative ergriffen und sich mit diesem Anliegen an die Deutsche Gesellschaft für Projektmanagement e.V. (GPM) gewandt.

Die GPM ist mit ca. 300 Firmenmitgliedern und ca. 6000 persönlichen Mitgliedern der bei weitem führende Projektmanagement-Verband in Deutschland. Mit ihren Ausbildungsstandards, ihren Veröffentlichungen und ihren Fachkonferenzen setzt sie deutschlandweit Maßstäbe für gutes, zeitgemäßes Projektmanagement. Sie ist über den Dachverband IPMA (International Project Management Association) auch international vernetzt. Der fachliche Austausch innerhalb der GPM findet vor allem im Rahmen von Fachgruppen statt. Sie hat sich 2013 auf Antrag der Initia-tivgruppe bereit erklärt, eine Fachgruppe zu „Agilem Projektmanagement“ einzurichten.

Diese Fachgruppe arbeitet seither kontinuierlich mit einem Teilnehmerkreis von ca. zwölf Per-sonen aus zehn Unternehmen. Die Teilnehmer bringen eigene Erfahrungen ein und arbeiten daran, auch basierend auf den Ergebnissen von StabiFlex-3D, die Praxis in ihren Unternehmen zu verbessern. Gleichzeitig arbeiten sie daran, agile vertrauensbasierte Konzepte weiterzuent-wickeln und einem großen Kreis potentieller Anwender zugänglich zu machen. Ziel der Arbeit in der Fachgruppe ist es, dabei gleichermaßen gute Arbeitsbedingungen für alle Beteiligten an Projekten im Unternehmen zu schaffen wie die Wettbewerbsfähigkeit der Unternehmen zu verbessern.


52

Integration in die Beratungspraxis der GITTA mbHBereits während der Projektlaufzeit konnte die GITTA mbH die im Projekt erarbeiteten Konzepte direkt in zwei Beratungsprojekten einsetzen:

» In einem High-Tech-Unternehmen mit ca. 200 Mitarbeitern, das elektronische und elek-trotechnische Geräte und Komponenten entwickelt und fertigt. In diesem Unternehmen konnten die in StabiFlex-3D erarbeiteten Konzepte des agilen Projektmanagements in der physischen Produktentwicklung unmittelbar übertragen werden. Sie erwiesen sich auch in diesem Unternehmen, in dem die Produkte und Prozesse völlig anderen Anforderungen gerecht werden müssen als beim StabiFlex-3D Verbundpartner GE Energy Power Conver-sion GmbH, als direkt einsetzbar.

» In einem Stahlbauunternehmen mit ca. 500 Mitarbeitern, in dem es keinerlei inhaltliche Nähe zu elektronischen oder softwaretechnischen Fragen mehr gab. Trotzdem waren die agilen Strukturen genauso übertragbar wie der vertrauensbasierte Ansatz. Insbesondere letzterer zeigte sich in dieser Umgebung, in der über verschiedene Länder und Ingenieurbüros hin-weg eine sehr intensive Kooperation nötig ist, als ein wesentliches Element einer Prozess-verbesserung und der Steigerung der internationalen Wettbewerbsfähigkeit.

Darüber hinaus sind Projektresultate implizit in eine Reihe von weiteren Projekten eingeflossen und Teil der konzeptionellen Grundlagen der GITTA mbH geworden. Gerade der Fokus auf vertrauensfördernde Strukturen und Maßnahmen hat sich als hilfreich für eine große Band-breite von Projekten der Organisationsveränderung und -entwicklung erwiesen. Dies schlägt sich am sichtbarsten in den Trainings und Schulungen für Führungskräfte nieder, die von der GITTA mbH in den letzten Jahren vor allem in den Branchen Automotive, Stahlgewinnung und Versorgungsunternehmen durchgeführt wurden.

Insgesamt lässt sich sagen, dass die Ergebnisse des Projekts StabiFlex-3D nicht nur der GITTA mbH selbst, sondern auch ihren Kunden einen erheblichen Mehrwert gebracht haben und immer noch bringen. Damit war das Projekt eindeutig ein Baustein zu einer direkten Steigerung von Wettbewerbsfähigkeit und Arbeitsqualität.

Ausblick für die ForschungDie Projektergebnisse eröffnen gleichzeitig Perspektiven für weitere Forschungsbemü-hungen. Sowohl der vertrauensbasierter Ansatz in Organisationen und Prozessen als auch agile Methoden betonen ein selbstreguliertes Arbeiten und erlauben die Orientie-rung an dem tatsächlich vorhandenen Vermögen der Mitarbeiter – in ihren Stärken wie in ihren Schwächen. Damit haben beide Strategien ein erhebliches Potential für eine


53

Unternehmenskultur, die dem demografischen Wandel und der Gesundheitsförderung Rech-nung trägt. Es gibt aus dem Projekt heraus Impulse, daraus neue Forschungsprojekte zu entwickeln.


54

11. Literatur

Anderl, R., Eigner, M., Sendler, U. & Stark, R. (Hrsg.). (2012).Smart Engineering - Interdiszipli-näre Produktentstehung, acatech DISKUSSION, 1. Aufl., Berlin: Springer Vieweg.

Bahlow, J. & Kullmann, G. (2012). Die Zukunft ist agil. Agiles Vorgehen im Anlagenbau. In Management und Qualität, 5, (S. 8-11).

Bahlow,J., Longmuß, J. & Spanner-Ulmer, B. (2012). Das Prozessmodell Systemvertrauen. In J. Longmuß, B. Spanner-Ulmer, G. Kullmann & A. Bullinger (Hrsg.). Das Konzept System-vertrauen. (S.21-31). Chemnitz: aw&I.

Becke, G., Bleses, P. & Schmidt, S. (2011). Betriebliche Gesundheitsförderung in flexiblen Arbeitsstrukturen der Wissensökonomie. In E. Bamberg, A. Ducki & Metz A.-M. (Hrsg.). Gesundheitsförderung und Gesundheitsmanagement in der Arbeitswelt. Ein Handbuch (S.671-691). Göttingen: Hogrefe.

Geissler, H. & Sattelberger, T. (2003). Management wertvoller Beziehungen: Wie Unternehmen und ihre Businesspartner gewinnen. Wiesbaden: Gabler.

Gloger, B. (2009). „Scrum“. Produkte zuverlässig und schnell entwickeln, 2. Aufl., München: Hanser.

Götz, K. (2006). Vertrauen als funktionale Systemeigenschaft. In: K. Götz (Hrsg.). Vertrauen in Organisationen (S.59-71), München: Rainer Hampp.

Helfer, M. & Longmuß, J.(2012). Das Vertrauensdiagramm – Die neun Dimensionen von Systemvertrauen. In: J. Longmuß, B. Spanner-Ulmer, G. Kullmann & A. Bullinger (Hrsg.). Das Konzept Systemvertrauen (S.32-48). Chemnitz: aw&I.

Hurtz, A. & Flick, D. (2002). Verbesserungsmanagement. Was gute Unternehmen erfolgreich macht. Wiesbaden: Gabler.

Kötter, W., Kullmann, G. & Pieper, B. (2009). Das Teamorientierte Unternehmen. In Manage-ment und Qualität, 6, (S.12-14)

Kötter, W. (2010). Ganzheitliche Produktionssysteme (GPS): zukunftsfähig durch stabil-flexible Standards und arbeitspolitische Balance. In: K.M. Möslein, R. Trinczek, A.C. Bullinger,


55

F. Danzinger & S. Lücking (Hrsg.). Flexibel, stabil und innovativ: Arbeit im 21. Jahrhundert; Kon-ferenzband zur Jahreskonferenz des BMBF-Förderschwerpunkts „BALANCE“, 4.-6.10.2010, Nürnberg.

Kötter, W., Bahlow, J., Kullmann, G. & Stahlmann, K. (2011): Arbeitswissenschaftliche Human-kriterien als stabil-flexible Standards in Ganzheitlichen Produktionssystemen (GPS) In: Gesell-schaft für Arbeitswissenschaft (Hrsg.). Mensch, Technik, Organisation – Vernetzung im Pro-duktentstehungs- und –herstellungsprozess. Dokumentation des 57. Frühjahrskongresses der Gesellschaft für Arbeitswissenschaft, 23.03. bis 25.03.2011, Chemnitz, (S.389-392), Dortmund: GfA-Press.

Kötter, W. & Helfer, M. (im Druck). Stabil-Flexible Standards. In: W. Kötter, C. Zanker & M. Schwarz-Kocher. (Hrsg.). Balanced GPS. Ganzheitliche Produktionssysteme mit stabil- flexiblen Standards und konsequenter Mitarbeiterorientierung. Gabler: Wiesbaden.

Kötter, W., Kullmann, G. & Stahlmann, K. (2012). Aktive Gestaltung der Arbeitsqualität als Teil des partizipativen Umsetzungsprozesses eines ganzheitlichen Produktionssystems. In: M. Schmauder, T. Schmidt & S. Rank (Hrsg.). Informationen als Veränderungstreiber – technische & organisatorische Aspekte, Tagungsband zum Institutskolloquium des Instituts für Technische Logistik und Arbeitssysteme, TU-Dresden, (S.93-101), Dresden: Selbstverlag der TU.

Longmuß, J., Spanner-Ulmer, B., Kullmann, G. & Bullinger, A. (Hrsg.) (2012). Das Konzept Systemvertrauen. aw&I: Chemnitz.

Longmuß, J & Buchholtz, G. (2004). Wissensmanagement im Prozess der Produktentstehung. In Business-wissen.de

Longmuß, J. (2003). Der Referenz-Prozess – eine Leitlinie für den gesamten Produktentste-hungsprozess. In Konstruktion, 9, (S.64-67).

Müller, J. (2010). Vorgehensmodelle und klassische Projektplanung: Kontradiktion, Alternative oder Ergänzung? Saarbrücken: vdm.

Munzert, J. (1989). Flexibilität des Handelns. Theoretische Überlegungen und experimentelle Untersuchungen zum Konzept des Motorikschemas. Köln: bps.

Osterloh, M. & Weibel, A. (2006). Investition Vertrauen: Prozesse der Vertrauensentwicklung in Organisationen. Wiesbaden: Gabler.


56

Schwaber, K. (2007). Agiles Projektmanagement mit „Scrum“. Unterschleißheim: Microsoft Press.

Schröder, D. & Steimle, U. (2009). Standardisierung und Partizipation. In K. Zink, W., Kötter, J., Longmuß, & M.J. Thul (2009). Veränderungsprozesse erfolgreich gestalten. (S.138-145). Berlin: Springer.

Takeda, H. (1995). Das synchrone Produktionssystem. Just-in-time für das ganze Unternehmen. Landsberg: Moderne Industrie.

Thomas, A. (2005). Vertrauen im interkulturellen Kontext aus Sicht der Psychologie. In: J. Maier (Hrsg.). Die Rolle von Vertrauen in Unternehmensplanung und Regionalentwicklung: – ein interdisziplinärer Diskurs (S.19-48), forost Arbeitspapiere Nr. 27, München: forost.

Volpert, W. (Hrsg.) (1980). Beiträge zur Psychologischen Handlungstheorie. Bern: Hans Huber.

Volpert, W. (1990). Welche Arbeit ist gut für den Menschen? In: F. Frei & I. Udris (Hrsg.). Das Bild der Arbeit (S.23-40), Bern: Huber.

Volpert, W. (2003). Wie wir handeln – was wir können. Ein Disput als Einführung in die Hand-lungspsychologie. Sottrum: artevact.

Zeitler, N. (2011). „Scrum“ vs. Wasserfall. Neuer Ärger beim Projektmanagement. In CIO [ONLINE] Verfügbar unter: http://www.cio.de/scrum/2293378/ Zugriff, am 19.03.2013

Zink, K., Kötter, W., Longmuß, J. & Thul, M.J. (2009). Veränderungsprozesse erfolgreich gestalten. Berlin: Springer.


57

12. Autoren- / Herausgeberverzeichnis

Jörg Bahlow, Dipl.-Ing., Seniorberater, GITTA mbH

Angelika C. Bullinger, Prof. Dr. habil., Professur Arbeitswissenschaft und Innovationsmanagement, TU Chemnitz

Martin Helfer, Mag. rer. nat., Berater, GITTA mbH

Anne Höhnel, Dipl. Wirt.-Ing., Professur Arbeitswissenschaft und Innovationsmanagement, TU Chemnitz

Jörg Janning, Dr.-Ing., GE Energy Power Conversion GmbH

Helmut Jebenstreit, Dipl.-Ing., GE Energy Power Conversion GmbH

Gerhard Kullmann, Dipl.-Ing., Geschäftsführer der GITTA mbH

Jörg Longmuß, Dr.-Ing., Senior-Berater, GITTA mbH

Thomas Seeling, Dipl.-Soz., Professur Arbeitswissenschaft und Innovationsmanagement, TU Chemnitz

Birgit Spanner-Ulmer, Prof. Dr., Direktorin des Bayrischen Rundfunks


58

13. Abbildungsverzeichnis

Abbildung 1: Drei Dimensionen von Vertrauenskultur .......................................................... 5

Abbildung 2: Das agile Manifest (in Anlehnung an www.agilemanifesto.org, 2001) ........... 14

Abbildung 3: „Scrum“ im Überblick ..................................................................................... 15

Abbildung 4: Die „Scrum“-Rollen ........................................................................................ 16

Abbildung 5: „Scrum“-Dokumente ...................................................................................... 17

Abbildung 6: Die Abfolge der Meetings ............................................................................... 18

Abbildung 7: Orientierungsrahmen der „Scrum“-Teams ..................................................... 26

Abbildung 8: „Scrum“ braucht eine definierte Anforderungsliste ......................................... 27

Abbildung 9: „Scrum“ setzt auf den PEP (Produktentstehungsprozess) auf ....................... 29

Abbildung 10: Unverzichtbare Kernelemente von „Scrum“ ................................................... 30

Abbildung 11: Regelkommunikation im „Scrum of Scrums“ .................................................. 31

Abbildung 12: Das Vertrauensdiagramm .............................................................................. 33

Abbildung 13: Das Prinzip der partizipativen Standardisierung ............................................ 39

Abbildung 14: Agiles Entwickeln mit „Scrum“ ....................................................................... 40

Abbildung 15: Backlog als Tabelle (Muster) ......................................................................... 42

Abbildung 16: Chancen und Risiken bei der Umsetzung von „Scrum“ ................................. 43

Abbildung 17: Wichtige Punkte im „Roll-Out“-Prozess von „Scrum“ ..................................... 44

Abbildung 17: Ausschnitt aus dem Prozessmodell Systemvertrauen nach Bahlow, Longmuß & Spanner-Ulmer, 2012 ........................................... 48


59


60

Kullmann, Longmuß, Bullinger, Spanner-Ulmer (Hrsg.)...erforderliche Verbindung von Vorgehensweisen...

Documents

Transcript of Kullmann, Longmuß, Bullinger, Spanner-Ulmer (Hrsg.)...erforderliche Verbindung von Vorgehensweisen...