In diesem Lernprojekt sollte für einen neu entstandenen Bereich erarbeitet werden, wie agiles Vorgehen unter den Bedingungen des Bereichs aussehen konnte und was zweckmäßige Organisationsformen und Hilfsmittel sein könnten. Die Vorgehensweisen und Techniken des agilen Arbeitens waren so gleichzeitig Gestaltungselemente eines Lernprozesses und in der zweiten Phase auch Lerngegenstand. Dabei war das Ergebnis zunächst völlig offen, weil es zu Beginn nicht einmal Kriterien dafür gab, was eine „richtige Lösung“ wäre.In dem Text werden die beiden Phasen des Lernprojekts dargestellt: 1. Das Testen der Anwendung agiler Methoden auf bereichsinterne Abläufe und deren Etablierung, wo sie sich als hilfreich erwiesen. 2. Die Übertragung des Gelernten auf die unmittelbare Abwicklung von Kundenprojekten. Damit war das agile Lernprojekt keine Aufgabe mehr zusätzlich zum Alltagsgeschäft, sondern in den Arbeitsalltag integriert, das Team konnte agile Methoden eigenständig in weitere Arbeitsschritte transferieren.
Steckbrief
Unternehmen
MAN Energy Solutions Augsburg mit ca. 4000 Mitarbeitern am Standort
Auftrag
Optimierung der internen Abläufe, darauf ausgerichtete persönliche Weiterbildung und spezifische Kompetenzentwicklung für die Mitarbeiter eines Bereichs
Rollen
Lernende: Ein junges Team von 7 Ingenieuren aus verschiedenen Abteilungen
Begleiter: zwei externe Lernbegleiter, einer davon meist vor Ort
Auftraggeber: Ein Abteilungsleiter, der die Ergebnisse auch im Namen der anderen Abteilungsleiter abnehmen kann
Ablauf
Das Team hat zunächst interne Handlungsfelder bearbeitet, dann auch laufende Kundenprojekte. Die Etappen hatten in der Regel eine Laufzeit von 4 Wochen, bei hoher Arbeitsbelastung auch länger. Der gesamte Prozess erstreckte sich über einen Zeitraum von ca. 2 Jahren.
Technik
• Webkonferenzen, um den zweiten Begleiter einzubeziehen
• Zur Projektorganisation wurde zeitweise mit dem internen SharePoint und der digitalen Kanban-Lösung „Kanboard“ gearbeitet
Besonderheiten
• Lernziel des agilen Lernens war das agile Vorgehen selbst
• Offenes Ergebnis, niemand konnte vorher sagen, was eine „richtige Lösung“ wäre
8.1 Ausgangssituation
Der Unternehmensbereich war erst vor relativ kurzer Zeit in dieser Form gebildet worden, seine Aufgabe waren Modernisierungsprojekte von Motoren im Marine- und Kraftwerksbereich. Der Bereich setzte sich zusammen aus Vertrieb, Projektmanagement, technische Entwicklung (Adaptierung/Vertriebszuarbeit/Innendienst/Projektierung) und „Field Service“ (vor Ort beim Kunden). Aufgabe des Bereichs war, pro Jahr mehrere große Kundenprojekte abzuwickeln in einer Größenordnung von mehreren Hunderttausend bis mehrere Millionen Euro.
Advertisement
Die Aufgaben reichten vom ersten Kundenkontakt über die Projektierung, Vertragsverhandlungen, die finale Konfiguration, die Konstruktion und Produktion des Produkts bis zur Auslieferung und Montage der fertigen Lösung vor Ort. Am Lernprojekt beteiligt waren Mitarbeiter der Abteilungen Vertrieb und Projektmanagement, Konstruktion und Field Service. Diese Gruppe war ein relativ junges Team, aber meist schon mit mehrjähriger Projekterfahrung.
Kennzeichnend für den Bereich war:
Eine starkes Wachstum, wobei die Aufträge schneller wuchsen als dazugehörige Kapazitäten.
Start-up-Mentalität: Ein neuer und sich schnell verändernder Bereich innerhalb etablierter Konzernstrukturen.
Mitarbeiter, die sich von Allroundern hin zu Experten ihres Faches entwickelten, das veränderte auch die Art und Tiefe der notwendigen Dokumentation.
Eine Tendenz zu (zu) vielen parallelen Aufgaben und Prozessoptimierungen zusätzlich zum Tagesgeschäft – mit der Folge, dass nicht alles, was begonnen wurde, auch zu Ende gebracht werden konnte.
Dementsprechend geringe Dokumentation und Nachverfolgung von Erfolgen und Misserfolgen. Dies erschwerte die Weiterentwicklung der Prozesse.
Notwendige Prozessentwicklungen bzw. -optimierungen, die von denselben Mitarbeitern vorgenommen werden mussten, die auch das ständig wachsende Tagesgeschäft zu bewältigen hatten. An diesem Punkt waren die Mitarbeiter sich mehr oder weniger selbst überlassen und bekamen keine Hilfe von außen.
Stärken des Bereichs waren u. a. eine pragmatische, unbürokratische Zusammenarbeit über Abteilungs- und Bereichsgrenzen hinweg sowie eine starke Orientierung auf pragmatische Lösungen („Mach Mal Mentalität“), außerdem eine hohe Motivation und Erfolgsorientierung.
Das Thema des Lernprojekts sollte ursprünglich „Projektmanagement“ sein. Bereits im ersten Workshop stellte sich aber schnell heraus, dass dazu im Bereich genug Wissen und Erfahrung vorhanden war – die zentrale Frage im Arbeitsalltag war die Prozessgestaltung. Die wichtigsten Prozesse im Arbeitsablauf waren zu Projektbeginn zwar geklärt, aber an verschiedenen Punkten gab es noch großen Entwicklungsbedarf.
Advertisement
Im Unternehmen wurde in dieser Zeit parallel das Thema „Agiles Vorgehen“ immer stärker gewichtet, so dass das Lernprojekt auch aus dem Management und dem Personalbereich viel Aufmerksamkeit erfuhr. Unter anderem beteiligte sich streckenweise die Personalabteilung mit begleitender Unterstützung und der Durchführung eines Workshops „Agiles Vorgehen bei MAN“. Der Weg war frei, Agiles Vorgehen selbst zum Gegenstand eines agilen Lernprojekts zu machen. Lernziel war es zu klären, wie agiles Vorgehen unter den Bedingungen des Bereichs aussehen konnte sowie welche Organisationsform und welche Hilfsmittel dafür zweckmäßig sein konnten.
Die Rolle des Auftraggebers hatte der Leiter der Abteilung „Sales und Projektmanagement“ inne; er vertrat also nur einen Teil des Lernteams,. Er war weder Fach- noch disziplinarischer Vorgesetzter der Teammitglieder aus der technischen Entwicklung und dem Field Service, nahm seine Rolle aber in Abstimmung mit den anderen Abteilungsleitern wahr und wurde darin vom Team vollständig akzeptiert.
8.2 Umsetzung
Am Anfang des Projekts wurde in einem Workshop von Team und Begleitern der Gesamtprozess von der Kundenakquise bis zur Inbetriebnahme und zum Projektabschluss analysiert. Identifiziert wurden die größten Schwachstellen im Gesamtprozess mit besonderem Handlungsbedarf. Daraus wurden folgende Aufgaben für das Projektteam abgeleitet:
Vertiefte Klärung der Startbedingungen („On-Site-Inspection“)
Vorziehen von Bearbeitungsschritten soweit wie möglich, um Belastungsspitzen kurz vor Abschluss eines Projektes zu vermeiden („Frontloading“)
Definiertes Projektende mit Sicherung der gemachten Erfahrungen („Lessons Learned“)
Außerdem wurde vom Abteilungsleiter gewünscht, Möglichkeiten der Anwendung agiler Methoden auf bereichsinterne Abläufe zu testen und dort zu etablieren, wo sie sich als hilfreich erwiesen und von den Mitarbeitern akzeptiert wurden. „Agil“ war als Modewort bekannt, die genauen Inhalte und internen Anwendungsmöglichkeiten anfangs jedoch noch fremd.
8.3 Die erste Phase: Die „Spielwiese“ – Erstellen von Dokumenten und Verfahrensweisen
Die agilen Methoden sollten zunächst an denjenigen Themen der Prozessoptimierung geübt werden, die sich nicht direkt auf Kundenprojekte auswirken würden. Ein (vorläufiges) Scheitern war ausdrücklich erlaubt und unproblematisch, weil die Auswirkungen intern geblieben wären. Die Aufgaben waren
„On-Site-Inspection“: Ausarbeiten eines Prozesses zur Entsendung von Monteuren mit dem Ziel, die Klärung der Anforderungen aller Fachbereiche zu gewährleisten, und Dokumentation der Ergebnisse (siehe Abb. 8.1)
Definiertes Projektende mit Abschlussbericht und Sicherung der gemachten Erfahrungen („Lessons Learned“).
Abb. 8.1
Beispiel-Aufgabe
×
Gearbeitet wurde in Etappen, die jeweils mit einem Review der Ergebnisse, deren Abnahme bzw. Rückgabe an das Team und einer Reflexion des Vorgehens abgeschlossen wurden. Im Verlauf dieser Phase wurden die zu erstellenden Dokumente und Ablagestrukturen immer wieder verschiedenen Stakeholdern vorgestellt, um ihre Einsetzbarkeit in der Praxis zu testen. Gleichzeitig musste den z. T. sehr unterschiedlichen Bedarfen der Abteilungen, die im Team vertreten waren, Rechnung getragen werden.
In dieser Phase wurden – neben klassischen Moderationstechniken wie Kartenabfragen – verschiedene Techniken des agilen Vorgehens von den Betreuern eingebracht. Ein Beispiel ist das Arbeiten mit einem Kanban-Board. Zuerst wurde diese Methode mit Moderationskarten am Flipchart eingeführt, dann mit Hilfe der Software „Kanboard“ durchgeführt, die von den Begleitern parallel neu entwickelt worden war. Bei einem Treffen wurde „Planning Poker“ zur Abschätzung von Aufwänden (und damit Inhalten je Etappe) genutzt, was sich aber nicht etablieren konnte.
Erfahrungen der ersten Etappen
Bereits die ersten Etappen ermöglichten im Review das Erkennen von Schwierigkeiten beim Aufsetzen eines agilen Lernprojekts:
„Creeping Scope“ (schleichende Veränderung des Zielbereichs): Die Teammitglieder arbeiteten oft sehr mit Blick auf das Detail und taten sich schwer, eine Grenze des Arbeitsumfanges zu definieren. Als Folge erhöhte sich laufend der Umfang des Projekts („Wenn wir schon dabei sind, nehmen wir XY auch noch mit“. „Wenn wir dieses Thema schon aufreißen, dann machen wir es gleich richtig …“). Die hohe Eigendynamik führte dazu, dass der eigenständig erweiterte Umfang nicht mehr in der anfangs geschätzten Zeit machbar war (und in manchen Bereichen fünfmal größer wurde als ursprünglich gemeinsam beschlossen).
„Guerilla-Projekt“: Individuelle Interessen wurden im Verlauf über die ursprünglichen Ziele und die Anforderungen des Auftraggebers gestellt. Es gab kein gemeinsames, sondern viele individuelle Ziele mit gelegentlichen Überlappungen. Im Vordergrund stand, den eigenen Fachbereich weiterzuentwickeln und die anderen dazu zu bringen, „endlich richtig zu arbeiten“.
Prioritäten: Durch ständige Vollauslastung im Tagesgeschäft bekam das Projekt stellenweise nicht die notwendige Priorität. Auswirkungen waren z. B. Nichtteilnahme an Etappentreffen, Nicht- oder nur teilweise Erreichung der Ziele, ab und zu auch Demotivation, da das Zusatzprojekt wegen der Auslastung im Tagesgeschäft nur durch Überstunden realisierbar war.
Zielerreichung: Ebenfalls demotivierend war, dass längere Zeit Ziel und Ergebnis praktisch nie übereinstimmten. Durch die hohe Eigenmotivation wurden die Ziele bereits im Etappentreffen sehr ambitioniert gesetzt („Wir waren bis jetzt sehr voll, aber nun wird das besser …“). Während der Zielvereinbarung wurden Urlaube, Dienstreisen und das übliche Tagesgeschäft unterschätzt. Zusätzlich wurde in dieser Zeit dem Team erst wirklich bewusst, dass sie sich in einer VUCA Welt befinden, sprich in einem Umfeld, das von Volatilität, Unsicherheit, Komplexität und Ambiguität geprägt ist, und Methoden finden müssen, sich auf die komplexen, schnell veränderlichen und schwer vorhersehbaren Rahmenbedingungen einzustellen.
Als Gegenmaßnahme hätte Planning Poker hierfür sehr gut funktionieren können, eine Methode zur relativen Aufwandsschätzung von User Stories aus der agilen Softwareentwicklung. Dies setzte sich aber nicht durch, weil es mit der vorherrschenden Arbeitskultur schwer zu vereinbaren war: Einerseits waren alle hoch motiviert und hatten hohe Anforderungen an sich selbst. Andererseits war es schwer, während der Etappentreffen mit ihrer „Projekt-Euphorie“ den Aufwand anderen wichtigen Vorhaben gegenüberzustellen und eine klare Prioritätenliste mit Kapazitätsplanung zu erstellen.
Insgesamt wurden im Bereich tendenziell viele Projekte engagiert angefangen, die Motivations- und Prioritätskurve brach jedoch schnell ab, weil der Fokus auf neue Themen gelegt wurde. Der hohe Aufwand für Planning Poker wurde gescheut und die Abwägung von Aufwand und Nutzen der Methode fand nicht statt.
Im ersten Etappentreffen wurde deutlich, dass die Anforderungen aus den oben genannten Gründen völlig verfehlt worden waren. Der Abteilungsleiter nahm als Auftraggeber keines der Ergebnisse ab und es herrschte große Verwirrung und Enttäuschung, so dass nach einer Reflexion ein Neustart nötig war. Dies war in diesem Moment sehr frustrierend, im Nachhinein jedoch wichtig und lehrreich: Scheitern war erlaubt, und da das Lernprojekt noch auf der „Spielwiese“ stattfand, entstand kein materieller Schaden für die Firma.
Im Laufe der Zeit stieg das Bewusstsein, dass die Umgebung, so wie sie ist, kaum veränderbar ist, sondern die Ziele angepasst werden müssen. Gut angenommen wurde die Metapher, mit einem Floß auf einem Ozean unterwegs zu sein, wo man Wind und Wellen nicht beeinflussen, sondern nur sein Floß in Ordnung halten kann.
Es war auf der „Spielwiese“ auch eine zunehmende Motivation der Mitarbeiter zu erkennen. Erste erworbene Fähigkeiten wurden sichtbar. Das agile Projektmanagement wurde als ein bis dato fast unbekanntes, aber sehr wichtiges Thema „entdeckt“, das seither eine Eigendynamik im Unternehmen entwickelt hat (selbstständiges Besuchen von Fachseminaren, Scrum-Weiterbildung usw.). Die Mitarbeiter des Projektteams hoben sich dahingehend von ihren Kollegen ab, wobei die Begeisterung für agil auch „überschwappte“. An den Schnittstellen entstanden Interessenskonflikte zwischen den Abteilungen. Dies wurde den Mitarbeitern bewusst, und in der Folge wurden Schritt für Schritt Vereinbarungen entwickelt.
8.4 Die zweite Phase: Operation am offenen Herzen – Agiles Vorgehen in Kundenprojekten
Ziel der zweiten Phase war, das Gelernte und die Ansätze zur Nutzung agiler Methoden auf die unmittelbare Abwicklung von Kundenprojekten zu übertragen. Das hieß, zu überlegen und zu testen, wo und inwieweit ein iteratives Vorgehen mit kurzen Etappen und Rückmeldeschleifen zweckmäßig und in der spezifischen Konstellation der Abteilungen umsetzbar sein konnte. Das Umstellen des gesamten Abwicklungsprozesses auf „agil“ war keine Option, da das klassische Projektmanagement für die Abwicklung größtenteils sehr gut funktioniert. Die meisten Arbeitsschritte lassen sich von Anfang an verlässlich planen, da Projektstart und -ende sowie der Umfang von Anfang an bekannt sind. Immer wieder gibt es jedoch Phasen, in denen zwar der Zeitplan abgesteckt und der grobe Umfang bekannt ist, jedoch Details unbekannt und schwer einzuschätzen sind.
In einem Workshop wurde gemeinsam überlegt, in welchen Projektphasen eine agile bzw. hybride Arbeitsweise Vorteile haben könnte. Gemeinsam ausgewählt wurde die Konzeptphase des Designs. Diese Phase ist entscheidend für den späteren Projekterfolg und war bis zum Projektbeginn die häufigste Fehlerquelle. Mit der Umstellung auf agil wurde (erstmals) allen Fachbereichen die konzipierte Lösung in iterativen Schleifen vorgestellt. Das erhöhte die Chance, Fehler aufzudecken. Gleichzeitig erhöhte es den Frontloading-Effekt, da der spätere Monteur bereits zu einem sehr frühen Zeitpunkt alle für die Montage benötigten Zusatzteile bestellen konnte.
Erstmalig war das agile Lernprojekt keine Aufgabe zusätzlich zum Alltagsgeschäft, sondern in den Arbeitsalltag integriert. Damit bekam es eine höhere Priorität und wurde ausgeweitet auf Mitarbeiter, die vorher nicht involviert gewesen waren. In der Folge wurden schnelle Rückmeldungen von Erfolgen oder Misserfolgen möglich.
Parallel zu den beiden oben genannten Phasen stellte das Team selbstständig und außerhalb des Lernprojektes auch den Tendering-Prozess (Ausarbeitung des Angebots auf eine Ausschreibung) auf agil um. Kennzeichnend für diesen sehr intensiven Prozess sind:
Die Ausschreibung eines (zumeist) staatlichen Kunden muss innerhalb einer festgelegten Zeit (1–3 Wochen) bearbeitet werden.
Sie betrifft alle Fachbereiche.
Das Angebot erfordert einen hohen Detaillierungsgrad und große Genauigkeit, da es Vertragsgegenstand ist und Fehler hohe Kosten verursachen können.
Innerhalb der Tendering-Phase arbeitet pro Fachbereich mindestens ein Mitarbeiter nahezu Vollzeit an der Ausschreibung.
Es gibt häufige Rücksprachen zwischen Fachbereichen, dem Kunden und den lokalen Niederlassungen sowie ständige Änderungen der Rahmenbedingungen.
Der neue, agile Tendering-Prozess wurde relativ früh für alle Mitarbeiter in der Abteilung angewendet. Damit hatte das Team das Erlernte eigenständig in einen neuen Bereich transferiert. Die Projektmitglieder unterstützten ihre Kollegen, da sie auch in anderen Prozessoptimierungsthemen involviert waren, dort die gelernten Fähigkeiten anwandten und somit verbreiteten.
Instrumente/Technik
Eine Herausforderung war der Umgang mit der IT, unter anderem, weil die unterschiedlichen Fachbereiche auf individuellen Laufwerken arbeiten, jeweils mit beschränkten Möglichkeiten. Zur Arbeit im Lernprojekt wurden vor allem zwei Programme für den Austausch und die Kollaboration an den Aufgaben zur Verfügung gestellt: ein unternehmensinterner SharePoint und die speziell für Lernumgebungen entwickelte Software „Kanboard“, die hilfreich ist für die Moderation von Etappentreffen und die Visualisierung des Arbeitsstandes sowie für eine Verdeutlichung des agilen Ansatzes.
Der extra eingeführter SharePoint mit erweiterten Möglichkeiten wie z. B. Benachrichtigung bei Änderungen oder Versionshistorie funktionierte nur eingeschränkt: Einige Funktionen waren nicht selbsterklärend, manche verwirrend. Die Arbeitsweise unterschied sich von den sonstigen Routinen im Arbeitsalltag und machte eine Einarbeitung bzw. Beschäftigung mit dem Thema notwendig. Während der SharePoint bei manchen Teammitgliedern auf Begeisterung stieß, lehnten ihn andere kategorisch ab. Je größer die Neigung von Mitarbeitern zur Detailarbeit war, desto mehr Akzeptanz wurde dem SharePoint entgegengebracht.
Die Arbeit am Kanban-Board fand ursprünglich auf einem Flipchart statt (für die externen Begleiter wurden Bilder per Mail versendet), später auf SharePoint. Zwischenzeitlich wurde eine weitere Software auf Eignung geprüft. Durchgesetzt hat sich letzten Endes eine Kanban-Lösung über OneNote. Später wurde noch „Kanboard“ auf der Plattform der Begleiter getestet, aber auch dort nicht wirklich angenommen.
Die Suche nach der richtigen Plattform zeigte die typischen Probleme vieler Softwareeinführungen: Wenn nicht alle Mitarbeiter die Plattform nutzen, kann sie sich kaum durchsetzen. Akzeptiert werden nur einfache Lösungen, bereits das Eingeben von Benutzername und Passwort statt single-sign-in führten zu Abneigung. Die Tools müssen außerdem selbsterklärend sein. Tutorials und Handbücher werden kaum akzeptiert, selbst wenn die Einarbeitung nur wenige Minuten dauern würde. Vom Team insgesamt wurden nur die allgemein üblichen Programme genutzt; Zitat: „Was die Office-Plattform verlässt, überlebt nicht im Alltag“.
8.5 Beobachtungen und Lessons Learned
Die Motivation war grundsätzlich gut. Zum einen gab es ein starkes Interesse an dem inhaltlichen Ziel der Prozessverbesserung. Zum anderen wurde auch das Thema „agil“ mit großem Interesse aufgenommen; vermutlich unter anderem, weil es im Unternehmen bereits stark kommuniziert wurde, ohne dass es schon wirklich greifbar geworden war. So gab es im Team auch einen gewissen Stolz darauf, am Standort Vorreiter zu sein. Am Ende des ersten Jahres erschien in der Betriebszeitung sogar ein Artikel über das Projekt.
Das Arbeitspensum im Projekt wurde zum Teil empfindlich beschränkt durch die große Arbeitsbelastung im Tagesgeschäft – viele Mitarbeiter leisteten ohnehin schon Überstunden. Dies begrenzte stark, was zwischen den Etappentreffen geleistet werden konnte, und ließ sehr wenig Raum für Lernen auf allgemeinerer Ebene.
Es gab zu diesem Zeitpunkt bei MAN ES am Standort Augsburg noch keine etablierten Standards oder Beispiele einer stabilen Praxis zu agilem Vorgehen. Deshalb konnten sich weder der Auftraggeber noch das Team im Haus rückversichern, ob sie eine „gute Lösung“ gefunden hatten – es gab dafür noch keinen Maßstab. So konnten sich Auftraggeber und Team die Kriterien für die Beurteilung der Arbeitsergebnisse nur selbst setzen. Im Wesentlichen waren das:
Alle relevanten Punkte im Prozessschritt sind berücksichtigt
Die Lösung ist einfach anzuwenden
Die Lösung ist unmittelbar hilfreich
Die Lösung wird von den Beteiligten akzeptiert.
Dies hatte zeitweise erkennbar Unsicherheit auf Seiten des Teams zur Folge. Am Ende gab es aber die gemeinsame Überzeugung von Team und Auftraggeber, die Prinzipien des agilen Vorgehens gut verstanden sowie produktiv und zweckmäßig auf die eigene Arbeit übertragen zu haben.
Die Vorgehensweisen und Techniken des agilen Arbeitens waren so nicht nur über die gesamte Laufzeit Gestaltungselemente eines Lernprozesses, sondern in der zweiten Phase auch Lerngegenstand. Das Team lernte also in der Bearbeitung seiner Klärungsbedarfe gleichzeitig die Werkzeuge kennen, um in Zukunft solche Klärungen selbst besser durchführen zu können.
Es zeigte sich, dass die allesamt akademisch ausgebildeten Teammitglieder – anders als etwa Lernende mit gewerblichem Hintergrund – den Lernstoff sehr selektiv zur Kenntnis nahmen. Offensichtlich wurde alles, was nicht unmittelbar hilfreich schien, nur kurz überflogen und aussortiert oder gleich ganz ignoriert. Dieses Vorgehen erinnert stark an ein Lernen für Klausuren im Studium. Eine solche Haltung zum Lernen macht die Vermittlung eines fachlich breiten Wissensstandes mit agilen Methoden schwierig.
Auch wenn agiles Arbeiten von allen als sinnvoll betrachtet wurde, gelang die Umsetzung nicht allen Teammitgliedern gleich gut. Das agile Projektmanagement erfordert ein Mindset, das Veränderungen (auch der bisherigen Arbeitsweise) zulässt und eigene Ziele denen des Teams in gewisser Weise unterordnet. Das Loslassen gewohnter Routinen fiel jedoch nicht immer leicht.
Gleichzeitig erfordert die agile Arbeitsweise auch Änderungen der Rahmenbedingungen, die nur der Arbeitgeber bzw. die Führungskraft ermöglichen kann. Die räumliche Trennung der Teammitglieder über unterschiedliche Stockwerke führte beispielsweise zu einer schnellen Abschwächung der Projekteuphorie, die während der Etappentreffen vorgeherrscht hatte. Sobald die Mitarbeiter anschließend zu ihren Arbeitskollegen zurückkehrten, fielen sie in die gewohnte Routine zurück und ihre Prioritäten verschoben sich stark zugunsten des Tagesgeschäftes. In diesem Fall war eine räumliche Veränderung nicht möglich, da das Projekt nur wenige Stunden in Anspruch nahm im Vergleich zu den Standardaufgaben der Mitarbeiter. Agile Projekte in Vollzeit und mit größerer räumlicher Nähe der Beteiligten würden sicherlich die Ergebnisse und den Wirkungsgrad des Teams deutlich verbessern.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz (http://creativecommons.org/licenses/by-sa/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Wenn Sie das Buch oder Teile daraus remixen, verändern oder anderweitig direkt darauf aufbauen, dürfen Sie Ihre Beiträge nur unter derselben Lizenz wie das Original verbreiten.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
