Kann ein Team 150 Leute haben? FAST Agile sagt Ja

FAST Agile ist die interessanteste Organisationspraxis, die ich seit einiger Zeit kennengelernt habe. Heute teile ich mit, was FAST Agile ist, und untersuche, ob es sich lohnt, damit zu experimentieren. TL;DR? Ziemlich überzeugend, aber dennoch experimentell.

Was ist FAST Agile?

1. FAST Agile ist eine agile Softwarevariante. FAST konzentriert sich auf die Selbstorganisation innerhalb sehr großer Teams. Diese großen Teams werden Kollektive genannt. Dabei kann es sich um wenige bis hin zu 150 Personen handeln [1].

Zweimal pro Woche trifft sich das Kollektiv. Bei der Konferenz:

• Teammitglieder zeigen und erzählen, welche Fortschritte sie gemacht haben .
• Der Produktführer bekräftigt die Vision und gibt die Richtung vor . Sie geben Kontext zu den Top-Projekten. Sie führen neue Prioritäten ein, wenn die Arbeit abgeschlossen ist oder sich Prioritäten ändern. Und typischerweise zeigen sie die Prioritäten visuell an einer Wand oder einem virtuellen Äquivalent an.
• Die Mitglieder des Kollektivs organisieren sich selbst und bilden kleinere Teams, um die Arbeit mit der höchsten Priorität zu liefern.

Der interessanteste Teil von FAST Agile sind diese selbstorganisierenden Teams, also lassen Sie uns sie etwas detaillierter beschreiben.

Bei jedem Meeting melden sich Menschen freiwillig für die Leitung von Teams und für die Mitarbeit in diesen Teams. Wenn sich jemand freiwillig bereit erklärt, ein Team zu leiten, tritt er vor und sagt: „Ich werde an [einem der Top-Projekte] arbeiten.“ Die Leute schließen sich dann den gebildeten Teams an und arbeiten in diesem Bereich. Die Mindestteamgröße beträgt zwei Personen, daher müssen die Leute „mit den Füßen abstimmen“, um das Team zu bilden.

Die gebildeten Teams tun es nicht müssen sich an den Prioritäten orientieren, die das Produkt festgelegt hat. Beispielsweise kann sich ein Team um die Verbesserung der Bereitstellungspipeline oder die Verbesserung der Überwachung einiger instabiler Dienste kümmern.

Außerhalb der wöchentlichen Sitzungsstunden verbringen die Menschen die meiste Zeit in ihren selbstgewählten, selbstorganisierten Teams. Theoretisch könnte man zweimal pro Woche das Team wechseln. Aber in der Praxis finden die Leute am Ende heraus, mit wem sie gerne zusammenarbeiten, und Teams neigen dazu, sich nach dem ersten Monat oder so zu beruhigen .

Sie bleiben flexibel genug, dass Mitarbeiter sich ändern können, wenn sich die geschäftlichen Anforderungen ändern oder Menschen mit Fachwissen in verschiedenen Bereichen benötigt werden. Der Wechsel von Teams ist eine erwartete Änderung mit geringem Aufwand. Das bedeutet also, dass es während der Kollektivbesprechungen ein Muster gibt, bei dem die Leute ihre Teams neu bilden, die Zusammensetzung sich jedoch tendenziell nicht so stark ändert, wie Sie sich vorstellen können.

Es gibt viele weitere Details, wie z. B. den Umgang mit Fehlern und den Bereitschaftsdienst. Auf einige dieser Themen werde ich später noch eingehen. Der grundlegende Kern von FAST Agile sind jedoch diese selbstauswählenden Teams, die innerhalb eines größeren Kollektivs an Projekten arbeiten. Die Kollektivtreffen sind strukturiert und konzentrieren sich darauf, einen Kontext zu den Bedürfnissen des Unternehmens zu liefern und Fortschritte im Hinblick auf diese Prioritäten zu kommunizieren.

Zusammenfassung der Unterschiede

FAST unterscheidet sich stark von der Art und Weise, wie die meisten agilen Softwareunternehmen heute arbeiten. Hier sind die Unterschiede, wie ich sie sehe:

Wie Sie sehen, ist FAST ein ganz anderer Ansatz als der, den die meisten Unternehmen heute verfolgen.

Was sind also die Kompromisse?

Aus meiner Sicht sind dies die Kompromisse von FAST agile:

• FAST bietet möglicherweise eine bessere organisatorische Skalierbarkeit
• Mit FAST kann schrittweise experimentiert werden
• FAST sollte zu weniger Neuorganisationen führen
• FAST erleichtert die Reaktion auf sich ändernde Prioritäten
• SCHNELL könnte für die intrinsische Motivation und Bindung besser sein

Aber…

• Viele Umgebungen sind mit FAST nicht kompatibel
• Möglicherweise müssen Sie sich um die Selbstverwaltung kümmern
• FAST erfordert viel Arbeit
• Die FAST-Materialien sind voller Fachjargon

Wir werden diese nacheinander besprechen.

FAST bietet möglicherweise eine bessere organisatorische Skalierbarkeit

Wenn Sie Organisationen skalieren, tun Sie dies normalerweise, indem Sie sie „horizontal“ skalieren. Sie erweitern die Organisation Team für Team. Jedes dieser Teams besitzt einen Teil des Produkts, und Sie verfügen häufig über eine Plattformorganisation, die die Produktteams effektiver macht.

