Je weet, na een tijdje aan meerdere producten te hebben gewerkt en dingen te hebben gebouwd, heb ik altijd nagedacht over deze hele sprint ding dat iedereen doet. net als elk bedrijf, elk team volgt gewoon deze twee weken durende sprint cyclus omdat dat is wat iedereen doet, en het maakt me gewoon denken veel als wat ze echt krijgen van het doen van dingen als deze. Je hebt sprintplanning, je hebt dagelijkse standups, je hebt retrospectieven, je hebt al deze ceremonies die je tijd in beslag nemen wanneer je echt iets kon bouwen.En ik zeg niet dat vergaderingen slecht zijn, maar meestal hebben deze sprintrituelen geen gewicht, het is alsof mensen het moeten doen omdat dat het proces is, niet omdat het hen daadwerkelijk helpt betere producten te leveren. Dus ik heb een aantal manieren bedacht om korte uitvoeringscycli te ontwerpen zonder al deze sprint overhead, en het heeft echt goed gewerkt voor mij: Work in Natural Cycles Based on Actual Tasks Het grootste probleem met sprints is dat ze je dwingen in deze kunstmatige cyclus van twee weken, ongeacht wat je eigenlijk bouwt.Zoals als een functie 3 dagen duurt om te bouwen, waarom plant je het dan in een sprint van twee weken?En als iets 3 weken duurt, splits je het kunstmatig gewoon om de sprint te passen. Wat ik in plaats daarvan doe, is dat ik werk in natuurlijke cycli breek op basis van de werkelijke taak. Sommige taken duren 2-3 dagen, sommige een week, sommige langer. En ik werk er gewoon aan tot ze klaar zijn, verzend ze en ga naar het volgende. Er is geen kunstmatige deadline die geen verband heeft met het werkelijke werk. Dit is het belangrijkste deel omdat het je in staat stelt om je te concentreren op verzendkwaliteit in plaats van dingen in willekeurige tijdvakken te passen. Ship Continuously Instead of Batch Releases Sprints zorgen ervoor dat je alles in deze release-cycli stort. Je voltooit 10 functies in twee weken en geeft ze allemaal tegelijk vrij. Maar dit heeft geen zin voor de meeste producten, vooral SaaS-producten waar je op elk gewenst moment kunt implementeren. Ik verzend functies zodra ze klaar zijn. Als iets is gedaan op dinsdag, ik duw het op dinsdag. Als iets anders klaar is op vrijdag, dat gaat uit op vrijdag. Op deze manier krijgen gebruikers waarde sneller, en je kunt feedback sneller krijgen. En de feedback is het belangrijkste deel omdat dat is hoe je weet of je het juiste ding hebt gebouwd of niet. Focus on One Thing at a Time In sprints plannen teams zoals 5-10 verschillende dingen om tegelijkertijd aan te werken.En dan springt iedereen tussen taken, de context schakelt de hele tijd, en niets wordt echt goed gedaan. Kies de belangrijkste functie of probleem, werken aan het, voltooien het, verzenden het, en dan naar de volgende ding.Dit betekent niet dat je niet kleine taken aan de kant, maar uw belangrijkste focus moet één ding zijn. Use Deadlines Only When They Actually Matter Sprints maken deze kunstmatige deadlines om de twee weken.Maar de meeste functies hebben niet echt een specifieke deadline nodig.Zoals als je een nieuwe dashboardfunctie bouwt, maakt het niet uit of het op maandag of woensdag verschijnt? In plaats van deadlines op alles te dwingen, gebruik ik ze alleen als er eigenlijk een reden is.Zoals als je iets voor een conferentie lanceert, of als je een klant een specifieke datum belooft, of als er een concurrerende reden is om op een bepaalde tijd te verzenden.Deze zijn echte deadlines die echt tellen.Alles anders kan worden verzonden als het klaar is en goed is gedaan. Keep Communication Lightweight De grootste overhead van sprints is alle vergaderingen. Planning vergaderingen, dagelijkse standups, beoordelingen, retrospectieven. Wat ik doe is communicatie echt licht houden. Als ik solo werk, houd ik alleen notities voor mezelf over wat ik werk aan en wat ernaar gaat. Als ik met een team werk, checken we gewoon in wanneer dat nodig is, niet op een vast schema. Iemand heeft een vraag? Ze vragen. Iemand heeft iets gedaan? Ze delen het. Iemand is geblokkeerd? Ze spreken op. Het vereist geen dagelijkse vergadering om 10 uur elke dag waar iedereen zegt waar ze aan werken wanneer je al weet waar iedereen aan werkt. Plan Only What You Need to Plan Sprintplanning zorgt ervoor dat je twee weken van tevoren werkt.Maar het ding is, je weet niet echt wat er in die twee weken komt.Misschien verschijnt er een bug, misschien verandert gebruikersfeedback je prioriteiten, misschien realiseer je je dat iets belangrijker is dan wat je gepland had. Misschien plan ik 2-3 dingen vooruit, dus ik weet altijd wat er komt, maar ik plan de hele maand of het hele kwartaal niet in detail. Measure by Outcomes, Not by Process Sprints laten je dingen meten zoals snelheid, storypoints, burndown-grafieken.Maar dit zijn gewoon procesmetricen. Wat echt telt is de resultaten. Heb je iets verzonden? Gebruikers gebruiken het? Heeft het het probleem dat je probeerde op te lossen opgelost? Is het geld verdienen als dat het doel is? Dit zijn de echte metricen die je vertellen of je succesvol bent of niet. Het proces maakt niet uit of het resultaat goed is, en het proces helpt niet als het resultaat slecht is. Het belangrijkste wat ik heb geleerd is dat je geen sprints nodig hebt om goede producten te leveren. je hebt alleen een duidelijke focus nodig, snelle feedbackloops en de discipline om dingen daadwerkelijk te voltooien voordat je naar het volgende gaat. En dit betekent niet dat de structuur slecht is. Je moet nog steeds plannen, je moet nog steeds communiceren, je moet nog steeds prioriteiten stellen. Maar je kunt dit allemaal doen zonder jezelf te dwingen in deze rigide twee-week cycli die echt geen zin hebben voor hoe de werkelijke productontwikkeling werkt.
