Was ist ein „Tiger-Team“? Definition, Ursprung und Einsatzmöglichkeiten

„Houston, wir haben ein Problem.“

Wir alle haben ihn schon mindestens einmal verwendet. Er ist zum Synonym für jenen Moment geworden, in dem einem das Herz in die Hose rutscht, wenn etwas Wichtiges kaputtgeht und man schnell eine Lösung braucht.

Im Arbeitsalltag bedeutet das meist ein Problem, das mehrere Teams betrifft. Wie zum Beispiel jener eine Fehler, der mehrere Fehlerbehebungsrunden überstanden hat, drei Kundendatenbanken lahmgelegt hat und das Volumen der Support-Tickets in die Höhe treibt. Es begann in der Entwicklung, aber mittlerweile sind auch der Support, das Produktmanagement und der Kundenerfolg daran beteiligt.

Was Sie in diesem Moment brauchen, ist ein „Tiger-Team“: eine kleine, temporäre Gruppe von Spezialisten, die zusammengestellt wird, um ein klar definiertes, hochbrisantes Problem zu lösen. Die Idee entstand in den 1960er Jahren in der Luft- und Raumfahrt und hat sich seitdem auf den Ingenieurbereich, den öffentlichen Dienst, den Bereich der Sicherheit und den täglichen Betrieb ausgeweitet.

Irgendwann wurde die Beschreibung jedoch so weit gedehnt, dass sie fast jedes dringende Meeting mit einigen wenigen Führungskräften umfasste. Wir werden erläutern, was ein „Tiger-Team“ eigentlich ist, woher der Begriff stammt und wie es sich von den Task Forces und „War Rooms“ unterscheidet, mit denen es oft verwechselt wird.

Was ist ein „Tiger-Team“?

Ein „Tiger-Team“ ist ein kurzfristig gebildetes Team mit einer einzigen Aufgabe: ein Problem zu lösen, das die bestehende Struktur nicht schnell genug beheben kann.

Die Struktur ist wichtiger als die Beschreibung. Ein „Tiger-Team“ benötigt ein klar definiertes Ziel, das erforderliche Fachwissen zur Untersuchung sowie genügend Befugnisse, um handeln zu können, ohne zu einem weiteren ständigen Ausschuss zu werden.

Tiger-Teams weisen in der Regel einige gemeinsame Merkmale auf:

Diese Struktur lässt sich an den „Tiger Teams“ des US-Arbeitsministeriums im Bereich der Arbeitslosenversicherung erkennen. Seit 2021 bringt das Ministerium Spezialisten aus den Bereichen Betrugsbekämpfung, Kundenerfahrung, Arbeitslosenversicherung, Daten und Systemtechnik zusammen, um Probleme in den einzelnen staatlichen Programmen zu bewerten und kurzfristige Verbesserungsmaßnahmen zu empfehlen. In den ersten 24 Monaten arbeiteten diese Teams mit 36 Bundesstaaten zusammen.

Allerdings sieht nicht jedes „Tiger-Team“ gleich aus. Manche Mitglieder bleiben möglicherweise teilweise in ihrer regulären Arbeit tätig, während andere sich vollständig davon zurückziehen.

Woher stammt der Begriff „Tiger-Team“?

Der Begriff geht auf die amerikanische Luft- und Raumfahrt der 1960er Jahre zurück, lange bevor er in der Sprache des Geschäfts Einzug hielt.

Eine der frühesten dokumentierten Verwendungen findet sich in dem 1964 erschienenen SAE-Beitrag „Program Management in Design and Development“ von J. R. Dempsey, W. A. Davis, A. S. Crossfield und Walter C. Williams. Darin wurde ein „Tiger-Team“ als eine Gruppe von „ungezähmten und unkonventionellen technischen Spezialisten“ beschrieben, die aufgrund ihrer Erfahrung, Energie und Vorstellungskraft ausgewählt wurden. Ihre Aufgabe bestand darin, unermüdlich nach möglichen Fehlerquellen in Raumfahrtsystemen und Simulationen zu suchen.

Und dabei handelte es sich nicht einfach nur um erfahrene Experten, die in einem Raum versammelt wurden. Von ihnen wurde erwartet, dass sie Annahmen hinterfragen, Schwachstellen aufdecken, die anderen entgangen waren, und außerhalb der üblichen Rahmenbedingungen eines Programms arbeiten.

Sechs Jahre später verlieh die Apollo-13-Mission dem Begriff eine seiner berühmtesten Assoziationen. Am 13. April 1970 explodierte ein Sauerstofftank, während sich das Raumschiff etwa 200.000 Meilen von der Erde entfernt befand. Jack Swigert funkte an die Missionskontrolle: „Houston, wir haben hier ein Problem“, ein Satz, der später als „Houston, wir haben ein Problem“ in die Populärkultur Einzug hielt.

Der NASA-Flugleiter Gene Kranz leitete daraufhin das, was in den NASA-Unterlagen als das „Tiger-Team“ der Apollo-13-Mission bezeichnet wird , und arbeitete gemeinsam mit dem gesamten Missionsleitungsteam daran, die Probleme zu lösen, die einer sicheren Rückkehr der Astronauten im Wege standen. Das Missionsleitungsteam der Apollo-13-Mission erhielt später für seine Rolle bei der Rettungsaktion die Presidential Medal of Freedom.

Apollo 13 trug dazu bei, das „Tiger-Team“ als Modell für konzentrierte Problemlösung unter Druck zu etablieren, hat den Begriff jedoch nicht geprägt.