Die Komplexität der Organisation explodiert mit zunehmender Personenzahl. Wenn Sie zehn Leute im Ingenieurwesen haben, können alle miteinander kommunizieren. Hundert Leute im Ingenieurwesen können nicht alle miteinander reden. Und die Codebasis passt nicht in den Kopf eines Einzelnen. Sie unterteilen diese Komplexität also in Teams, und jedes Team hat einen Bereich, auf den es sich konzentrieren kann.

FAST ist interessant, weil es ein Versuch ist, Organisationen „vertikal“ zu skalieren. Anstatt mehr Teams hinzuzufügen, versucht FAST , größere Teams zu bilden, sogenannte Kollektive. Die Kollektive besitzen immer noch Code, die selbstorganisierten Teams innerhalb dieses Kollektivs jedoch nicht. Und Sie müssen die Kommunikation immer noch segmentieren. Aber die Teams sind dynamischer und entwickeln sich kontinuierlich weiter. Anstatt Teams durch Neuorganisationen umzugestalten, ist dies ein kontinuierlicher, erwarteter Teil Ihrer Arbeitsweise.

Teamgröße ist für viele Ingenieursleiter ein vertrautes Thema. Wie groß sollten Teams sein? Lassen Sie uns ein wenig in dieses Thema eintauchen, denn es hilft uns zu verstehen, wie FAST angeblich besser skaliert.

Wie groß sollten Teams sein?

Wenn Sie Zeit mit Leuten des VP of Engineering verbringen, kommt gelegentlich das Thema der Größe des Engineering-Teams zur Sprache. Sie hören Argumente für kleine Teams und Argumente für große Teams. Beide Seiten haben ihre Vorzüge.

Vorteile kleiner Teams

• Weniger Koordinations- und Kommunikationsaufwand innerhalb des Teams.
• Dadurch kann man sich schnell bewegen.
• Weniger Arbeitsströme, dadurch einfachere Konzentration und Erzielung von Ergebnissen.
• Einfacher zu verwalten.

Vorteile großer Teams

• Flachere Organisation. Ein Ingenieurunternehmen mit 150 Ingenieuren verfügt über drei bis vier Direktoren und zehnköpfige Teams. Es wird 6-8 Direktoren und 1-2 Vizepräsidenten mit fünfköpfigen Teams haben. Woher kommt die Verwirrung in einer Organisation? Wahrscheinlich die Führung, sodass große Teams Verwirrung reduzieren können.
• Mehr Belastbarkeit. Jemand kann Urlaub nehmen und das Team kann problemlos weitermachen.

Kleine Teams sind also innerhalb ihres Teams großartig, aber weniger ideal, weil es so viele von ihnen gibt, dass die organisatorische Komplexität zunimmt. Größere Teams eignen sich besser für die Gesamtkomplexität der Organisation, sind jedoch weniger ideal für die Leistung innerhalb jedes Teams.

Der Ansatz vieler Führungskräfte besteht darin, große Teams zu bilden, die sich auf weniger Arbeitsabläufe konzentrieren. Dies reduziert die interne Teamkomplexität und reduziert auch die organisatorische Komplexität.

Sie können FAST als einen Ansatz betrachten, der versucht, durch lächerlich große Teams eine noch größere organisatorische Einfachheit zu erreichen. Und es wurde versucht, auch die Vorteile kleiner, sich selbst zusammenstellender Teams zu nutzen.

Die Skalierung von Organisationen ist eine herausfordernde Aufgabe

Ein Großteil meiner Beratungstätigkeit besteht darin, Organisationen beim Umgang mit Größenordnungen zu helfen. Es gibt mehrere Phasen der Skalierungsherausforderungen, denen Unternehmen gegenüberstehen.

Die erste Barriere liegt typischerweise bei der 15-25-Ingenieur-Marke. Zu diesem Zeitpunkt ist Ihre Amöbe zu groß geworden und muss sich teilen. Sie sehen diese Art von Problemen:

• Kommunikationskanäle werden wirkungslos.
• Beim Engineering kommt es zu Liefer- und/oder Qualitätsproblemen.
• Manager oder Führungskräfte fühlen sich überfordert. Wenn man mehr Leute hinzufügt, wird es nicht besser, sondern schlimmer.

Und eine zweite Hürde liegt bei etwa sechzig Ingenieuren. An diesem Punkt werden Sie deutlich mehr Koordinationsprobleme bemerken:

• Teamübergreifende Projekte sind selten erfolgreich.
• Produktarbeit überfordert Plattformteams oder umgekehrt.
• Unfähigkeit, große Initiativen abzuschließen.

Ich habe immer wieder erlebt, wie brillante Menschen daran scheiterten, diese schrittweisen Veränderungen in der organisatorischen Komplexität zu bewältigen. Meine Vermutung ist, dass diese Schrittreihenfolge an Komplexität zunimmt, wenn man eine zusätzliche Verwaltungsebene hinzufügt.

Das Wachsen von Ingenieursorganisationen ist eine echte Fähigkeit. Es erfordert ein tiefes Verständnis dafür, wie Organisationen und Menschen funktionieren. Sie lernen Dinge wie:

• Koordinationsmodelle , um Gruppen von Menschen zur Zusammenarbeit zu bewegen.
• Stream-ausgerichtete Teams versus funktional gestaltete Teams.
• So führen Sie Reorganisationen durch, bei denen Sie Personen und Code verschieben, wenn sich die Geschäftsprioritäten ändern.
• So unterteilen Sie Produkte in technische Verantwortungsbereiche, die sich mit Produktinvestitionen überschneiden.
• Einrichten von Kommunikationskanälen rund um Teams.
• Einrichtung von Bereitschafts- und Zuverlässigkeitsprogrammen zur effektiven Unterstützung Ihres Produkts.
• Aufbau von Plattformorganisationen und Developer-Experience-Initiativen zur Bekämpfung der Komplexität.
• Usw.

