# Daily Standups Are Bullshit (Tenzij ze verdienen hun loon) > Dagelijkse stand-ups zijn niet inherent slecht - maar wanneer ze ritueel in plaats van uitlijning, ze verspillen tijd en schade vertrouwen. Dit artikel onderzoekt waarom ceremonie is belasting, hoe de waarde ervan te meten, en praktische async-eerste alternatieven die teams op één lijn houden zonder het verbranden van energie of tijd. Agile is aanpassing - niet naleving. ## Inleiding In mijn bijna 30 jaar van software ontwikkeling, heb ik bijgewoond meer dagelijkse standups dan ik zorg te tellen. Sommige waren elektrische - korte momenten van uitlijning die blokkers ontruimde en stuurde ons sprinting naar voren. Andere waren performatieve rituelen waar vermoeide ontwikkelaars citeerde "zelfde als gisteren" naar een galerie van gedempte camera's. Het verschil? Een soort stand-up *verdiende zijn belasting*De andere was slechts een ceremonie. [TOC] ## Een bekentenis Ik moet bekennen: Ik ben een onverbeterlijke Agilist. Ik werd die manier door het ervaren van de WORST van de PRINCEs, Waterfalls, en zwaarhandige proceskaders. Ik heb geleefd door de "volledige documentatie voor een enkele regel van code" tijdperk. Ik heb gezeten in Change Control Board vergaderingen waar het implementeren van een one-line fix vereiste drie weken goedkeuring papierwerk. Het simpele feit is: **Agile is de beste manier om goede software te bouwen.** Om Churchill te parafraseren: > *"Inderdaad is gezegd dat Agile is de slechtste vorm van software ontwikkeling proces - met uitzondering van al die andere vormen die zijn geprobeerd van tijd tot tijd."* Maar het zit zo: **pro-Agile zijn betekent niet pro-ritueel zijn.**. In feite, het verdedigen van onbeantwoorde ceremonies is de *tegenover* van behendig. Dit is wat ik geleerd heb: **agile gaat over aanpassing, niet trouwen**. Maar de meeste teams erven Scrum rituelen groothandel, behandelen ze als heilig in plaats van pragmatisch. Dagelijks stand-ups, sprint planning, retrospectieven - dit zijn instrumenten, geen geboden. En zoals elk instrument, ze moeten worden beoordeeld door of ze *werk*. Dit artikel gaat niet over het elimineren van stand-ups. Het gaat over vragen of uw ceremonies leveren waarde evenredig met hun kosten. Want in mijn ervaring, **het meest wendbare wat je kunt doen is je wendbare proces aanpassen**. ## Scrum is een sjabloon, geen dogma Laat me duidelijk zijn: **Scrum is briljant als startpunt.** Het gaf teams structuur toen we verdronken in waterval. Als je net begint met Agile, Scrum is ongeveer zo goed als ze komen - het biedt duidelijke ceremonies, gedefinieerde rollen, en een bewezen kader dat werkt voor vele teams. Maar ergens langs de lijn, raakten we in de war. *Scrum volgen* met *beweeglijk zijn*. Scrum is a **toolkit**. Agile is a **mindset**. Hier is het deel waar niemand het over heeft: **Zodra Scrum begint te rafelen, vertragen, of bieden minder waarde dan het kost - dat is wanneer u zich aan te passen**. Dit vereist ervaring, maar het is belangrijk om echte wendbaarheid. Het vermogen om te herkennen wanneer je proces evolutie nodig heeft is wat volwassen wendbare teams scheidt van die cargo-culting ceremonies. En hier is de ongemakkelijke waarheid: Scrum Masters krijgen alleen betaald als je Scrum blijft gebruiken. Dus neem hun advies aan, maar onthoud dat hun prikkels niet perfect zijn afgestemd op "gebruik wat het beste werkt." [Het Agile Manifest](https://agilemanifesto.org/) nooit gemandateerd dagelijkse stand-ups. Het waardeerde "individuen en interacties over processen en tools" en benadrukte **"zelforganiserende teams"** Maar ik heb gezien hoe teams 9am-stand-ups over drie tijdzones hebben geforceerd omdat "dat is wat Scrum zegt." Dat is geen wendbaarheid - dat is traditie gekleed als methodologie. Ik heb me gerealiseerd dat veel mensen die "agile" doen het Agile Manifesto nooit hebben gelezen. Het is het basisdocument - geschreven in 2001 door 17 software-ontwikkelaars die moe waren van zwaargewicht, procesgestuurde ontwikkeling. Ze ontmoetten elkaar drie dagen en destilleerden wat eigenlijk werkte in vier waarde verklaringen. Hier is het: > **Het Agile Manifest** > > *We ontdekken betere manieren om software te ontwikkelen door het te doen en anderen te helpen het te doen. Door dit werk zijn we tot waarde gekomen:* > > - **Personen en interacties** over processen en tools > - **Werksoftware** meer uitgebreide documentatie > - **Samenwerking met de klant** over contractonderhandelingen > - **Reageren op verandering** Over het volgen van een plan > > *Dat wil zeggen, terwijl er waarde in de items aan de rechterkant, we waarderen de items aan de linkerkant meer.* Let op wat er NIET in zit: dagelijkse stand-ups, sprint planning, verhaalpunten, retrospectieven. Die kwamen van Scrum, die werd gemaakt om deze waarden te implementeren. Maar ergens langs de weg, begonnen we de implementatie van Scrum te behandelen als het doel in plaats van de waarden zelf. Het Manifest gaat over **beginselen**"Individuen en interacties over processen en tools" betekent dat als je proces (stand-ups) in de weg staat van interacties (werkelijke samenwerking), je het achterstevoren doet. **Zelforganiserende teams hebben geen ceremonies nodig die aan hen worden opgelegd. Ze kiezen de praktijken die werken.** ```mermaid graph TD A[Agile Manifesto] -->|Inspires| B[Scrum Framework] B -->|Provides| C[Ceremonies & Practices] C -->|Should be| D{Adapted to Context} D -->|Teams often skip this| E[Rigid Adherence] D -->|True agility| F[Continuous Optimization] E -->|Results in| G[Process Theatre] F -->|Results in| H[Effective Delivery] style A stroke:#e1f5ff style F stroke:#d4edda style G stroke:#f8d7da style H stroke:#d4edda ``` In mijn ervaring, zijn de teams die het snelst verzenden niet degenen die Scrum volgen volgens het boekje. **hun eigen proces te inspecteren en aan te passen** zo streng als ze inspecteren en hun code aanpassen. ## Standups vaak degraderen in ritueel Laat me een beeld schetsen dat je misschien herkent: Het is 9:00 AM. Je bent diep in het oplossen van een gnarly concurrency bug. Uw IDE is open, debugger bevestigd, mentaal model volledig geladen. Dan - ping - de standup vergadering begint over 2 minuten. Je zet je context om... en wacht tot er drie mensen ontmuteren. - **Alice:** "Hetzelfde als gisteren, werken aan de login functie." - **Bob:** Testen afmaken, geen blokkers. - **Carol:** *(camera uit)* "Ja, nog steeds in die database migratie." Tien minuten later ga je terug naar je code... het mentale model is weg... je brengt nog 15 minuten door met het herstellen van de context. **Wat heeft die bijeenkomst opgeleverd?** In mijn ervaring delen falende stand-ups gemeenschappelijke symptomen: ### De Rituele Decay Checklist - [ ] De meeste updates zijn variaties van "hetzelfde als gisteren" - [ ] Er worden geen besluiten genomen - [ ] Meer dan 50% van de bezoekers heeft camera's uitgeschakeld - [ ] Tijdzone verspreide krachten te laat/vroeger aanwezig - [ ] Mensen multitasken tijdens de bijeenkomst - [ ] Niemand stelt vervolgvragen - [ ] De bijeenkomst had een Slack-bericht kunnen zijn Wanneer deze symptomen verschijnen, uw stand-up is niet het creëren van uitlijning. **gesynchroniseerde vermoeidheid**. ### Het probleem van de aanwezigheid roll Laten we eerlijk zijn: in veel werkplekken is de 9am stand-up een aanwezigheidsrol. Het is een manier om te controleren of mensen "op hun bureau" zijn (of tenminste wakker). Dit is niet wendbaar - het is bewakingstheater. Als je een dagelijkse standup nodig hebt om te weten of je ontwikkelaars werken, heb je een vertrouwensprobleem, geen procesprobleem. **Behandel je ontwikkelaars als professionals.** Beoordeel hen met wat ze leveren, niet met de vraag of ze op tijd naar een vergadering kwamen. ```mermaid graph LR A[Standup Intent] -->|Should produce| B[Alignment] A -->|Should identify| C[Blockers] A -->|Should enable| D[Quick Decisions] E[Ritual Standup] -->|Actually produces| F[Status Updates] E -->|Actually creates| G[Context Switching] E -->|Actually wastes| H[Focus Time] style A stroke:#d4edda style B stroke:#d4edda style C stroke:#d4edda style D stroke:#d4edda style E stroke:#f8d7da style F stroke:#fff3cd style G stroke:#f8d7da style H stroke:#f8d7da ``` ## Alle ceremonie is belasting Hier is het kader dat veranderde hoe ik denk over wendbare praktijken: **Elk ritueel verbruikt hulpbronnen:** - **Tijd** - 15 minuten × 5 ontwikkelaars × 5 dagen = 6,25 uur/week - **Cognitieve energie** - context switching vernietigt diep werk - **Emotionele bandbreedte** - "performatieve aanwezigheid" is vermoeiend - **Focus** - het onderbreken van stroomtoestanden heeft samengestelde kosten In democratische samenlevingen accepteren we belasting. *wanneer zij essentiële diensten financiert*. Wegen, scholen, gezondheidszorg - deze rechtvaardigen de last omdat we in ruil daarvoor waarde krijgen. Agile ceremonies werken op dezelfde manier. ```mermaid graph TD A[Ceremony/Ritual] -->|Consumes| B[Team Resources] B --> C[Time] B --> D[Energy] B --> E[Focus] B --> F[Context] A -->|Must produce| G{Value?} G -->|Yes| H[Justified Tax] G -->|No| I[Process Theatre] H -->|Examples| J[Blocker identified
Alignment achieved
Decision made] I -->|Examples| K[Status updates
Calendar filler
Nobody engaged] style A stroke:#e1f5ff style G stroke:#fff3cd style H stroke:#d4edda style I stroke:#f8d7da ``` ### De belastingvergelijking Voor elke ceremonie om haar bestaan te rechtvaardigen, moet dit waar zijn: **Waarde Bezorgd > Hulpbronnen Geconsumeerd** In mijn ervaring falen stand-ups als teams niet beide kanten van deze vergelijking meten. Ze erven de ceremonie, runnen het voor altijd, en vragen nooit: *"Is dit het nog steeds waard?"* ## Beter, goedkoper, snellere alternatieven Hier is wat ik heb gezien werken over verschillende team contexten: ### Status-updates → Async-check-ins Probeer in plaats van synchrone vergaderingen: **Slack/Teams Thread (Daily)** ``` 👋 Good morning! Quick updates: ✅ Yesterday: Completed auth refactor (#234) 🎯 Today: Tackling payment integration (#456) 🚧 Blockers: Need staging DB access (@alice) ``` **Tijdskosten:** 2 minuten vs. 15 minuten **Impact in de tijdzone:** Nul **Doorzoekbare geschiedenis:** Ja. ### Het effect van de communicatievermenigvuldiger Hier is een sleutel die de meeste teams missen: **Slack check-ins worden DE plek om te communiceren met iedereen die geïnteresseerd is in vooruitgang.** Productmanagers, stakeholders, ontwerpers, andere engineering teams - ze kunnen zich allemaal abonneren op het kanaal en op de hoogte blijven zonder ontwikkelaars te dwingen tot nog een bijeenkomst. **Uw taak is om uw team te bouwen als een functie levering machine. Communicatie is de olie die het draaiende houdt.** Als de CEO vraagt "waar werkt het team aan?" stuur ze dan een link. Wanneer het product een update nodig heeft, worden ze geabonneerd. Wanneer andere teams coördineren, zien ze je vooruitgang in real-time. Dit is communicatie *Versterking*, niet *overhead*. ### Het echt Async maken Hier is hoe dit te laten werken over elke tijdzone: **Het patroon:** "Status updates door 9:00" (uw lokale tijd) - en vertrek **gedetailleerde notities voor elke taak in de Slack-thread**. Niet alleen "werken op auth" maar "Auth refactor: voltooide JWT validatie, starting refresh token flow, blocker: behoefte ontwerp goedkeuring op fouttoestanden." De Australië Dev laat hun notitie wanneer werkt het beste voor hen - misschien aan het eind van hun dag. Om 9 uur UK tijd (of eerder als het dringend is), je leest het en actie het: "Dave, kunt u Joe helpen met de goedkeuring van het ontwerp?" Dan laat je het TEAM regelen hoe het gebeurt. **Zij besturen het proces.** Je bent niet elke interactie aan het orkestreren, je verwijdert blokkers en laat professionals direct coördineren. Dit is het Agile principe van **zelforganiserende teams** in actie. Niet "teams die een voorgeschreven proces volgen," maar teams die rond het werk zelf organiseren. De informatie is transparant, de context wordt gedeeld, en het team zoekt uit hoe het op te lossen. Het detail in de notities betekent dat je geen synchrone verduidelijking nodig hebt. Het team organiseert zichzelf rond de informatie. ### GitHub + Slack = Culture + Status Link GitHub naar uw Slack kanaal. Nu een status-update BEKOMT een PR. Code reviews zijn zichtbaar. U viert wint met emoji. Dat is niet frivole - het is cultuur. ``` 🎉 @alice opened PR #234: Add JWT refresh token flow 💪 @bob approved PR #234: "Beautiful error handling!" 🚀 @alice merged PR #234 into main ✅ Build passed: 47 tests, 0 failures ``` Je stand-up is zojuist je GitHub activiteitsfeed geworden. Zero tax, automatische zichtbaarheid, peer recognition ingebouwd. **Maak de meest kritische plaats voor communicatie een NICE plaats om te zijn.** Als uw team kanaal is waar werk gebeurt, maak het waar mensen willen zijn. Vieren wint. Waardeer goed werk publiekelijk. Bedankt mensen voor het helpen. **Dit is ingenieurscultuur.** Wanneer het belangrijkste communicatiekanaal zich positief voelt, nemen mensen meer aan, vragen eerder om hulp, en delen kennis vrij. Een giftig of saai kanaal? Mensen dempen het. Uw communicatie machine breekt af. ### Wanneer Async mislukt (en hoe het te repareren) Async-first is niet perfect. - **Mensen lezen het kanaal niet.**: Maak het waardevol (GitHub meldingen, beslissingen, wint). - **Geblokkeerd voor 4 uur onopgemerkt**: Clear protocol. Tag met .., @mention, escaleren na 2 uur. Track "blokker response time" als een metriek. - **Spanningen in de tijdzone = 8 uur vertraging**: Identificeer 2-3 uur overlappende venster. Voor wereldwijde teams, accepteren overdracht vertraging, maar document grondig. - **Junioren spreken niet harder.**Maak 'ik zit vast' veilig door vroege vragen te vieren. **De sleutel: async-first betekent niet alleen async.** Als er iets vastzit, spring je op een oproep. Synchronisatie vergaderingen oplossen problemen, niet rapporteren status. **Hetzelfde geldt voor fysieke ruimtes** Als je nog steeds in een kantoor bent en een teamkamer hebt - maak het leuk. Je wilt dat je team daar rondhangt. Goede stoelen. Goede koffie. Whiteboards die echt werken. Natuurlijke licht indien mogelijk. Een ruimte die niet voelt als een straf. Als de teamruimte aangenaam is, komen er natuurlijk mensen aan. Conversaties gebeuren. Problemen worden opgelost aan het whiteboard. Iemand overhoort een blocker en springt erin om te helpen. Dat is organische samenwerking - het soort dat standups proberen (en falen) om te produceren. Dit is wat **zelforganiserende teams** Niet in een cirkel staan en rapporteren aan een Scrum Master... maar professionals die rond het werk organiseren omdat de omgeving het makkelijk maakt. Een deprimerende kamer met kapotte meubels en fluorescerende verlichting? Mensen werken thuis of verbergen zich aan hun bureau. Uw communicatieapparaat blijft gefragmenteerd. **Info Synchronisatievergaderingen:** U kunt nog steeds terugkerende vergaderingen boeken wanneer dat nodig is - u hoeft niet alles te annuleren. De sleutel is intentie. Een wekelijkse 1-op-1? Houdt het. Het behoudt ruimte op agenda's en toont belang. Het verschil is dat deze worden *optionele synchrone discussie* in plaats van *verplichte statusrapportage*. Boek de herhaling, maar maak duidelijk: "Als je deze week niets te bespreken hebt, kun je het overslaan." **Hier is mijn aanpak als senior/leider:** Ik annuleer nooit de 1-op-1. Nooit. Maar ik maak duidelijk dat ze dat kunnen. Het is er voor hen. Dit stuurt een bericht: "Ik heb deze keer voor jou beschermd. Gebruik het als je het nodig hebt. Geen druk als je het niet doet." Sommige weken zullen ze het overslaan omdat ze heads-down en stromen. Andere weken zullen ze gebruiken alle 30 minuten omdat iets hen stoort of ze willen praten door middel van een ontwerp. De terugkerende bijeenkomst maakt **spatie**- Geen verplichting. Dit is vooral nuttig voor: - One-to-ones (reserveer de relatieruimte) - Architectuurdiscussies (complex, voordeel van whiteboarden) - Stakeholderdemo's (emotionele/politieke waarde in live interactie) Het doel is geen nul vergaderingen. **vergaderingen die hun tijd verdienen**. ### Uitlijning → Nauwkeurige borden In mijn ervaring hebben teams die hun kanban boards actueel houden geen stand-ups nodig voor zichtbaarheid. **Signaalrijke boardindicatoren:** - Verhaalpunten met foutbalken (betrouwbaarheidsbereiken) - "Stuck" tags met verouderingsindicatoren - PR-status direct op kaarten - Werkelijke vs. geschatte tijdbepaling Als uw bestuur betrouwbaar is, **Als je ernaar kijkt, moet je antwoorden: "Wat doet iedereen?"** ### Blockers → Issue tagging + Async Pings Echte blokkers hebben onmiddellijke aandacht nodig, geen volgende dag stand-up. **Beter patroon:** 1. Tag probleem met `🚧 blocked` 2. Ping relevante persoon rechtstreeks 3. Indien niet opgelost binnen 2 uur, escaleer dan om te leiden 4. Track blocker resolutie tijd als een metriek ### Team Cohesie → Wekelijkse retro's + paring Het argument dat ik het vaakst hoor: *"Maar stand-ups houden ons verbonden als een team!"* Maar is een dagelijkse status update de beste manier om verbinding te maken? In mijn ervaring, deze creëren *sterker* obligaties: - **Paarsessies** - daadwerkelijke samenwerking - **Wekelijkse retro's** - eerlijke reflectie - **Zwakke waterkoeler kanalen** - async sociale tijd - **Maandelijkse teamlunches** - niet-werkverbinding ```mermaid graph LR A[Team Cohesion Goals] --> B{Choose Method} B -->|Status sharing| C[Async Check-ins
2 min/person] B -->|Problem solving| D[Pairing Sessions
As needed] B -->|Reflection| E[Weekly Retro
1 hour/week] B -->|Social bonding| F[Slack channels
Continuous] G[Daily Standup
15 min × 5 days] -.->|Tries to do all| A style A stroke:#e1f5ff style C stroke:#d4edda style D stroke:#d4edda style E stroke:#d4edda style F stroke:#d4edda style G stroke:#fff3cd ``` ### De Context Matrix Niet alle teams moeten dezelfde ceremonies aannemen. Team Profile Opstand Waarde Beter Alternatief |--------------|---------------|-------------------| | **Ouder, verdeeld, async-first** Laag inchecken Slack + nauwkeurige boards | **Junior-heavy team** Laag Mentratiemodel (zie hieronder) | **Strakke deadline, hoog risico** Afhankelijk van de balans: Zal 15 min vertragen u? Als geen blokkers, waarom melden als je in een haast? Probeer Slack war room + on-demand huddles | **Stabiele functieteam** Zeer Laag Laag Laag Belasting Async updates; schaal tot dagelijks alleen bij het bouwen van complexe multi-persoonsfuncties of kritieke kwesties . | **Open source, wereldwijde tijdzones** Async updates + wekelijkse video-samenvatting > **Afgezien van: De mythe van de Junior Ontwikkelaar** > > Gemeenschappelijke wijsheid: "Juniors hebben dagelijkse stand-ups nodig om te leren." Realiteit: stand-ups vaak **toename van angst** voor junioren zonder hen te helpen groeien. > > **Jouw team zit vol met jouw junioren.** Geen stand-ups. Mentratie doet. Toeschrijven tijd voor senioren om hen te helpen. Maak het cultureel: Leads runnen senioren, senioren runnen Juniors. Juniors kunnen voorbereiden met hun senior voordat updates, maar ze moeten hun eigen stem hebben - een senior nooit spreekt voor hen. > > **Professionele ontwikkeling gebeurt door mentorschap, niet status rapportage.** Standups leren geen schatting, architectuur, of debuggen. Paar doen. Code reviews doen. 1-op-1s doen. In mijn ervaring is het fout om geen stand-ups te hebben of ze niet te hebben. **toepassing van dezelfde ceremonie op elke context**. ## Alles past zich aan aan wat werkt Hier is de waarheid: **Alles past zich aan aan wat het beste werkt voor uw team.** Dit is wat het Agile principe van **zelforganiserende teams** Niet "teams die Scrum perfect volgen," maar **teams die hun proces voortdurend aanpassen om het werk te dienen**. Sommige teams LEVEN VOOR dagelijkse stand-ups - de energie, de verbinding, het snel-vuur probleem oplossen. Sommigen zullen protesteren, zelfs tegen een Slack bericht, de voorkeur geven aan diepe focus met minimale onderbreking. Een echt zelf-organiserende team experimenten, maatregelen, en kiest. Je past je aan om het resultaat te bereiken. ### Wie beslist om het proces te veranderen? Als ik zeg "het team beslist," wie belt er dan eigenlijk? **leads of senior ontwikkelaars** Leiderschap creëert voorwaarden voor verbetering. **Het patroon:** 1. Iemand stelt een experiment voor - "Probeer async check-ins voor 2 weken?" 2. Team bespreekt trade-offs - zorgen, metrics, hoe terug te keren 3. Lead beslist of het wordt uitgevoerd - gebaseerd op buy-in en haalbaarheid 4. Team meet resultaten - blokkeren tijd? tevredenheid? 5. Team besluit om te houden, terug te keren, of te itereren **Transparantie is de sleutel.** Verandering gebaseerd op bewijsmateriaal ("we hebben gegevens dat dit niet werkt"), niet mening ("Ik denk dat dit beter is"). Als je team geen zorgen kan maken over proceswijzigingen, heb je geen zelforganiserend team - je hebt commando-en-controle met betere buzzwords. ### Spikes: De Experimentatie Spier Hier is een patroon waar ik van hou: **spikes**. Als je sprints (of gewoon snelle cyclusfeedback) gebruikt, zijn pieken je experimentele budget. **Houd nota van een "we moeten proberen X tech" discussie.** Als iemand zegt: "Ik vraag me af of Postgres full-text search sneller zou zijn dan Elasticsearch voor dit," schrijf het op. Bespreek het dan niet meteen. **Gebruik spikes als leuke pauzes tijdens zware ontwikkeling.** Werken aan een grote, lange functie die je vermaalt? Plan een spike. "Alice, neem een dag en probeer die React Server Componenten benadering die je noemde. Kijk of het onze hydratatie problemen oplost." **Spikes zijn leuk voor devs.** Ze zijn toestemming om te verkennen, te leren en potentieel te falen. **Volg ze als een team:** - Hoe lang moet deze piek zijn? (2 uur? 1 dag? 3 dagen?) - Wat proberen we te leren? ("Werkt deze aanpak?" niet "Build the whole feature") - Hoe weten we of het gelukt is? ("Kan 10k items renderen zonder vertraging") - **Bevindingen aan het eind presenteren** - Je bent niet alleen gek, je beantwoordt vragen voor het team. Dat laatste punt is kritiek. De piek eindigt met "hier is wat ik geleerd." Kan 10 minuten in Slack, kan 20 minuten op een whiteboard. Het formaat maakt niet uit. Wat er toe doet is **Je draagt bij aan de kennis van het team, niet alleen er uit halen.**. **Dit is vooral belangrijk voor junioren.** Een junior die een piek maakt in caching is niet alleen "leren Redis." Ze worden de teamexpert voor die specifieke use case. Ze onderzochten het, testten het, en nu geven ze les aan het team. "Je zei dat je over caching wilde leren. Hier is een 2-daagse piek: onderzoek Redis vs in-memory caching voor onze API antwoorden. Presenteer je bevindingen aan het team op vrijdag." De junior verbruikt niet alleen kennis van senioren - ze zijn **bijdragen aan het collectieve begrip van het team**Zo bouw je vertrouwen op, zo voelen junioren zich niet meer als bedriegers. ### Spikes betalen voor zichzelf Hier is het economische argument voor pieken: het zijn niet alleen leeroefeningen - het zijn beslissingsversnellers. **Pad 1: Adoptie** Volgende dev cyclus, kunt u die tech gebruiken. U levert meer waarde als gevolg van de piek. Het betaalde voor zichzelf. Alice bracht een dag spiking React Server Componenten? Twee weken later, het team schepen een functie met 80% minder client-side JavaScript. Die eendaagse investering bespaarde dagen van het debuggen hydratatie problemen. **Pad 2: Eliminatie** Of je elimineert een keuze, waardoor spec'ing waardevoller door het verminderen van paden. "We hebben geprobeerd GraphQL federatie en het is veel te complex voor onze teamgrootte. Nu weten we: vasthouden met REST voor de komende 6 maanden." Dat is geen mislukte piek - dat is een **Succesvol besluit**. Je stopte met tijd te verspillen met je af te vragen "moeten we GraphQL gebruiken?" Het antwoord is nee, ondersteund door bewijs. Beide uitkomsten hebben waarde. Of je krijgt een tool of je elimineert afleiding. Het ergste resultaat is nooit pieken - gewoon eindeloos debatteren "moeten we proberen X?" zonder gegevens. **Zelfs proces krijgt pieken.** U kunt een "proces eigenaar" in het team en gebruik proces spikes. "Laten we proberen async check-ins voor 2 weken. Dat is een proces spike. We meten blocker response time en zien wat er gebeurt." **Het principe: verandering wordt gedreven door experimenten.** Het is gezond voor een team om te spelen met technologie. Het is gezond om te spelen met proces. Het alternatief is stagnatie - dezelfde tools, dezelfde ceremonies, dezelfde frustraties voor jaren. Spikes normaliseren experimenten. Ze maken het veilig om te zeggen "Ik weet niet of dit zal werken" en probeer het toch. Vraag jezelf af: **Wat moet de output van het team zijn?** 1. **Statusupdates** (bijgewerkt ten minste dagelijks) - zodat stakeholders weten wat er gebeurt 2. **Invoer om van richting te veranderen** (echt core to agile) - maar standups zijn daar toch niet ECHT voor; dat is een apart async proces door achterstand verfijning, retro's en feedback van belanghebbenden De *beste resultaat* Ik heb gehad met de async zelforganiserende Slack aanpak. Je identificeert wat "offline" moet worden genomen (in een aparte vergadering van stakeholders) of wanneer je een teamvergadering nodig hebt om iets complexs te bespreken. ### Onthoud: Het product is de uitvoer Totdat er een functie is om mee te spelen, **het product van uw proces is de output van uw ontwikkelmachine**Dat is wat er toe doet. Als uw bedrijf behoefte heeft aan lopende voortgangsupdates, denk dan na over hoe u dat als CHEAPLY (in fiscale termen) mogelijk kunt leveren: **Creatieve alternatieven:** - Script dat kijkt naar JIRA tickets voor verhaalpunten voltooid - LLM-gestuurde schatter op basis van historische taaksnelheid - Geautomatiseerde wekelijkse samenvatting van Git commits + PR beschrijvingen - Dashboard trekken van CI/CD-pijpleidingstatus - Slack bot dat oppervlakken blokkers automatisch van ticket tags Er zijn OPTIES die goedkoper zijn dan het dwingen van mensen om elke dag handmatig vooruitgang te melden. Het doel is niet om communicatie te elimineren. **automatiseer de mechanische onderdelen zodat mensen zich kunnen concentreren op de waardevolle onderdelen** - de beslissingen, de samenwerking, de creatieve oplossing van problemen. ## Meten van rituelen zoals systemen Als je een ontwikkelaar bent, houd je je systemen in de gaten. Je volgt latency, foutpercentages, resource use. Je stelt SLO's in en onderzoekt wanneer ze degraderen. **Waarom doen we dit niet voor onze processen?** ### Communicatie Metrics die er eigenlijk toe doen Voordat je ceremonies kunt meten, meet de **communicatie zelf**Hier zijn de statistieken die ik heb getraceerd die echte problemen aan het licht brachten: **Reactietijd voor blokkers** - Gemiddelde tijd van "geblokkeerde" tag naar resolutie - Doel: < 2 uur tijdens de overlap van de teamuren - Als je constant langer dan 4 uur bent, werken je communicatiekanalen niet. **Time-to-PR-Review** - Hoe lang duurt het voordat PR open is voor de eerste beoordeling? - Doel: < 4 uur voor kleine PR's, < 24 uur voor grote PR's - Als beoordelingen zitten voor dagen, ofwel mensen niet controleren Slack of je hebt te veel WIP **Responspercentage van de vragen** - Wanneer iemand om hulp vraagt in het teamkanaal, hoe vaak krijgen ze dan een reactie binnen 1 uur? - Streefcijfer: > 80% tijdens overlapuren - Als het laag is, werkt je kanaal niet als communicatie-hub. **Dempfrequentie** - Niet alleen een DevOps metriek - het is een communicatie metriek - Als je dagelijks inzet, werkt de coördinatie. - Als implementaties cluster op donderdag, uw proces heeft knelpunten **Slack Channel Engagement** - Niet alleen "wie postte" maar "wie reageerde op anderen" - Hebben 3 mensen alle communicatielast bij zich? - Ligt de helft van het team op de loer? **Het patroon:** Als deze statistieken gezond zijn, werkt je communicatie-infrastructuur. **Geen ceremonie zal het oplossen.**. U moet het onderliggende probleem (onduidelijke eigendom, lage psychologische veiligheid, gereedschap wrijving, enz.) aanpakken. ### Gezondheidscontrole van de ceremonie Vraag uw team elk kwartaal: 1. **Welk probleem lost deze ceremonie op?** - Als niemand het duidelijk kan verwoorden, dood het dan. 2. **Welk bewijs laat zien dat het werkt?** - "We hebben het altijd gedaan" is geen bewijs. 3. **Is er een snellere manier?** - Kan async werken? Kan automatisering helpen? 4. **Wat gebeurt er als we het overslaan?** - Doe het experiment, pauzeer 2 weken, meet de impact. 5. **Hebben we alternatieven getest?** - Als je dezelfde ceremonie al jaren onveranderd leidt, ben je niet behendig. ### Praktisch voorbeeld: Mijn laatste team We hadden dagelijks stand-ups voor 18 maanden. Toen stelde ik een experiment voor: **Hypothese:** Ons volwassen team kan blijven uitlijnen met 3x wekelijkse check-ins + async updates. **Metrics:** - Blocker-resolutietijd - Sprint doel bereikt percentage - Teamtevredenheid (anonieme enquête) - Gemiddelde PR-leeftijd **Resultaat na 4 weken:** - Blokkertijd: **ongewijzigd** (We gebruikten Slack tags) - Sprintdoelen: **+1 verbetering** (meer focustijd) - Tevredenheid: **+ 15% stijging** (minder vergaderingsmoeheid) - PR leeftijd: **-8 uur gemiddeld** (meer beoordelingstijd) Niet omdat stand-ups slecht zijn, maar omdat... **Onze context rechtvaardigt de belasting niet.**. ```mermaid graph TD A[Current Ceremony] -->|Define| B[Success Metrics] B -->|Propose| C[Alternative Approach] C -->|Run| D[Time-boxed Experiment] D -->|Measure| E{Better Results?} E -->|Yes| F[Adopt New Approach] E -->|No| G[Keep Original] E -->|Mixed| H[Iterate & Re-test] F --> I[Document & Share] G --> J[Schedule Next Review] H --> C style A stroke:#e1f5ff style D stroke:#fff3cd style F stroke:#d4edda style I stroke:#d4edda ``` ## Team Maturity & Context Matter Ik wil duidelijk zijn: **Ik zeg niet dat je overal stand-ups moet elimineren.**. Sommige contexten profiteren echt van de dagelijkse synchronisatie: ### Wanneer stand-ups Verdienen van hun belasting In mijn ervaring leveren dagelijkse standups waarde voor: **Nieuw gevormde teams** - Leden kennen elkaars werkstijlen niet. - Impliciete kennis is nog niet opgebouwd. - Noodzaak van expliciete coördinatie tijdens de vaststelling van normen **Junior-Heavy Teams** - Leren schatten en plannen - Profiteer van de dagelijkse mentorschap raakpunten - Het opbouwen van professionele communicatievaardigheden **High-Pressure Release Windows** - Coördinatie van complexe inzetafhankelijkheden - Snelle identificatie van de blokker is cruciaal - Psychologische veiligheid in gedeelde stress **Cross-Functional Discovery** - Product, ontwerp en engineering samen verkennen - Snelle iteratie op prototypes - Strakke terugkoppelingslussen essentieel **Het belangrijkste beginsel:** Wanneer de context van uw team verandert, moeten uw ceremonies ook. Ik heb gewerkt met teams die stand-ups deden tijdens een 6 weken durende productlancering, en daarna overgeschakeld op async. **Dat is aanpassing.**. ## Hoe ziet het er goed uit? Laat me delen hoe effectieve ceremonie eruit ziet, als het werkt: ### Voorbeeld: de 7-minute standup Een van de beste teams waar ik mee heb gewerkt: **Formaat:** 1. Iedereen post update in Slack *voor* Vergadering 2. Ontmoeting begint: "Iedere blokkers of beslissingen nodig?" 3. Adresseer alleen die items 4. Als er niets dringends is: "Geweldig, vergadering geannuleerd, weer aan het werk" **Gemiddelde duur:** 7 minuten **Geannuleerde vergaderingen:** ~40% van de tijd **Waarde:** Hoge bandbreedte probleemoplossing, nul status theater ### Voorbeeld: De Async Video Update Voor een verdeeld team over 9 tijdzones: **Patroon:** - Elke persoon neemt 60 seconden Loom video op aan het einde van de dag - Berichten naar gedeelde Slack-thread - Anderen kijken naar async en antwoorden met opmerkingen / aanbiedingen van hulp - Wekelijkse vergadering alleen synchroniseren voor complexe discussies **Tijdskosten:** 60 seconden opname + 3 minuten kijken **Problemen met de tijdzone:** Geëlimineerd **Verbinding:** Hoger (zie gezichten, gehoortoon) ### Voorbeeld: Het vertrouwensdashboard In plaats van te vragen "Ben je op de rails?" bouwde een team een eenvoudig dashboard: Taak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |------|----------|-----------|-------------| Auth refactor 5 punten 2 uur geleden API betalen 8 punten 60% 5 uur geleden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . De migratie van de DB 3 punten, 30%, 1 dag geleden Vertrouwen van minder dan 70% leidde tot automatische "Hulp nodig?" Slack bericht. **Resultaat:** Blockers kwamen proactief boven, geen vergadering nodig. ## De echte geest van Agile Dit is wat me stoort aan de stand-up orthodoxie: Het Agile Manifesto zegt **"reageren op verandering over het volgen van een plan."** Toch verzetten we ons tegen het veranderen van onze ceremonies. We erven stand-ups van Scrum, en we blijven ze controleren zelfs als het bewijs suggereert dat ze niet werken. Dat is geen wendbaarheid. **traditie**. In mijn ervaring stellen echt wendbare teams moeilijke vragen: - "Deze ceremonie werkte vorig jaar. Is het nog steeds?" - "We zijn nu verdeeld. Moeten onze sync patronen veranderen?" - "Ons team is verdrievoudigd. Heeft dezelfde structuur schaal?" - "We hebben net het grote project verstuurd. Wat optimaliseren we nu?" ```mermaid graph TD A[Agile Mindset] -->|Requires| B[Continuous Improvement] B -->|Applied to| C[Product] B -->|Applied to| D[Code] B -->|Should apply to| E[Process] E -->|Questions| F{Is this ceremony
still valuable?} d apply to| E[Process] E -->|Questions| F{Is this ceremony
still valuable?} F -->|Yes + Evidence| G[Keep & Measure] F -->|No + Evidence| H[Change or Remove] F -->|Unsure| I[Run Experiment] G --> J[Schedule Next Review] H --> J I --> F style A stroke:#e1f5ff style E stroke:#fff3cd style G stroke:#d4edda style H stroke:#d4edda style I stroke:#d4edda ``` ## Conclusie: de ceremonie moet zijn last verdienen Laat me dit mee naar huis nemen met een simpel principe: > **Een ceremonie is niet wendbaar omdat het een naam heeft in de Scrum Guide. > Het is alleen wendbaar als het zijn last verdient.** Standups zijn geen onzin. **Verplichte, onbeantwoorde, contextvrije stand-ups zijn.** In mijn ervaring behandelen de beste teams ceremonies als code: - Zij **refactor** wanneer patronen tevoorschijn komen - Zij **optimaliseren** wanneer de prestaties lijden - Zij **verwijderen** wanneer niet langer nodig - Zij **testalternatieven** alvorens te committen - Zij **maatregel** om te weten wat werkt Dit is **zelforganiserende teams in de praktijk**. Geen teams die een voorgeschreven proces perfect volgen. Maar teams die voortdurend hun eigen manier van werken inspecteren en aanpassen. Agile gaat niet over het beschermen van rituelen. **het beschermen van de duidelijkheid, de stroom en de levering**. Als een 2-minuten Slack check-in bereikt wat een 15-minuten stand-up gebruikt om te verschepen en uw team schepen sneller, voelt minder vermoeidheid, en onderhoudt uitlijning **dat is behendigheid in actie**. Dus dit is mijn uitdaging voor jou: **Deze week, vraag je team:** 1. Wat zouden we verliezen als we een week lang stand-ups oversloegen? 2. Wat zouden we winnen? 3. Zijn we bereid om het te testen? Je zou kunnen ontdekken dat de stand-up is essentieel. Geweldig nu heb je bewijs, niet aanname. Of je zou kunnen ontdekken dat het is belasting zonder voordeel voor maanden. Ook geweldig nu kunt u optimaliseren. Hoe dan ook, je doet het meest wendbare ding dat mogelijk is: **aanpassen op basis van de realiteit, niet ritueel**. --- ## Referenties & Verdere lezing - [Agile Manifest](https://agilemanifesto.org/) De oorspronkelijke principes - [Draai het schip om!](https://davidmarquet.com/) door L. David Marquet Intent-based leiderschap vermindert ceremonie behoeften - [Team Topologieën](https://teamtopologies.com/) Hoe teamstructuur de communicatiebehoeften beïnvloedt - [Remote: Kantoor niet vereist](https://basecamp.com/books/remote) Async-eerste denken uit Basecamp --- *Heb je geëxperimenteerd met alternatieven voor dagelijkse standups? Ik zou graag horen wat werkte (of niet) voor uw team. [Neem contact op.](/contact) of laat hieronder een reactie achter.*