Tiger-Team vs. Task Force, War Room, Red Team und Skunkworks

Tiger-Teams werden oft mit anderen Gruppenstrukturen verwechselt, wie beispielsweise Task Forces, War Rooms, Red Teams und Skunkworks. Bei all diesen handelt es sich zwar um kleine Gruppen, die außerhalb der üblichen Teamstruktur arbeiten, doch sie werden aus unterschiedlichen Gründen zusammengestellt.

Am häufigsten wird ein „Tiger-Team“ mit einer „Task Force“ verwechselt, da beide Teams Mitarbeiter aus verschiedenen Funktionen zusammenbringen können. Der Unterschied liegt im Auftrag. Eine Task Force untersucht möglicherweise ein weitreichendes Problem, koordiniert eine Initiative oder empfiehlt Änderungen. Einem „Tiger-Team“ wird in der Regel ein enger gefasstes Problem zugewiesen und mehr Freiheit eingeräumt, um dieses zügig zu lösen.

Ein „War Room“ hat einen anderen Ausgangspunkt. Er wird im Zusammenhang mit einem bereits stattfindenden Incident eingerichtet und bietet den daran beteiligten Personen einen gemeinsamen Ort sowie einen gemeinsamen Rhythmus für Entscheidungen. Aus einem „War Room“ kann ein „Tiger-Team“ hervorgehen, wenn der unmittelbare Incident ein tiefer liegendes Problem offenbart, das konzentrierte Arbeit erfordert, sobald sich die Lage stabilisiert hat.

Red Teams sind bewusst auf Konfrontation ausgerichtet. Im Bereich der Cybersicherheit definiert das NIST ein Red Team beispielsweise als ein Team, das organisiert wurde, um die Angriffs- oder Ausnutzungsfähigkeiten eines Angreifers nachzuahmen. Das Ziel besteht darin, Schwachstellen aufzudecken, indem das System auf die Probe gestellt wird. Ein Tiger-Team mag zwar diese Denkweise nutzen, seine umfassendere Aufgabe besteht jedoch darin, das Problem zu lösen, für dessen Bewältigung es zusammengestellt wurde.

Ein „Skunkworks“-Team verfolgt einen anderen Ansatz. Dieses Modell, das durch die „Skunk Works“ von Lockheed Martin bekannt wurde, gewährt einer kleinen Gruppe ungewöhnlich große Autonomie bei der Entwicklung von Neuem. Tiger-Teams werden in der Regel zur Lösung eines bestimmten Problems mit einer festgelegten Bedingung gebildet. Skunkworks-Teams können hingegen viel länger zusammenbleiben, während eine Idee erforscht, entworfen und getestet wird.

Diese Unterscheidungen sind wichtig, denn einer Gruppe einen dringlicher klingenden Namen zu geben, ändert nichts daran, wie sie funktioniert. Bevor man ein „Tiger-Team“ bildet, sollte man sich lieber fragen, ob das Problem diese spezielle Struktur überhaupt erfordert.

Wann sollte man ein „Tiger-Team“ bilden?

Ein „Tiger-Team“ ist sinnvoll, wenn ein Problem funktionsübergreifend ist, den Einsatz von Spezialisten erfordert oder im normalen Prozess ins Stocken geraten ist. Doch wenn Spezialisten in ein temporäres Team einbezogen werden, werden sie dadurch von ihrer eigentlichen Arbeit abgezogen.

Ein guter Fall erfüllt in der Regel vier Kriterien:

Das gleiche Modell lässt sich auch präventiv einsetzen, bevor eine risikoreiche Änderung in die Produktion gelangt oder eingeführt wird.

Was sind die wichtigsten Rollen in einem Tiger-Team?

Ein „Tiger-Team“ braucht keine große Besetzung, aber jeder sollte wissen, wofür er verantwortlich ist. In den meisten Fällen benötigen Sie einige wenige Kernrollen:

In einem kleinen Team kann eine Person mehrere Rollen übernehmen. Entscheidend ist, dass Zuständigkeiten, die Verantwortung für das Tagesgeschäft, Fachwissen und die Dokumentation jeweils klar zugeordnet sind.

So leiten Sie ein Tiger-Team in 7 Schritten

Sobald das Team zusammengestellt ist, muss die Arbeit ausreichend strukturiert sein, damit die Untersuchung nicht zu einer Aneinanderreihung von Meetings, Theorien und zusammenhanglosen Korrekturmaßnahmen verkommt. Die folgenden Schritte führen das Team von der ersten Sitzung über die Validierung bis hin zur Übergabe.

1. Formulieren Sie das Ziel als Arbeitsauftrag

Jedes „Tiger-Team“ braucht eine Abschlussbedingung: das konkrete Ergebnis, das allen signalisiert, dass das Problem gelöst ist und das Team sich auflösen kann. Einigen Sie sich zunächst darauf und machen Sie daraus dann eine Richtlinie, an der sich die Beteiligten bei ihren täglichen Entscheidungen orientieren können.

Ein kurzer Arbeitsauftrag reicht in der Regel aus, um die Arbeit zu erledigen. Er sollte folgende Fragen beantworten:

Achten Sie besonders auf die letzte Frage. Stellen Sie sich ein Team vor, das einen wachsenden Bearbeitungsrückstand abarbeitet. Die Warteschlange unter 500 Fälle zu bringen, mag sich wie ein Erfolg für einen Nachmittag anfühlen. Sie eine ganze Woche lang auf diesem Niveau zu halten, während die tägliche Bearbeitung weiterhin schneller voranschreitet als der eingehende Arbeitsaufwand, ist ein weitaus stärkerer Beweis dafür, dass die Lösung von Dauer ist.

