Homeoffice? Präsenz? Beides? E-Book

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 192

Veröffentlichungsjahr: 2023

Beschreibung

Ist die Erfolgsgeschichte von Agilität zu Ende? Agile Arbeitsweisen verhelfen Teams zu einer hohen Produktivität, Innovationskraft und Qualität - vor allem wenn die Zusammenarbeit in einem Teamraum stattfinden kann. Das vereinfacht die Kommunikation erheblich und stärkt den Teamspirit. Bisher. Doch wie funktioniert Agilität in einer Zeit, in der Homeoffice zur Normalität geworden ist und Teams seltener gemeinsam an einem Ort zusammen kommen? Kann Hybrid Collaboration, eine Kombination aus persönlicher und digitaler Zusammenarbeit, die Antwort auf die veränderten Arbeitsweisen sein? Oder führt sie im Gegenteil zu einem schleichenden Zerfall von Teamdynamik und Produktivität? In diesem Buch berichten acht Experten aus unterschiedlichen Unternehmen über ihre Erfahrungen mit Hybrid Collaboration in agilen Teams. Die Autoren teilen ihre persönlichen Sichtweisen und Erfahrungen zu Grundlagen, Entwicklungen, Maßnahmen und Erfolgsfaktoren der Hybrid Collaboration. Damit zeichnen sie ein umfassendes Bild und geben praktische Hinweise, wie die Potenziale hybrider Zusammenarbeit für agile Teams genutzt werden können. Das Buch ist eine wertvolle Ressource für alle, die sich mit der Gestaltung einer hybriden Arbeitsorganisation beschäftigen und Antworten auf die Anforderungen unserer schnelllebigen und digitalisierten Arbeitswelt suchen.

Leseprobe

Für Elena, Maria, Gabriela

INHALT

Einführung

Andreas Apeldorn: Agile Teams heute – eine Polemik

Andreas Apeldorn: Am Anfang war das Chaos – Warum ›Agil‹ ein Erfolgsmodell wurde

Der Blick zurück: Wasserfall als Standard

für Projektmanagement

Wenn nichts mehr geht: der War-Room

Die Geburtsstunde von Scrum

Gesunder Menschenverstand? Das Agile Manifest

Andreas Apeldorn: Hybrid Collaboration – Notnagel oder Modell mit Zukunft?

Co-Location: Legende und Wahrheit

Aus der Not geboren: Hybrid Collaboration

Remote Zusammenarbeit: Chance und Risiko für agile Teams

Hybrid Collaboration: das ›New Normal‹?

Hybrid ist nicht gleich Hybrid

Medienbruch benachteiligt die Remote-Teammitglieder

Herausforderungen verstehen und bewerten

Spontane Kommunikation

Nonverbale Kommunikation

Zusammenarbeit in Gruppen

Transparenz zu Arbeitsergebnissen herstellen

Gleichzeitig an Inhalten zusammenarbeiten

Individuelle Lösungen im Team ausprobieren

Fazit

Christian Schweizer: Technologie und Räume – Neue Arbeitsweisen vs. alte Arbeitsumgebungen

Technologie und Räume sind relevante Faktoren für die Zusammenarbeit hybrider Teams

Entwicklung von hybriden Arbeitsumgebungen in der Praxis

Technologie-Standards für hybride agile Teams

Der Traum vom perfekten hybriden Erlebnis

Technologische Handlungsfelder zur Optimierung

von hybrider Zusammenarbeit

Raumgestaltung für hybride Szenarien

Technologische Trends und Ausblick

Nils Schekorr: Ich sitze im Rapsfeld, Du im Weltraum – Teams und die Herausforderungen der hybriden Zusammenarbeit

Warum brauchen wir Teams nochmal?

Ab wann sind wir ein Team?

Was kann das Team, was die Organisation nicht kann?

Was ist in der Remote-Zusammenarbeit für ein Team so anders?

Die ständige Selbstbetrachtung schafft Distanz zu den anderen

Der gefilterte Blick von allen auf alle beschränkt und überfordert zugleich

Das Ausbalancieren mehrerer Orte lenkt vom Geschehen in der Gruppe ab

Sprache wird wichtiger und sorgt für Sachorientierung

Und nun? Wie bekommen wir die Balance wieder hin?

