FAST Agile-zwermen

Het FAST Agile Framework

In Advanced, Agile by PeterLeave a Comment

Leestijd: 11 min.

FAST Agile is een nieuwe scalings methodiek die kiest voor het toepassen van het Open Space concept. De FAST Agile methodiek is in dit artikel beschreven.

De bedenker van Fluid Scaling Technology for Agile, Ron Quartel, werd niet echt enthousiast van andere scalings methodieken. Hij werd echter enthousiast toen hij een andere benadering zag van scaling. Bij een Open Space meeting werd in een zeer korte tijd een volledige samenwerking bereikt met tientallen mensen. Open Space Technology heeft de basis gelegd van FAST Agile.

Ron Quartel adviseert om niet eens na te denken over FAST Agile als je Open Space Technology nog niet begrijpt. Hij verzoekt je dan om je eerst te verdiepen in Open Space Technology. Volgens Quartel biedt Open Space Technology namelijk de juiste structuur om natuurlijk leiderschap en innovatie te laten ontstaan.

Ken je OST nog niet? Lees dan eerst het artikel: Wat is Open Space Technology?

De belangrijkste bron van dit artikel is: http://www.fast-agile.com/ Daarnaast zijn diverse youtube videos en presentaties van Ron Quartel bekeken en samengebracht om dit artikel te schrijven. FAST Agile is interessant, lees maar verder.

In het artikel De bouwstenen van FAST Agile staan alle door Quartel meegenomen andere Agile methodieken en theorieën.

Fluid Scaling Technology

Het uitgangspunt van FST is dat een hoge mate van zelfsturing een vereiste is om goed te kunnen scalen. Volgens Quartel hebben veel andere scaling systemen het over zelfsturende teams, maar brengen tegelijkertijd een scala aan voorschriften. In zijn optiek zijn deze ‘eisen’ een beperking voor zelfsturende teams.

Het FAST Framework is bedacht voor het begeleiden van technologische ontwikkelprocessen, maar kan wellicht breder worden ingezet.

Dit artikel is vrij uitgebreid en bestaat uit een aantal onderdelen:

  1. Introductie
  2. Visie, waarden, regels en principes
  3. Past FAST bij jouw organisatie?
  4. Rollen
  5. Faciliteiten
  6. Marktplaats
  7. Release Map

1. Introductie

1.1 Wat is FAST?

FAST (ook wel FAST Agile of Open Space Agile genoemd) is een op zichzelf staande methode voor een team of ‘team van teams’ (Tribe) om iteratief samen te werken. FAST verschilt met andere agile frameworks en agile schaalmodellen:

  • FAST maakt een vlotte samenwerking mogelijk.
  • Team zelfselectie en dynamic reteaming zijn ingebouwd.
  • Het is gebouwd op Open Space Technology en niet op Scrum.
  • Kleinschalig tot groot (5-150 personen) per tribe, dus oneindig schaalbaar.
  • Zelforganisatie is onontkoombaar.

FAST is: een flexibel kader, een cultuurverandering tool en een manier om innovatie in een organisatie een nieuwe impuls te geven. FAST is mede gebaseerd op Simple Rules, onderstaande bewijst dat.

Het doel van FAST Agile is om controle te krijgen over snelle vooruitgang en tegelijkertijd hyperproductiviteit te bereiken. De uitgangspunten zijn:

  • Vertrouw de developers (dat deze het juiste doen op het juiste moment).
  • Zelforganisatie (door gebruik van Open Space Technology)

In deze introductie staat hoe je kunt starten met FAST Agile, hoe het in grote lijnen werkt en waarom het werkt volgens Ron Quartel.

Hoe start je met FAST Agile?

Je start met FAST door alle ontwikkelingsteams, die aan hetzelfde project werken, samen te voegen tot één Tribe (max. 150 personen, overeenkomstig de theorie van Dunbar).

Fast Agile - Zwermen voorbeeld