2. Legen Sie Rollen, Entscheidungsbefugnisse und Grenzen fest

Beginnen Sie damit, den Leiter, den Sponsor, die Spezialisten und die Person zu benennen, die das Arbeitsprotokoll auf dem neuesten Stand hält. Klären Sie dann frühzeitig die Frage der Entscheidungsbefugnisse. Das Team kann einige Entscheidungen selbst treffen, andere bedürfen der Zustimmung des Sponsors, und wieder andere liegen weiterhin bei den Teams, die normalerweise dafür zuständig sind.

Das Team benötigt zudem klare Grenzen für seine Arbeit. Bevor die Ermittlungen an Fahrt gewinnen, sollten Sie Folgendes festhalten:

Letzteres verhindert, dass man vom Thema abschweift. Bei einer Untersuchung im Bereich der Zahlungen könnten beispielsweise Probleme bei der Preisgestaltung, dem Konto-Setup oder der Kundenanmeldung zutage treten. Einige davon lassen sich vielleicht später beheben, aber wenn man sie alle in den aktuellen Auftrag einbezieht, wird aus einem zweiwöchigen Aufwand schnell ein zweimonatiger.

Auch die Kapazitäten erfordern die gleiche Aufmerksamkeit. Verteilen Sie dringende Aufgaben neu, verschieben Sie Fristen, wo es möglich ist, und informieren Sie die betroffenen Eigentümer über die Änderungen. Andernfalls müssen die Mitglieder des Teams das Tiger-Team zusätzlich zu all ihren bisherigen Aufgaben leiten.

3. Trennen Sie Beweise von Theorien und entscheiden Sie dann, was zu überprüfen ist

Wenn ein „Tiger-Team“ gebildet wird, haben möglicherweise bereits mehrere Personen eine Erklärung dafür, was schiefgelaufen ist. Beginnen Sie damit, das, was das Team weiß, von dem zu trennen, was es vermutet.

Überprüfen Sie im Rahmen dieser Übung frühere Korrekturen, Experimente, Notizen zu Incidents und Entscheidungen. Ein Ansatz, der heute vielversprechend erscheint, wurde möglicherweise bereits vor sechs Monaten getestet. Erstellen Sie daraus eine kurze Liste mit den plausibelsten Erklärungen. Halten Sie für jede davon fest, was Ihrer Meinung nach vor sich geht, welche Beweise dies unterstützen, wie Sie dies überprüfen werden und welches Ergebnis sich daraus ergibt.

Reihenfolge der Aufgabenliste: Was Sie dabei lernen können. Eine Theorie, die den Großteil des Problems erklären könnte und deren Überprüfung eine Stunde dauert, verdient mehr Aufmerksamkeit als eine, deren Überprüfung eine Woche Entwicklungsarbeit erfordert.

4. Führen Sie ein Protokoll über Entscheidungen, die den Ermittlungsverlauf beeinflussen könnten

Speichern Sie die Gespräche, die Einfluss auf die nächsten Schritte des Teams haben könnten oder die jemand später möglicherweise verstehen muss. Dazu können ein akzeptiertes Risiko, ein verworfener technischer Ansatz, eine Änderung des Projektumfangs oder die Entscheidung gehören, eine Hypothese nicht weiter zu verfolgen.

Überprüfen Sie das Protokoll immer dann, wenn neue Beweise eine frühere Annahme in Frage stellen, und halten Sie die aktuelle Entscheidung zusammen mit den zugrunde liegenden Beweisen mit hoher Sichtbarkeit sichtbar.

5. Lassen Sie das Problem die Einstellung des Arbeitsrhythmus bestimmen

Wie oft ein Tiger-Team ein Meeting abhält, hängt davon ab, wie schnell sich das Problem verändert. Während eines laufenden Ausfalls kann sich das Team alle paar Stunden neu zusammenfinden. Eine zweiwöchige Untersuchung eines sich langsam entwickelnden Datenproblems lässt sich in der Regel mit ein paar Besprechungen pro Woche bewältigen.

Unabhängig vom Tempo sollte jedes Meeting einen klaren Zweck haben. Neue Erkenntnisse, die das Gesamtbild verändern, ein Hindernis, das nur der Sponsor beseitigen kann, oder eine Entscheidung, die das Team gemeinsam treffen muss – all das sind geeignete Gründe. Der tägliche Fortschritt lässt sich besser in schriftlichen Protokollen festhalten, die die Beteiligten jederzeit einsehen können, wenn sie einen freien Moment haben.

Wenn sich die Arbeit über mehr als ein paar Wochen hinzieht, planen Sie eine Zwischenbesprechung ein. Das gibt dem Team die Möglichkeit, Abstand von den täglichen Ermittlungen zu gewinnen und sich zu fragen:

Ehrliche Antworten in dieser Phase können verhindern, dass das Team die zweite Hälfte seiner Arbeit mit dem falschen Problem verbringt.

Die Beteiligten müssen in der Regel nicht direkt am Prozess beteiligt sein. Eine kurze schriftliche Notiz alle paar Tage, in der zusammengefasst wird, was das Team erfahren hat, welche Entscheidungen getroffen wurden und wo es noch Schwierigkeiten gibt, hält sie ausreichend auf dem Laufenden, um bei Bedarf eingreifen zu können.

