Wie erzeuge ich eine gute Atmosphäre in Online-Workshops?

Wie erzeuge ich eine gute Atmosphäre in Online-Workshops?

Eine gute und aktivierende Atmosphäre ist das A und O

„Ich war ehrlich überrascht, wie kurzweilig der Workshop war. Mit vielen interaktiven Übungen, fast ohne PowerPoint, mit gemeinsamem Whiteboard und digitalen Post-Its – die Zeit verging wie im Fluge.“

Lern-Spiel auf dem Board

„Ich habe noch nie zuvor aus einem Online-Seminar so viel mitgenommen.“

So und so ähnlich war das Feedback aus unseren bisher durchgeführten Onlline-Workshops. Die Vorbereitung war allerdings mehr Aufwand, als wir dachten. Ein als Präsenz-Seminar entwickeltes Konzept lässt sich nicht so einfach als Online-Seminar durchführen. Aber es hat super funktioniert und sich auf jeden Fall gelohnt.

Update: Aufgrund vieler Nachfragen, wie man Remote Meetings und Workshops gestalten kann, haben wir kurzerhand ein Kompakt-Online-Seminar dazu erstellt und bieten Euch das ergänzend zu diesem Blog-Beitrag an.

Was macht eine gute Atmosphäre aus?

  • Eine gute Aktivierung und gegenseitiges Kennenlernen mit Video.
  • Viel Interaktion und sich mit den Tools nach und nach vertraut machen.
  • Abwechslung in den Formaten (genauso wichtig, wie im Präsenz-Workshop).
  • Remote-Spiele helfen bei der Lernerfahrung und unterstützen eine gelungene Atmosphäre.
  • Pausen mit Disziplin, lange aufeinander warten ist ein Atmosphären-Killer.
  • Kleinere (kürzere) Einheiten, als im Präsenz-Workshop und sehr häufiges Feedback – zu den Workshop-Inhalten und zum Format an sich.

Aktivierung

Online scheint anstrengender zu sein. Es empfehlen sich eher kleinere Einheiten in kurzen Zeitabständen. Ein 2-Tages-Seminar wird besser an 4 halben Tagen durchgeführt, sonst geht leicht die Energie in den Keller. Wir vermuten, dass das daran liegt, dass eine höhere Aufmerksamkeit notwendig ist, aufgrund der reduzierten Vielfalt der Sinneseindrücke.

Themensammlung im Rahmen einer Online-Konferenz

Der Start mit Aktivierung, Vorstellungsrunde und Erwartungsabfrage funktionierte verblüffend ähnlich, wie im Präsenz-Seminar. Die Teilnehmer brachten vom Trainer moderiert Ihre Post-Its auf die Metaplanwand.

Nach diesen Erfahrungen sind wir definitiv der Meinung, dass diese Atmosphäre ohne Video nicht zu schaffen wäre. Eine persönliche Bindung kann nur entstehen, wenn man sich sieht.

Interaktion

Anschließend führten wir eine Scrum-Simulation durch. Als virtueller Tisch fungierte das Board. Etwas experimentieren mussten die Teilnehmer, da das „Zurechtschneiden“ von Moderationsmaterialien nicht immer wie erwartet funktionierte: Manchmal ließ das Tool nur bestimmte Varianten zu, die mit Schere und Klebeband einfacher gewesen wären.

Dafür funktionierte der Aufbau eines Scrum-Boards wesentlich einfacher – allerdings musste die Nutzung des Boards erst einmal geübt und verinnerlicht werden. Es wurde sehr deutlich, dass wie immer die Theorie verhältnismäßig einfach ist, die Praxis dann aber doch einiges an Übung erfordert, bis man nicht mehr bei jedem einzelnen Schritt heftig überlegen muss.

Stationenlernen in Online-Gruppen

Auf einem gemeinsamen Whiteboard kann es zu Konkurrenz-Situationen kommen, insbesondere, wenn in Teil-Gruppen in getrennten „Räumen“ gearbeitet wird. Dies lässt sich wunderbar spielerisch nutzen, z.B. indem auf dem Board wechselseitig Kommentare hinterlassen werden: Kommunikation über Post-Its. Und natürlich in der Reflexion besprechen.

Wie im Präsenz-Training zeigten sich viele Effekte, die in der anschließenden Retrospektive – manche nennen es auch De-Briefing – ausführlich diskutiert wurden, bis hin zum Finden sinnvoller Maßnahmen.