Es braucht mehr regelmäßige Reflexion über die Verhältnisse innerhalb des Teams

Es braucht mehr aktiv bereitgestellte Gelegenheiten für Informalität

Es braucht mehr Wertschätzung für Beziehungsarbeit in Teams durch das Management

Zusammenfassung

Friederike Wurth: Vom Suchen und Finden neuer Wege – Agile Methoden in der hybriden Zusammenarbeit

Der Google Design Sprint

OKR – Objectives und Key Results

Scrum

Fazit

Bernhard Hochstätter: Optimierung am Limit – Scaled Agile und verteilte Teams

Rückblick

Best Practices für die übergreifende Zusammenarbeit in hybriden Teams

›Remote-First‹-Ansatz

Lokale Zusammenführung, verteilt in der

Orchestrierung

Digitale Kollaborationstools

Zeitzonen Management

Regelmäßige Treffen

Disziplin

Storytelling

Take care

Fazit

Jan Ackermann: Präsenz, remote oder hybrid? Agile Teams haben die Qual der Wahl

Einstieg

Die Kernbereiche der Team-Kohäsion

Workshop zur Standort-Bestimmung

Das soziale Gefüge des Teams

Der Purpose eines Teams

Die operative Kompetenz

Die Kraftquelle des Teams

Die Team-Vereinbarung

Zusammenfassung

Heiko Leicht: Personalführung – remote oder hybrid?

Einordnung in den historischen Wandel bei

Globalisierung und hybriden Teams

Vor und zurück

Corona

Auswirkungen auf das Leitbild Leadership

Leadership ist mehr als Scrum

Leadership ist zu einem großen Teil Coaching

Taktische und strategische Aufgaben im Leadership

Coaching

Konfliktlösung

Coaching In-Person oder Remote

Kernproblem des Leaderships in hybriden Teams

Praxisbeispiel

Fazit

Dr. Linus Schaaf: Digitale Ko-Kreation im 10X Service Design Lab

Das 10X Service Design Lab

Die technische Ausstattung des 10X-SDL

Wandel von analoger zu digitaler Ko-Kreation

Limitation analoger Arbeit

Interaktionen mit digitaler Information aufgeschlüsselt

Wirtschaftliche Aspekte der digitalen Ko-Kreation

Synthese der Erkenntnisse

Andreas Apeldorn: Zusammenfassung, roter Faden und ein Vorschlag

Autoren

Andreas Apeldorn

Bernhard Hochstätter

Christian Schweizer

Friederike Wurth

Heiko Leicht

Jan Ackermann

Dr. Linus Schaaf

Nils Schekorr

EINFÜHRUNG

Agiles Arbeiten ist eine Erfolgsgeschichte.

Agile Teams setzen Maßstäbe bezüglich Qualität, Produktivität, Entwicklungszeiten, Engagement. Multi-disziplinär, schnell und direkt in der Kommunikation, fokussiert und selbstorganisiert, mit einem starken Team Spirit. Darauf fußt der Erfolg, den agile Teams seit mehr als 20 Jahren feiern.

Allerdings mehren sich Stimmen, die das Gegenteil behaupten. Im April dieses Jahres machte beispielsweise ein Blog-Artikel eines Entwicklers die Runde, mit dem Titel »Wir arbeiten nicht. Null«. Der Autor & Entwickler Emanuele Maggiori beschreibt in seinem »Erfahrungsbericht« Agilität als eine Farce, die die Produktivität in Teams tötet. Der Artikel bekam nicht nur eine Menge positiver Kommentare, sondern verbreitete sich schnell um die ganze Welt – in Deutschland wurde er unter anderem auf Golem.de veröffentlich und reichlich kommentiert. Zugegeben: einzelne Kritikpunkte aus diesem Artikel sind auch in meinem Umfeld vorgekommen. Sie waren aber immer lösbar. Zumindest wenn man seine Aufgabe als Scrum-Master ernst nimmt, was für die Allermeisten meiner Kolleginnen und Kollegen gilt.