6. Geben Sie der Korrekturmaßnahme Zeit, sich zu bewähren

Eine Korrektur kann am Tag ihrer Veröffentlichung überzeugend wirken und dennoch versagen, sobald wieder normaler Datenverkehr, normales Volumen oder Randfälle auftreten. Deshalb sollte das Team das Problem nicht als gelöst erklären, sobald sich die Zahlen verbessern.

Wie lange die Korrektur überwacht werden muss, hängt davon ab, wie oft das Problem erneut auftreten könnte. Bei einem Dienst mit hohem Datenaufkommen erhalten Sie beispielsweise möglicherweise bereits innerhalb weniger Stunden ein verlässliches Signal. Bei einem monatlichen Finanzabschluss ist möglicherweise ein weiterer vollständiger Zyklus erforderlich, bevor man sagen kann, dass die Korrektur Bestand hat.

Behalten Sie in der Zwischenzeit zwei Nummern in der Ansicht:

Wenn sich die Zahlen wieder verschlechtern, betrachten Sie dies als neuen Hinweis. Beziehen Sie ihn in die Untersuchung ein und prüfen Sie, was sich dadurch ändert. Möglicherweise rückt dadurch eine andere Hypothese in den Vordergrund oder es zeigt sich, dass die ursprüngliche Diagnose nur einen Teil der Probleme erklärte.

7. Geben Sie die Arbeit sauber zurück

Zu diesem Zeitpunkt hat das Team bereits den Großteil dessen erstellt, was für eine Übergabe erforderlich ist. Der Arbeitsbericht, die Beweismittel, die Tests, das Entscheidungsprotokoll und die Validierungsdaten sind bereits in der Akte enthalten. Sie in einen ausgefeilten Abschlussbericht umzuschreiben, bedeutet nur zusätzliche Arbeit und wenig mehr.

Stellen Sie stattdessen diese Unterlagen zusammen und sorgen Sie dafür, dass die verbleibende Eigentümerschaft unübersehbar ist. Der endgültige Eigentümer sollte am Ende wissen:

Bevor jemand einen Schritt zurückgeht, beantworten Sie folgende Frage: Wer wird benachrichtigt, wenn das Problem erneut auftritt?

Sobald das Ergebnis vorliegt und die Frage geklärt ist, kann sich das „Tiger-Team“ auflösen. Die Mitglieder kehren zu ihrer regulären Arbeit zurück, die laufenden Aufgaben werden wieder in die normale Struktur überführt, und die Untersuchung bleibt für denjenigen dokumentiert, der sie als Nächstes benötigt.

Reaktive vs. präventive Tiger-Teams

Tiger-Teams werden in der Regel an einem von zwei Zeitpunkten eingesetzt. Manche werden erst dann zusammengestellt, wenn ein Problem bereits Auswirkungen auf das Geschäft hat. Andere werden früher hinzugezogen, solange noch Zeit bleibt, Schwachstellen aufzudecken und den Plan anzupassen.

Der Unterschied hängt davon ab, was das Team herausfinden möchte.

Reaktive Tiger-Teams setzen erst dann ein, wenn ein Problem bereits im Gange ist

Dies ist die Version, die die meisten Menschen mit Tiger-Teams in Verbindung bringen. Dabei kann es sich um eine verzögerte Markteinführung, einen wiederkehrenden Ausfall, den Zusammenbruch eines kritischen Prozesses oder um mehrere Teams handeln, die versuchen, das Problem zu beheben, ohne die Ursache zu finden.

Zu diesem Zeitpunkt verfügt das „Tiger-Team“ bereits über Anhaltspunkte, auf denen es aufbauen kann. Die Aufgabe besteht darin, diese Hinweise miteinander in Verbindung zu bringen, die Ursache einzugrenzen, die plausibelsten Erklärungen zu überprüfen und das System wieder in einen stabilen Zustand zu versetzen.

Das Erreichen dieser Phase kann kostspielig sein. In der „Global Data Center Survey 2025“ des Uptime Institute gaben 87 % der Befragten, die in den letzten drei Jahren einen schwerwiegenden Ausfall erlebt hatten, an, dass dieser durch besseres Management, bessere Prozesse oder eine bessere Konfiguration hätte vermieden werden können.

Ihre jährliche Ausfallanalyse 2026 ergab außerdem, dass 57 % der Befragten angaben, ihr jüngster größerer Ausfall habe mehr als 100.000 US-Dollar gekostet, während jeder Fünfte die Kosten auf über 1 Million US-Dollar schätzte. Diese Zahlen beziehen sich speziell auf Rechenzentren und sollten daher nicht als allgemeiner Maßstab für jedes „Tiger-Team“ herangezogen werden.

Sie zeigen jedoch, warum die Arbeit nach einer reaktiven Maßnahme nicht mit der sofortigen Behebung des Problems enden sollte. Sobald sich die Lage stabilisiert hat, sollten Sie die Bedingungen untersuchen, die dazu geführt haben, dass das Problem so weit eskalieren konnte.

Präventive „Tiger-Teams“ erkennen Probleme frühzeitig

Ein präventives „Tiger-Team“ wird eingesetzt, solange noch Spielraum für Planänderungen besteht.