Ohne zu sehr ins Detail zu gehen sei noch angemerkt, dass viele didaktische Methoden wie Stationenlernen, oder die eine oder andere Liberating Structure durchaus ähnlich, wie im Präsenz-Seminar funktioniert haben.

Selbst ein Spiel, das einige Elemente des Ball-Point-Game in die Online-Welt übertragen konnte, hat super funktioniert.

Praktische Tipps für die Durchführung

Team Charta Online
  • Bis 12 Teilnehmer ist alles noch gut überschaubar. Bei mehr Teilnehmern wird es für einen Trainer sehr schwierig, Gruppenübungen zu betreuen. Wir waren sogar mit 2 Trainern am Start, damit konnten wir sicherstellen, dass sich kein Teilnehmer ausgegrenzt gefühlt hat.
  • Während der immer wieder eingestreuten kurzen Theorieblöcke ist es wichtig, die Teilnehmer zu ermuntern, genauso aktiv Zwischen-Fragen zu stellen, als befänden sich alle im Präsenz-Seminar. Das ist mit ständig sichtbarem Bild auch viel einfacher, als in einer typischen Telefonkonferenz, da man sich auch visuell bemerkbar machen konnte (z.B. näher an die Kamera bewegen, usw.)
  • Theorieblöcke sollten immer möglichst kurz sein. Im Online-Seminar ist dies noch wichtiger.
  • Textlastige PowerPoint-Folien sollten nach Möglichkeit vollständig vermieden werden. Besser ist es, Inhalte ähnlich wie auf Flipcharts live zu zeichnen oder zu erarbeiten.
  • Bilder bzw. Grafiken funktionieren einigermaßen gut, sogar mit PowerPoint. Allerdings ist bei Animationen Vorsicht geboten: PowerPoint-Möglichkeiten wir Verblassen oder Einfliegen verfehlen oft ihre Wirkung, da die übertragenen Bilder zu selten aktualisiert werden und die Animationen dadurch im besten Fall „ruckeln“.
  • Eine Einführung in die Technik des verwendeten Online-Boards zu Beginn ist unbedingt notwendig. Einfach nur die Funktionalität zu erklären, funktioniert jedoch nicht. Vielmehr werden zu Beginn ein oder zwei Übungen benötigt, bei denen man ausreichend Zeit hat und den Umgang mit unterschiedlichen Möglichkeiten des Boards ausprobieren kann.
  • Wenn die Atmosphäre stimmt, können auch tiefgreifende Fragen bearbeitet werden – wie z.B. eine Team Charta erstellen oder das Wertesystem des Teams zu ergründen.

Ein paar Worte zur Technik und zum Setup

Zum Einsatz kamen:

  • Ein Online-Collaboration-Board (wir haben Miro verwendet)
  • Eine gute, ruckelfreie Video-Konferenz-Software (bei uns Zoom)
  • Jeder Teilnehmer hatte zwei Bildschirme und eine Kamera zur Verfügung

Ein zweiter Bildschirm mit mindestens FullHD-Auflösung ist unverzichtbar, um das gemeinsam bearbeitete Board und die Videos der anderen Teilnehmer immer sichtbar zu haben. Wenn ich zwischen Fenstern hin und her wechseln muss, kostet das viel Aufwand – und lenkt ungemein ab.

Jeder Teilnehmer benötigt eine Kamera. Ohne Video ist ein Workshop in dieser Form nicht vorstellbar. Erst wenn man sich sieht, entsteht die notwendige Gruppendynamik.

Einige der der Teilnehmer zeigten mit Hilfe einer externen Kamera nicht nur das übliche Portrait, sondern darüber hinaus etwas von Ihrem Arbeitsplatz, teilweise sogar mit Blick auf ihren Bildschirm. Natürlich möchte oder kann das nicht jeder tun und natürlich kommt es sehr auf den Teilnehmerkreis an, wie viel man von sich preisgeben möchte. Aber nicht nur, dass das davon abhielt, nebenher etwas Anderes zu tun, es erzeugte auch eine tolle Atmosphäre mit persönlicher Note.

Auf dem Board haben wir alle Flipcharts und Metaplanwände vorbereitet – genau so, als befänden wir uns in einem realen Schulungsraum. Und digitales Moderationsmaterial hat durchaus auch Vorteile: Es gibt keine schwarzen Finger und die Post-Its sind unendlich – und fallen ganz nebenbei auch nie vom Board ab.

