Aufgrund der Vielzahl an Konnotationen zur Agilität ist es schwierig, eine allgemeingültige Aussage zu treffen. Dennoch bestehen Verbindungen und man kann Agilität gut unter bestimmten Gesichtspunkten in das Ambidextrie-Werkzeug-Set einfügen:

In den letzten Jahren hat sich die Agilität – beginnend aus dem IT-Bereich (Scrum) – zu einer eigenen Arbeitsform etabliert, die auch außerhalb von IT Anwendung findet. Sie wurde in Bereichen eingesetzt, in denen man mit den „klassischen“ Denkweisen nicht mehr weiterkam und eine radikalere Abkehr vorhandener Handlungsmuster nötig wurde. Die Anwendung agiler Arbeitsmethoden resultierte in einem bunten Strauß durchaus auch weltanschaulicher Methoden und Praktiken. Um ein gemeinsames Begriffsverständnis zu erreichen, definieren wir an dieser Stelle Agilität wie folgt: Agilität ist jene Arbeitsweise, die

• nicht langfristiger Planung unterliegt, sondern in kurzen Entwicklungsetappen (Iterationen) voranschreitet und dabei ständig evaluiert.
• KPI als Kriterien zur Erfolgsmessung hinter sich gelassen hat und stattdessen auf das Erarbeiten von Erkenntnissen abzielt (z. B. besseres Verständnis über das Problem, über Implikationen, über Werkzeuge und Instrumente zur Zielerreichung, über vorhandenes und fehlendes Wissen, etc.)
• „schöner Scheitern“ zur Methodik erhebt, um aus Fehlern zu lernen („fail hard, fail fast“).
• von einer Vielzahl an Perspektiven auf das gleiche Thema profitiert und deshalb einen starken Netzwerk-Charakter hat.

In Bezug auf Ambidextrie lässt sich Agilität unter bestimmten Gesichtspunkten mit dem Explore-Modus gleichsetzen. Somit ist Agilität für bestimmte Aufgaben im Rahmen der Organisation geeignet, für andere (aus dem Exploit-Spektrum) wiederum nicht. Die Anwendung agiler Arbeitspraktiken in der Breite hat an einigen Stellen zu einer gewissen Frustration geführt, weshalb nun gelegentlich das Kind mit dem Bade ausgeschüttet wird. Die Ernüchterung, dass auch agiles Arbeiten nicht „das Allheilmittel“ ist, ist immer noch zu beobachten.

Agile Herangehensweisen bzw. Werkzeuge aus dem Explore-Bereich eignen sich für Aufgaben und Vorhaben, bei denen die Lösung nur grob bekannt ist oder nur einzelne Beschreibungen der Eigenschaften der Lösung existieren (z. B. „Wir brauchen irgendwas, das dafür sorgt, dass…“). Da das Ziel nicht vollständig klar ist, besteht meistens auch keine Einigkeit darüber, wie das Ziel zu erreichen ist, welche Methoden, Werkzeuge oder Regeln Anwendung finden könnten oder sollen. Diese Ausgangslage unterscheidet sich elementar vom „Gegenspieler“, dem Exploit-Modus: Dort ist da Ziel oft recht gut beschrieben, Rahmenbedingungen und Ressourcen sind klar und die Werkzeuge zur Zielerreichung sind oft schon erprobt (oft: Gesetze, Regelwerke, feststehende Prozesse, Vorschriften).

Die positiven Verdienste des agilen Arbeitens/der Erledigung von Aufgaben mit dem Explore-Modus gehen meist mit einer negativen Kehrseite einher, die für Firmen oft größere Probleme auslöst: Von dem freieren, ergebnisoffenen und nicht vorstrukturierten Prozess ist der Weg zum Chaos, zu ungeplanten (und damit oft unerwünschten) Ereignissen nicht weit. Die Zielerreichung ist bei weitem nicht so gut planbar wie bei einem durchstrukturierten Prozess wie z. B. bei einem Projekt, bei dem zumindest im Projekt-Set-Up Anfangs- und Enddatum eingetragen werden, Aufgaben verteilt werden und darauf hingearbeitet wird, dass diese Ziele eingehalten werden.

Es ist Unternehmen eigen, dass sie mit unkontrollierbaren Ereignissen Schwierigkeiten haben und je größer das Unternehmen ist, umso eher wird versucht, diesem Geschehen einen definierten Rahmen zu geben. Dieser definierte Rahmen in der Steuerung kollidiert mit den inhaltlich unklaren Einzelteilen, die am Beginn einer Explore-Aufgabe stehen: Es ist z. B. bei einem Innovationsteam noch nicht absehbar, wann sie mit einer neuen Produktinnovation „fertig“ sein werden, geschweige denn, wie diese aussieht oder wie viel Umsatz sich damit bis 2030 machen lässt. Das heißt nicht, dass man dieser Erkenntnisse nie haben wird, aber dass sie zuverlässig am Beginn einer Explore-Phase stehen, ist sehr unwahrscheinlich.

Ein Problem bei der Betrachtung von Agilität liegt in der fehlenden Definition von Agilität. In den letzten Jahren hat sich (beginnend aus der IT-Welt) ein bunter Pool an Grundannahmen, weltanschaulichen Setzungen, Forderungen, Postulaten, Werkzeugen, Beispielen und Erkenntnissen gebildet. Aufgrund der Vielzahl an Konnotationen ist es schwierig, eine eindeutige Aussage zu machen – dennoch bestehen Verbindungen und man kann Agilität gut unter bestimmten Gesichtspunkten in das Ambidextrie-Werkzeug-Set einfügen.