Die NASA hat diesen Ansatz direkt angewendet. Als ihr Engineering and Safety Center ein Bewertungsteam zusammenstellte, um den Antriebsbus des CALIPSO-Raumfahrzeugs zu überprüfen, erstellte die Gruppe einen Fehlerbaum, um mögliche Ausfallpfade vor dem Start zu untersuchen. In der Rückschau der NASA auf 15 Jahre Engineering and Safety Center beschrieb NESC-Direktor Tim Wilson den Ansatz wie folgt:

Unser Ansatz bestand darin, einen Fehlerbaum zu erstellen, der Alles aufzeigte, was möglich ist, um einen Fehler zu verursachen, und zu prüfen, ob während des Fertigungsprozesses geeignete Kontrollmaßnahmen vorhanden waren, um sicherzustellen, dass diese Verbindungsstücke nicht undicht werden.

Das entspricht in etwa dem Geist des frühen „Tiger-Teams“ aus der Luft- und Raumfahrt. Dem Team wird eine folgenschwere Aufgabe übertragen, und es wird aufgefordert, diese zu hinterfragen, bevor die Konsequenzen eintreten.

Das Ergebnis sollte dem Gesamtprojekt konkrete Handlungsansätze liefern, wie zum Beispiel:

Beispiele für Tiger-Teams aus der Praxis

Tiger-Teams kommen im Bauwesen, in der Softwareentwicklung und im öffentlichen Sektor zum Einsatz. Graham, Grafana Labs und die britische Behörde zur Betrugsbekämpfung im öffentlichen Sektor (Public Sector Fraud Authority) haben jeweils ein solches Team gebildet, um ein klar abgegrenztes Problem mit einem eindeutigen Ziel zu lösen. Die Fachkompetenzen variierten von Fall zu Fall, während die Struktur gleich blieb.

Graham verkürzte die Einbauzeit für Spurstangen um 51 %

Das Tiefbauunternehmen Graham bildete ein „Tiger-Team“ für einen sich wiederholenden, aber kostspieligen Teil seines South-Bank-Quay-Projekts. Die Teams mussten 166 Zugstangen verlegen, die jeweils mehr als 38 Meter lang waren und die Kaimauer an einer Ankerwand verankerten.

Das Team brachte Grahams Projektmitarbeiter, den Subunternehmer für die Montage, den Hersteller der Zugstangen und weitere Partner aus der Lieferkette zusammen. Zunächst erstellten sie einen Ablaufplan für den Montageprozess, dann erfassten sie die Arbeitsabläufe vor Ort mithilfe von Zeitrafferaufnahmen und einer Zeit- und Bewegungsstudie. Sobald sie eine Ausgangsbasis hatten, passten sie den Prozess an und maßen ihn erneut.

Laut der Fallstudie der „Get It Right“-Initiative sank die Montagezeit pro Spurstange von 185 Minuten auf 91 Minuten – eine Reduzierung um etwa 51 % –, während die Anzahl der Aufgaben um 37 % zurückging. Graham berichtete zudem von einer Zeitersparnis von 14 Tagen im Rahmen des Programms und geschätzten Einsparungen in Höhe von 230.000 £.

Das Team identifizierte kleinere Änderungen im gesamten Prozess, testete diese anhand derselben Arbeit und konnte genau aufzeigen, was sich verbessert hatte.

Grafana Labs hat ein Release-Problem in eine dauerhafte Eigentümerschaft umgewandelt

Die Open-Source-Veröffentlichungen von Grafana Labs wurden zunehmend manuell durchgeführt, während die Verantwortung für deren Verbesserung auf mehrere Entwicklerteams verteilt war. Drei leitende Entwickler, die bereits an Teilen des Problems gearbeitet hatten, wurden für ein Quartal zusammengebracht, um den Workflow zu vereinfachen, Builds zu automatisieren und direkte Patches für Grafana-Cloud-Kanäle zu unterstützen.

Das Release-Tiger-Team reduzierte manuelle Schritte drastisch und vereinfachte die Abwicklung von Sicherheits-Releases. Bis zum Ende des Quartals hatte die Arbeit zudem eine längerfristige Lücke so deutlich gemacht, dass Grafana eine eigene Release-Gruppe ins Leben rufen konnte.

Dieser Ablauf hilft dabei, wiederkehrende Probleme im Software-Release-Management anzugehen. Eine kurze Intervention kann die unmittelbaren Reibungspunkte beseitigen und gleichzeitig aufzeigen, wo die fortlaufende Verantwortung liegt. Grafana hat dasselbe Modell auch in anderen Bereichen angewendet, unter anderem mit einem „Tiger-Team“, das dazu beigetragen hat, einen wichtigen Partner zu gewinnen.

Die britische Regierung setzte ein „Tiger-Team“ ein, bevor aus Betrugsrisiken tatsächliche Verluste wurden.

Im Jahr 2022 nutzte die britische Behörde zur Bekämpfung von Betrug im öffentlichen Sektor (Public Sector Fraud Authority) das „Tiger-Team“-Modell, während neue Förderprogramme für den Energiesektor noch in der Planungsphase waren.

Das Team brachte Betrugsspezialisten aus Regierungsbehörden, der Ofgem, Energieabrechnungsstellen sowie externe Experten aus dem Energiesektor zusammen. Laut dem Jahresbericht 2022–23 der Public Sector Fraud Authority hat es Betrugsfolgen- und Risikobewertungen für sechs neue Energieprogramme im Ministerium für Wirtschaft, Energie und Industriestrategie sowie für ein Programm im britischen Finanzministerium fertiggestellt.