In eerste instantie kunnen alle teams als een “gezamenlijke zwerm” binnen deze Tribe bij elkaar blijven. Alle kenmerken van het werk worden onderhouden en visueel bijgehouden in een Release Map die de basis vormt voor de Product Backlog.

Daarna komt de Tribe in een vaste cadans bij elkaar om het werk aan het product te tonen sinds de laatste bijeenkomst. De daarop volgende market place in OST-stijl wordt gebruikt om ‘openstaand werk’ te bespreken en te vertellen wat ze de volgende iteratie gaan doen. Aan het einde van de Marketplace bepalen de ontwikkelaars of ze in de voorgaande zwerm blijven of overstappen naar een andere zwerm omdat dit zinvol is. Dit heet Flex-teaming of Dynamic assembly. Deze werkwijze is deels gebaseerd op reteaming van Helfland.

De deelnemers bepalen zelf waar hun vaardigheden het best tot hun recht komen, dit doen ze door in te stappen in het team waar hun vaardigheden het meest nodig is.

Voorgaande is gebaseerd op Open Space Technology, een bewezen methodiek. Dus mocht je twijfels hebben, lees dan rustig verder.

2. Visie, waarden, regels en principes

Nu volgen achtereenvolgens de visie, waarden, regels en principes van FAST Agile

2.1 De visie van FAST Agile

Untethering the human spirit with the workplace

Ron Quartel

In het Nederlands: De menselijke geest losmaken van de werkplek

2.2 FAST Waarden

De waarden die FAST Agile hanteert zijn:

  • Code Craft (voldoen aan kwaliteit en technische uitmuntendheid)
  • Zelforganisatie (vertrouwen en samenwerking)
  • Gedeelde visie (afstemming gemeenschappelijk doel)

2.3 FAST Regels

FAST creëert een complex adaptief systeem met eenvoudige regels:

  • Doe het juiste (voor de release)
  • Een teamspeler zijn, d.w.z. een coach zijn en coachbaar zijn.
  • Een T-vormige speler (een generaliserend specialist) te zijn.
  • Streven naar uitmuntendheid in uw vakgebied

2.4 FAST principes

FAST hanteert 2 eenvoudige principes:

  • De juiste mensen werken op het juiste moment aan de juiste dingen op het juiste moment.
  • Het werk zal opduiken en gedaan worden in de volgorde waarin het moet gebeuren.

3. Past FAST bij jouw organisatie?

Een waarschuwing is volgens Ron Quartel op zijn plaats. Hij vraagt je om eerst te checken of onderstaande regels wel bij je passen of wellicht van toepassing zijn:

3.1 Mindset

Is de mindset in jouw organisatie overeenkomstig de waarden en principes van FAST?

  • Geloof je in de kracht van zelforganisatie en Open Space Technology?
  • Vertrouw je erop dat je developers deskundig en zorgzaam zijn en het juiste zullen doen?

Is het antwoord hierop nee? Dan past FAST absoluut niet bij jouw organisatie. Hoewel de volgende items ook belangrijk zijn, start het met de mindset.

3.2 Stop met doen wat niet werkt!

Stopbord

Quartel is duidelijk, FAST Agile vraagt je om te stoppen met wat niet werkt:

  • Stop met het bekijken en behandelen van developers als activa.
  • Stop micromanagement.

3.3 Bereidheid tot experimenteren

Als je starten met FAST Agile overweegt, experimenteer dan eerst, neem onderstaande adviezen mee:

  • Start FAST niet op voor een project met een kritieke deadline.
  • Onderzoek welke experimenten anderen hebben geprobeerd. Dit om inzicht te krijgen in de experimenten die jij van plan bent te beginnen.
  • Neem eventueel een FAST consultant in de arm

3.4 Faciliteiten