Ich entschied mich zu einem Test und schrieb eine Polemik über die Erlebnisse eines Product-Owners in einem fiktiven agilen Team (die ›Hybrid Diaries‹ Polemik findet Ihr auch im Prolog dieses Buches). In dieser Polemik geschieht wirklich alles, was in aktuellen Teams schiefgehen kann – und das auch noch etwas zynisch überspitzt. Anschließend zeigte ich mein Werk zehn Scrum-Mastern und Führungskräften aus meinem Bekanntenkreis – nur einer widersprach dem Inhalt. Die anderen neun meinten sinngemäß: »Was Du schreibst ist bitter, aber leider die Realität.«

Warum bekommen solche Polemiken heute so viel Zuspruch? Was ist so anders als noch vor wenigen Jahren, so dass agiles Arbeiten so einfach als Produktivitätskiller dargestellt werden kann? Fest steht: die Digitalisierung die Arbeitsweise agiler Teams verändert. Spätestens seit der Coronapandemie haben digitale Tools ›alte‹ Boards aus Papier und Pappe abgelöst. Video-Conferencing ersetzt Meetings vor Ort, das Homeoffice den gemeinsamen Teamraum. All dies mit großen Vorteilen, etwa bezüglich Effizienz, oder Flexibilität. Vieles, das heute selbstverständlich scheint, war vor wenigen Jahren noch undenkbar. Auch wenn das reine Arbeiten aus dem Homeoffice jetzt wieder weniger Bedeutung hat als vor der Pandemie – ein Zurück zu ›vor-pandemischen‹ Arbeitsweisen ist kaum vorstellbar.

Heute geht der Trend zu Hybrid Collaboration. Hybrid Collaboration ist ein Arbeitsmodell in dem die Teammitglieder sowohl online als auch persönlich zusammenarbeiten, und zwar jederzeit und überall: teils in einem gemeinsamen Büro, teils im Homeoffice, national oder international. Die Vision: die Vorteile der persönlichen Interaktion in einem gemeinsamen Raum mit dem Potenzial und der Flexibilität der digitalen, virtuellen Kommunikation zu verknüpfen.

Alles bestens also? Oder gibt es bei Hybrid Collaboration auch Schattenseiten?

Es gibt Anzeichen dafür. In den USA werden die Auswirkungen von Hybrid Collaboration schon seit längerer Zeit diskutiert. So soll Hybrid Collaboration zu einem weniger starken Teamgeist führen. Zu weniger sozialer Bindung zwischen den Teammitgliedern. Zu einem schlechteren Informationsfluss zwischen den Beteiligten.

Ist am Ende Hybrid Collaboration verantwortlich dafür, dass Agilität nicht mehr funktioniert? Dieser Gedanke ließ mir keine Ruhe.

Ich brachte das Thema deshalb noch einmal in einer agilen Community zur Sprache. Auch hier war das Ergebnis zwiespältig: während die Auswirkungen von Hybrid Collaboration auf Performance, Umsetzungsgeschwindigkeit und Qualität der Teams durchweg als ›gleich oder besser‹ beurteilt wurde, gab es Klagen über abnehmendes Engagement, geringeren Team-Spirit, geringere ›Greifbarkeit‹ der Teammitglieder.

Das Fatale: Diese eher ›soften‹ Auswirkungen bleiben offensichtlich lange unbemerkt und unbeachtet. Doch dann beginnen sehr plötzlich Schwierigkeiten: sinkende Produktivität und geringere Liefertreue, der Burnout von Teammitgliedern, im schlimmsten Fall der komplette Zerfall eines Teams.

Ein Teamleader meinte: »Es ist wie bei einer Zirrhose, einer ›Team-Zirrhose‹: der Verfall geschieht zuerst unbemerkt. Aber wenn sie entdeckt wird, ist es zu spät.«

Hybrid Collaboration soll in agilen Teams also zur ›Team-Zirrhose‹ führen können. Das ist eine sehr drastische These. Aber eine These, die meine Ko-Autoren und mich zu der Idee führte, dieses Buch herauszugeben. Wie sind die praktischen Erfahrungen in den Unternehmen mit Hybrid Collaboration? Was überwiegt in der Praxis – Chancen oder Risiken? Wie wird Hybrid Collaboration so gestaltet, dass Teams von den Potentialen nachhaltig profitieren – und nicht plötzlich an einer ›Team-Zirrhose‹ kollabieren?