Selbst wenn Sie über Mitarbeiter mit diesem Fachwissen verfügen, erfordert die Bewältigung der Skalierung einen hohen Aufwand seitens Ihres Managementteams. Wenn FAST also besser skalieren kann, können Sie das Potenzial Ihres Managementteams freisetzen, sich auf etwas anderes zu konzentrieren. Und da Ihre Schrittreihenfolgeänderungen so viel seltener auftreten, könnten Sie möglicherweise die Verwaltung Ihrer Organisation erheblich vereinfachen.

Ein Gedankenexperiment rund um FAST agile

Stellen Sie sich also vor, Sie könnten die Teamgröße skalieren. Was wäre, wenn Sie anstelle von Teams aus fünf oder zehn Personen effektive Teams aus zwanzig Personen hätten? Oder 60-köpfige Teams?

Auf den ersten Blick ist das ein lächerlicher Vorschlag. So große Teams sind nicht effektiv. Selbst zwölfköpfige Teams sind eine Herausforderung. Manchmal sehe ich die Lebensläufe von Leuten, denen zwanzig oder dreißig Leute Bericht erstattet haben. Meine erste Reaktion ist, dass ich denke, dass sie in einer schrecklichen Firma gearbeitet haben. So viele direkte Untergebene zu haben, ist ein „organisatorischer Geruch“.

Die zentrale Prämisse von FAST Agile besteht darin, dass Sie Ihre Teams horizontaler skalieren können, wenn Sie innerhalb dieses größeren Kollektivs Selbstorganisation und selbstauswählende Teams hinzufügen. Jedes Team (FAST nennt sie Kollektive) kann viel größer sein. Und dann werden die Teams, mit denen die Menschen täglich zusammenarbeiten, innerhalb dieser Kollektive selbst zusammengestellt.

Wenn die größeren Kollektive effektiv wären, würden sie die organisatorische Komplexität erheblich reduzieren. Bei einem typischen Software-Startup kann es Jahre dauern, bis eine Aufteilung in Verantwortungsbereiche erforderlich ist. Die Codebasis müsste nicht streng in Bereiche unterteilt werden, die jedem Team gehören. Dies würde erhebliche Managementzeit freisetzen, die Manager nutzen könnten, um sich auf das Produkt und die Teams zu konzentrieren.

Das ist also die zentrale Sache, die wir testen müssen: Bieten Selbstorganisation und Selbstorganisation eine Arbeitsweise, die genauso effektiv ist wie kleinere, konzipierte Teams?

Wenn dies der Fall ist, bietet es eine Möglichkeit zur Skalierung von Organisationen, die bei der Skalierung von Organisationen möglicherweise um eine Größenordnung besser ist. Warum so viel? Vergleichen wir eine Organisation, die mit Teams der Größe sechs Personen wächst, mit einer Organisation, die mit „Teams/Kollektiven“ der Größe sechzig Personen skaliert.

In diesem Argument sind viele Annahmen verankert, und vielleicht können Sie einige Löcher darin bohren. Aber selbst wenn Sie dies tun, ermöglicht FAST im Wesentlichen einer größeren Organisationseinheit, einen Bereich des Produkts und der Codebasis zu besitzen.

FAST ist neu, daher gibt es derzeit nicht viele Beweise dafür, ob FAST-Teams genauso effektiv arbeiten wie herkömmliche agile Teams. Aber ich vermute, dass die Antwort auf diese Frage ja lautet. Ich habe mehrere Gründe, das zu glauben. Zunächst einmal waren Jim Shores erste Erfahrungen damit recht positiv und er ist jemand, dem ich vertraue.

Ein zweiter Grund, warum ich bei FAST optimistisch bin, ist, dass ich einige Erfahrungen mit der Selbstorganisation großer Gruppen von Menschen gemacht habe. Und ich war überrascht, wie gut es funktionierte.

In kleinen Unternehmen gibt es natürlich viel Selbstorganisation. Aber wenn Unternehmen wachsen, standardisieren Sie Dinge und entfernen die Selbstorganisation, außer innerhalb von Teams. Eines der interessantesten Experimente, an denen ich teilgenommen habe, war jedoch eine groß angelegte Selbstorganisationsveranstaltung bei New Relic. Wir haben alle unsere Teams neu gestaltet und alle in fünfzig Softwareteams gebeten, auszuwählen, welchem Team sie beitreten möchten. Wir hatten Einschränkungen hinsichtlich der Fähigkeiten, die jedes Team benötigte, und hatten definiert, was jeder besitzen musste. Am Ende war es viel erfolgreicher, als alle erwartet hatten, sogar wir Organisatoren.

Auch wenn die Jury sich darüber nicht einig ist, bin ich der Vermutung, dass diese Praxis im richtigen Kontext viel Potenzial hat.

Mit FAST kann schrittweise experimentiert werden

Dies wird in den FAST-Materialien nicht erwähnt, aber eine Sache, die mir an FAST besonders interessant aufgefallen ist, ist, dass man schrittweise damit experimentieren kann.

Sie können FAST Agile versuchsweise in einem Team implementieren und dann einen Blob-Ansatz verwenden, bei dem Sie im Laufe der Zeit weitere Teams übernehmen. Wenn es gut läuft, schlucken Sie weiterhin weitere Teams. Wenn dies nicht der Fall ist, brechen Sie das Experiment ab.