Het is handig om eerst een globaal overzicht te geven, de detaillering en toepassing volgt later.

  • Plaats het hele developers team, dat op hetzelfde product zit, bij elkaar
  • Begin met een klein kernteam van Code specialisten en bouw de tribe daar op.
  • Beschik over een vergaderruimte die groot genoeg is om de Marketplace te ondersteunen, immers elke iteratie komen tot 150 mensen bij elkaar. Die willen met elkaar in een Open Space setting kunnen praten. Deze ruimte heet overigens: Het Forum.
  • Daarnaast zijn er meerdere kleinere ruimtes nodig voor de zwermen. (5 tot 20 mensen)

4. Rollen

4.1. FAST Product Director (Product Regisseur)

Met Director wordt een regisseur bedoelt, zoals een regisseur van een film omdat dit een goede analogie is van wat de rol inhoudt.

Deze rol is ook enigszins vergelijkbaar met de rol van de Product Owner in Scrum. Je verantwoordelijkheid als Product Director (PD) is om te communiceren en te onderhouden van:

  • Productvisie.
  • Product roadmap (ruwe set van releases met de belangrijkste kenmerken en tijdlijn).
  • Release plan (het overzicht van de features/functies).
  • Story map met de set van functies voor de release.

De FAST Product Director is een belangrijke leidinggevende rol. Developers zullen de visie willen volgen en daartoe hun product willen bouwen. De FAST Product Director moet in staat zijn om bij elke iteratie alle members te stimuleren.

4.2 Developer – member – lid

De naam van de rol is ‘developer’ het maakt niet uit wat jouw vaardigheid is, net als bij Scrum. Men verwacht van je dat je excellent bent in je vak of dat wilt bereiken. De Tribe met developers bestaat uit cross-functionele vaardigheden en T-vormige mensen.

Als je code schrijft dan wordt kwaliteit verwacht van een Code Crafter. In een later te verschijnen artikel kom ik nog op terug met een uitleg van deze benaming.

Wat anders is bij FAST is dat er ook je verwacht wordt dat je een coach bent en dat je in staat bent om te coachen. Het doel van deze benadering is dat je kennis wilt delen en daardoor geen silo’s ontstaan.

Members hebben een T-shape. T-shape is een persoonlijkheidsprofiel met als belangrijkste aspecten: algemeenheid en specialisatie. Vanzelfsprekend passend bij de uitdaging die je als Developer hebt.

4.3 Swarm Steward

Swarm Steward wordt je zodra je beslist om tijdens de FAST meeting suggesties te doen om werk op te nemen in de iteratie. Dus het voorstellen van een opstarten van een bepaalde activiteit tijdens de Iteration Market Place. Dan is jouw rol automatisch Swarm Steward van het voorstel. In het Nederlands: een vorm van ‘een teamleider’ voor een iteratie.

4.4 Feature Steward

Om feature eigenaarschap zeker te stellen, tot de voltooiing van de feature, kan een deelnemer instemmen dat hij of zij eigenaar blijft. Totdat deze feature is afgerond, zelfs als de feature meerdere iteraties duurt. Een Feature Steward mag deze rol doorgeven aan een ander, mits deze het er mee eens is.

4.5 Fast Coach

Deze rol is beschreven in het artikel: Wat is FAST Agile?

6. Faciliteiten

Er zijn een paar voorwaarden aan de beschikbare faciliteiten om een maximale productiviteit te bereiken.

De faciliteiten hebben volgens FAST een bepaalde indeling en speciale kamers nodig. De meeste ‘moderne’ kantoorgebouwen voldoen daar vaak al aan. Wat echt belangrijk is dat er een ruimte is waar een vergadering in Open Space-stijl gehouden kan worden. En wel met de hele Tribe tijdens de FAST Meeting. (tot 150 mensen). Deze ruimte noemt men dan: Het Forum

6.1 Het Forum

Het Forum is plaats waar het enige FAST-artefact: de Release Map zichtbaar is. In deze ruimte rondom de Release Map faciliteert de Product Director de FAST bijeenkomst. Zoals gezegd moet deze ruimte groot genoeg zijn voor de hele Tribe.