Unser Buch ist ein Versuch, diese Fragen und damit den Einfluss von Hybrid Collaboration auf agile Teams anhand von Praxisbeispielen zu beleuchten und zu bewerten. Dazu hat jeder Autor seinen eigenen Beitrag geschrieben – mit der eigenen Sicht auf Grundlagen, Entwicklungen, Maßnahmen und Erfolgsfaktoren. Jeder Autor hat zudem einen eigenen Schwerpunkt aus den Bereichen Leadership, Organisation, Methodik, Technik.

Damit steht jeder einzelne Artikel zunächst einmal für sich. In der Summe der Artikel ergibt sich aber ein aktuelles, umfassendes und praktisches Bild zum aktuellen Stand von Hybrid Collaboration in den Unternehmen heute. Ein Bild, das Einsichten schafft und die unterschiedlichen Ansätze und Praktiken aufzeigt, wie hybride Zusammenarbeit für agile Teams positiv genutzt werden kann. Und: auf welche Symptome geachtet werden sollte, um Anzeichen für eine ›Team-Zirrhose‹ zu erkennen – und gegenzusteuern.

Wir gehen davon aus, dass Hybrid Collaboration gerade erst am Anfang einer Entwicklung steht. Deshalb sehen wir unser Buch vor allem als Beitrag, Diskussionen anzustoßen, und neue Ideen zu entwickeln.

Und wünschen dabei viel Spaß!

Literatur

Emmanuel Maggiori: I’ve been employed in tech for years, but I’ve almost never worked. https://emaggiori.com/employed-in-tech-for-years-but-almost-never-worked/

AGILE TEAMS HEUTE – EINE POLEMIK

Von Andreas Apeldorn

Liam, ein Product-Owner, berichtet über die Herausforderungen mit seinem Team. Trotz eines vielversprechenden Starts und anfangs idealen Bedingungen kämpft das Team mit den Tücken der hybriden Zusammenarbeit: Missverständnisse, fehlendes Vertrauen und mangelnder Team-Spirit hemmen das Team. Agilität trifft auf die neue Realität: Ist die agile Arbeitsweise wirklich zukunftsfähig? Finde es heraus und begleite Liam in einem – aus seiner Sicht – typischen Meeting.

Hi, ich bin Liam.

Ich bin 37, verheiratet, Schwabe, habe einen Hund und bin Triathlet. Außerdem bin ich Product-Owner für ein innovatives Produkt, das im Rahmen unserer Digitalisierungsstrategie weltweit eingeführt werden soll. Natürlich kritisch, natürlich teuer, natürlich innovativ und mit Management Attention. Allerdings arbeiten wir schon seit zwei Jahren daran und einige hier werden deshalb ungeduldig.

Wir sind natürlich agile gestartet. Alles andere ist ja ein No-Go.

Unser Team ist cross-funktional aufgestellt, das heißt, wir haben alle Experten beisammen, um unser Produkt vollständig zu entwickeln. Es besteht aus

Berta, unsere Business-Analystin. Sehr fit in ihrem Fach, und eigentlich immer verschnupft.

Christine, die Backend-Developerin. Urgestein unserer Company, immer kooperativ.

Sarah, unsere UX-Designerin. Cool, straight, …und so.

Tom, der Cloud Engineer. Relativ neu in seinem Fach und sehr zuverlässig. Lebt in Dubai, ist Kartoffelchips-Freak.

Leon, der Frontend-Entwickler. Hat alles schonmal gemacht, in der Frontend-Entwicklung seine Bestimmung gefunden.

Ben, der Testengineer. Ein klassischer Quereinsteiger, im früheren Leben Dönerbudenbetreiber.

Und natürlich Fritz, der Scrum-Master. Immer fröhlich, immer hilfsbereit und jeder hat das Gefühl, dass er eine Vision hat. Die leider nur er selbst kennt.

Alle im Team sind zu 100% dabei – jeder kann sich voll auf unseren Auftrag konzentrieren. Dazu haben wir einen eigenen Teamraum, in dem wir zusammenarbeiten könnten. Perfekte Rahmenbedingungen also, die sonst nur wenige Teams haben.

Unser Team ist 2020 gestartet – inmitten der Coronapandemie. Statt Teamraum war Remote-Arbeit angesagt, zu Beginn vollständig. Jetzt, nach der Pandemie, ist ein Teil des Teams immer wieder im Büro, ein Teil der Crew arbeitet im Homeoffice.