FAST sollte zu weniger Neuorganisationen führen

Veränderungen passieren in Organisationen. Prioritäten verschieben sich, Leute gehen, Bereiche des Produkts erfahren unerwartetes Wachstum. Vorherige technische Entscheidungen belasten Sie und Sie müssen zusätzliche Arbeit leisten. Es ergeben sich neue Möglichkeiten, die Investitionen erfordern.

All diese Dinge haben Auswirkungen auf die Struktur Ihrer Organisation. Sie haben eine Reihe von Teams, von denen jedes seine eigenen Verantwortungsbereiche hat. Wenn diese Änderung eintritt, gestalten Sie Ihre Organisation im Laufe der Zeit um, um die bestmögliche Leistung zu erzielen. Diese Refactorings sind „Reorgs“ und können in wachsenden Organisationen häufig vorkommen!

Reorgs sollten mit FAST viel seltener auftreten. Die Reorganisationseinheit ist so groß, dass Sie sie nicht so oft durchführen müssen.

Ein möglicher Nachteil dabei ist, dass es keine Teams mit definierten Verantwortungsbereichen gibt. Es kann also zu einer Streuung der Verantwortung und einem schlecht gepflegten Code-Commons kommen. (Wir werden etwas später darüber sprechen)

FAST erleichtert die Reaktion auf sich ändernde Prioritäten

Wenn sich in konventionell strukturierten Teams die Prioritäten ändern, werden Teams gebildet, die die Arbeit erledigen. Wenn diese Teamstruktur die neuen Prioritäten nicht unterstützt, müssen Sie Ihre Organisation umgestalten.

Bei FAST erfolgen Prioritätsänderungen fließender und kontinuierlicher. Solange die Verantwortlichkeiten innerhalb des Kollektivs liegen, organisieren sich die Teams einfach um die Arbeit herum, und es ist wie ein ganz normaler Tag.

Durch die Struktur der kollektiven Besprechungen sind auch wechselnde Prioritäten weniger dramatisch. Sie haben im Wesentlichen zweimal pro Woche eine integrierte All-Hands-Funktion. Bei den Kollektivbesprechungen können Sie kontinuierlich den Kontext kommunizieren und Ihr Team über Ihre Kunden und Ihren Markt informieren. Dies sollte dazu beitragen, dass Ihr Team besser aufeinander abgestimmt ist.

Wenn ich diesen Ansatz mit etwas wie vierteljährlichen OKRs vergleiche, erscheint er flüssiger und als würde er die Menschen besser aufeinander abstimmen. Es erfordert eine engagierte Anstrengung des Produktleiters, kontinuierlich Kontext und Prioritäten auszutauschen. Aber einige der besten Teams, denen ich angehörte, hatten einen Produktleiter, der auf diese Weise handelte, also vermute ich, dass diese Zeit gut investiert ist.

SCHNELL könnte für die intrinsische Motivation und Bindung besser sein

Viele Teams haben das Gefühl, dass ihre Prozesse als Werkzeuge zur Kontrolle von Menschen konzipiert sind. Und es kann sich anfühlen, als würde man am Fließband arbeiten.

FAST berücksichtigt Selbstorganisation als grundlegenden Bestandteil seines Designs. Es ist so grundlegend, dass es ohne Selbstorganisation nicht funktionieren wird. Es erfordert ein völlig anderes Toolkit für das Management und ist größtenteils (wenn auch nicht vollständig) inkompatibel mit hierarchischen Top-Down-Ansätzen.

Daniel Pink hat bekanntlich drei Aspekte der intrinsischen Motivation beschrieben:

• Autonomie – Der Wunsch, selbstbestimmt zu sein, was mehr Engagement als Compliance bedeutet.
• Meisterschaft – Der Drang, sich besser auszubilden.
• Zweck – Der Wunsch, etwas zu tun, das einen Sinn hat und wichtig ist. Unternehmen, die sich nur auf den Gewinn konzentrieren, ohne den Zweck zu bewerten, werden am Ende einen schlechten Kundenservice und unzufriedene Mitarbeiter haben.

Mit FAST sind Sie in der Lage, Ihre Arbeit selbst zu steuern und fühlen sich dadurch autonom. Sie haben die Möglichkeit, sich auf Arbeiten zu konzentrieren, die Ihre Fähigkeiten verbessern und ein Gefühl der Meisterschaft erlangen. Und Sie werden ständig daran erinnert, wie Ihre Arbeit mit dem zusammenhängt, was für das Unternehmen wichtig ist, was Ihnen hilft, ein Gefühl der Zielstrebigkeit zu entwickeln. Auch wenn dies nicht garantiert ist, sehe ich für Unternehmen, die FAST implementieren, das Potenzial, hohe Bindungsraten zu erzielen.

Selbstorganisation liefert auch einige nützliche Signale, die dafür sorgen können, dass eine Gemeinschaft von Menschen besser zusammenarbeitet. Der Typ „Idiot-Manager“ bekommt ein Signal, dass sein Verhalten nicht erwünscht ist. Wie? Sie treten vor, um ein Team zu leiten, und sagen die Arbeit, die sie erledigen möchten. Wenn niemand seinem Team beitritt, findet die Arbeit nicht statt und das Team bildet sich nicht (Teams bestehen aus mindestens zwei oder drei Leuten, sonst passiert das nicht).

