Eine Task Force ist in bestimmten Situationen sinnvoll, um mit vereinten Kräften ein übergreifendes Problem oder einen Engpass zu lösen, sei es technischer oder wirtschaftlicher Natur. Wird aber eine Task Force zu einer Dauereinrichtung, ist das häufig ein Zeichen, dass sich das Unternehmen nicht die Mühe macht, über die Ursache des Problems nachzudenken.

Die Task Force – Um was geht’s denn?

„Wann kommt endlich meine Anforderung?“ (Stakeholder allgemein) – „Früher wurden solche Kleinigkeiten einfach nebenbei umgesetzt“ (Vertrieb) – „Die Plattform-Teams sollen sich ausschließlich auf ihre Projekte konzentrieren“ (IT-Leitung, Produktmanagement) – „Das ist doch schnell gemacht!“ (spätestens ab erster Führungsebene) – „Wir haben zu der Anforderung eh‘ ein Projekt demnächst, da packen wir’s dann rein“ (Produktmanagement) – „Die Live-Bugs fixen wir später, wir müssen mit dem Projekt fertig werden“ (Produktmanagement).

Kommt Euch bekannt vor? Auch die Lösung dafür im eigenen Unternehmen? Aber erst mal einen Schritt zurück. Um was geht es? Die Produktentwicklung und das Produktmanagement müssen permanent Anforderungen unterschiedlichster Art gegeneinander abwägen:

• Nach Nutzertyp: Externe Nutzer vs. interne Nutzer (Content Management- Buchhaltungs-Systeme etc.)
• Nach Größe: Projekte vs. kleinere Features
• Nach Art des Wertes: Wertschöpfung (Umsatz, PR, Kosteneinsparung etc.) vs. Risikovermeidung (i.d.R. durch Bugs und drohende Plattformausfälle)
• Nach Grad der Funktionalität: funktionale vs. nichtfunktionale Anforderungen

Task Force – Die Lösung ist schnell gefunden

Die natürliche Gewichtung in Unternehmen liegt bei Projekten für externe Nutzer, die einen hohen Wert und eine hohe Sichtbarkeit versprechen. Dem gegenüber stehen kleinere Anforderungen und Fehler auf der Produktiv-Plattform (a.k.a. Live Bugs). Letztere Gruppe von Anforderungen lassen sich im Tagesgeschäft nur schwer mit Projekten vereinbaren. Selbst Organisationen, die nicht mehr primär in Projekten sondern in Produkten mit festen Teams denken, können diesen Konflikt nicht vermeiden. Schauen wir uns die typischen Ursachen an:

• Anfänglich kleine Features können schnell metamorphosieren und zu ausgewachsenen Projekten werden.
• Die ständigen thematischen Kontextwechsel lassen dem Team kaum Raum für konzeptionelle Überlegungen.
• Für ein Team ist eine größere Änderung bzw. ein größeres Projekt attraktiver. Das hängt mit der höheren Aufmerksamkeit im Unternehmen und mit der höheren Wahrscheinlichkeit, neue Technologien und Ansätze auszuprobieren, zusammen.
• Gleiches gilt für Bugs, die aus vergangenen Projekten resultieren. Wer möchte schon gerne am nächsten Tag nach der großen Party den eigenen Müll wegräumen?

Die Lösung? Die liegt doch auf der Hand. Wir gründen ein eigenes Team, das sich nur um diese kleinen Anforderungen kümmert. Das hört sich schlau an, oder? Geradezu eine Win-Win-Situation! Die Projekt-Teams konzentrieren sich auf die Big Points und die internen Stakeholder sind jetzt auch zufrieden. Wir nennen das Team ‚Taskforce‘ oder noch besser ‚Bypass Team‘. Alternativ: ‚Fast Lane Team‘ oder besonders charmant: ‚Doctors&Nurses‘.

Doch nur wieder Symptombekämpfung mit der Task Force?

Fällt Euch was auf? Die Bezeichnungen beschreiben allesamt die Bekämpfung von Symptomen: ‚Fast Lane‘: die Produktentwicklung ist zu langsam. ‚Bypass‘: der Hauptzufluss für Anforderungen ist dicht. ‚Taskforce‘: wir müssen eine Löschmannschaft zusammenstellen, um einen Brandherd zu bekämpfen usw. Taskforce beschreibt „…eine für eine begrenzte Zeit gebildete Arbeitsgruppe [mit umfassenden Entscheidungskompetenzen] zur Lösung komplexer Probleme.“ (Bibliographisches Institut GmbH).

In der Praxis ist diese Task Force aber kein temporäres, sondern ein permanentes Gebilde mit 2-3 oder mehr Entwicklern und gegebenenfalls einem dedizierten Feature Owner – ich spreche hier ganz bewusst von einem Feature Owner und nicht von einem Product Owner!

Zurück zur oben beschriebenen Win-Win-Situation. In der Praxis bemerken wir nach einer Weile, dass das Task Force Prinzip unvorhergesehene Nebenwirkungen hat:

• Es werden sich nur schwer Entwickler oder Produktmanager finden, die permanent Teil einer solchen Task Force sein möchten. Auch Rotationsmodelle können die Bereitschaft nur minimal erhöhen.
• Stakeholder nutzen diesen Kanal instinktiv als zweite Instanz, um ihre Ideen und Anforderungen um die Produktplanung herum umzusetzen.
• Die Abstimmungs- und Koordinationskosten mit anderen Teams steigen signifikant, da sich eine Task Force technisch und konzeptionell im hohen Wechsel zwischen unterschiedlichen Domains bewegt, die originär von anderen Teams bearbeitet werden.