Für heute ist unser Sprint-Planning angesagt. Zweieinhalb Stunden, klassisch aufgeteilt in Sprint-Planning 1 und Sprint-Planning 2. Wir nutzen dafür nicht unseren Teamraum, sondern einen Konferenzraum, weil dort ein großer Bildschirm steht. In der Mitte des Tisches ist unsere Spinne – eine Kombination aus Mikrofon und Lautsprecher für die Tonübertragung beim Video-Conferencing.

Bei uns im Büro sind heute on Site: Christine, die Backend-Entwicklerin. Tom, der Cloud-Engineer. Alle sitzen im Raum und haben ihre Laptops geöffnet vor sich.

Remote zugeschaltet sind – Moment, ich muss eben Teams starten … Fritz, der Scrum-Master. Sarah, die UX-Entwicklerin. Leon, der Frontend-Entwickler. Außerdem Ben, der Testengineer. Berta, die Business-Analystin ist nicht da. Schnupfen? Möglich.

Fritz, unser Scrum-Master, hat das Meeting eröffnet. »Hallo zusammen! Schön, Euch zu sehen!«, krakeelt es aus der Spinne. Er strahlt uns über den Bildschirm an – er ist wirklich ein famoses Gute-Laune-Paket. Ich muss trotzdem noch schnell eine Mail beantworten. »Jetzt macht doch bitte nochmal alle die Kamera an, wie wir es in der letzten Retro besprochen haben. Was meint Ihr?« Niemand reagiert, die Kameras bleiben aus. Doch, Leon schaltet sich jetzt zu. Allerdings ist er nur zur Hälfte sichtbar, und das auch nur von der Seite. Meine Teammitglieder hier im Raum reagieren nicht, und unser Scrum-Master geht darüber hinweg. »Keine Kamera? Auch gut. Wahrscheinlich habt Ihr einen Grund dazu, und dann wollen wir das doch respektieren, oder nicht? Lasst uns lieber mal sehen, was unser PO für Euch hat, nicht wahr? Liam?«

»Klar, Fritz, gerne. Ich teile eben meinen Bildschirm. Habt Ihr alle unser Backlog offen?« Keine Antwort. Hier im Raum bekomme ich Handzeichen, ›Daumen hoch‹, ein Nicken … Von den zugeschalteten Leuten kommt nichts … da, Leon hat sich gerade bewegt. Ich nehme an, dass es ein Zeichen der Zustimmung war. Bei den anderen – keine Ahnung, die Kameras sind ja auch aus.

Ich fange einfach mal an und stelle die erste Story vor. Sie ist wichtig, cool und müsste in überschaubarer Zeit umgesetzt werden können. »So, das ist die Story. Und, Fragen?« Nichts. Die Anwesenden im Raum schütteln den Kopf. Einer tippt etwas auf seinem Laptop. »Na, dann lasst uns doch mal schätzen«, strahlt Fritz, unser Scrum-Master. »Geht doch mal auf den Link, den ich in den Chat gestellt habe, dann öffnet sich unser Planning-Poker-Tool. Der Link funktioniert nicht?« »Nö …«, wimmert die Spinne vor sich hin. Vielleicht war es auch Sarah. Oder irgendetwas anderes. »Oh, dann nehmt mal diesen Link hier. Der gefällt mir sowieso viel besser … Jetzt klappt es?« »Jojo …« »Dann mal los!« Alle schätzen – es gibt viermal 13, einmal zwei, einmal 20 Punkte. „OKEEEHH…« … das war Fritz. »Da muss wohl noch etwas geklärt werden, meint Ihr nicht? Sarah, Du hast 2 Punkte geschätzt. Kannst Du sagen, warum?« Sarah ist remote, die Kamera ist aus, es kommt keine Antwort. »Sarah?« »Oh, ja? Meine Schätzung? Ach so, ich weiß nicht. Ich habe mich vertippt. 13 passt.« Wieder Stille. »Alles klar«, jubelt Fritz. »Und du, Ben? Du hast 20 geschätzt?« Ben schaltet sein Mikrofon und sein Videobild an. Sein rundes Gesicht füllt den Bildschirm komplett aus. Er setzt an und erklärt. Leider nuschelt er immer so. Und redet lang. So auch heute. Ich verstehe ›Scharf‹, ›mit allem‹ – und denke an Döner. Ich kann mir kaum vorstellen, dass irgendjemand etwas von dem, was er erzählt, verstanden hat. Ich jedenfalls nicht. Irgendwie ist es mir auch egal. Ich checke nochmal kurz meine Mails, während er spricht.