Selbstorganisation ermöglicht es den Menschen auch, sich mit schmerzhaften Aspekten der Arbeit auseinanderzusetzen, die in anderen Unternehmen möglicherweise keine Beachtung finden. Wenn die Testsuite beispielsweise schrecklich ist, kann jemand vortreten und ein Team leiten, das dieses Problem behebt. Es ist durchaus sinnvoll, Arbeiten zu erledigen, die nicht ausdrücklich geschäftliche Priorität haben. Aber es ist offen und andere müssen mitmachen, damit es passiert. Dies kann dazu beitragen, das Gefühl zu vermeiden, dass man sich in einer Feature-Fabrik befindet.

Schließlich können Sie die Menschen auswählen, mit denen Sie jeden Tag zusammenarbeiten. Als ich in der Vergangenheit selbstorganisierende Teams gesehen habe, war das ein unerwarteter Vorteil: Die Leute entschieden sich dafür, mit Leuten zusammenzuarbeiten, mit denen sie zusammenarbeiten wollten. Und diese Teams waren viel stärker als ich erwartet hatte.

Dem gegenüber stehen alle neuen Probleme, die die Leute mit FAST erleben würden. Eine Herausforderung könnte in informellen Machtdynamiken oder potenzieller Politik liegen.

Viele Umgebungen sind mit FAST nicht kompatibel

Da FAST noch so neu ist, ist die Implementierung riskanter. FAST macht nicht in jeder Situation Sinn. Und es gibt noch mehr Unbekannte. Stellen Sie sich das am besten als experimentellen Ansatz vor.

Welche Umgebungen eignen sich am besten zum Ausprobieren von FAST? Und wo sollte man FAST meiden?

Je mehr Qualitäten aus dieser Liste Ihr Unternehmen aufweist, desto besser passt es zu FAST:

• Interesse an Managementinnovationen und Experimenten.
• Hohes Vertrauen, angstarme Umgebungen. Oder zumindest der Wunsch, Befehl und Kontrolle in der Führung zu vermeiden.
• Ein guter Führer oder Moderator des Prozesses. Jemand, der ein effektives Kollektivtreffen leiten, den Prozess einrichten, bewerten und aktiv verwalten kann. Jemand, der die Dynamik von Organisationen versteht und weiß, wie Menschen in Gruppen zusammenarbeiten. (Sie könnten mich dafür engagieren).
• Eine mittlere bis hohe Änderungsrate der Prioritäten. FAST ist weniger nützlich, wenn sich die Prioritäten nicht verschieben.
• Ein Team, das kooperativ, selbstgesteuert, leistungsstark und kontinuierlich lernt.
• Ein Führungsteam, das seine Prioritäten erkennen kann.
• Sie haben einen Produktleiter, der bei jedem Kollektivtreffen über die Prioritäten und den Geschäftskontext sprechen kann. Und sie können effektiv kommunizieren.

Je weniger diese Eigenschaften zutreffen, desto mehr Gegenwind werden Sie mit FAST erleben. Ich glaube nicht, dass man sich dafür in einer perfekten Umgebung befinden muss. In gewisser Weise denke ich, dass es wichtiger ist, diese Dinge sein zu wollen, als sie tatsächlich zu sein. Der vielleicht wichtigste Erfolgsfaktor ist also, dass die Führung dabei ist, Raum dafür zu schaffen.

Möglicherweise müssen Sie sich um die Selbstverwaltung kümmern

Selbstorganisierende Systeme können effektiv arbeiten. Aber sie sind nicht frei. Sie ähneln eher der Verwaltung einer Gemeinschaft.

Sie müssen Einschränkungen und Mittel schaffen, um Anreize für das richtige Verhalten zu schaffen. Und Sie müssen sorgfältig beobachten und verwalten, um sicherzustellen, dass die Dinge nicht aus der Bahn geraten.

In jeder Organisation gibt es schlechte Akteure oder Menschen, die nicht mit den Interessen der Gemeinschaft übereinstimmen. Ich erinnere mich an ein Gespräch mit einem Ingenieur, der mir sagte (ich mache mir nichts vor), dass er seiner Meinung nach nicht verpflichtet sei, Mehrwert für seinen Arbeitgeber zu schaffen. Manche Ingenieure möchten sich vielleicht auf Dinge konzentrieren, die ihre Fähigkeiten weiterentwickeln oder sie zu wertvolleren Mitarbeitern machen, statt auf Dinge, die für das Unternehmen, das sie beschäftigt, gut sind.

Mit FAST melden Sie sich für die Verwaltung einer Community von Menschen an.

In herkömmlichen Situationen macht die Hierarchie klar, wer dafür verantwortlich ist. Ich vermute, dass es bei FAST einfach wäre, Konflikte zu vermeiden und „die Mitglieder es herausfinden zu lassen“. Dies könnte dazu führen, dass informelle Machtnetzwerke in einer Art Tyrannei der Strukturlosigkeit dominieren. Wenn Sie FAST verwenden, würde ich mich davor hüten.

Das andere Extrem wäre, die Probleme nicht von der Gruppe lösen zu lassen und das Management komplett damit zu beauftragen. Dies könnte auch schädlich sein.

Daher erfordert FAST eine gute Moderation, sorgfältige Beobachtung und gelegentliche Interventionen.

FAST erfordert viel Arbeit

Der Hauptgrund, warum Sie möglicherweise nicht mit FAST experimentieren möchten, ist, dass bei FAST eine Menge versteckter Arbeit steckt. Es erfordert große Veränderungen in Ihrer Organisation, hin zu einer ungewohnten Arbeitsweise.