Mehr oder weniger selbsterklärend ist, dass alle Internetverbindungen stabil sein müssen. Wenn einer ständig reausfliegt, der Ton schlecht ist, oder das Bild ruckelt, dann ist man von den technischen Unzulänglichkeiten so sehr abgelenkt, dass die Konzentration auf die Lerninhalte sehr schwer wird.

Fazit

Remote- bzw. Online-Seminare oder -Workshops können Präsenz-Veranstaltungen nicht vollständig ersetzen. Aber mit den entsprechenden Techniken und didaktischen Methoden lässt sich mehr bewirken, als wir ganz am Anfang erwartet hätten. Wir waren positiv überrascht.

Und Online-Workshops haben sogar ein paar Vorteile: Man muss nirgends hin fahren, hat keinen Stau und keine Schwierigkeiten mit Raumbuchungen. Und nie Probleme mit leeren Stiften.

Visual RE – Was ist das? & Wozu ist das gut?

Visual RE – Was ist das? & Wozu ist das gut?

Visual RE ist ein Set an Denkweisen und Methoden, die in der Produktentwicklung helfen, schneller ein gemeinsames Verständnis zu erreichen.

Der Begriff Visual RE steht zunächst mal für
Requirements Engineering mit visuellen Methoden“.
Visual RE steht aber auch für
Requirements Exploration, also einen iterativen Prozess, in dem wir mit Hilfe schneller Feedbackzyklen herausfinden, was der Anwender wirklich braucht.

Requirements Engineering wird ja nun schon seit Jahren erfolgreich eingesetzt. Wozu braucht es jetzt eigentlich Visual RE?

Visual RE adressiert im Wesentlichen die folgenden zwei Punkte:

  1. Das Gesamtbild ständig vor Augen zu haben.
  2. Unterstützen eines kontinuierlichen Dialogs mit dem Ziel des gegenseitigen Verständisses und schnellem Feedback.

Informationen, die irgendwo abgelegt werden, sind nicht mehr präsent.
Aus den Augen aus dem Sinn. Visuell arbeiten bedeutet also, das Gesamtbild ständig vor Augen zu haben und aktiv damit zu arbeiten.

Das fördert zielgerichtetes Arbeiten, weil man den Kontext besser einsortieren kann. Außerdem wird kooperatives Arbeiten optimal unterstützt.

Beispiel dafür ist ein Kanban-Board, in dem die Arbeit eines Team visuell abgebildet ist und jeder im Team sehen kann, welche Arbeit gerade von wem in welchem Schritt bearbeitet wird. Sehr hilfreich z.B., wenn mehrere Personen (Product Owner, Requirements Engineers, UX-Experten, etc.) gemeinsam an Anforderungen zu einem Produkt arbeiten. Ein weiteres Beispiel, welches noch näher am Kontext des Anforderungsmanagement ist, wäre die Story Map. Dieses visuelle Arbeitsmittel stellt auf sehr übersichtliche Art und Weise die Zusammenhänge von Anforderungen und Releases gleichzeitig mit den Arbeitsschritten des Anwenders in einem Bild dar. Ein großer Wert ist hier die Präsenz der Story Map im Teamraum. Hier haben wir schon oft erlebt, wie sich am Board ein lebhafter Dialog um fehlende und ggf. auch überflüssige Features entwickelt hat.
Visual RE stellt alle bekannten Methoden, die solche Art von Vorgehensweisen unterstützen in einen Gesamtzusammenhang.

Im RE geht es des weiteren darum, gegenseitiges Verständis zwischen dem, der ein Produkt wünscht und dem, der das Produkt herstellen soll zu erreichen. Also viel Kommunikation. Erwiesenermaßen ist die Verwendung von bildhaften und optisch strukturierten Informationen deutlich effektiver, als rein sprachlich oder textuell präsentierte Information.

Die Erfahrung hat gezeigt, dass leider viel zu viele Requirements-Prozesse darauf abzielen, Information zuerst möglichst vollständig zu sammeln und dann zur Entwicklung oder Weiterverarbeitung über den Zaun zu werfen.
Ein typisches Antipattern dokumentenzentrierter Vorgehensweisen.
Dies dient eben nicht dem gegenseitigen Verständis, sondern eher nur der eigenen Absicherung.
Visuelle Methoden fokussieren von Anfang an auf einen gemeinsamen Entstehungsprozess. Bilder und visuell unterstützende Techniken wie z.B. MindMaps, Canvas oder z.B. auch Papier-Prototypen beschleunigen dabei -direkt im Dialog- die Feedbackschleifen und reduzieren so Missverständnisse. Durch die Verwendung explizit unvollständiger und erklärungsbedürftiger Bilder ensteht im Dialog nach und nach ein gemeinsames Bild. Dieses Prinzip, welches zunächst paradox erscheint, lässt sich sowohl im phasenorientierten, als auch im agilen Vorgehen einsetzen, um gegenseitiges Verständis zu erzeugen.