Bis Fritz Ben unterbricht. »Sag mal, Ben, Du könntest aber auch mit einer 13 leben, nicht wahr?«, schlägt er vor und gluckst dabei fröhlich. Aus der Spinne tönt ein Geräusch. »Super! Das ist doch einmal ein Ergebnis! Liam, trägst Du das ein?« Ich zögere. 13 Punkte – wir hatten zu Anfang einmal eine ganz ähnliche Story, aber damals hatte sie nur 5 Points bekommen. Und jetzt 13? Ich schaue meine Teamkollegen im Raum an. »OK, man kann vielleicht auch auf 8 gehen. Aber dann ist das Sicherheitspolster weg.« Meint Christine, die Backend-Developerin. Und schaut mich über ihren Laptop hinweg mit großen Augen an. Na, dann …

»Weißt Du, Liam, das Team entscheidet selbst über den Aufwand und die Komplexität. Das ist Selbstorganisation, Vertrauen, Agilität!«, flötet Fritz über die Spinne. »Äh, ja«, erkläre ich und trage das Ergebnis ein. 13, alle sind sich einig. Das ist wohl die ›Magie‹, von der man in agilen Teams spricht.

Ich stelle dann die nächste Story vor und das Prozedere beginnt von vorne. Wieder und wieder. Nach einer gefühlten Ewigkeit sind 5 Stories geschätzt, alle mit zwischen 13 und 20 Punkten. Stories mit 3, 5 oder 8 Punkten, wie zu Anfang, kommen kaum mehr vor. Irgendwie werden die Schätzungen immer höher …

»Und jetzt zum Commitment!«, krakeelt es in den Raum … Irgendwas ist mit der Spinne heute nicht in Ordnung. Fritz hat jetzt eine Stimme wie eine Kettensäge, wobei eine Kettensäge etwas empathischer klingt. Das hat Fritz eigentlich nicht verdient … »Die Velocity im letzten Sprint war ja super – 60 Punkte für 3 abgeschlossene Stories! Okay, wir haben 4 offengelassen, aber – ganz großes Kino!«, meint Fritz zu wissen. »60 Punkte! Da wir im nächsten Sprint alle wieder komplett anwesend sind – und ihr ja schon reichlich an den noch offenen Stories gearbeitet habt – meint Ihr, Ihr könnt die ersten 3 TOP Stories noch ins Backlog ziehen?« Banges Hoffen. »Und die restlichen offenen Stories werden dann bestimmt auch fertig, oder?«

Leon regt sich, seine Kamera flimmert etwas. Sein Gesicht ist zwar immer noch nicht zu sehen, dafür ein T-Shirt Aufdruck ›EAT SLEEP FORTNITE REPEAT‹. Er ist halt auch Video-Gamer. »Äh, ich weiß nicht …«, brabbelt es aus der Spinne. »Ich würde nur eine neue Story mit reinnehmen.« »Also nur die erste Story neu ins Backlog?« »Ja, wäre ok«, meint Leon. »Was meinen die anderen?« fragt Fritz. Niemand antwortet. Zwei Leute im Raum nicken, was Fritz natürlich nicht hören und auf seinem Monitor wahrscheinlich auch nicht sehen kann. Trotzdem freut er sich. »Wir haben ein neues Backlog«, jubelt er, während ich vom Glauben abfalle. Es fühlt sich an wie immer: Die Velocity ist super, aber gefühlt geht die Leistung des Teams kontinuierlich nach unten … »Leider haben wir unsere Zeit aufgebraucht, weil die Schätzung etwas länger gedauert hat. Das Task-Planning holen wir morgen im Daily nach, ok?« »OK!«, tönt wieder jemand aus der Spinne. Danach ist Ruhe.

