De "twee pizza's"-regel van Amazon: een teamworkshop als oefening
Amazon was een van de eerste bedrijven die agile werkwijzen op grote schaal toepasten - zonder daarbij te steunen op Scrum of andere agile frameworks. Een kernelement voor agile teams bij Amazon was daarbij de “Two Pizza Teams”-regel.
Amazon’s twee pizzateams: Niet zo makkelijk als het lijkt
De “Two Pizza Team” regel stelt dat een team alleen groot genoeg kan zijn om gevoed te worden met 2 pizza’s. De regel komt overigens van Amazon-oprichter Jeff Bezos zelf.
Hoewel er tientallen jaren zijn verstreken sinds het ontstaan van deze pizzaregel, houdt Amazon de “twee-pizza-teams-regel” nog steeds in ere. Zie: Inleiding tot DevOps op AWS. Het idee van kleine, zelfgeorganiseerde teams lijkt daarom een tijdloze universele geldigheid te hebben.
Ook al klinkt het idee van kleine teams eenvoudig, er zijn een paar andere randvoorwaarden waarmee rekening moet worden gehouden om het effect van kleine teams op de wendbaarheid van het bedrijf te maximaliseren.
Laten we dus eens kijken hoe je deze managementfilosofie en de bijbehorende randvoorwaarden in je teams kunt meten en verbeteren:
Health Check: Amazon Two Pizza Team
Het kernidee achter de “Two Pizza Teams” regel is dat kleinere teams sneller kunnen handelen en reageren. Deze flexibiliteit is vaak een belangrijke onderscheidende factor bij de ontwikkeling van software om concurrerend te blijven.
Maar om ervoor te zorgen dat deze kleine teams daadwerkelijk sneller kunnen handelen, moet aan een aantal voorwaarden worden voldaan:
- Het team heeft een duidelijk doel voor ogen en voelt zich volledig verantwoordelijk voor het bereiken ervan.
Strikt genomen is een team zonder gemeenschappelijk doel geen team, maar een groep mensen. Als het team geen verantwoordelijkheid neemt voor een duidelijk omschreven doel, zal de omvang van het team niet veel kunnen bijdragen aan wendbaarheid. - De teamleden beschikken over alle benodigde vaardigheden om hun eigen doelen te bereiken.
Bestaat jouw team alleen uit mensen uit dezelfde specialisatie? Dat is geen agile team: Agile teams zijn cross-functioneel en hebben alle rollen en vaardigheden die ze nodig hebben binnen het team om hun doelen te bereiken: Bedrijfsanalisten, productontwerpers, ontwikkelaars etc. De samenstelling moet altijd overeenkomen met het teamdoel. - Het team heeft alle beslissingsbevoegdheden en middelen en is daarom niet afhankelijk van derden om onze doelen te bereiken.
Als het team sterk afhankelijk is van andere teams of besluitvormers, wordt elke wendbaarheid in de kiem gesmoord. Het team moet in staat zijn om zelfstandig technologieën uit te proberen, gegevens voor besluitvorming te genereren en directe feedback van klanten te krijgen. - Het team heeft directe toegang tot klanten om feedback van klanten te krijgen.
Als een team van twee pizza’s gewoon door een backlog heen werkt zonder enig klantcontact te hebben, is dat maar in beperkte mate veelbelovend. Om je organisatie als geheel echt wendbaarder te maken, moet elk team direct toegang hebben tot zijn eigen klanten om zonder omwegen feedback van klanten te ontvangen en erop te reageren.
Zie ook: Amazon’s principe van klantobsessie
Dus voordat je je teams gaat inkrimpen, moet je zeker zorgen voor deze randvoorwaarden. Een goede workshopvorm om deze “Two Pizza Health Check” te controleren is de volgende terugblik:
Ben je onzeker over wat retrospectieven zijn en hoe ze je helpen om de “2 Pizza Team”-cultuur van Amazon te implementeren? Begin dan hier:
Amazon Two Pizza Team Terugblik
Met deze Two Pizza Team retrospective kun je samen met je team de randvoorwaarden analyseren en verdere ontwikkeling in gang zetten:
Amazon Two Pizza Team Health Check: Zo verloopt de retro
Random Icebreaker (2-5 minuten)
Echometer biedt jullie een generator voor willekeurige check-in vragen.
Review van de openstaande acties (2-5 minuten)
Voordat je met nieuwe onderwerpen begint, zou je ter controle van de effectiviteit moeten bespreken wat er van de acties uit eerdere retrospectieven is geworden. Echometer geeft automatisch een overzicht van alle openstaande actiepunten uit eerdere retro's.
Health Check
Alle teamleden kunnen de health checks anoniem op een schaal beantwoorden. Neem de resultaten van de health checks vervolgens samen door en noteer eventueel aanvullende opmerkingen. Als je dezelfde health checks in meerdere retrospectieven gebruikt, kun je ook trends in de loop van de tijd in Echometer volgen.
- We hebben een duidelijk teamdoel waar we de volledige verantwoordelijkheid voor nemen.
- We hebben alle vaardigheden in het team om onze doelen te bereiken.
- Als team hebben we alles wat we nodig hebben om onze doelen te bereiken, onafhankelijk van derden.
- Als team is het voor ons gemakkelijk om feedback van klanten te verzamelen en erop te reageren.
Retro-onderwerpen bespreken
Gebruik de volgende open vragen om jullie belangrijkste bevindingen te verzamelen. Eerst bedenkt iedereen dit voor zichzelf. Echometer staat toe om elke kolom van het retro-bord afzonderlijk te onthullen, om de feedback vervolgens te presenteren en te groeperen.
- Welke vaardigheden of kennis missen we het meest in het team?
- In welke situaties zijn we als team afhankelijk van derden om onze doelen te bereiken?
- Wat zou ons helpen om sneller te reageren op behoeften en feedback van klanten?
Catch-all vraag (Aanbevolen)
Zodat ook andere onderwerpen een plek hebben:
- Waar wil je het verder nog over hebben in de retro?
Prioritering / Stemming (5 minuten)
Op het Retro-Board in Echometer kun je de feedback heel eenvoudig prioriteren met de stemming. De stemming is natuurlijk anoniem.
Maatregelen definiëren (10-20 minuten)
Via het plusteken bij een feedback kun je een gekoppelde maatregel aanmaken. Nog niet zeker welke maatregel de juiste zou zijn? Open dan via het plusteken in plaats daarvan een whiteboard over het onderwerp om kernoorzaken en mogelijke maatregelen te brainstormen.
Checkout / Afsluiting (5 minuten)
Echometer stelt je in staat om anonieme feedback van het team te verzamelen over hoe nuttig de retro was. Dit resulteert in de ROTI-score ("Return On Time Invested"), die je in de loop van de tijd kunt volgen.
Amazon Two Pizza Team Health Check
Health Check vragen (schaal)
Open vragen
Conclusie: Amazon’s Two Pizza Team regel
De Two Pizza Team regel heeft in de loop der jaren terecht zijn relevantie behouden. Het is echter belangrijk op te merken dat de grootte van het team alleen geen garantie is voor een wendbare organisatie.
Alleen in combinatie met duidelijke teamdoelstellingen en zelfeffectieve teams die oplossingen kunnen ontwikkelen in direct klantcontact zonder interne afhankelijkheden, kan een organisatie de vruchten plukken van een grotere klanttevredenheid en een snellere ontwikkeling op de markt.
Afhankelijk van de bedrijfscontext is het vaak niet voldoende om alleen naar individuele teams te kijken. In de regel moet ook de organisatiestructuur ter discussie worden gesteld om de voorwaarden te scheppen voor een goed presterend, wendbaar bedrijf:
Om echt een hoog presterende agile organisatie te worden, moet je op een andere manier naar je organisatiestructuur kijken en bereid zijn je mindset en gedrag te veranderen.
Tom Godden, AWS Enterprise Strategist, bron: Amazon Executive inzichten
Zie ook in deze context: Amazons “Dag 1 Mentaliteit”
Ik hoop dat de Two Pizza Team Retrospective een stimulans kan zijn om deze voorwaarden voor jouw team te creëren. En misschien geeft het ook stof tot nadenken op organisatorisch niveau!
Bonus: Wil je leren van andere agile pioniers zoals Netflix?
We hebben ook de innovatiecultuur van Netflix onder de loep genomen en hebben een paar workshop-formaten voor je!
- Waarom Netflix alle resultaten (inclusief mislukkingen)
- Netflix heeft geen besluitvormingsprocessen, maar geïnformeerde kapiteins
- Ideeën moeten vroeg worden gesocialiseerd bij Netflix
- Denken in weddenschappen en ideeën testen