6.2 Samenwerkingsgebieden of -kamers

Je hebt genoeg ruimtes nodig om de juiste hoeveelheid teams een eigen plekje te kunnen bieden. De Tribe breekt uit in teams en zwermen uit aan het einde van de FAST-vergadering. Dan gaan ze naar een vooraf bepaalde ruimte.

Het Forum kan ook worden gebruikt door de teams. Pair Programming en/of mob programming zijn twee ideaal plaatjes in FAST Agile, dus is het handig om ruimtes te hebben waar dit mogelijk is. Vanzelfsprekend zijn er whiteboards, minstens één in elke ruimte.

7. Marketplace

In FAST is er maar één vergadering. De FAST-Marketplace. Deze marktplaats kent meerdere fasen of onderdelen. Maar het is één vergadering en markeert het begin en einde van een iteratie.

De Marketplace is de kern van de FAST scalings methode. De marktplaats wordt derhalve uitgebreid beschreven.

De Marketplace bestaat uit 5 delen

  1. Tonen en vertellen (Show and tell)
  2. Marketplace (Open de volgende iteratie)
  3. Aankondigingen en afstemming van de visie. (Announcements and Alignment of Vision)
  4. Zwermen, afhankelijkheidsbeheer en planning (Swarm huddle, dependency management and planning)
  5. Code crafting.

7.1 Tonen en vertellen

  • Locatie: Forum
  • Facilitator: Product Director
  • Deelnemers: Product Director, Stakeholders, Tribe
  • Doel: Synchronisatie

Tijdens deze fase zal elke zwerm (team) die het werk van de vorige iteratie heeft voltooid, naar voren stappen en hun werk aan de aanwezigen tonen. De productdirecteur, belanghebbenden en iedereen in de forumbijeenkomst kunnen vragen stellen. De Product Director en Stakeholders kunnen kritiek en feedback geven.

Bij het observeren van de voltooide werkitems en het luisteren naar de feedback van de aanwezige stakeholders, kan de Product Director de werkitems volgen als verfijningen, nieuwe functies toevoegen of zelfs sommige functies laten vallen. De Release Map zal dienovereenkomstig worden bijgewerkt. De productdirecteur kan de werkitems ook op dit moment als “klaar” verklaren.

Het doel van deze fase is om de Tribe op één lijn te krijgen met de huidige staat van het systeem. Wat is de delta die jouw Tribe heeft toegevoegd sinds de laatste FAST vergadering? Dat is wat moet worden gedeeld – in de hoogtepunten en niet in detail. Geef alleen een demonstratie als het helpt om voorgaande duidelijker te communiceren. Probeer te voorkomen deze vergadering een traditionele vergadering met presentaties wordt.

FAST in een Continues Delivery omgeving met DevOps