Um es klarzustellen: Die hier beschriebenen Techniken sind nicht von Grund auf neu, sondern stellen die Prinzipien visuellen Arbeitens im Kontext der Ermittlung, des Managements und des Erkunden von Anforderungen in den Vordergrund. Außerdem bringt es existierende Methoden und Techniken in einen größeren Gesamtzusammenhang.
Kurz: Visual RE

Technical Debt Game

Technical Debt Game

Let’s talk about technical debt.

Was ist los…

… wenn die Velocity sinkt?

… wenn es immer länger dauert neue Features in die Software zu bringen?

… wenn die Anzahl der gemeldeten Fehler nicht weniger wird, sondern eher noch mehr?

… wenn alle danach schreien, das Produkt lieber neu zu entwickeln, als dass man weiterhin daran arbeiten möchte?

Entwicklungsteams reden dann oft von technischer Schuld oder englisch: Technical debt.

In diesem Beitrag möchten wir das „Technical debt game- for non technical people“ vorstellen, welches auf der play4agile 2019 entstanden ist und das Thema erlebbar macht. Die Simulation ist eine gute Grundlage und Anschauliche Demonstration für eine Diskussion über die eigene Lage in der Produktentwicklung.

Die Simulation wurde schon in mehrere Community Events und Traings eingesetzt.

Anleitung, Material und eine passende Präsentation sind im Download enthalten. Statt der Zahlenkarten könnt Ihr auch 2 Sets von dem Spiel The Mind dazu verwenden.

Wenn wir die Simulation bei Euch durchführen sollen oder Ihr Starthilfe braucht, sprecht uns einfach an…

Viel Spass beim ausprobieren!

Digitalisierung ist Wandel

Digitalisierung ist Wandel

Digitalisierung in einem Unternehmen ist nicht einfach eine Reformation der IT oder der Einsatz von ein paar neuen digitalen Technologien.

Digitalisierung ermöglicht und zwingt -aufgrund des Wettbewerbs- Unternehmen neue Geschäftsfelder zu erschließen. Mittel- und langfristig bedeutet dies einen Wandel des Business-Modells. Auf der einen Seite erschafft dies neue Chancen durch Innovationen. Auf der anderen Seite bedeutet dies einen Wandel der Aufgaben für Mitarbeiter. Arbeitsplätze sind in Gefahr, wenn die Mitarbeiter nicht bereit sind, Neues dazu zu lernen. Die Arbeit wird nicht weniger, kann sich aber eben radikal verändern. Digitalisierung bedeutet also immer auch eine Verunsicherung der Mitarbeiter, auf die eine Organisation eingehen muss.

Die neuen digitalen Technologien bringen die Kunden und Anwender deutlich näher an das Unternehmen als früher, oder erhöhen die Frequenz des Kontaktes bzw., des Informationsaustauschs. Dies ermöglicht eine viel konkretere Erfüllung der Kundenbedürfnisse, da durch schnelles Feedback (z.B. unmittelbare Nutzungsstatistiken o.ä.) besser der Kundenwunsch erkannt werden kann. Auch hier gibt es eine Kehrseite: Die Nutzer erwarten viel häufiger eine Änderung oder Anpassung auf ihre individuellen Bedürfnisse.

Dies erfordert einen Wandel der Arbeitsweise des Unternehmens, da damit eine höhere Flexibilität erforderlich wird. Agile Produktentwicklungsmethoden sind daher seit Jahren auf dem Vormarsch. Letztendlich werden agilere Unternehmen als Gewinner aus der Digitalisierung hervorgehen.

Um nun mit diesen Herausforderungen umzugehen, bedarf es einen Wandel der Führung. Selbstorganisation in Teams, mehr Eigenverantwortung bei den Mitarbeitern heißt auch, dass Führungskräfte oder sogar ganze Führungsmodelle neu gedacht werden müssen. Die Themen, die heutzutage heiß diskutiert werden, sind: Loslassen und stetiges Übertragen von Verantwortung an Mitarbeiter/Teams (Empowerment), Unterstützung & Coaching der Mitarbeiter (Servant Leadership) und Führen am System. Führen am System bedeutet Veränderung von Strukturen, statt qualifizierte Mitarbeiter zu (micro-)managen.