Die Arbeit begann früh genug, damit die Teams auf die Erkenntnisse der Spezialisten reagieren konnten. Laut BEIS trug der breite Bereich an Fachwissen dazu bei, Betrugsaspekte in die Programme einzubeziehen, und verschaffte den Ministern bereits in der Formungsphase der Programme Sichtbarkeit über die wichtigsten Risiken.

Fünf Fehler, die ein Tiger-Team zum Scheitern bringen können

Diese fünf Fehler können ein Tiger-Team untergraben, selbst wenn das Problem und die Teamstruktur klar sind.

1. Mehrere Dinge gleichzeitig ändern

Wenn der Druck hoch ist, ist es verlockend, drei oder vier vielversprechende Lösungen gleichzeitig umzusetzen und zu schauen, ob das Problem dadurch verschwindet.

Das kann Ihnen zwar schnell zu einem besseren Ergebnis verhelfen, wirft aber eine heikle Frage auf: Welche Maßnahme hat geholfen? Wenn ein technisches Tiger-Team in ein und demselben Release eine Abhängigkeit aktualisiert, ein Timeout ändert und die Kapazität erhöht, sagt ein Rückgang der Fehler kaum etwas über die Ursache aus. Außerdem erschwert es das Zurücksetzen, falls später ein anderes Problem auftritt.

2. Das Team ausschließlich aus externen Mitarbeitern zusammenstellen

Eine neue Perspektive kann hilfreich sein, aber die Mitarbeiter, die täglich mit dem betroffenen System arbeiten, kennen oft Ausnahmen, Workarounds und Abhängigkeiten, die es nie in die Dokumentation geschafft haben. Werden diese außer Acht gelassen, kann dies zu Lösungen führen, die von außen betrachtet sauber aussehen, aber versagen, sobald sie auf den tatsächlichen Workflow treffen.

Dies gilt nicht nur für den technischen Bereich. Ein Tiger-Team, das beispielsweise einen Genehmigungsprozess neu gestaltet, sollte die Meinungen derjenigen einholen, die diese Genehmigungen täglich bearbeiten, und nicht nur die der Führungskräfte, die sie beaufsichtigen.

3. Das „Tiger-Team“ als Mittel zur Schuldzuweisung

Sobald die Beteiligten den Eindruck gewinnen, dass das Tiger-Team versucht, den Verursacher des Problems zu identifizieren, werden sie möglicherweise zurückhaltender beim Freigeben von Informationen. Jemand könnte eine frühere Fehlentscheidung verschweigen, eine gescheiterte Notlösung nicht erwähnen oder eine alte Entscheidung verteidigen, weil er sich persönlich dafür verantwortlich fühlt. Dadurch stehen dem Team weniger Beweise zur Verfügung, und die Ermittlung der tatsächlichen Ursache wird erschwert.

4. Eine riskante Änderung vornehmen, ohne einen Plan zu haben, wie man sie rückgängig machen kann

Eine vielversprechende Lösung kann selbst einen neuen Fehler verursachen. Teams geraten in Schwierigkeiten, wenn sie zwar einen Plan haben, wie eine Änderung eingeführt werden soll, aber nicht, wie sie rückgängig gemacht werden kann. Ein Rollback wird zudem schwieriger, sobald Kunden, Daten oder nachgelagerte Systeme bereits mit der Änderung interagieren.

5. Schaffung einer zweiten Informationsquelle für das Tiger-Team

Dringende Arbeiten beginnen oft dort, wo man am schnellsten vorankommt: in einem privaten Chat, einer Ad-hoc-Tabelle, einem temporären Dokument oder einem separaten Projekt-Board. Probleme entstehen, wenn Entscheidungen, Belege und Aufgaben über all diese Kanäle verstreut sind.

Der eine sieht die aktuellste Entscheidung im Chat, während der andere in einer Tabelle noch nach der alten Entscheidung handelt. Nach Schließung des Teams wird es noch schwieriger, den Ablauf der Ereignisse nachzuvollziehen.

So leiten Sie ein Tiger-Team in ClickUp

Ein Tiger-Team kann zwar über die richtigen Mitarbeiter und einen präzisen Auftrag verfügen, aber dennoch Zeit verlieren, weil die Beweise in einem Tool gespeichert sind, Entscheidungen in einem anderen getroffen werden und die Folgearbeiten wieder an einem anderen Ort stattfinden. Hier sehen Sie, wie ein Team den gesamten Aufwand in ClickUp abwickeln könnte, am Beispiel des zuvor genannten Fehlers beim Bezahlvorgang.

Vorbereitung am ersten Tag

Angenommen, die Checkout-Fehler sind nach einem kürzlich erfolgten Release auf 4 % gestiegen, und der Sponsor hat ein Tiger-Team beauftragt, sie wieder unter 1 % zu senken. Der Leiter erstellt zunächst einen Ordner mit dem Namen „Checkout-Fehler Tiger-Team“ im Engineering-Space. Die Arbeit bleibt in der Nähe des Teams, das sie übernehmen wird, sobald sich das Tiger-Team auflöst.

Innerhalb des Ordners erstellt der Projektleiter ein ClickUp-Dokument für das Arbeitsbriefing. Es enthält die Abschlussbedingung (Fehlerquote unter 1 % über zwei volle Wochen), die Baseline, die Metriken für Erfolg und Sicherheit, den Umfang des Projekts, wer welche Entscheidungen treffen darf sowie eine Tabelle für das Entscheidungsprotokoll. Während der ersten Sitzung des Teams einigt sich das Team darauf, zunächst die neue Abhängigkeit zur Zahlungs-API zu testen. Der Projektleiter markiert diese Zeile im Dokument und wandelt sie in eine Aufgabe um, ohne das Briefing zu verlassen.