Sie können FAST mit der Arbeit in einer neuen Computerprogrammiersprache vergleichen. Die neue Sprache scheint vielversprechend, da sie über so viele neue ergonomische Funktionen verfügt, dass sie viel besser zu sein scheint als alles, was Sie bisher gesehen haben. Es gibt jedoch keine Frameworks und Bibliotheken, die in dieser neuen Sprache geschrieben sind. Sie müssen also viel davon selbst bauen.

Der größte Nachteil von FAST besteht also darin, dass es sich nicht um eine gut etablierte Praxis handelt. Sie müssen viele Dinge erfinden, um mit den Inkompatibilitäten zwischen der Funktionsweise von FAST und herkömmlichen Praktiken umzugehen. Hier sind einige Beispiele:

Wie funktioniert Performance-Management?

In herkömmlichen Teams gibt es einen Manager, der die Arbeit überwacht und Einzelpersonen coacht. Sie haben Leistungsbeurteilungen und wenn jemand nicht zu Ihnen passt, kann der Manager eingreifen. Obwohl es Probleme mit Leistungsbeurteilungen gibt, verstehen die meisten Menschen, wie sie funktionieren, und sie erfüllen einen Zweck in der Organisation.

In FAST-Teams gibt es keine wirklich offensichtliche Möglichkeit, Leistungsbeurteilungen durchzuführen. Weiß der Vorgesetzte der Person überhaupt, was sie tut oder wie sie arbeitet? Man kann „Teams“ nicht einmal bewerten, weil sie vergänglich sind.

Daher muss der gesamte Begriff des Leistungsmanagements neu erfunden werden. Auch wenn das ohnehin eine gute Idee sein mag, erfordert es doch Überlegung und Einfallsreichtum.

Welche Rolle spielen technische Manager bei FAST?

Es gibt viele Möglichkeiten, die Rolle eines technischen Managers zu strukturieren. Generell empfehle ich, den technischen Leiter für das Projektmanagement verantwortlich zu machen, da er so Seite an Seite mit seinem Team arbeiten kann, ohne dass er in einen Bereich gerät, in dem der Leistungsunterschied Probleme verursacht. Es gibt viele gültige Möglichkeiten, die Rolle des technischen Leiters zu definieren, aber ich bevorzuge diese.

In FAST ist die Rolle des technischen Leiters weniger klar. Da es keine langlebigen Teams gibt, ist es für den technischen Leiter schwieriger, Seite an Seite mit seinen direkt unterstellten Mitarbeitern zu arbeiten.

Sie könnten technische Manager beauftragen, die selbst zusammengestellten Teams zu leiten. Oder Sie könnten sie zu reinen Personalmanagern machen. Oder Sie könnten sie zu Spielertrainern machen.

All dies hat Nachteile und einige ziemlich große Nachteile. FAST scheint den Bedarf an technischem Management zu verringern. Sie benötigen immer noch Leute, die Sie einstellen, das Leistungsmanagement durchführen und den Prozess überwachen. Aber vielleicht nicht so sehr wie in einer herkömmlichen Organisation?

Ich habe viele Organisationen leiden sehen, weil sie Management nicht als Disziplin wertschätzen. Aber ich würde vermuten, dass FAST-Organisationen weniger Management benötigen.

Ich bin wirklich gespannt, ob das funktioniert, und möchte von Organisationen hören, die mit FAST experimentieren. Was machen Sie mit der Geschäftsführung?

Wie stellen Sie die Codequalität ohne Eigentumsbereiche sicher?

Codebesitz bietet natürliche Anreize, die Codequalität hoch zu halten. Es liegt in Ihrem eigenen Interesse, denn Ihr zukünftiges Selbst muss in Ihrem aktuellen Code arbeiten.

In einer Situation mit gemeinsamem Codebesitz müssen Sie größere Anstrengungen unternehmen, um die Codequalität sicherzustellen. Meine Empfehlung wäre Pairing oder Mobbing als Pflichtübung.

Sie benötigen außerdem strengere Standards für Codemuster. Sie benötigen Code-Linting. Und Sie benötigen eine Art architektonische Entscheidungsfindung. Sie möchten nicht zwanzig Muster dafür haben, wie Ihr Frontend-Code mit dem Status umgeht. Dies sind Probleme, mit denen Sie in den meisten Softwareunternehmen konfrontiert werden, aber in einem Unternehmen, das FAST verwendet, sind sie viel dringlicher.

Eine Sache, in die viele Unternehmen zu wenig investieren, ist Schulung und Kommunikation rund um effektive Software-Designmuster. Und Gespräche, um sicherzustellen, dass sich alle darüber einig sind, welche Ansätze wann verwendet werden sollen. Diese sind in einer FAST-Organisation wahrscheinlich noch wichtiger.

Der Besitz von Shared Code ist eine Praxis, die bereits einige Präzedenzfälle hat. Es lohnt sich, sich die Zeit zu nehmen, um herauszufinden, wie Sie mit FAST erfolgreich sein können.

Was passiert mit mehreren Kollektiven und dem Überschreiten von Kollektivgrenzen?

Arbeit, die kollektive Grenzen überschreitet, ist in FAST im Wesentlichen undefiniert. Und auch große Initiativen, die ein hohes Maß an Koordination erfordern, werden von FAST nicht ausreichend spezifiziert. Man müsste also Lösungen für diese Situationen finden.

Jede Organisation, die groß genug ist, um mehrere Kollektive zu haben, die FAST verwenden, wird auf kollektivübergreifende Projekte stoßen. Die Muster zur Lösung dieser Probleme werden ähnlich oder analog zu der Art und Weise sein, wie Sie das Problem in kleinerem Maßstab lösen. Aber das ist meines Wissens weitgehend Neuland. Daher müssen Sie einige Koordinationsmodelle verwenden, um diese Probleme zu lösen, wenn sie auftreten. Es wird ein Akt der Erfindung sein.

