Dagliga standups är inte i sig dåligt - men när de blir ritual istället för anpassning, de slösar tid och skador förtroende. Denna artikel undersöker varför ceremoni är skatt, hur man mäter dess värde, och praktiska async-första alternativ som håller teamen i linje utan att bränna energi eller tid. Agile är anpassning - inte följsamhet.
Under mina nästan 30 år av mjukvaruutveckling, Jag har deltagit mer dagliga standups än jag bryr mig om att räkna. Några var elektriska - korta stunder av anpassning som rensade blockerare och skickade oss sprinting framåt. Andra var performativa ritualer där trötta utvecklare reciterade "samma som igår" till ett galleri av muterade kameror.
Skillnaden? En typ av standup Intjänade sin skattDen andra var bara en ceremoni.
Jag måste erkänna: Jag är en inbiten agilist. Jag blev på det sättet genom att uppleva WORST av PRINCEs, Waterfalls, och tunghänt processramar. Jag har levt igenom "omfattande dokumentation innan en enda rad kod" eran. Jag har suttit i Change Control Board möten där distribuera en line fix krävs tre veckors godkännande pappersarbete.
Det enkla är: Agile är det bästa sättet att bygga bra programvara. För att parafrasera Churchill:
"Det har faktiskt sagts att Agile är den värsta formen av mjukvaruutvecklingsprocess - utom för alla de andra former som har prövats då och då."
Men så här är det: Att vara pro-Agil betyder inte att vara pro-rituell. – Att försvara obestridda ceremonier är faktiskt motsatta av smidighet.
Så här har jag lärt mig: agil handlar om anpassning, inte följsamhet. Ändå de flesta lag ärver Scrum ritualer grossist, behandlar dem som heliga snarare än pragmatiska. Dagliga standups, sprint planering, retrospektiva - dessa är verktyg, inte bud. Och som alla verktyg, de bör utvärderas av om de arbete.
Den här artikeln handlar inte om att eliminera ståuppar, utan om att ifrågasätta om era ceremonier ger ett värde som står i proportion till deras kostnad. Det mest smidiga du kan göra är att anpassa din smidiga process.
Låt mig vara tydlig: Scrum är lysande som utgångspunkt. Det gav team struktur när vi drunknade i vattenfall. Om du precis börjar med Agile, Scrum är ungefär så bra som de kommer - det ger tydliga ceremonier, definierade roller, och en beprövad ram som fungerar för många lag.
Men någonstans längs vägen, vi förvirrade Efter Scrum där att vara smidig.
Scrum är en Verktygslåda. Agile är en Tankesätt.
Här är delen som ingen pratar om: när Scrum börjar fray, sakta ner dig, eller erbjuda mindre värde än det kostar - det är då du anpassar. Detta tar erfarenhet, men det är NYCKEL till sann smidighet. Förmågan att känna igen när din process behöver evolution är vad separerar mogna smidiga team från dessa last-kulting ceremonier.
Och här är den obekväma sanningen: Scrum Masters får bara betalt så länge du fortsätter att använda Scrum. Så ta deras råd, men kom ihåg att deras incitament inte är perfekt i linje med "använd vad som fungerar bäst."
Det agila manifestet aldrig beordrade dagliga standups. Det värderade "individer och interaktioner över processer och verktyg" och betonade "Självorganiserande team" Ändå har jag sett lag tvinga fram 9am-ståndpunkter över tre tidszoner eftersom "det är vad Scrum säger." Det är inte agility - det är tradition klädd som metodik.
Jag har insett att många människor som gör "agile" har aldrig riktigt läst Agile Manifesto. Det är det grundläggande dokumentet - skrivet 2001 av 17 mjukvaruutvecklare som var trötta på tungvikt, processdriven utveckling. De träffades i tre dagar och destillerade vad som faktiskt fungerade i fyra värdeförklaringar.
Här är det:
Det agila manifestet
Vi avslöjar bättre sätt att utveckla programvara genom att göra det och hjälpa andra att göra det. Genom detta arbete har vi kommit att värdesätta:
- Individer och interaktioner över processer och verktyg
- Programvara för arbete över omfattande dokumentation
- Kundsamarbete över avtalsförhandlingar
- Att reagera på förändringar över att följa en plan
Det vill säga, även om det finns värde i objekten till höger, vi värderar objekten till vänster mer.
Lägg märke till vad som INTE finns där inne: dagliga standups, sprintplanering, sagopoäng, retrospektiv. De kom från Scrum, som skapades för att implementera dessa värden. Men någonstans längs vägen började vi behandla Scrums implementering som målet istället för själva värderingarna.
Manifestet handlar om Principer, inte recept. "Individuella och interaktioner över processer och verktyg" betyder om din process (standups) kommer i vägen för interaktioner (faktiskt samarbete), du gör det bakåt.
Självorganiserande team behöver inte ceremonier påtvingas dem. De väljer de metoder som fungerar.
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
Enligt min erfarenhet är det inte de som följer Scrum som är snabbast. inspektera och anpassa sin egen process lika rigoröst som de inspekterar och anpassar sin kod.
Låt mig måla en bild du kanske känner igen:
Klockan är 09:00. Du är djupt inne i att lösa en gnarly konvergens bugg. Din IDE är öppen, avlusare ansluten, mental modell fullt laddad. Sedan - ping - standup mötet börjar om 2 minuter.
Du kopplar ihop dig med samtalet, vänta tills tre personer säger upp sig.
Tio minuter senare återgår du till din kod, den mentala modellen är borta.
Vad uppnådde detta möte?
Enligt min erfarenhet, misslyckade standups har vanliga symtom:
När dessa symptom visas, din standup skapar inte anpassning. synkroniserad trötthet.
Låt oss vara ärliga: på många arbetsplatser, 9am standup är en närvaro roll. Det är ett sätt att verifiera människor är "vid sina skrivbord" (eller åtminstone vaken). Detta är inte agilt - det är övervakning teater.
Om du behöver en daglig standup för att veta om dina utvecklare arbetar, du har ett förtroende problem, inte ett processproblem. Behandla dina utvecklare som proffs. Döm dem efter vad de levererar, inte efter om de kom till ett möte i tid.
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
Här är ramverket som förändrade hur jag tänker om smidiga metoder:
Varje ritual förbrukar resurser:
I demokratiska samhällen accepterar vi beskattning När den finansierar viktiga tjänster. – Vägar, skolor, sjukvård - dessa rättfärdigar bördan eftersom vi får värde i gengäld.
Agile ceremonier fungerar på samma sätt.
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<br/>Alignment achieved<br/>Decision made]
I -->|Examples| K[Status updates<br/>Calendar filler<br/>Nobody engaged]
style A stroke:#e1f5ff
style G stroke:#fff3cd
style H stroke:#d4edda
style I stroke:#f8d7da
För att en ceremoni ska kunna rättfärdiga sin existens måste detta vara sant:
Värde levererat > Fullbordade resurser
Enligt min erfarenhet misslyckas standups när lag inte mäter båda sidor av denna ekvation. De ärver ceremonin, kör den för alltid, och aldrig frågar: "Är det fortfarande värt det?"
Här är vad jag har sett arbeta i olika team sammanhang:
Försök i stället för synkrona möten:
Tråd för spår-/tröghet (dagligen)
👋 Good morning! Quick updates:
✅ Yesterday: Completed auth refactor (#234)
🎯 Today: Tackling payment integration (#456)
🚧 Blockers: Need staging DB access (@alice)
Tidskostnad: 2 minuter jämfört med 15 minuter Tidszonspåverkan: Noll Sökbar historik: Ja, det är jag.
Här är en KEY BENEFIT de flesta lag missar: Slack check-ins blir platsen för att kommunicera med alla som är intresserade av framsteg. Produktchefer, intressenter, designers, andra teknikteam - de kan alla prenumerera på kanalen och hålla sig informerade utan att tvinga utvecklare in ännu ett möte.
Ditt jobb är att bygga ditt team som en funktion leverans maskin. Kommunikation är den olja som håller den igång.
När VD frågar "vad arbetar teamet med?", skicka dem en länk. När produkten behöver en uppdatering, de prenumererar. När andra team samordnar, de ser dina framsteg i realtid. Detta är kommunikation Förstärkning, inte överliggande.
Så här får det här att fungera över alla tidzoner:
Mönstret: "Statusuppdateringar kl 9" (din lokala tid) - och lämna detaljerade anteckningar för varje uppgift i tråden Slack. Inte bara "arbeta på auth" utan "Auth refactor: klar JWT-validering, starta uppdatera tokenflöde, blocker: behöver konstruktion godkännande på feltillstånd."
Australien dev lämnar sin not när det fungerar bäst för dem - kanske i slutet av sin dag. Vid 9am UK tid (eller innan om brådskande), du läser det och vidta det: "Dave, kan du hjälpa Joe med designgodkännandet?" Då låter du TEAM ordna hur det händer.
De driver processen. Du tar bort blockerare och låter proffs koordinera direkt.
Detta är den agila principen av Självorganiserande team Inte "team som följer en föreskriven process", utan team som organiserar sig kring själva arbetet. Informationen är transparent, sammanhanget delas och teamet räknar ut hur man löser det.
Nu har du gjort din process riktigt async. Detaljerna i anteckningarna innebär att du inte behöver synkront klargörande. Teamet själv-organiserar runt informationen.
Länk GitHub till din Slack kanal. Nu en statusuppdatering BECOMER en PR. Kod recensioner är synliga. Du firar vinster med emoji. Det är inte lättvindigt - det är kultur.
🎉 @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
Din standup blev precis din GitHub aktivitet feed. Noll skatt, automatisk synlighet, kamratigenkänning inbyggd.
Gör den mest kritiska platsen för kommunikation en NICE plats att vara. Om ditt team kanal är där arbete händer, gör det någonstans människor vill vara. Fira vinner. Uppskatta bra arbete offentligt. Tack människor för att hjälpa.
Det här är ingenjörskultur. När den huvudsakliga kommunikationskanalen känns positiv, människor engagerar sig mer, be om hjälp tidigare, och dela kunskap fritt. En giftig eller tråkig kanal? Människor dämpar det. Din kommunikationsmaskin bryts ner.
Async-först är inte perfekt.
Nyckeln: async-first betyder inte bara async. När något är fast, hoppa på ett samtal. Synka möten lösa problem, inte rapportera status.
Samma sak gäller fysiska utrymmen
Om du fortfarande är på ett kontor och har ett teamrum, gör det snyggt.
Fina stolar, anständigt kaffe, whiteboards som faktiskt fungerar, naturligt ljus om möjligt, ett utrymme som inte känns som ett straff.
När lagrummet är trevligt, människor naturligt gravitera där. Samtal händer. Problem löses vid whiteboard. Någon hör en blockerare och hoppar in för att hjälpa. Det är organiskt samarbete - den typ som standups försöker (och misslyckas) att tillverka.
Detta är vad Självorganiserande team Det ser faktiskt ut som att inte stå i en cirkel och rapportera till en Scrum Master. Men proffs som organiserar sig runt arbetet eftersom miljön gör det enkelt.
Ett deprimerande rum med trasiga möbler och fluorescerande belysning? Människor arbetar hemifrån eller gömmer sig vid sina skrivbord. Din kommunikationsmaskin förblir fragmenterad.
Om Synkroniseringsmöten: Du kan fortfarande boka återkommande möten när det behövs - du behöver inte avboka allt. Nyckeln är avsiktlighet. En veckovis 1-on-1? Behåll det. Det bevarar utrymme på kalendrar och visar betydelse. Skillnaden är att dessa blir Frivillig synkron diskussion snarare än Obligatorisk statusrapportering.
Boka upprepningen, men gör klart: "Om du inte har något att diskutera denna vecka, kan du hoppa över det."
Här är min strategi som senior/ledare: Det här skickar ett meddelande: "Jag har skyddat dig den här gången. Använd det om du behöver det. Ingen press om du inte."
Några veckor de kommer att hoppa över det eftersom de är heads-down och flödar. Andra veckor de kommer att använda alla 30 minuter eftersom något stör dem eller de vill prata genom en design.
Det återkommande mötet skapar utrymme. Ingen skyldighet.
Detta är särskilt användbart för:
Målet är inte noll möten. möten som förtjänar sin tid.
Enligt min erfarenhet, lag som håller sina kanban styrelser ström behöver inte standups för synlighet.
Signalrika brädindikatorer:
Om din styrelse är pålitlig, Titta på det borde svara "Vad gör alla?"
Riktiga blockerare behöver omedelbar uppmärksamhet, inte ett nästa dags standup.
Bättre mönster:
🚧 blockedArgumentet jag hör oftast: "Men ståuppar håller oss anslutna som ett team!"
Men är en daglig statusuppdatering det bästa sättet att bygga anslutning?
Enligt min erfarenhet, dessa skapar starkare Obligationer:
graph LR
A[Team Cohesion Goals] --> B{Choose Method}
B -->|Status sharing| C[Async Check-ins<br/>2 min/person]
B -->|Problem solving| D[Pairing Sessions<br/>As needed]
B -->|Reflection| E[Weekly Retro<br/>1 hour/week]
B -->|Social bonding| F[Slack channels<br/>Continuous]
G[Daily Standup<br/>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
Alla team borde inte anta samma ceremonier.
på teamprofilen på standup-värde och bättre alternativ |--------------|---------------|-------------------| | Mogna, distribuerade, async-först Slack kontroller + noggranna brädor | Junior-tungt team på låg höjd mentorskapsmodell (se nedan) | Tät deadline, hög risk Om du inte har några blockerare, varför rapportera när du har bråttom? Prova Slack War Room + on-demand huddles | Stabilt funktionsteam till dags dato endast när du bygger komplexa multi-person-funktioner eller kritiska frågor | Öppen källkod, globala tidzoner med mycket låga Async-uppdateringar + veckovisa videosammanfattningar
Bortsett från: Junior Utvecklarmyt
Vanlig visdom: "Juniors behöver dagliga standups för att lära." Verklighet: standups ofta ökad ångest för juniorer utan att faktiskt hjälpa dem att växa.
Din grupp höjer dina domare. Inte standups. Mentorship gör det. Anvisa tid för seniorer att hjälpa dem. Gör det kulturellt: Leads run Seniors, Seniors run Juniors. Juniors kan förbereda med sin senior före uppdateringar, men de måste ha sin egen röst - en senior talar aldrig FÖR dem.
Professionell utveckling sker genom mentorskap, inte statusrapportering. Standups lär inte ut uppskattning, arkitektur, eller felsökning. Parning gör. Kodrecensioner gör. 1-on-1s gör.
Enligt min erfarenhet, misstaget är att inte ha ståuppar eller inte ha dem. tillämpa samma ceremoni i varje sammanhang.
Här är sanningen: ALLTING anpassar sig till det som fungerar bäst för ditt team.
Detta är vad Agile principen om Självorganiserande team Inte "lag som följer Scrum perfekt", utan "lag som följer Scrum perfekt". team som kontinuerligt anpassar sin process för att tjäna arbetet.
Vissa team LIVE FÖR dagliga standups - energin, anslutningen, snabb-brand problemlösning. Vissa kommer att protestera även på en Slack meddelande, föredrar djupt fokus med minimalt avbrott.
En verkligt självorganiserande team experiment, åtgärder, och väljer. Du anpassar dig för att uppnå resultatet.
När jag säger "teamet bestämmer", vem ringer då? leads eller senior utvecklare Föreslå förändringar. Det är bra. Ledarskap skapar förutsättningar för förbättring.
Mönstret:
Öppenhet är nyckeln. Förändring baserad på bevis ("vi har data som detta inte fungerar"), inte åsikt ("Jag tycker att detta är bättre").
Om ditt team inte kan uttrycka oro över processförändringar, du har inte ett självorganiserande team - du har kommando-och-kontroll med bättre buzzwords.
Här är ett mönster jag älskar: Nässpetsar. Om du använder sprints (eller bara snabb cykel återkoppling), spikar är din experiment budget.
Lägg märke till någon "vi bör prova X tech" diskussion. När någon säger "Jag undrar om Postgres fulltextsökning skulle vara snabbare än Elasticsearch för detta", skriv ner det. Inte debattera det rätt då. Fånga det.
Använd spikar som roliga pauser under tung utveckling. Arbeta på en stor, lång funktion som slipar ner dig? Schemalägga en spik. "Alice, ta en dag och prova att React Server Components approach du nämnde. Se om det löser våra fuktproblem."
Spikes är FUN för Devs. De får utforska, lära och kanske misslyckas.
Spåra dem som ett team:
Den sista punkten är kritisk. spetsen slutar med "här är vad jag lärt mig." Kan vara 10 minuter i Slack, kan vara 20 minuter vid en whiteboard. Formatet spelar ingen roll. du bidrar till teamets kunskap, inte bara extrahera från det.
Detta är särskilt viktigt för juniorer. En junior som gör en spik på caching är inte bara "lära Redis." De blir lagets Redis expert för den specifika användningsfall. De forskade det, testade det, och nu de undervisar laget.
"Du nämnde vill lära sig om caching. Här är en 2-dagars spik: undersöka Redis vs in-minne caching för våra API-svar. Presentera dina resultat för laget på fredag."
Nu är junior inte bara konsumera kunskap från seniorer - de är bidra till gruppens kollektiva förståelseDet är så man bygger upp självförtroende, så slutar juniorer att känna sig som bedragare.
Här är det ekonomiska argumentet för spikar: de är inte bara lärande övningar - de är beslut acceleratorer.
Väg 1: Antagande Nästa dev cykel, kan du använda den tech. Du levererar mer värde som ett resultat av spiken. Det betalade för sig själv. Alice tillbringade en dag spika React Server Komponenter? Två veckor senare, laget skickar en funktion med 80% mindre klient sida JavaScript. Att en dag investering sparat dagar av felsökning fuktproblem.
Väg 2: Eliminering Eller så eliminerar du ett val, vilket gör spec'ing mer värdefullt genom att minska vägar. "Vi försökte GraphQL federation och det är alldeles för komplicerat för vårt team storlek. Nu vet vi: hålla med REST för de kommande 6 månaderna." Det är inte en misslyckad spik - det är en lyckat beslut. Du slutade slösa tid undrar "ska vi använda GraphQL?" Svaret är nej, backas upp av bevis.
Båda resultaten har värde. Antingen får du ett verktyg eller du eliminera distraktion. Det värsta resultatet är aldrig spika - bara ändlöst debattera "ska vi prova X?" utan data.
Till och med processen får spikar. Du kan vara en "process ägare" i laget och använda process spikar. "Låt oss prova async check-ins i 2 veckor. Det är en process spik. Vi mäter blockerare svarstid och se vad som händer."
Principen: förändring drivs av experiment. Det är hälsosamt för ett team att leka med teknik. Det är hälsosamt att leka med processen. Alternativet är stagnation - samma verktyg, samma ceremonier, samma frustrationer i åratal.
Spikes normaliserar experiment. De gör det säkert att säga "Jag vet inte om detta kommer att fungera" och prova det ändå.
Fråga dig själv: Vad måste lagets resultat vara?
och bästa resultat Jag har haft är med async självorganiserande Slack strategi. Du identifierar vad som ska "tas offline" (till ett separat möte av intressenter) eller när du behöver ett teammöte för att diskutera något komplext.
Tills det finns en funktion att leka med, produkten av din process är produktionen av din utvecklingsmaskinDet är det viktiga.
Om ditt företag behöver rullande uppdateringar, fundera på hur du kan leverera det som CHEAPLY (i skattetermer) som möjligt:
Kreativa alternativ:
Det finns alternativ som är billigare än att tvinga människor att manuellt rapportera framsteg varje dag.
Målet är inte att eliminera kommunikation. automatisera de mekaniska delarna så att människor kan fokusera på de värdefulla delarna - besluten, samarbetet, den kreativa problemlösningen.
Om du är utvecklare övervakar du dina system. Du spårar latens, felfrekvenser, resursanvändning. Du ställer in SLOs och undersöker när de bryts ned.
Varför gör vi inte det här för våra processer?
Innan du kan mäta ceremonier, mäta kommunikation i sig. Här är mått som jag har spårat som avslöjade verkliga problem:
Svarstid till blockerare
Tid-till-PR-översyn
Svarsfrekvens
Spridningsfrekvens
Slack Channel- förlovning
Mönstret: Om dessa mätvärden är sunda, så fungerar din kommunikationsinfrastruktur. ingen ceremoni kommer att fixa det. Du måste ta itu med det underliggande problemet (otydligt ägande, låg psykologisk säkerhet, verktygsfriktion etc.).
Fråga ditt team varje kvartal:
Vad är det för problem med att lösa denna ceremoni?
Vilka bevis visar att den fungerar?
Finns det ett snabbare sätt?
Vad händer om vi hoppar över det?
Har vi testat alternativ?
Vi hade dagliga standups i 18 månader, sen föreslog jag ett experiment:
Hypotes: Vårt mogna team kan upprätthålla anpassningen med 3x veckovisa incheckningar + async-uppdateringar.
Detektorer:
Resultat efter 4 veckor:
Inte för att ståuppar är dåliga, utan för att vi gjorde det permanent. vårt sammanhang inte rättfärdigade skatten.
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
Jag vill vara kristallklar: Jag säger inte att eliminera ståuppar överallt.
Vissa sammanhang drar verkligen nytta av daglig synkronisering:
Enligt min erfarenhet levererar dagliga standups värde för:
Nybildade grupper
Juniortunga grupper
Högtrycksrelease Windows
Gränsöverskridande upptäckt
Huvudprincipen: När ditt teams sammanhang förändras, bör dina ceremonier också göra det.
Jag har jobbat med team som gjorde standups under en 6-veckors produktlansering, sedan bytte till async efteråt. Det är anpassning..
Låt mig dela med mig av hur effektiv ceremonin ser ut, när den fungerar:
Ett av de bästa lag jag jobbat med körde standups så här:
Format:
Genomsnittlig varaktighet: 7 minuter Möten som ställts in: 40 % av tiden Värde: Högbandsbredd problemlösning, noll status teater
För ett distribuerat team över 9 tidszoner:
Mönster:
Tidskostnad: 60 sekunder inspelning + 3 minuter titta Tidszonsfrågor: Eliminerad Anslutning: Högre (seende ansikten, hörselton)
Istället för att fråga "är du på rätt spår?", byggde ett team en enkel instrumentpanel:
på uppgift på uppskattning på förtroende på senaste uppdateringen på |------|----------|-----------|-------------| på Auth refaktor 5 poäng på 90 % för 2 timmar sedan Betalnings API 8 poäng på 60 % för 5 timmar sedan på DB migrering 3 poäng på 30 % 1 dag sedan
Förtroende under 70% utlöste automatisk "behövlig hjälp?" Slack meddelande.
Resultat: Blockerare dök upp proaktivt, inget möte behövs.
Här är vad som bekymrar mig om standup ortodoxi:
Agile Manifestet säger "motsvarar förändring efter en plan."
Vi ärvde standups från Scrum och fortsätter driva dem även när bevis tyder på att de inte fungerar.
Det är inte agility. tradition.
Enligt min erfarenhet ställer verkligt smidiga team svåra frågor:
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<br/>still valuable?}
d apply to| E[Process]
E -->|Questions| F{Is this ceremony<br/>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
Låt mig ta med detta hem med en enkel princip:
En ceremoni är inte smidig eftersom den har ett namn i Scrum Guide. Den är smidig bara när den tjänar sin börda.
Standups är inget skitsnack. Obligatoriska, obestridda, kontextfria standups är.
Enligt min erfarenhet behandlar de bästa lagen ceremonier som kod:
Det här är Självorganiserande team i praktiken. Inte lag som följer en föreskriven process perfekt. Men lag som kontinuerligt inspekterar och anpassar sitt eget sätt att arbeta.
Agile handlar inte om att skydda ritualer. skydda tydlighet, flöde och leverans.
Om en 2-minuters Slack-incheckning uppnår vad en 15-minuters standup brukade — och ditt team fartyg snabbare, känner sig mindre trött, och upprätthåller anpassning — det är smidighet i handling.
Så här är min utmaning till dig:
Den här veckan, fråga ditt team:
Du kanske upptäcker att det är viktigt att stå upp, och det är bra — nu har du bevis, inte antaganden.
Eller du kanske upptäcker att det har varit skatt utan ersättning i månader. Också stor - nu kan du optimera.
Hur som helst, du kommer att göra det mest smidiga som möjligt: anpassning baserad på verkligheten, inte ritual.
Har du experimenterat med alternativ till dagliga standups? Jag skulle älska att höra vad som fungerade (eller inte) för ditt team. Hör av dig till honom. eller lämna en kommentar nedan.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.