Aufbau der Hypothesenliste

Diese erste Aufgabe wird zusammen mit allen anderen Theorien, die das Team überprüfen möchte, in eine Liste namens „Hypothesenwarteschlange“ aufgenommen. Die Status der Liste orientieren sich an den Beweisgruppen aus Schritt 3, wobei ein weiterer Status für laufende Arbeiten hinzugefügt wird: „Verdacht“, „In Prüfung“, „Bestätigt“ und „Ausgeschlossen“. Unbekannte Faktoren können als offene Fragen im Auftrag festgehalten werden.

Sobald Tests abgeschlossen sind, werden die Aufgaben weitergeleitet, und das gesamte Team kann sehen, was bereits bekannt ist und was noch eine Vermutung ist. Der Teamleiter fügt jeder Hypothese drei Benutzerdefinierte Felder hinzu: Auswirkung, Testkosten und Ergebnis. Durch Sortieren nach „Auswirkung“ und anschließend nach „Testkosten“ werden die Theorien, die am meisten erklären könnten und deren Überprüfung am wenigsten Zeit in Anspruch nimmt, ganz oben angezeigt.

Prüfen, was bereits versucht wurde

Bevor die Entwickler den API-Test durchführen, fragt einer von ihnen Brain²: „Haben wir die Timeouts der Anbieter für Zahlungen schon einmal getestet?“

Brain² durchsucht über die Enterprise Search Aufgaben, Dokumente, den Chat und verbundene Apps und findet eine ähnliche Untersuchung von vor sechs Monaten mit verknüpften Quellen. Das Team liest nach, was beim letzten Mal ausgeschlossen wurde, passt den Test an und fügt die Links in die Hypothesen-Aufgabe ein, damit der Verlauf damit verknüpft bleibt.

Neue Anfragen aus der Untersuchung heraushalten

Am Ende von Woche 1 haben Personen außerhalb des Teams begonnen, entsprechende Probleme anzusprechen: einen Fehler bei der Preisanzeige, einen langsamen Flow beim Konto-Setup. Jedes dieser Probleme könnte leicht zu neuer Arbeit führen.

Der Projektleiter richtet ein ClickUp-Formular ein, das die Übermittlungen an eine separate Liste namens „Parking Lot“ weiterleitet. Jede Übermittlung wird dort zu einer eigenen Aufgabe, und der Sponsor überprüft die Liste bei jedem Check-in, um zu entscheiden, ob etwas in den Projektumfang gehört.

Dem Sponsor eine zentrale Anlaufstelle bieten

Der Sponsor muss eingreifen, wenn eine Entscheidung von ihm abhängt, muss aber den weiteren Verlauf der Untersuchung nicht täglich verfolgen.

Der Projektleiter fügt ein Kontrollkästchen mit der Bezeichnung „Entscheidung des Sponsors erforderlich“ hinzu und erstellt ein Dashboard mit drei Karten: eine für Aufgaben, die auf den Sponsor warten, eine für blockierte oder überfällige Arbeiten und eine für die Nachverfolgung der Ausfallrate als Feld. Der Sponsor öffnet diese Seite vor jedem Check-in.

Erinnerungen und Aktualisierungen automatisch ausführen lassen

In Woche 2 deaktiviert das Team als vorübergehende Abhilfe ein Feature für betroffene Konten, und diese Entscheidung muss in 7 Tagen erneut überprüft werden. Der Teamleiter legt das Fälligkeitsdatum der Aufgabe auf diesen Tag fest und fügt eine Automatisierung hinzu, die den Eigentümer benachrichtigt, sobald das Datum erreicht ist.

Auch die Information der Stakeholder nimmt zunehmend Zeit des Projektleiters in Anspruch. Ein „Super Agent“ veröffentlicht nun jeden Monday und Donnerstag eine kurze Zusammenfassung, in der neue Entscheidungen, Hindernisse und alles, was auf den Sponsor wartet, behandelt werden.

Rückgabe der Arbeit

Die Fehlerquote liegt zwei volle Wochen lang unter 1 %, sodass das Team seine Ausstiegsbedingung erfüllt hat. Der Teamleiter verschiebt die verbleibenden offenen Aufgaben in die Liste des Teams für Zahlungen und weist sie neu zu. Der letzte Eintrag im Entscheidungsprotokoll nennt den neuen Eigentümer und die Bedingungen, unter denen eine neue Untersuchung eingeleitet werden sollte. Anschließend archiviert der Teamleiter den Ordner.

Preise für ClickUp

Das beste „Tiger-Team“ weiß, wann es sich zurückziehen muss

Ein „Tiger-Team“ ist eine kontrollierte Ausnahme. Man bündelt vorübergehend Fachwissen, Entscheidungsbefugnisse und Aufmerksamkeit auf ein Problem, das die übliche Struktur im normalen Tempo nicht bewältigen kann.

Das macht den Abschluss genauso wichtig wie die Intervention selbst. Sobald das Problem unter Kontrolle ist, sollte das Team in der Lage sein, sich zurückzuziehen, ohne seine Entscheidungen, Beweise oder unvollendete Arbeit mitzunehmen. Wenn die Organisation weiterhin von derselben temporären Gruppe abhängig ist, um den Betrieb aufrechtzuerhalten, hat sich das Problem verändert.