»Ciao! Bis nachher in der Retro! Ich freue mich auf Euch!«, erklärt Fritz. Da gibt´s bestimmt was zu besprechen. Ich werde wohl teilnehmen, und mich dann muten. Parallel andere Sachen machen und mit einem halben Ohr hinhören. In der Regel reicht das ja auch.

Agilität ohne Alternative? Hybride Zusammenarbeit?

Da muss mehr kommen, finde ich.

Helft mir!

Euer Liam

PS: Liam ist – wie alle anderen Protagonisten in dieser Story – eine fiktive Figur. Ebenso ist die Geschichte selbst fiktiv. Ähnlichkeiten mit lebenden Personen sind rein zufällig.

AM ANFANG WAR DAS CHAOS

Warum ›Agil‹ ein Erfolgsmodell wurde von Andreas Apeldorn

Warum hat sich Agilität als Erfolgsmodell in der Unternehmenswelt durchgesetzt? Der Autor nimmt uns auf eine Zeitreise mit, vom starren, fehleranfälligen Wasserfallmodell bis zur agilen Revolution. Dabei entlarvt er die Schwächen konventioneller Projektmanagement-Ansätze und zeigt, wie agile Methoden wie Scrum durch direkte Kommunikation, Interaktion und Team-Spirit Unternehmen wendiger, effizienter und erfolgreicher machen.

Dieser Beitrag ist für alle, die verstehen wollen, was den Erfolg agiler Teams ausmacht. Und warum heute neue Ansätze gefordert sind.

Seit dem Aufkommen von Scrum vor etwa 20 Jahren hat sich ›Agility‹ zu einem Erfolgsmodell entwickelt, das seinesgleichen sucht. Mit dem Ergebnis, dass Agilität – und insbesondere Scrum – in vielen Unternehmen eine Art ›Standard‹ geworden ist, eine Policy, bei der kaum mehr hinterfragt wird, ›warum‹ überhaupt so gearbeitet werden soll. Wie bei vielen Dingen lohnt es sich deshalb auch hier, nach den Ursprüngen zu schauen.

Der Blick zurück: Wasserfall als Standard für Projektmanagement

In der Zeit vor der Jahrtausendwende war Wasserfall die Standardmethode für anspruchsvolles Projektmanagement.

Bei nach dem Wasserfall-Prinzip organisierten Projekten kamen zunächst die Businessexperten zusammen, sammelten die Geschäftsanforderungen und dokumentierten sie in einem umfassenden Dokument. Diese Dokumente waren lang und detailliert und enthielten alles, von der Geschäftsstrategie bis hin zu umfassenden funktionalen Spezifikationen und visuellen Entwürfen für Benutzeroberflächen. Ich habe selbst schon Business-Requirement-Dokumente mit knapp 2000 Seiten in der Hand gehalten. Anschließend kamen Techniker zusammen, und entwickelten auf dieser Basis ein technisches Anforderungsdokument. In diesem Dokument wurden die IT-Architektur, die Datenstrukturen, objektorientierte funktionale Entwürfe, Benutzeroberflächen und andere nichtfunktionale Anforderungen definiert. Erst danach kamen die Entwickler an Bord, um die Systeme zu entwickeln, zu testen und produktionsreif zu machen. Was auf dem Papier wie ein geordneter und geregelter Prozess aussah führte in der Realität allerdings oft zu Problemen.

Einige typische Stolpersteine waren:

Ungenauigkeit der Anforderungen: Da alle Anforderungen am Anfang des Projekts festgelegt wurden konnten Unklarheiten oder Änderungen im Laufe der Zeit zu Fehlinterpretationen und Anpassungsschwierigkeiten führen.

Lange Entwicklungszyklen: Wasserfallprojekte folgten einem strengen Ablauf, bei dem jede Phase abgeschlossen sein musste, bevor die nächste Phase beginnen konnte. Dies führte mitunter zu langen Entwicklungszyklen, die sich negativ auf die Reaktionsfähigkeit des Projekts auswirkten.

Mangelnde Flexibilität: Änderungen oder Anpassungen während des Projekts konnten schwierig sein, da der Wasserfallansatz auf strikter Planung und Vorhersehbarkeit basierte.