Wie geht FAST mit Bereitschaftsdiensten um?

Bereitschaftsdienst wird im FAST-Leitfaden nicht ausdrücklich erwähnt. Sie müssen also einen Plan erfinden, um damit umzugehen.

In herkömmlichen Teams besteht die Standardempfehlung für den Bereitschaftsdienst darin, dass jedes Team für seine eigenen Abläufe verantwortlich ist. Und dass jeder im Team auf Abruf ist. Das bedeutet, dass Sie Teams aus mindestens vier Personen haben sollten, damit die Belastung nicht zu groß wird. Der Gedanke dahinter ist, dass Teams, die für ihre Arbeitsergebnisse auf Abruf bereitstehen, einen Anreiz für sie darstellen, Zuverlässigkeit zu entwickeln. Dadurch können sie sicherstellen, dass sie über einen angemessenen Bereitschaftsplan verfügen.

Mit FAST können Sie möglicherweise eine Bereitschaftsrotation mit Stufen erstellen (folgen Sie diesem Runbook und eskalieren Sie, wenn das Problem dadurch nicht behoben wird). Und Sie müssen explizit eine Übersicht darüber führen, wer was unterstützen kann. Dies wird Ihren Teams nicht zugeordnet.

Dies ist nicht besonders schwierig, kommt aber weniger häufig vor als herkömmliche Bereitschaftsdienstpraktiken und erfordert die Aufmerksamkeit des Managements.

Wie sieht es mit der Behebung von Fehlern und Support-Eskalationen aus?

FAST hat eine optionale Rolle namens „Feature Steward“. Sie sind eine Art Experte für eine bestimmte Funktion und die Anlaufstelle für Stakeholder rund um diese Funktion. Es ist nicht erforderlich, dass sie kontinuierlich an dieser Funktion arbeiten, aber sie müssen über ein kontinuierliches Verständnis dafür verfügen.

Wie beim Bereitschaftsdienst benötigen Sie eine Zuordnung der Funktionen zu Personen mit Fachkenntnissen zu diesen Funktionen. Dies ist sowohl für Fehler als auch für Support-Eskalationen wichtig. Und Sie können es auch mit der Rufbereitschaft kombinieren. Sie benötigen eine Möglichkeit, Probleme an die richtigen Personen weiterzuleiten.

Sie müssen außerdem sicherstellen, dass Sie über einen Mechanismus zum Schließen von Wissenslücken verfügen, wenn das Fachwissen auf ein oder zwei Personen beschränkt ist.

Eine Sache, die Sie entscheiden müssen, ist Ihre Richtlinie zur Behebung von Fehlern. Möchten Sie, dass sie immer behoben werden und die Arbeit an anderen Funktionen verlangsamt wird? Wurden die Fehler von der Person behoben, die sie verursacht hat, oder möchten Sie ein anderes Schema? Und wie bestimmen Sie, wer für die Fehlerselektion verantwortlich ist? Wahrscheinlich eine Art Rotation ?

Auch Support-Eskalationen erfordern einen gewissen Aufwand. Ansprechpartner ist der Feature Steward für einen Bereich. Was aber, wenn der Feature Steward im Urlaub ist? Sie möchten wahrscheinlich mehr als eine Person, die sich in jedem Bereich auskennt. Und was, wenn die Support-Frage am Ende Arbeit erfordert? Erledigen Sie einfach die Arbeit oder speisen Sie sie in die zentralen Prioritäten ein?

Keines dieser Probleme ist schwer zu lösen, aber es ist Managementarbeit. Und bei allem, was Sie tun, müssen Sie einen Kompromiss zwischen Fokus und Reaktionsfähigkeit eingehen.

Was ist mit Zuverlässigkeitsvorfällen und Vorfallrückblicken?

FAST definiert nicht, wie mit Vorfällen umgegangen wird. Ihre Bereitschaftsmuster bestimmen weitgehend, wie mit Vorfällen umgegangen wird, und wahrscheinlich wird jeder, der weiß, wie man die Situation behebt, zur Behebung herangezogen.

FAST beschreibt nicht, wie man mit Vorfall-Retrospektiven umgeht. Ich würde empfehlen, etwa Folgendes zu tun: Planen Sie eine Retrospektive des Vorfalls vor dem nächsten Kollektivtreffen. Eines der Ziele der Retrospektive wäre es, einige Maßnahmen zu identifizieren, die durchgeführt werden könnten, um entweder die Wahrscheinlichkeit oder die Schwere der Ursache des Vorfalls zu verringern. Eine andere wäre, so viel wie möglich aus dem Vorfall herauszufinden.

Beim Kollektivtreffen unmittelbar nach dem Vorfall teilte ich mit, was wir gelernt hatten, und machte es automatisch zur Priorität für den nächsten Zyklus, einige der in der Retrospektive identifizierten Arbeiten durchzuführen.

Bei New Relic haben wir FAST nicht verwendet, aber wir hatten eine ähnliche Richtlinie. Wir nannten es „Do Not Repeat Incidents“ (DRI). Es war eines der besten Dinge, die wir jemals für Zuverlässigkeit getan haben. Es galt die Regel, dass die DRI-Arbeit automatisch wichtiger war als andere Prioritäten. Daher führte ein Vorfall immer dazu, dass entweder der Umfang verringert wurde oder die Frist verschoben wurde.

Wie arbeiten Designer in FAST?