Was nach der Übergabe übrig bleibt, ist die Dokumentation darüber, wie das Problem verstanden und gelöst wurde. In ClickUp bleibt diese Dokumentation auch nach der Archivierung des Ordners des „Tiger-Teams“ durchsuchbar, sodass der nächste Eigentümer die Aufgabenstellung, die Hypothesen und das Entscheidungsprotokoll finden kann, ohne sie neu erstellen zu müssen.

Häufig gestellte Fragen zu Tiger-Teams

Wie groß sollte ein „Tiger-Team“ sein?

Es gibt keine allgemeingültige Personalstärke. Halten Sie die Kerngruppe so klein, wie es das Problem zulässt, und ziehen Sie dann andere Spezialisten hinzu, wenn Sie deren Fachwissen benötigen. Ein größerer Personalbestand bedeutet mehr Aufwand für Kommunikation und Terminplanung. Wenn jemand lediglich Beweismittel vorlegen oder eine bestimmte Frage beantworten muss, muss er nicht unbedingt festes Mitglied des Tiger-Teams werden.

Kann ein „Tiger-Team“ aus der Ferne arbeiten?

Ja. Ein „Tiger-Team“ muss sich nicht in einem gemeinsamen Raum befinden. Was es jedoch benötigt, ist schneller Zugriff auf dieselben Beweismittel, klare Eigentümerschaften und einen verlässlichen Ort für Entscheidungen. Bei einem verteilten Team sollten Sie die Arbeitsprotokolle stets auf dem neuesten Stand halten und synchrone Telefonkonferenzen nur für Entscheidungen, Hindernisse oder Beweismittel reservieren, die den Ermittlungsverlauf verändern. So verhindern Sie, dass Zeitzonen dazu führen, dass aus jeder Aktualisierung ein weiteres Meeting wird.

Ist ein „Tiger-Team“ Teil von Agile oder Scrum?

Nein. Ein „Tiger-Team“ ist keine formelle Scrum-Rolle, kein Scrum-Ereignis und keine formelle Verantwortlichkeit. Der offizielle Scrum Guide definiert ein Scrum-Team als eine Gruppe, die sich um den Product Owner, den Scrum Master und die Entwickler zusammensetzt. Ein Unternehmen, das Scrum einsetzt, kann dennoch ein „Tiger-Team“ bilden, um ein Problem anzugehen, das über die Grenzen bestehender Teams hinausgeht. Sie müssen lediglich entscheiden, wie diese temporäre Arbeitsgruppe mit den aktuellen Sprint-Verpflichtungen und Produktzielen zusammenwirkt.

Muss ein „Tiger-Team“ technisch versiert sein?

Nein. Das Modell hat seinen Ursprung in der Luft- und Raumfahrt und ist nach wie vor in den Bereichen Ingenieurwesen und Sicherheit verbreitet, doch die Struktur kann überall dort zum Einsatz kommen, wo ein schwieriges Problem konzentriertes Fachwissen erfordert. Ein „Tiger-Team“ könnte Betrugsfälle untersuchen, einen betrieblichen Prozess neu gestalten, ein regulatorisches Problem lösen oder ein geschäftliches Problem bewältigen. Das erforderliche Fachwissen richtet sich nach der jeweiligen Problemstellung.

Können auch Personen von außerhalb des Unternehmens einem „Tiger-Team“ beitreten?

Ja. Externe Spezialisten, Anbieter, Berater oder Lieferkettenpartner können einbezogen werden, wenn sie über Kenntnisse verfügen, die dem internen Team fehlen. Geben Sie ihnen dieselben klaren Vorgaben hinsichtlich Umfang, Zugriffsrechten, Vertraulichkeit und Entscheidungsbefugnissen wie den internen Mitgliedern. Sie sollten dabei sein, weil die Untersuchung ihr Fachwissen benötigt, und nicht einfach, weil ihre Organisation vom Ergebnis betroffen ist.

Was passiert, wenn das „Tiger-Team“ das Problem nicht lösen kann?

Das Team sollte die Organisation dennoch mit einem enger gefassten Problem verlassen, als es zu Beginn hatte. Das kann bedeuten, festzustellen, was bereits ausgeschlossen wurde, die verbleibenden Unbekannten zu isolieren, zu dokumentieren, welche Maßnahmen fehlgeschlagen sind, und aufzuzeigen, wo das derzeitige Team an die Grenzen seines Fachwissens oder seiner Befugnisse gestoßen ist. Auf dieser Grundlage kann die Führungsebene entscheiden, ob die Arbeit einen anderen Spezialisten, mehr Zeit, einen festen Eigentümer oder eine umfassendere strukturelle Veränderung erfordert. Das Nichterreichen der ursprünglichen Bedingung macht die Erkenntnisse aus der Untersuchung nicht zunichte.

Was ist der Unterschied zwischen einem „Tiger-Team“ und einem funktionsübergreifenden Team?

„Funktionsübergreifend“ beschreibt, wer zum Team gehört. „Tiger-Team“ beschreibt, warum die Gruppe zusammengestellt wurde und wie lange sie voraussichtlich bestehen bleibt. Ein funktionsübergreifendes Team kann dauerhaft bestehen und für ein laufendes Produkt, einen Prozess oder einen Geschäftsbereich zuständig sein. Ein Tiger-Team wird zur Lösung eines bestimmten Problems gebildet und löst sich auf, sobald diese Aufgabe erledigt ist. Ein Tiger-Team ist oft funktionsübergreifend, aber die beiden Begriffe sind nicht austauschbar.