Fehlende Kundenbeteiligung: Kunden wurden normalerweise zu Beginn des Projekts in die Anforderungsfestlegung einbezogen. Änderten sich jedoch ihre Bedürfnisse im Laufe der Zeit, führte die fehlende kontinuierliche Kundenbeteiligung häufig zu Lösungen, die nicht den aktuellen Anforderungen entsprachen.

Schwieriges Risikomanagement: Da Risikobewertungen normalerweise zu Beginn des Projekts durchgeführt werden, können spätere unvorhergesehene Risiken schwerer zu bewältigen sein.

Mangelnde Transparenz: Der sequenzielle Charakter des Wasserfallmodells kann dazu führen, dass Teams in den verschiedenen Phasen des Projekts wenig Einblick in den Fortschritt der anderen haben. Dies erschwert die Zusammenarbeit und Koordination.

Hohe Kosten von Änderungen: Sind in späteren Phasen Änderungen erforderlich, können die Kosten für die Umsetzung dieser Änderungen aufgrund der fehlenden Flexibilität des Wasserfallmodells erheblich steigen.

Späte Lieferung der Lösung: Kommt es innerhalb der strengen Phasenabfolge zu Verzögerungen in einzelnen Phasen kann es bei Wasserfallprojekte dazu kommen, dass das Endprodukt später als geplant geliefert wird.

Mangelnde Anpassungsfähigkeit an sich ändernde Marktbedingungen: Wenn sich Marktbedingungen während eines Projekts ändern, kann es schwierig sein, das Projekt anzupassen, um auf diese Änderungen zu reagieren.

Fehlende regelmäßige Kundenrückmeldungen: Bei Wasserfallprojekten werden Kundenrückmeldungen häufig erst am Ende des Projekts berücksichtigt. Dies kann zu unerwarteten Abweichungen von Kundenanforderungen führen.

Wie auch Isaac Sacolick in seiner »Brief History of the Agile Methodology« ausführte, konnte es bei Wasserfallprojektenunter dem Strich mehrere Jahre dauern, bis ein Projekt umgesetzt war und der Auftraggeber die bestellte Lösung bekam – wenn es überhaupt so weit kam. Laut dem Chaos-Report 2015 waren etwa 29% der Wasserfall-Projekte ›erfolgreich‹ (d.h. im Zeit- und Budgetrahmen und mit einem zufriedenstellenden Ergebnis). 52% der Projekte gerieten in Schwierigkeiten (d.h. sie lagen über dem Budget, über dem Zeitrahmen und/ oder hatten weniger als die erforderlichen Merkmale und Funktionen). 19% der Wasserfallprojekte scheiterten völlig (d.h. sie wurden vor der Fertigstellung abgebrochen oder geliefert und nie verwendet).

Dass nur 29% der Wasserfallprojekte erfolgreich waren bedeutet, dass 71% der Projekte früher oder später im Krisenmodus landeten. Und für diese kritischen Fälle gab es den ›War-Room‹.

Wenn nichts mehr geht: der War-Room

Ein War-Room ist ein Raum, in dem alle Mitglieder des Projektteams zusammenkommen, um sich intensiv auf die Lösung der Probleme im Projekt zu konzentrieren. Das war aus mehreren Gründen hilfreich:

Zusammenarbeit: Die War-Room Umgebung hilft dabei, alle wichtigen Stakeholder zusammenzubringen und intensiv zusammenzuarbeiten. Der Zeitaufwand für Abstimmung und die Kommunikation wird reduziert, alle Teammitglieder sind vor Ort und sofort informiert.

Geschwindigkeit: Probleme können in Echtzeit erkannt, diskutiert und gelöst werden. Dies ist ein erheblicher Unterschied zu einer traditionellen Organisation, in der es oft Tage oder sogar Wochen dauern kann, bis ein Problem die relevanten Interessengruppen erreicht hat und gelöst werden kann. Die Nähe und Verfügbarkeit von Entscheidungsträgern im War-Room kann außerdem Entscheidungsprozesse erheblich beschleunigen. Denn die Wege sind kurz.

Transparenz: In einem War-Room herrscht vollkommene Transparenz. Jeder ist über den Projektstatus und alle laufenden Probleme informiert. Diese Transparenz kann dazu führen, dass auch das Verantwortungsgefühl für das gemeinsame Projekt steigt. Zudem kann sie dafür sorgen, dass alle Beteiligten an einem Strang ziehen.