Een werkitem kan op dit moment door de Product regisseur worden beschouwd als “Deploy Ready”. DevOps zal deze beslissing verwerken en het werkitem implementeren. (Het werkitem wordt volledig gemarkeerd op de releasekaart (of eventueel van de kaart verwijderd).

7.2 Marktplaats (Open de volgende iteratie)

  • Locatie: Forum
  • Facilitator: Product Director
  • Deelnemers: Stakeholders, stam, stam
  • Doel: De Tribe gaat zelf werk selecteren voor de komende iteratie en organiseert zich in teams (zwermen).

Na afloop van Show en Tell (7.1) gaan we over naar de marketplace phase (marktfase). Deze term is ontleend aan Open Space Technology.

De Product Director zal een aantal enthousiasmerende commentaren geven en zal wellicht gebieden belichten die een hogere prioriteit hebben. De vloer is daarna van de Swarm Stewards, deze laten weten waar ze naartoe willen.

Natuurlijk leiderschap

Dit is de start van natuurlijk leiderschap, leden van de Development Tribe zullen ‘op het het podium’ staan en op het forum aankondigen welke functie of probleem zij in de komende iteratie (meestal twee dagen) willen begeleiden. Ze (nu: Swarm Stewards) brengen een korte beschrijving van hoe zij dit willen bereiken, misschien vertellen ze ook nog waarom zij een passie voor het onderwerp hebben.

Ze hebben een of andere ‘kamer- of plaatsreservering’ geplaatst, bijvoorbeeld met een post-it, om aan te geven dat ze één van de ruimtes hebben gereserveerd voor deze zwerm. De faciliteiten kunnen echter beperkend zijn in het aantal beschikbare kamers.

Zodra alle kamers zijn ‘geboekt’ of er zijn geen vrijwilligers meer voor Swarm Steward, dan inspecteert de Product Director de marktplaats en kan hij of zij vragen stellen.

De Product Director heeft enige vetomacht maar gebruikt dit als laatste redmiddel. Dit kan leiden tot een verandering in de gekozen prioriteiten. Wellicht vanuit de gedachte van de productdirecteur om de wensen nauwkeuriger weer te geven. Toch dient dit een uitzondering te zijn en te blijven. Want de Tribe is uiteindelijk verantwoordelijk voor het kiezen van het juiste werk om het product stapsgewijs vooruit te helpen.

Een Swarm Steward zal beslissen wat belangrijk is voor de ontwikkeling van het product of de vrijgave van het product. De Swarm Steward is immers eigenaar van het idee en doet een belofte aan de Tribe om over een paar dagen de gewenste voortgang te brengen. Te denken valt aan:

  • Werkitem van de releasemap
  • Refactoring
  • Onderdelen werk (in plaats van feature werk)
  • Bug fixes (de hoogste prioriteit)
  • Spikes / onderzoek

De stam wordt vertrouwd om te doen wat goed is voor het product.

7.3 Aankondigingen en afstemming van de visie

  • Locatie: Forum
  • Facilitator: Product Director
  • Deelnemers: Stakeholders, Tribe
  • Doel: Afstemming van visie en inspiratie

Terwijl de hele Tribe is verzameld, worden alle openbare aankondigingen gedaan en een energievolle Product Director mag deze gelegenheid niet missen. In de Amerikaanse uitingen van Quartel wordt hier een gloedvol betoog gehouden over dat ‘de troepen aangemoedigd dienen te worden’ en ‘dat de PD de visie nogmaals helder moet herhalen’.

7.4 Zwermen, afhankelijkheidsbeheer en planning

  • Locatie: Development rooms
  • Facilitator: Swarm Steward
  • Deelnemers: Zwerm
  • Doel: Identificeer, bespreek en los afhankelijkheden op met andere zwermen en beslis over een architectonisch plan voor de werkzaamheden.

Om de Kickoff van deze Iteratie te kunnen beëindigen, kijken de Swarm Stewards nog met een eerste snelle scan of er onderlinge afhankelijkheden zijn. Dan gaan ze naar hun ‘gereserveerde’ kamers en wachten om te zien wie van de Tribe ervoor heeft gekozen heeft om met hen samen te werken de komende iteratie.

teams of teams
teams of teams

Zodra de zwerm is aangekomen, starten ze een mini-planningssessie. Als er afhankelijkheden zijn met andere zwermen, wordt voorgesteld om een grotere vergadering te hebben met de andere zwerm(en) om de strategie te bespreken.

Een groot aantal resultaten zou uit deze fase kunnen komen, een aantal voorbeelden:

  • Een zwerm zou kunnen besluiten dat hun werk misschien beter vertraagd kan worden door de complexiteit van afhankelijkheden en/of ander werkitem te kiezen.
  • Er kan bijvoorbeeld worden gekozen om een verandering in de architectuur aan te brengen.
  • Een story kan niet doorgaan.
  • Werkitems kunnen opgesplitst worden.
  • Men start met een grote refactoring.
  • Werk kan worden overgedragen aan een andere zwerm.
  • Etc.

Het doel is om met een ontwikkelingsplan te komen voor de resterende tijd in de iteratie. Dit zie je waarschijnlijk als taken op post-its bij elk whiteboard van elke zwerm.

Vanzelfsprekend komt het ook voor dat er een zeer kleine zwerm ontstaat. Zij kunnen dan beslissen om door te gaan of niet te starten. Kortom, ontbinden en de individuen voegen zich bij andere zwermen. Weet je het nog? Dit is ‘De wet van de twee voeten’ of ‘De wet van mobiliteit’ volgens Open Space Technology.

7.5 Code Craftmanship

FAST Agile is bedacht voor technologische ontwikkelingen te kunnen scalen. Voor dit artikel is het van belang om de vijfde peiler te beschrijven. De vijfde peiler is Code Craftmanship. Of te wel vakmanschap in het coderen. Dit wordt als volgt beschreven:

Extreme Programming Explained - cover

Code Craftmanship! Het gebruiken van XP (Extreme Programming) is niet verplicht, maar wel sterk aanbevolen. Kies ook bijvoorbeeld voor Mob Programming, Extreme Programming of elke andere methode waarbij technische uitmuntendheid mogelijk is EN je kunt aantonen dat je een vakman in code schrijven bent.

Pair Programming is niet verplicht, maar eigenlijk wel een must bij de komst van een nieuw teamlid. Pair Programming wordt beschouwt als een efficiënte en vriendelijke manier om iemand op de hoogte te brengen van de snelheid en de cultuur van de betreffende tribe.

De Product Director moet te allen tijde beschikbaar zijn om vragen te beantwoorden en duidelijkheid te krijgen.

6. Release Map

Als laatste hoofdstuk de Release Map. Het enige artefact van FAST Agile. Zoals eerder te lezen viel is de locatie van de Release Map: Het Forum.

Voor de Release Map is het nodig om User Story Mapping te beschrijven.

6.1. User Story Mapping

User Story Mapping - cover

De Release Map of Product Wall is gebaseerd op het idee van User Story Mapping. Het is een manier om snel het geheel van de Backlog te visualiseren.

Het is in eerste instantie gevuld met functies die niet zijn afgebroken. Wanneer en hoe ze worden afgebroken is aan de Tribe en wordt door een zwerm in een iteratie gedaan. Het afgebroken werk wordt weergegeven in hun eigen feature maps.

Features worden opgesplitst in grote stories en dan weer in steeds kleinere werkitems totdat ze door een team kunnen worden opgepakt in de beschikbare tijd. Kortom, werkzaamheden in stukken verdelen. Net als al het andere in FAST gebeurt een werkonderbreking net genoeg, net op tijd.

6.2 Een voorbeeld

Een Swarm Steward besluit aan een nieuwe functie te werken. Het pas samengekomen team moet bepalen wat een zinnig werkitem is dat ze kunnen leveren in de iteratie met het aantal leden en de vaardigheden die ze in hun zwerm hebben.

Daartoe zullen ze beginnen met het verkleinen van Stories en stoppen wanneer ze de meest verstandige mogelijkheid hebben gevonden die aan deze eisen voldoen.

Dit zou de eerste activiteit zijn voor een team, om te doen voor een codering, in het geval van een nieuwe functie of een groot item dat nog niet is afgebroken. Deze werkitems worden op een feature map geplaatst die steeds meer gefragmenteerd en fijnmaziger wordt naarmate het project vordert.

De features, stories en werkitems kunnen binnen FAST al dan niet van de juiste grootte zijn. Dat is aan de Tribe. Volgens Ron Quartel kan FAST werken in een sized-, estimated en in een no-estimate omgeving.

Tot slot

Wellicht is dit artikel te omvangrijk om in één keer FAST Agile volledig te overzien.

Veel belangrijker is echter dat deze vrij nieuwe scalingsmethodiek wellicht een andere blik werkt op mogelijkheden in jouw organisatie.

Leave a Comment