Aus den oben genannten Punkten resultiert eine viel schwerwiegendere, weil langfristige und schleichende Nebenwirkung. Arbeiten unterschiedliche Akteure – die auch noch organisatorisch entkoppelt sind – an ein und derselben technischen Domäne, wirkt sich das unweigerlich auf die Code-Qualität aus.

Auch die Plattform leidet

Nachhaltige technische Qualität erreichen wir nur, wenn es klare Verantwortlichkeiten, und noch wichtiger, klare Vereinbarungen über die Qualitätsstandards in einer Komponente oder Domäne gibt. Hierzu zählen Vereinbarungen über permanente Refactoring-Maßnahmen beim Umsetzen von User Stories, Testabdeckung mit Unit- und Behavior-Tests, Coding Style als wichtiger Aspekt für Wartbarkeit und Verständlichkeit. Wollen wir das erreichen, steigt der Kommunikations- und Abstimmungsaufwand zwischen einer Task Force und den Domänen-Teams signifikant.

Bei einer 1:1 Konstellation kann dieser Aufwand noch überschaubar sein, spätestens aber bei einer 1:n Situation führt das zu einem nicht mehr vertretbaren Störfaktor auf beiden Seiten und konterkariert den eigentlichen Gedanken der raschen und unbürokratischen Umsetzung von kleinen Anforderungen. Die Qualität und Wartbarkeit des Codes droht immer mehr abzunehmen und trägt als einer von vielen anderen Faktoren dazu bei, dass immer mehr technische Schuld aufgenommen wird, die irgendwann nicht mehr bezahlbar ist. Die drohenden Konsequenzen, ein komplettes Neuschreiben der Plattform – ob iterativ oder am Stück – sind bekannt.

Häufig sehen wir einen Konflikt zwischen der mittel- und langfristigen Roadmap eines Teams und den kurzfristigen Verbesserungen.

Aber nicht nur die Ziele auf der technischen Seite können divergieren, sondern auch die Ziele auf wirtschaftlicher Seite. Häufig sehen wir einen Konflikt zwischen der mittel- und langfristigen Roadmap eines Teams und den kurzfristigen Verbesserungen und Korrekturen durch eine Task Force. Das sogenannte „Alignment“ (strategische Ausrichtung und Positionierung) wird damit unterwandert bzw. muss mit hohem Aufwand von Seiten der Produktmanager moderiert werden.

Die oben beschriebenen Effekte wie technische Schuld, Kommunikationsaufwände, unklares Alignment müssen als indirekte Kosten zu den direkten Kosten wie Gehälter hinzugezählt werden. Die Antwort auf die Frage, ob sich das dann noch rechnet, überlasse ich jedem selbst. In dieser Phase erleben wir häufig den nächsten Reflex von Führungskräften, nämlich die Schwächen des Systems durch mehr Prozesse zu beherrschen wie etwa zusätzliche Abstimmungsmeetings, Einsatz von Tools und noch ausgefeiltere Priorisierungsmechanismen.

Die Task Force – Alles für die Katz‘?

Also doch alles für die Katz’? Ja und nein. Eine Task Force steht wie viele andere organisatorische Artefakte für eine Bekämpfung von Symptomen. Vielmehr müssen wir den Raum schaffen, um das grundsätzliche Problem zu analysieren und herausfinden, was die Ursache für den Ruf nach einem zusätzlichen Anforderungskanal ist:

• Warum fragen Stakeholder nach Features, die aktuell nicht auf der Produkt-Roadmap der anderen Teams stehen? Fehlt hier das allgemeine Verständnis für die Ziele und für die Reihenfolge der sich daraus ableitenden Maßnahmen?
• Warum gibt es einen hohen Bedarf nach der Weiterentwicklung von internen Systemen (CMS, Reportingsystem etc.)? Liegt hier noch Potential brach? Und macht es Sinn, über ein kleines, spezialisiertes Team für einen dieser Bereiche nachzudenken?
• Falls nein, gibt es einen intelligenteren Weg, diese Anforderungen vorpriorisiert in die Planung der bestehenden Teams einzustreuen, ohne dass deren Ziele und Missionen gefährdet werden?
• Warum gibt es überhaupt einen gesonderten Backlog für Bugs, der zudem permanent wächst? Können wir nicht die Verantwortung für Fehler in die Teams zurückgeben und sogar noch einen Schritt weitergehen und eine Null-Fehler Regelung einführen, damit Bugs sofort nach Auftreten behoben werden und erst gar kein Backlog aufgebaut wird?

Eine Task Force ist in bestimmten Situationen sinnvoll, um mit vereinten Kräften ein übergreifendes Problem oder einen Engpass zu lösen, sei es technischer oder wirtschaftlicher Natur. Wird aber eine Task Force zu einer Dauereinrichtung, ist das häufig ein Zeichen, dass sich das Unternehmen nicht die Mühe macht, über die Ursache des Problems nachzudenken und sich scheut, Strukturen, Abläufe und Ziele permanent zu hinterfragen.

Bild: Task Force 141 – „Doom on you Mr. Tango!“ von KJ