Um auf die sich schnell ändernden Anforderungen reagieren zu können, sind lange hierarchische Entscheidungswege oft nicht mehr geeignet. Die neue Arbeitsweise benötigt zudem auch andere Strukturen. Digitalisierung bedeutet also auch einen Wandel der Strukturen hin zu flacheren Hierarchien, mehr Vernetzung von kleinen operativen Teams, oder gar eine Abschaffung der klassischen Organisationsstruktur (z.B. Soziokratie 3.0).

Da diese verschiedenen Wandel niemals komplett abzuschließen sind, ist eine Organisation im Zeitalter der Digitalisierung stetig im Fluss. Dies erfordert ein Umdenken bei allen Beteiligten. Also nicht nur ein Wandel von Analog auf Digital, sondern ebenfalls und insbesondere ein Wandel des Mindsets. (Stichwort Fixed Mindset vs. Growth Mindset).

Das macht eine Digitalisierungs-Transformation so schwierig, aber auch immer wieder spannend.


Hier noch die Sketchnote zum Artikel:

Modern RE 2019

Modern RE 2019

Wir waren in diesem Jahr auf der Modern Requirements Engineering (#MRE19,#modernRE)

Sehr interessante Vorträge…
Weiter unten meine Sketchnotes zu den von mir besuchten Vorträgen.

Außerdem haben wir unser Lieblingsthema visuelles Requirements Engineering vorgestellt, zu dem wir im Dezember ein Training anbieten.

Hier die visuellen Notizen, die direkt live während der Vorträge entstanden sind:

Mythen und Polemik

Mythen und Polemik

„Wir müssen agiler werden!“

Jeder kennt es: In der Kaffeeküche geht es mal wieder hoch her. Jemand hat eine Behauptung rausgehauen und jetzt prallen die Meinungen aufeinander. Wir haben uns mal 5 dieser Behauptungen herausgegriffen, die wir in letzter Zeit immer wieder mal gehört haben – und mit unserem gesammelten Wissen eine Antwort formuliert.

„Agilen Methoden sind besser“

Wortwörtlich genau so oft gehört. Gemeint ist meist, „sind besser, als der aktuell gelebte (Wasserfall-)Prozess“.

Manchmal.

Aber das hängt im Wesentlichen davon ab, mit welcher Art Anforderungen man es zu tun hat. Weiß man ziemlich sicher und genau, wie eine Lösung aussehen soll, bringt agiles Vorgehen u.U. keinen Vorteil.

Sind die Anforderungen jedoch eher unklar, man weiß nicht, ob der Kunde bestimmte Funktionen wirklich braucht und wie diese zu implementieren sind – dann muss man mit höherer Unsicherheit und mehr Risiken im Projekt umgehen. Dann muss man akzeptieren, dass ein Plan sich ändern wird, dann benötigt man Anpassungsfähigkeit und die Möglichkeit, schnell und leichtgewichtig Entscheidungen zu treffen und die Richtung zu justieren.

Bottom Line: Agil zu arbeiten empfiehlt sich bei manchen Aufgabenstellungen mehr, bei anderen weniger.

Und nicht jedes Unternehmen kann agil arbeiten. Ein Unternehmen benötigt einen gewissen Reifegrad, um Selbstorganisation zuzulassen und effektiv und effizient agil zu arbeiten. Manchmal passen die organisatorischen Strukturen (noch) nicht zum agilen Denken. Bevor dann irgendeine neue Methode eingeführt wird, scheitert, zu Frust führt und verflucht wird, ist es manchmal besser, bei den bekannten klassischen Methoden zu bleiben und sich Stück für Stück weiter zu entwickeln. Aber: Einfach ist das nicht.

Was auf jeden Fall nicht funktioniert: Das Management ordnet an, „Wir sind jetzt agil“, und versteht nicht, was wirklich dahintersteckt. Und dann werden blind irgendwelche Berater engagiert und „Agile Methoden“ eingeführt. Am Besten noch mit vielen Schulungen und Zertifizierungen. Das ist teuer, aber im besten Fall unwirksam.

„Agil bedeutet, nach zu Scrum arbeiten“

Oft wiederholt und trotzdem falsch. Scrum kann der Rahmen sein, der mir dabei hilft, Agilität zu leben. Kann, muss aber nicht.

Ich kann mit Scrum herrlich un-agil sein, genauso kann ich sehr agil sein, ohne Scrum zu nutzen.

Agil zu arbeiten heißt, anpassungsfähig zu sein und die agilen Werte und Prinzipien zu leben. Die Methode ist dabei nicht so wichtig – so lange sie uns nicht behindert.

„Wir brauchen agiles Projektmanagement“

Genaugenommen gibt es weder Wasserfall-Projektmanagement, noch agiles Projektmanagement – und schon gar kein hybrides Projektmanagement.

Es gibt sehr viele unterschiedliche Techniken und Praktiken im professionellen Projektmanagement. Diese sind für bestimmte Projekte mehr oder weniger sinnvoll und Projektmanager sollten das Können und die Freiheit haben, diese pragmatisch und (hoffentlich) passend zu den Gegebenheiten im Projekt anzuwenden.

Denn natürlich brauchen wir auch bei agilen Vorhaben eine funktionierende Planung und Vorhersagbarkeit. Ja, wir planen vielleicht leichtgewichtiger und vor allem nur das, was sinnvoll geplant werden kann, soll, oder muss. Wir machen kein Projektmanagement des Projektmanagements willen – aber war das nicht eigentlich schon immer so?

Unser Projektmanagement muss also agiles Arbeiten unterstützen und darf es nicht behindern. Manchmal muss ich ausprobieren, lernen und mich anpassen. Aber manchmal muss ich auch etwas längerfristig planen und den Überblick über Termine behalten. Das hängt davon ab, wie gut der Kunde schon weiß, was er braucht – und von der Klarheit, wie er diesen Bedarf ausdrücken kann. Es hängt nicht von den Werkzeugen ab, die ich im Projektmanagement verwende.

Manchmal sind die klassischen Tools hilfreich, manchmal sind sie zu schwergewichtig. Manchmal sind neue Techniken sinnvoll, manchmal reichen sie nicht aus. Wir nutzen, was sinnvoll ist.

„Agil bedeutet, nicht planen zu können und nicht zu wissen, was wann geliefert werden wird“

Im Gegenteil. Denn: Gibt mir die klassische Planung wirklich Sicherheit? Ich kenne kein klassisch abgewickeltes Projekt, das am Ende so geliefert wurde, wie zu Beginn gedacht. Projekte sind nun einmal neuartig, risikoreich, dynamisch und häufig komplex.

Agil sein heißt, dies zu akzeptieren und Schritt für Schritt vorzugehen – und regelmäßig zu validieren, ob wir noch auf dem richtigen Weg zum richtigen Ziel sind. Um mit Hilfe dessen, was wir aus den bereits erzeugten, sicht- und anfassbaren Teilergebnisse gelernt haben, die bestmöglichen Entscheidungen für unsere weitere Arbeit zu treffen.

Letztendlich ist das magische Dreieck, das Kosten, Inhalt und Zeit in Beziehung bringt, immer gültig. Und die Aussage, dass man Kosten, Inhalt und Zeit vorhersagen und festzurren kann, war noch nie richtig und wurde auch von wirklich professionellen Projektmanagern nie behauptet. Eigentlich logisch, denn dann bräuchte man ja auch kein Projekt-Management mehr, dann würde eine Projekt-Verwaltung vollkommen ausreichen.

„Das Projekt ist zu groß für Agil“

Große Projekte heißt, viele Beteiligte. Viele Beteiligte benötigen viel Interaktion. Je komplexer die Aufgaben, desto mehr Interaktion ist notwendig. Agiles Vorgehen erhöht die Anforderungen an die Häufigkeit der Interaktion.

Sind die Möglichkeiten und Fähigkeiten zur Interaktion und die notwendigen Freiheitsgrade für ausreichend schnelle Entscheidungen vorhanden, dann funktionieren Vorhaben. Wenn nicht, dann nicht.

Mit klassischen Methoden kann Komplexität und die Notwendigkeit für späte und schnelle Entscheidungen reduziert werden – das funktioniert jedoch nur, wenn die Anforderungen bekannt sind. Sind die Anforderungen, auch teilweise, unklar, bleibt keine Wahl: Viele Entscheidungen können nicht gleich zu Beginn eines Vorhabens endgültig getroffen werden. Und dann sind die Projekte vielleicht zu groß für die Fähigkeiten einer Organisation – bzw. vielleicht kann die Organisation nicht agil genug sein. Das liegt dann aber nicht an der Methode.