Eine Herausforderung für viele Designer besteht darin, sich auf die Zusammenarbeit mit dem Technikteam zu konzentrieren oder die Arbeit vor dem Technikteam zu erledigen. Oder lassen Sie sie in beide Richtungen arbeiten. Sie werden starke Argumente für beide Arbeitsweisen hören.

FAST gibt nicht an, wie dies funktionieren soll, daher müssen Sie selbst entscheiden. Melden sich Designer für die Teams an, an denen sie arbeiten sollen? Oder handelt es sich um eine Dienstleistungsorganisation, die an Dingen arbeitet und als Berater fungiert, wenn Menschen etwas von ihnen benötigen? Sie müssen sich entscheiden. Ich würde wahrscheinlich die Designer bitten, sich anzumelden und Teil der Teams zu werden, aber auch dies ist ein Beispiel für die Art von Entscheidungen, die Sie treffen müssen, wenn Sie FAST einführen.

Wie arbeiten Produktmanager in FAST?

Die Produktrolle in FAST besteht hauptsächlich darin, Prioritäten zu setzen und zu kommunizieren. Im FAST-Handbuch wird vieles über die darüber hinausgehende Arbeit nicht wirklich beschrieben.

Die Annahme im FAST-Handbuch scheint zu sein, dass die Produktmanager inspirieren und kommunizieren und dann die Ingenieure an den Funktionen arbeiten.

Soweit es möglich ist, würde ich Ingenieure dazu bringen, mit Kunden zu sprechen, und sie dazu bringen, sich Fachwissen in dem Produktbereich anzueignen, in dem sie arbeiten. Im Idealfall würden sie die Arbeit erledigen, sie den Kunden vorführen und von ihnen Feedback dazu einholen . Es könnte ein wertvoller Teil ihrer Arbeit sein, die Produktmanager dabei zu unterstützen und die Fähigkeit der Ingenieure zu verbessern, dies effektiv zu tun.

Dieses Modell bietet viel Flexibilität. Sie könnten die typische Übergabe vom Produkt an die Entwicklung durchführen oder sie gemeinsam mit den Kunden den Bereich entdecken und Probleme lösen lassen.

Wie Sie sehen, gibt es in FAST viele Lücken. Den Rest müssen Sie selbst lösen.

Die FAST-Materialien sind voller Fachjargon

Möglicherweise finden Sie die FAST-Website und das Handbuch verwirrend. Sie müssen sich mit einer Menge Fachjargon und lästiger Terminologie auseinandersetzen, um zum Gold von FAST Agile zu gelangen. Als Beispiel ist hier die schreckliche Definition von FAST Agile, die versucht, die Praxis in Version 2.12 des FAST-Leitfadens zu definieren:

„Was ist Fluid Scaling-Technologie? Die Fluid Scaling Technology kombiniert Open Space Technology und Open Allocation, um eine leichte, leicht verständliche und einfach zu beherrschende Methode zur Organisation von Menschen rund um die Arbeit zu schaffen – die skaliert. FAST ist die Abkürzung für Fluid Scaling Technology. Fluid Scaling Technology for Agile ist FAST Agile.“

Also. Schlecht. Und das ist sehr repräsentativ. Sie werden viele Verweise auf Kollektive, Wertzyklen, offene Technologie, Teal-Transformation, Theorie Y usw. sehen. Dies alles wird ohne Erklärung präsentiert, und selbst wenn es erklärt würde, wäre es nicht hilfreich. Sie sprechen ein Nischenpublikum agiler Theoretiker an und konzentrieren sich eher auf Zuschreibung als auf Nützlichkeit.

Abschluss

Wohin führt uns das? Lohnt es sich, mit FAST agile zu experimentieren?

Ich glaube, die Antwort darauf lautet „Ja“, aber mit Vorsicht und im richtigen Kontext. Sie können damit innerhalb einzelner Teams herumspielen. Und wenn Sie Unterstützung durch die Führung haben, experimentieren Sie schrittweise damit in größeren Organisationen.

Bitte teilen Sie es mir mit, wenn Sie damit experimentieren. Und wenn Sie Hilfe bei der Einführung in Ihrem Unternehmen benötigen, kontaktieren Sie mich. Ich helfe Ihnen entweder direkt oder verbinde Sie mit anderen, die Ihnen helfen können.

Danke

Frühe Versionen dieses Beitrags waren… wirklich schlecht. Ich möchte Seth Falcon und Davy Stevenson für ihre Kritik danken. Sie wiesen beide auf einige große Probleme mit dem Beitrag hin, die mich dazu veranlassten, einen Rückzieher zu machen und meinen Ansatz zu überdenken. Und sie haben einige hervorragende Punkte vorgebracht, die ich in ihre eigenen Abschnitte des Beitrags integriert habe. Schließlich habe ich den größten Teil des Beitrags umgeschrieben und war mit dem Ergebnis viel zufriedener. Danke schön! Seth hat einen Newsletter zum Thema technische Führung, der einen Blick wert ist, und Davy (wie ich) gibt Startup-Beratung und Coaching .

Jim Shore hat mich mit FAST agile bekannt gemacht. Er hat einige ausgezeichnete Vorträge über seine Erfahrungen damit. Und wir haben uns ein paar Mal getroffen und die Auswirkungen und die Umsetzung von FAST besprochen. Jim ist der Autor von The Art of Agile Development .

Bild von Kanenori von Pixabay

Fußnoten

1. Ich glaube, 150 Leute sind für ein Kollektiv wahrscheinlich unhandlich. Ich vermute, dass 60 Personen eine bessere Maximalgröße sind.