Dev Summit 2025. Het einde van estimation hell: zo levert elke sprint waarde op.

Agile, wie is er niet groot mee geworden? Maar de manier van werken wordt nog lang niet overal goed toegepast, aldus Jakob Buis, spreker op de Tweakers Dev Summit 2025. “Mijn hoofddoel is building effective software teams. Ik help bestaande teams die moeten groeien of die vastlopen met zichzelf of elkaar, weer op de rails te komen.”

Jakob, afwisselend interim manager, coach en scrum master, heeft een achtergrond in informatiekunde en bedrijfskunde: een combinatie die draait om de productie van software, behalve het programmeren zelf. Toch begon hij zijn loopbaan als developer. Acht jaar lang werkte hij als programmeur bij verschillende organisaties en deed hij brede ervaring op in uiteenlopende omgevingen. “Ik heb meer dan honderd bedrijven van binnen gezien”, vertelt hij. “Daar heb ik hele goede, maar ook behoorlijk frustrerende ervaringen bij opgedaan.”

Zo herinnert hij zich nog goed een projectmanager met dertig jaar ervaring die verplicht een scrumcursus moest volgen. “Hij kwam terug met de conclusie ‘dit is totale onzin’”, zegt Jakob droog. “Dat maakte het er niet makkelijker op.” Of de momenten waarop er om een tijdsinschatting werd gevraagd, hij 90 uur noemde en vervolgens hoorde dat het project al voor 60 uur verkocht was. “Dan wordt het een moeilijke discussie”, glimlacht hij. Precies zulke ervaringen zetten hem aan het denken over samenwerking en teamdynamiek: hoe bouw je goede teams die écht goede software kunnen leveren?

Wat hem het meest aanspreekt in zijn werk, is het zichtbare effect dat je kunt hebben op teams. Vooral bij teams waar de sfeer en samenwerking zijn vastgelopen, ziet hij vaak dat relatief simpele interventies al een groot verschil kunnen maken. “Het geeft heel veel voldoening om te zien dat mensen weer plezier krijgen in hun werk”, zegt hij. “Je hoeft er geen veertig jaar voor te hebben gestudeerd; de technieken zijn bekend. Maar juist door ervaring van buiten mee te brengen, kun je veel bereiken.” Het is precies die mix van ervaring, pragmatisme en mensgericht werken die Jakob kenmerkt: niet de grote theorieën, maar concrete verbeteringen in hoe teams dagelijks samenwerken - dáár ligt zijn kracht.

Technische bagage en leiderschap gaan hand in hand

Ondanks zijn focus op teams en processen behoudt Jakob bewust voldoende technische bagage. Hij verwijst naar een onderzoek uit 2020 waaruit bleek dat één factor de grootste invloed heeft op werkplezier: medewerkers willen dat hun leidinggevende in principe hun werk zou kunnen doen. “Dat betekent niet dat je alles perfect moet beheersen”, legt hij uit. “Maar je moet wel begrijpen waar het over gaat. Als twee developers aan je bureau staan en de een zegt A en de ander B, dan moet je kunnen meepraten. Gokken werkt niet.”

Daarom hanteert hij grofweg een 80/20-verdeling: voor 80 procent richt hij zich op teams en mensen, en de resterende 20 procent programmeert hij nog zelf. Door zelf af en toe projecten te doen en veel samen te werken met developers blijft hij op niveau. Daarnaast leest hij vakliteratuur en volgt hij discussies op platforms als Reddit.

Agile en scrum verschuiven naar resultaat

In de agile-wereld ziet Jakob geen totaal nieuwe methodieken, maar wel een verschuiving van de focus. “Tien jaar geleden deed iedereen scrum”, vertelt hij. “Maar vaak ging het alleen om de terminologie, zonder dat men echt begreep wat de bedoeling was; cargoculting.” De context veranderde: geopolitieke onzekerheid, economische druk en het vuca-tijdperk (volatility, uncertainty, complexity, ambiguity) zorgen voor meer voorzichtigheid bij organisaties. Softwareontwikkeling is kostbaar, hoge salarissen, grote teams, en investeringen moeten aantoonbaar resultaat opleveren.

Dat vertaalt zich naar een zakelijker insteek. In de beginjaren van agile lag de focus nog te vaak op de cultuur binnen het team en de organisatie. Als de cultuur maar goed was, dan kwam het wel goed. Nu is de aanname ‘als iedereen happy is, komt het goed’ veel minder aanwezig. Er is veel meer nadruk op meetbaar resultaat op korte termijn. Terug bij de kern van scrum betekent dat continu waarde leveren. De beste teams onderscheiden zich doordat ze elke sprint - of minstens elke maand - nieuwe software opleveren die door gebruikers wordt gebruikt. Dat creëert de gewenste feedbackloop van bouwen, observeren, leren en verbeteren. De tijd van teams die sprint na sprint nét niets live zetten en pas na een half jaar releasen, is volgens hem voorbij.

Praktijkervaring als basis voor de talk

Die resultaatfocus vormt ook de kapstok van de talk van Jakob op de Tweakers Dev Summit. Na twaalf jaar met uiteenlopende softwareteams keek hij terug: welke teams functioneerden echt goed en waarom? Er is geen garantie dat kopiëren werkt, maar er zijn wel patronen te herkennen. Op basis daarvan selecteerde hij een handvol sleutelfactoren die hij behandelt tijdens de Dev Summit 2025. Er zit genoeg theoretisch kader in om te begrijpen waarom iets werkt, maar het draait vooral om praktische aanknopingspunten die je meteen kunt toepassen als het bij jou niet lekker loopt.

De talk raakt alle onderdelen van het ontwikkelproces: van testen en code reviews tot klantinteractie. Het doel is niet om een compleet team in één keer om te gooien, maar om stap voor stap verbeteringen aan te brengen die echt verschil maken.

Een einde aan eindeloze estimate-sessies

Als voorproefje licht Jakob één onderwerp uit waar hij wat langer bij stilstaat: een einde aan eindeloze estimate-meetings. “Bijna ieder team heeft ze”, zegt hij. “En bijna niemand vindt ze leuk.” Ze kosten veel tijd, leiden tot meningsverschillen en zijn gevoelig voor biases. Bovendien zijn schattingen vaak minder accuraat dan teams denken. In een onderzoek presteerden teams die simpelweg telden in plaats van schatten beter: slechts 4 procent afwijking tussen planning en realiteit, tegenover 20 procent bij traditionele story points. En dat met minder moeite. De grotere twist houdt hij bewust geheim, voor de talk.

Daarnaast komen nog twee thema’s voorbij: beter begrijpen hoe je product echt wordt gebruikt wordt - met kleine stappen al veel inzicht - en retrospectives levendiger en effectiever maken. Bijvoorbeeld door verder terug te kijken of anonieme benchmarks met andere teams te gebruiken. Het zijn precies dat soort praktische, onverwachte inzichten die de talk kenmerken: herkenbaar voor ervaren teams, verrassend voor wie denkt dat agile alleen om stand-ups en post-its draait.

Dat veel teams de methodes en tools waar Jakob over spreekt nog niet toepassen, komt zelden door onwil. Er zijn drempels: je moet weten dat iets bestaat, bepalen wat je ermee wilt, en vaak je leidinggevende overtuigen om er tijd en budget voor vrij te maken. De waan van de dag - drukte, deadlines, lopende projecten - laat weinig ruimte om te experimenteren of structureel te verbeteren. Soms is er ook sprake van onwetendheid of berusting: “Hier is het druk, maar dat is overal zo.” Volgens Jakob klopt dat niet; elk bedrijf heeft zijn eigen problemen. De kunst is een omgeving te vinden waarin je problemen hebt waar je mee kunt leven, of beter nog: waar je samen iets aan kunt doen. Softwareontwikkeling blijft teamsport; verandering raakt niet alleen tools of processen, maar ook gedrag, rollen en overtuigingen van developers, managers, product owners en scrum masters.

Ploeteren of groeien tijdens de Tweakers Developers Summit 2025

Of je nu scrum master, tech lead of developer bent: Jakobs boodschap is simpel en uitvoerbaar. Kies voor kleine, meetbare verbeteringen, stop met tijd verspillen aan schattingen die niet kloppen, leer hoe je product écht wordt gebruikt, maak retrospectives weer scherp en leuk, en lever vooral continu waarde. Dat is het verschil tussen teams die blijven ploeteren en teams die groeien.

Wil je die vertaalslag morgen al maken? Kom dan naar de Tweakers Dev Summit 2025 en pik Jakobs beste lessen, inclusief verrassende tools en concrete stappen, uit de eerste hand mee tijdens zijn talk ‘Best practices of Agile teams’. Dit is dé kans om je team direct naar een hoger niveau te tillen.

Koop nu je kaartjes voor de Dev Summit 2025

Enthousiast geworden, en wil je Jakob en alle andere sprekers zien en horen op de Dev Summit 2025? Scoor dan nu je entreekaartje. Helaas zijn de earlybird-tickets inmiddels uitverkocht, en ook de reguliere kaartverkoop loopt hard. Een regulier ticket kost 299 euro en je kunt nog gebruikmaken van de actie waarbij je drie tickets voor de prijs van twee kunt scoren.

Koop hier nu je tickets!

Als je werkgever de kosten voor het ticket op zich neemt, ontvang je uiteraard een factuur voor de administratie. Persoonlijke gegevens worden niet gedeeld met partners.

Ben je student? Dan bieden we graag een gereduceerd tarief aan. Ook hiervoor kun je terecht in de ticketshop.

Onze partners dit jaar

Reacties (52)

[djwice]

Bij Scrum bepaald de Product Owner die verantwoordelijk is voor de business waarde de volgende van de stories.

Bij SAFe hebben alle stories al een business waarde.

Dus sturen op waarde per sprint doen we al ruim 20 jaar. Dus niets nieuws.

De effectiviteit van een team ligt voornamelijk aan de samenwerking/ team dynamiek en hoe goed het team van nature kwaliteit prioriteert boven kwantiteit en korte termijn snelheid.

Wat ik zie in de praktijk is dat vooral technical Debt en afraffelgedrag zorgt voor minder waarde kunnen leveren. Ook in teams waar het lijkt of ze elke sprint de meeste waarde leveren, groei curves laten zien in punten (door her definitie etc.). De teams die niet automatisch testen, best practices negeren, inconsistent zijn in architectuur of niet alles mee nemen in upgrades en refactor lopen uit eindelijk met een applicatie rond waar een kleine wijziging complex wordt.

Het probleem dat geadresseerd moet blijven is de lange termijn waarde en snelheid van aanpassing in bestaande omgevingen door nieuwe medewerkers.

Hoe logischer, consistent en modulair de applicatie gebouwd is en hoe exacter de data structuur gedefinieerd hoe meer waarde de applicatie heeft op langere termijn.

Dus focus daarop dan komt het goed met de business waarde, want elke vraag kan dan snel geleverd worden.

[Reactie gewijzigd door djwice op 23 oktober 2025 14:35]

[AlphaRomeo]

Ik zit toevallig in een organisatie waar we allerlei soorten teams hebben. Onder andere teams die elke poep en scheet die ze produceren uitvoerig testen in meerdere lagen. Die dagenlang tickets analyseren en debatten kunnen voeren over architectuur.

Onder de streep moet je je (in een commerciële organisatie) afvragen wat duurder is: een langere time to market, of het opbouwen van technical debt en het soms uitleveren van een half-af product.

Het maakt daarnaast nogal verschil of je medische apparaten ontwikkelt, in de ruimtevaart zit of aan de andere kant van het spectrum zit in minder kritische toepassingen. Als mijn team een fout maakt kan er een keer een robotarm crashen en hebben we wat mechanische schade, persoonsveiligheid komt hierbij niet in het geding (apart circuit). Als ik vooraf ga proberen die risico's helemaal af te dekken kan ik niet meer competitief ontwikkelen in een steeds snellere markt met onder andere opkomende industrieën in Azie. Soms is daarom een pragmatische aanpak wel degelijk de juiste, hoe zeer ons engineers dan soms ook steekt.

[Reactie gewijzigd door AlphaRomeo op 23 oktober 2025 13:41]

[djwice]

Onder andere teams die elke poep en scheet die ze produceren uitvoerig testen in meerdere lagen. Die dagenlang tickets analyseren en debatten kunnen voeren over architectuur.

Dat geeft dus aan dat er geen consistentie in de architectuur zit en dat het niet modulair gebouwd is.
Dus een team met veel technical debt.

Anders hoeft er geen discussie te zijn over architectuur, kunnen tests op 1 plek en geen discussie over wat een ticket betekent en hoe en waar het geïmplementeerd moet worden.

Bij mijn ontwerpen eis ik altijd dat het medische data en gevoelige financiële gegevens moet kunnen verwerken, ongeacht welke data er op dit moment verwerkt moet worden.
De aanpassingen om dit nu goed te doen en de voordelen die die compliancies geven (encryptie, separatie van concerns, monitoring, abnormaliteit etc.) hebben in nagenoeg alle processen voordelen.
Dit verdient je terug in je incident management proces en je business rapportages en de verlaagde technical debt kans.
En de inspanning en kosten hiervoor staat in het niets t.o.v. ooit een keer een gevoelig data kenmerk moeten toevoegen.

Het gaat dus niet om risico's afdekken, maar om goed ontwerpen. Niet ellen lang, maar vooraf de juiste keuzes en uitgangspunten nemen. Dat schept snelheid en flexibiliteit.

Ik heb nu een CustomGPT die dat voor mij doet, in 1 tot 2 minuten ontwerpt en definieert ie de infrastructuur en applicatie structuur conform alle compliancy standaarden en conform wet en regelgeving. Met in acht neming van de modulariteit, schaalbaarheid etc. incl. documentatie van alle keuzes.

Dit is gebouwd op de ervaringen van tientallen jaren en zo ontwerpt en maakt ie nu wat eerder dagen, weken of maanden kostte.
En zo is het fundament in 1x goed.

Ook kan die een bestaande implementatie valideren op tegen al die architectuur uitgangspunten. En aangeven welke dingen niet compliant of niet consistent of zelfs tegengesteld of remmend werken.

Denk bijvoorbeeld aan een volgorde eis in een event driven systeem. Dat is per definitie een ontwerp fout.

Mijn teams gaan typisch van 1 keer per sprint of meerdere sprints naar productie, naar meerdere keren per dag gecontroleerd live.
Nu een gesprek met de stakeholder en vanmiddag live of binnen een paar dagen met de features. Dat kan door duidelijkheid en consistentie en goede processen en fijne samenwerking. En afraffelen: no live, fix it yourself.


Estimation hell betekent simpelweg dat er technical debt is, inconsistenties, niet modulair ontwerp, waardoor er verschil van interpretatie kan ontstaan. Het betekent dus: breng eerst je applicatie op orde, dat help je commerciële organisaties het beste. Bijvoorbeeld met 25% van de tijd van het team besteden aan oplossen tech debt en in de overige 75% geen nieuwe toevoegen. Doe je dat wel dan mag dat volgende sprint niet in de 25% worden gefixt maar gaat het van de 75% af. Binnen een paar maanden zul je zien dat het team meer leverd in business waarde dan dat ze deden zonder die 25% tech debt investering. Dus ondanks dat er minder tijd aan business features wordt besteed krijg je meer omdat de kost to change larger wordt, want de applicatie is consistenter en er minder discussies zijn en meer duidelijkheid.

[Reactie gewijzigd door djwice op 23 oktober 2025 14:34]

[itons]

debt

[djwice]

Ah, van debet.

[stefanhendriks]

Technical debt is al een term waar we uren over kunnen debatteren. Soms heeft het ook te maken met stijl, voorkeur, laatste paradigma, framework, etc.

Je moet zeker tijd en aandacht besteden aan technical debt, maar je moet ook zeker bezig zijn met het shippen van features. Soms is een halfbakken feature om te checken of er markt voor is (time to market dus heel kort) beter dan een hele shiney feature die je veel tijd kost maar waar je achter komt dat het niet (vaak) wordt gebruikt. Dan kun je wel pronken met je mooie code, maar je hebt wel vele uren verbrand en je levert niets op. En soms weet je het niet van te voren.

Bouw je een vastomlijnd (scope is kristalhelder) programma, dan is het al wat anders.

Ik kan even niet serieus nemen dat je een GPT. gebruikt om eea te scaffolden en dat dat zoveel zou schelen. Dusver is de ervaring (breedgedragen) dat GPT's veel meuk produceren en juist niet voldoen aan wat je vraagt. Je zal er zelf nogmaals doorheen moeten (maar je hebt geen mentaal model, dus je moet je inlezen, etc). Het is sneller dan om zelf te typen en zeker te zijn hoe het opgezet is. Misschien bedoel je wat anders, maar het kwam op mij erg optimistisch over...

Estimations zijn sowieso altijd verkeerd. Het is geen toeval dat er een 'no estimation' beweging is; we kunnen hooguit onze onderbuikgevoelens gebruiken (met zoveel mogelijk context) om een ballpark te geven hoeveel moeite iets kost om te realiseren. Hoe kleiner, duidelijker en simpeler het verzoek hoe zekerder we een inschatting kunnen geven. Maar hoe groter, onduidelijker (!) en moeilijker (!!) hoe meer je het mis kan hebben.

In mijn optiek zijn inschatting sessies, of je dat nou met Scrum doet of niet, meer een communicatie middel , zodat je als team op dezelfde golflengte zit hoe je een bepaalde functionaliteit zou realiseren, hoe moeilijk/makkelijk het kan zijn, etc. Daar kan evt wat story points uit komen (of dagen/uren, whatever). Het omzetten naar 'tijd' en plotten op een tijdslijn (andere zaak) is weer wat anders.

Je kunt meerdere keren naar productie, das mooi. Dat kunnen wij ook. De praktijk: we hoeven dat niet. Simpelweg, er is niet zoveel spannends om op te leveren. Het kan ook een dag of zelfs een week wachten. De moeite om bijv zero downtime deployments te gebruiken , en mee te dealen (ook complexiteit bijv met DB migraties) wegen niet op tegen de moeite. En als we al vaker moeten deployen dan is de downtime hooguit een seconde, wat we dan bijv tijdens lunchtijden kunnen doen. Hier ook is de vraag: Wat is de kost vs benefit. In mijn beleving zijn developers te veel bezig met het tech feestje en niet bezig met de 'benefit' (wat levert het de gebruiker op). Je kunt zelfs beargumenteren dat snel deployen slechtere kwaliteit code in de hand werkt, want ach als je een bug hebt fix je die meteen en deploy je weer meteen... toch? ;-)

In the end moet je als team (teams) een duidelijker manier hebben van communiceren naar elkaar en naar de organisatie toe.

[djwice]

Nee, niet scaffolding. Hij maakt werkende infrastructuur, gedocumenteerd etc. Ik heb daarvoor van alle mogelijke features en alle mogelijk parameters de documentatie gegeven en hetzelfde geldt voor best practices. En ook een zeer strict schema (ja dat is niet klein) die exact alle kaders definieert. En nog een aantal dingen meer.

En als je dat goed doet, dan krijg je echt het resultaat. En ja, ik krijg van veel mensen twijfel reacties, totdat ze hem voor hun eigen use case gebruiken. Dingen waar ze al maanden op ploeteren om goed te krijgen. First time right binnen 2 minuten.

Voor de duidelijkheid, dat ik dit kan maken heeft wellicht te maken met dat ik aan cfn-guard heb meegewerkt in de ontwerpfase en dat ik een paar jaar terug - zonder AI - niet publiek gereleased - een automatisch AWS-infrastructuur documentatiesysteem gemaakt heb dat in detail kan vertellen in menselijke taal inclusief alle configuraties, correlaties, afhankelijkheden, compliancies en lack of compliancy. Pre en post deployment. Werkte in een lambda functie.

Dus dat ik behoorlijk goed - boven gemiddeld denk ik wel - weet hoe dit in elkaar zit, werkt en waar de uitdagingen zitten. Zodat ik daar ook duidelijke exacte regels voor heb.

______
Een halfbakken feature kun je nog steeds conform je architectuur, etc. maken, sterker nog het scheelt tijd en je kunt waarschijnlijk beter meten hoe de market response is.
Het is een misperceptie dat snel, afraffelen betekent. Afraffelen heeft vaak een negatieve impact op time to market.

En volgens mij zeg je inderdaad precies wat in de Scrum Guide staat wat betreft estimates. Zitten de teamleden op dezelfde golflengte, hebben ze allemaal hetzelfde beeld. Dat is het doel van de story points. Ze zijn niet bedoeld voor rapportages naar stakeholders of naar andere mensen buiten het team. En al helemaal niet voor targets.

Als je DB-migratie bij een deployment complex is, was het vorige ontwerp niet goed. Dus technical / design dept. Als dat zich herhaalt ga dan terug naar de tekentafel om je datamodel definitief goed te ontwerpen.
Blijkbaar zijn een aantal uitgangspunten niet correct.

Bij een 100% test coverage die parallel uitgevoerd wordt is de kans dat er fout werkende of risico volle code live gaat zeer klein.
Dus nee, snel betekend niet dat er slechte kwaliteit komt.
Zo voerd een API deployment op alle parameters een test uit met alle bekende OWASP attacks, uiteraard pas na de statische test van de API specificatie. En na validatie of er updates zijn van de lijst en na validatie of de nieuwe lijst een aantal items zijn geschrapt. Etc.
Wij kunnen zo'n duizend van die testen tegelijk uitvoeren.
Dit maken kostte 1 developer 3 weken, nadat ik het goed gespecificeerd had (de statische test definitie etc.), dit is wel 9.5 jaar terug gebouwd, nu zal het waarschijnlijk minder tijd kosten.

[Reactie gewijzigd door djwice op 23 oktober 2025 17:37]

[CodeCaster]

Agile/scrum had allang dood moeten zijn en werkt niet. Teams die het tegendeel beweren zijn langzaam en produceren veel minder output dan ze zouden kunnen. Liefhebbers claimen dat het proces dan gewoon niet goed wordt toegepast, maar er ís geen manier om Scrum goed toe te passen. Fite me.

[vargo]

Hier ben ik het niet mee eens. Ik zeg dit als developer, technische lead van grote software (en soms ook hardware) ontwikkel trajecten, en af en toe coach.

Ik proef dat je negatieve ervaringen hiermee hebt gehad, en dat kan idd heel frustrerend zijn. Scrum is helaas voor veel mensen synoniem geworden voor post-its, jira, eindeloze sprint planning sessies en standups, en ieder kwartaal 3 dagen moeten luisteren naar het marketing departement.

Het probleem is dat in heel veel organisaties het totaal verkeerd wordt toegepast: roepen dat er agile/scrum wordt gewerkt doordat er post-its aan de muur hangen, of juist veel te dogmatisch.

Bij verhalen dat het niet werkt, als je inzoomt, blijkt dat het gewoon niet wordt toegepast, niet goed wordt uitgevoerd, of geen geschikte settings is.

Sowieso zijn Agile en scrum niet hetzelfde. Agile is een idee, een gedachtengoed over hoe complexe projecten te draaien - ontstaan omdat veel grote waterval projecten totaal mislukten. Onder deze paraplu vallen een aantal methodieken: XP, scrum, kanban, devops, scaled agile, SAFe, (Lean? RUP?) etc. Je kan mi een agile organisatie cultuur hebben bouwen, maar het is geen proces dat je kan toepassen. Dit is volgens mij de crux waarom mensen Agile een sterfhuis noemen (ten onrechte mi)!

Ik snap ook nooit de drang naar SAFe die veel organisaties hebben: proberen te zorgen dat project klein en zelfstandig kunnen draaien, en als je dan toch moet schalen, neem dan een simpel scaled agile framework. Maarja... met SAFe heeft iedereen in de organisatie zijn eigen icoontje op het SAFe diagram.

Dat je agile/scrum als synoniem gebruikt is wel een teken aan de wand. Dat je het een process noemt idem: het is een structuur die je kan adopteren om je team en werk planning te organiseren.

Maar het kan wel degelijk werken, maar het moet wel in dienst staan van dat team dat naar een doel aan het werken is. Het moet het team beschermen tegen de onzin van de rest van de organisatie. Het moet dus ook iets zijn voor het team en door het team. Als het wordt opgelegd aan teams door scrum coaches die nooit een regel code hebben gezien is het vaak gedoemd te mislukken.

Wanneer ik scrum goed werkend heb gezien:

• goede mensen in het team: skills maar ook juiste houding
• dus een positieve instelling om iets nieuws te doen, iets ook beter te maken, en eigenaarschap te nemen (ook over scrum!)
• hou het ook leuk: planning poker voor sprint planningen, retrospectives in leuke setting met ruimte voor het team om iets te doen wat ze zelf leuk vinden
• team discipline - maak die standups / sprint planning kort en effectief. Haal echt wat uit de sprint demos, retros & reviews. Zorg ervoor dat je backlog op orde is met goede user stories
• Er moet dus ook echt een goede PO zijn; voor wat dat is verwijs ik graag naar de uitleg van Henrik Kniberg
• ik nam nooit coaches mee en als ik ervoor werd gevraagd was het mijn doel zsm weer overbodig te zijn.
• zelfs de scrum master rol vaak ingevuld door deze parttime te rouleren in het team => het zorgt ervoor dat het een ding van het team wordt ipv iemand die dat als job had
• combineer met xp, devops, kanban (prima alternatief voor scrum bij snel wisselende prioriteiten)
• hou het simpel, richt op de principes achter deze frameworks; niet dogmatisch de proces stappen volgen uit het boekje
• gebruik spikes om items in het backlog te verkennen die echt nog onbekend zijn. Gewoon X uur timeboxen in een sprint om te leren
• etc

Zoals je leest er zijn nogal wat ingredienten vereist om het succesvol te laten zijn, en mijn vuistregel was dat teams ook toch wel 1 tot 3 maanden de tijd nodig hadden om op gang te komen. En dat is dan enkel scrum: er spelen ook nog devops, xp, software en soms hardware engineering - en vooral tig externe factoren! - mee.

Mijn tip voor alle junioren die in een werkomgeving komen met een verziekt agile proces: verdiep je in Agile, en begin bij jezelf in je team om dingen gewoon een klein beetje beter te maken in je dagelijkse werkzaamheden. Doe dit iedere dag en dan wordt je vanzelf echt agile

(Of je loopt tegen een muur en bent er klaar mee, en ga je op zoek naar een andere job )

[Shal-Ziar]

Ik mag dan geen Scrum-Master /Agile-Koning of andere titel hebben, maar ik wil toch reageren.
Ik vind dat voor projecten met een onderzoekscomponent, waarbij je van de gebaande paden af moet gaan agile niet handig. Plannen en doelstellingen zijn daar lastig.

Moet je iets bouwen uit bestaande componenten of componenten die goed gedocumenteerd zijn dan is de onderzoeksfase van een project veel beter te overzien en in te schatten en komt Agile meer tot zijn recht.

[Joost1981_2]

Juist is het daar handig want je leert snel door korte feedbackloops. Verwar agile en scrum niet

[Shal-Ziar]

Ik bedoel meer onderzoek a-la onderzoeken lezen, dat vereist soms vrij veel tijd als je niet in het onderwerp zit en zijn er niet echt manieren om snel te testen.

[Ronwiel]

Bij het lezen van dit soort reacties vraag ik me dan af; wat vind je wel goed werken? Daarbij is output als metric voor een team wat eenzijdig. Mijn ervaring is dat binnen agile ook veel meer aandacht is voor de softe kant van het werk. Naar mijn mening net zo belangrijk als je ziet hoe hoog de druk is in IT en development.

[CodeCaster]

Met "output" bedoel ik dan ook niet geschreven regels code of opgeleverde issues, maar toegevoegde waarde en verbeterde samenwerking.

[com2,1ghz]

Werkt wel maar bedrijven blijven krampachtig vasthouden aan hun organisatielagen van bovenaf allerlei zaken worden doorgedrukt terwijl je samen afspreekt wat je de komende sprints denkt te leveren.

Simpeler en duidelijker dan SCRUM kan je niet hebben, heel het vast blijven hangen in onnodige bedrijfsprocessen waar wat SCRUM labels op geplakt zijn.

Zo hebben we projectmanagers die denken zo even dat teams alles kunnen laten vallen om iets op te pakken, om vervolgens af te vragen waarom het vorige product nog niet geleverd is. Product owners die acteren als managers. "Full time" scrum masters die ook iets van management doen en zaken van bovenaf doordrukken. Dat heeft allemaal niets met SCRUM te maken.
Teams die zo even samengevoegd worden of dat je werkt aan verschillende producten met verschillende roadmaps.

Eigenlijk precies het tegendeel waarbij je inderdaad minder output hebt, meer chaos en meer stress. Werk je gewoon simpel in sprints dan heb je dit gezeik nauwelijks.

[CodeCaster]

"Sprints" zijn geen oplossing voor inherent onplanbaar werk en ononderhoudbare code. Navelstaren in lange (een kwartier is lang) meetings is verspilling van tijd en energie.

[com2,1ghz]

Jawel omdat je behapbare delen pakt waarvan je het idee hebt om binnen een week of twee af denkt te krijgen. Team weet waar ze aan toe zijn, de stakeholders ook. Dat is heel het idee. Behapbaar maken en zorgen voor transapartie waarbij progressie zichtbaar is.

Als je last hebt van onplanbaar werk en ononderhoudbare code dan heb je een ander probleem dan scrum. Voor de rest weet ik niet waar je meetings hebt waar je voor je uit zit te staren maar dan heb je ook een ander probleem dan scrum.

[WernerL]

Het probleem is dat veel bedrijven nog steeds niet begrijpen hoe je fatsoenlijk scrum implementeert. Ook wordt er nog te vaak verwacht dat je een tijds inschatting geeft in plaats van inschatting op basis van complexiteit.

Combineer dat met het feit dat developers te veel petten moeten dragen naast hun normale developer-werkzaamheden en PMs die pushen om een sprint 'af' te krijgen en je eindigt met een kansloos 'scrum'-process waarin weinig ruimte is voor kwaliteit.

[Reactie gewijzigd door WernerL op 23 oktober 2025 09:29]

[trab_78]

Agile/Scrum als cargocult had inderdaad al lang dood moeten zijn. Dat staat ook in het artikel. Maar er zitten wel degelijk goede ideeën in Agile en Scrum. Zoals korte feedback loops en het opdelen van grote projecten in kleine taken.

Wat er mis is met alle Agile frameworks is dat ze geoptimaliseerd zijn voor het verdienen van geld met certificeringen. Daardoor ligt er te veel nadruk op het naar de letter volgen van de regels, in plaats van het begrijpen van de geest van de onderliggende ideeën.

Dat culmineert in SAFe, wat op zichzelf helemaal geen nieuwe ideeën introduceert, maar vooral een heel ingewikkeld framework optuigt. Kijk eens naar zo’n diagram uit het SAFe framework en denk dan terug aan het Agile manifesto, wat o.a. zegt: “We prefer people over processes.” (Mijn eigen parafrasering.)

[xx77qq]

Mee eens. Je kan scrum als startpunt gebruiken en vandaar uit optimaliseren naar hoe dit het beste in het team/organisatie werkt, misschien 3x per week een daily, misschien voor bepaalde projecten geen harde cyclus.
Waar ik zelf een broertje dood aan heb zijn de scrum masters (onzin functie) en product owners die strikt aan het ritueel vast willen blijven houden en weinig inhoudelijke kennis hebben. Dan ben je alleen maar meetings aan houden.

Nog een mooie: einde van de sprint nadert, developers worden zenuwachtig en raffelen hun werk af want anders boze PO'er, halen het alsnog niet, carry-over naar nieuwe sprint en bij de volgende sprint-demo zien we weer precies hetzelfde en ondertussen wordt de tech-dept verder opgebouwd.

scrum: Stupid CeRemonies Useless Meetings.

[1Mark]

Welke methode heb jij goed zien werken in organisaties?

[CodeCaster]

Een vieze mix van Kanban, Scrum, Prince2 en eigenwijsheid. Soms moet iets gewoon op tijd af. Soms moet je technical debt wegwerken. Soms moet je issues tot in den treure uitspecificeren en dan nog de pull request drie keer terugsturen naar de bouwer. Af en toe moet je met een paar mensen het werk bespreken. En kom niet terug met "maar dat ís Agile".

Vooral het halsstarrig vasthouden aan een (met name binnen een team of organisatie) bewezen onproductief proces is waar de slachtoffers vallen.

[1Mark]

Ok. En als je een wat grotere organisatie hebt: welke overhead-inrichting (bijv projectmanagers, PO's, scrum master, business controller, hiërarchisch leidinggevende) is vanuit jouw perspectief nodig?

Ik bedoel het niet suggestief of als commentaar, begrijp me niet verkeerd.

[vargo]

Het doel van Agile werk planning zou zoveel mogelijk moeten zijn dat de teams geen afleiding/last hebben van die grotere organisatie.

Maar grote organisaties laten zich lastig sturen, dus het vereist sterk leiderschap die snapt hoe complex engineering - én mensen - kunnen zijn.

Zorg er dus voor dat ieder team zich kan focussen op de kerntaak. Teamleden moeten enkel met elkaar bezig zijn. De PO is een uitzondering, en degene die de brug slaat naar de rest vd organisatie. En bij de sprint demo zie je (hopelijk) mensen (aka stakeholders) die feedback geven, of uit interesse willen zien wat de voorgang is.

Projecten kun je prima met Prince2 draaien, zolang je niet de scope gaat dichtzetten (het 'manage by exception' idee). Het project is voor alle niet 'delivery' zaken die wel geregeld moeten worden maar niet bijdragen aan het team doel: budgetten, UATs, organisatorische go-lives, problemen met een leverancier etc. Er is dan af en toe afstemming nodig, maar val het (Scrum) delivery team daar niet continu mee lastig. Een goede project manager is dus heel dienstbaar naar zo'n team: waar het team een extern probleem kan neerleggen en dat het vervolgens in een stuurgroep wordt opgelost.

Meerdere teams moeten ook zoveel mogelijk geen last van elkaar hebben (geen afhankelijkheden tussen die teams). Als er veel onderlinge afhankelijkheden zijn tussen teams is dat meestal een rode vlag dat de organisatie niet optimaal staat.

Mensen met een andere rol in de organisatie (business controller) hebben niet veel te maken met doen gewoon hun ding en zijn wellicht stakeholder (die met een PO te maken hebben), of onderdeel van een project.

Zie mijn langere reactie hierboven tav scrum masters: een rol die je prima beter binnen je team kan invullen. Meestal roulleer ik over team leden; soms vind iemand het leuk om dat vaker te doen, en soms past het ook echt niet bij een individu (dan niet). Het dwingt het team het scrum huishouden simpel en lichtgewicht te houden, en iedere team member krijgt de kans (en verantwoordelijkheid) om het beter te doen als ze daar ruimte voor zien.

[Joost1981_2]

Kan ik ook +100 doen?

Scrum is ouderwets. We leveren continu

[vargo]

Scrum sluit niet uit aan Continuous Delivery te doen: het zegt niets over hoe je je release planning moet doen. Continu increments naar productie pushen (liefst met fully automated QA), met feature toggles, dark releases, canary testing is helemaal prima.

Je kan dan nog steeds in iteraties naar doelstellingen werken, met bijbehorende scrum rituelen; en zoals ik in mijn langere post hierboven aangaf, zit er niet dogmatisch in. Pik de goede werkende dingen eruit, tweak of schrap wat niet werkt.

En vice versa, als je dat zonder scrum doet, en je team is happy en kan goed leveren wat de organisatie vraagt => ook helemaal

[Joost1981_2]

Maar waarom? Waarom wil je jezelf beperken tot iteraties van x weken? Dan is flexibel toch veel beter? We werken aan feature x en deze lanceren we over 3 1/2 week

Het enorme dogma is juist wat scrum zo verschrikkelijk maakt.

[vargo]

Zie mijn laatste zin: als dit voor je team werkt is dat prima!

Een team dat succesvol continuous delivery toepast is volwassen, en juist zeer agile, en opereert op een niveau waar ze de methodieken volledig naar hun unieke situatie hebben geoptimaliseerd.
(dat vond ik ook zo irritant aan mensen die dachten dat 'Het Spotify Model' naar iedere andere organisatie kan worden gecopy-pasted)

Maar de meeste teams zijn niet in staat het werk goed in te plannen. Dus die belofte van 3,5 week wordt dan 12 weken. En niet alleen dat, na 12 weken blijkt dat het toch niet helemaal was wat er gevraagd was. Misschien is het dan toch slimmer om het werk in stukjes op te knippen. En tussendoor even een checkpoint te hebben.

Bedenk je ook dat vroeger, in de tijd van megalomane waterval projecten, er rustig 1000 man 2 jaar aan iets aan het bouwen waren, en dat dan aan het einde van die 2 jaar bleek dat het een mislukking was. (ik draai lang genoeg mee dat ik dat in de begin dagen nog met eigen ogen gezien heb)

[smooc]

"Bovendien zijn schattingen vaak minder accuraat dan teams denken. In een onderzoek presteerden teams die simpelweg telden in plaats van schatten beter: slechts 4 procent afwijking tussen planning en realiteit, tegenover 20 procent bij traditionele story points"

Ik ben wel heel benieuwd wat je dan telt. Inherent aan het werk is dat er onbekende complexiteit is. Dat betekent per definitie dat als je een voorspelling gaat doen van die complexiteit er een (in)schatting gemaakt moet worden. Dus wat tel je? De tijd van functiepunt analyse is allang voorbij :-)

Als je gaat tellen hoeveel issues er in je sprint passen op basis van verleden heb je of super simpel werk of een team wat veel sneller kan en ambiteuzere doelen kan stellen. OKR vs KPIs.

Overigens is 20% is best goed. Standaard waterfall projecten hielden meestal al slack aan van ongeveer 20%.:-)

[Reactie gewijzigd door smooc op 23 oktober 2025 08:29]

[Keypunchie]

Tickets?

Onder de aanname dat de omvang van tickets een normaalverdeling heeft.

[Reactie gewijzigd door Keypunchie op 23 oktober 2025 08:31]

[smooc]

Tja dat verwacht dus een inschatting dat een ticket altijd dezelfde size heeft. En die normaalverdeling kan werken maar niet op het niveau van een sprint. Daar is de sample te klein voor (of je doet niets realistisch)

[trab_78]

Als je er van uitgaat dat je een planning moet halen: ja. Maar als je alleen zegt: over het algemeen kunnen we 10 (ik noem maar wat) taken in een sprint doen. Laten we 12 taken klaarzetten voor komende sprint. Kan zijn dat we er maar 8 af krijgen, maar als het meezit hebben we ook wat extra achter de hand. In mijn ervaring werkt dat prima, zonder dat je echt estimation hoeft te doen.

[DevWouter]

Storypoints zijn van oorsprong de uren keer 3

[smooc]

Dat zijn ze niet en is een misconceptie. Storypoints zijn gecorreleerd aan tijd maar niet causaal. Daarnaast zijn ze idiosyncratisch dwz niet vergelijkbaar tussen teams.

[DevWouter]

Dan moet ik je teleurstellen, want dat is letterlijk van de bedenker.
Kort samengevat: De uren keer 3 waarbij uitgegaan wordt van een "ideale" werkdag van 8 uur, zodat management in werkdagen kan rekenen, immers 8x3=24

Bron: https://ronjeffries.com/a...f/story-points/Index.html

[smooc]

Ha ik denk toch dat je dan iets beter moet lezen:

De originele XP-aanpak volgens Jeffries:

• Stories werden geschat in “Ideal Days” (ideale dagen)

• Dit was de tijd die een pair nodig zou hebben “als ze maar met rust gelaten werden”

• Om te komen tot echte kalendertijd vermenigvuldigden ze Ideal Days met een “load factor” van ongeveer 3

• Dus: 1 Ideal Day = ongeveer 3 echte werkdagen

Maar die load factor is per team bepaald en is dus een correlatie.

Jeffries’ punt is juist dat mensen story points zijn gaan misbruiken als tijdschattingen, wat leidt tot ongewenste druk en vergelijkingen tussen teams. Daarom betreurt hij nu de uitvinding ervan.​​​​​​​​​​​​​​​​

[DevWouter]

Het is een korte samenvatting
Het idee van "story points" werd uitgevonden om een bepaald probleem op te lossen (alinea 4 in de bron) en dat was namelijk het verwachtingsmanagement van managers.

[nandervv]

Oorspronkelijk misschien, maar inmiddels al lang niet meer. In feite zijn story-points vaak haast meer vibes qua complexiteit (best wel veel moeilijker dan een paar reference stories).

[DevWouter]

Het mooiste verhaal dat ik meegemaakt heb was toen een andere scrum master mij vroeg mee te doen aan een story poker sessie van zijn team. Elke keer legde ik de infinity card op tafel tot frustratie van zijn team. Het duurde even voordat ze door hadden dat ik, als extern, niet hun kennis had over wat een punt voor hun betekende. Maar nu het mooiste: Toen ik vroeg of ze hun referentie stories konden inschatten met de kennis en staat van nu had bijna ieder team lid een andere waarde.

En toen begon er rond de tafel bij iedereen lampjes te branden waarom mijn team geen story points gebruikte maar minuten en waarom we het eerst hebben over de eigenaar van een taak.

[Kwistnix]

Het grootste probleem met story points, dat ik altijd zie, is dat het vooral een feestje/abstractie is dat leeft bij de ontwikkelaars. Onderaan de streep moet er toch altijd een budget geregeld worden, waarbij de organisatie echt een schatting in uren wil hebben. Dat resulteert altijd in een hele kromme vertaalslag van SPs naar uren, waar dan ook altijd aan vast gehouden wordt. Duurt dan niet heel lang voordat je gewoon je stories weer in uren aan't schatten bent, maar voor de vorm worden het SPs genoemd. En ik begrijp het volkomen.

[trab_78]

Nee. Je moet juist altijd vermijden dat je story points in uren uitdrukt of andersom. Story points zijn slechts een schatting van de complexiteit van een taak: een junior dev zal voor dezelfde taak meer tijd nodig hebben dan een senior. En het blijft een schatting. De complexiteit schat je altijd in ten opzichte van een referentie taak.

[Joost1981_2]

Slicen, slicen en slicen ofwel, alle stories zijn klein.

WIP limit op aantal devs-1 en moet je eens opletten

[smesjz]

Ik heb meer dan honderd bedrijven van binnen gezien”, vertelt hij. “Daar heb ik hele goede, maar ook behoorlijk frustrerende ervaringen bij opgedaan.

Als ik kijk naar z'n LinkedIn dan is het loondienst bij een paar bedrijven en freelance sinds 2 jaar. Op z'n eigen site (PDF met presentatie) staat alleen dit: "Worked with 15+ agile teams in various companies & industries".

Ik ben dus benieuwd naar achtergrond over die honderd bedrijven...

[Reactie gewijzigd door AlphaRomeo op 23 oktober 2025 12:19]

[Tielenaar]

Dagje op bezoek is ook "een bedrijf van binnen zien". Kan me niet voorstellen dat je dan meteen een beeld hebt van de ins en outs van hun werken, maargoed.. Sowieso een beetje een verhaal met wat haken en ogen.

Ik ben in ieder geval blij dat ik nu ergens werk waar geen scrum gedaan wordt. Gewoon eigen verantwoordelijkheid pakken, tickets maken en oppakken op eigen inzicht en het is klaar wanneer het klaar is. Heeft het haast? Dan hoor je het wel, en geef je andere dingen prio. 10 minuten per week meeten is genoeg voor ons. Heer-lijk.

[demianmonteverd]

Ken de beste meneer niet, maar er bestaan vragen die je moet kunnen stellen, waarmee sneller tot de kern is te komen. Je hoeft echt niet drie jaar ergens te werken om te begrijpen wat er verkeerd gaat ergens. Vaak vertellen mensen het je al op je eerste werkdag bij de lunch als je ergens begint (of het komt naar voren tijdens de sollicitatie zelfs). En als consultant zal hij ook wel de visie en kijk op 'het probleem' vanuit het management mee hebben gekregen aan het begin van een opdracht.

En sowieso zo uniek zijn problemen vaak niet in de basis, het is hoe de factoren ten opzichte van elkaar zich verhouden waar de meeste verschillen zitten tussen organisaties met soortgelijke grootte.

En ja, natuurlijk zijn er speciale uitzonderingen en zijn er wel zaken die echt substantieel anders zijn tussen een ontwikkelteam van de ESA en bijv. Aegon.

[The Zep Man]

Als je werkgever de kosten voor het ticket op zich neemt, ontvang je uiteraard een factuur voor de administratie.

Anders niet?

[UTMachine]

Agile is niet iets verkeerd, alleen is het soms lastig om te bepalen of het helemaal beter werkt. Er moet nog steeds duidelijke kwaliteitscontroles worden gedaan, anders verzand het meer ‘developer doet gewoon waar hij zin in heeft’. Ik merk vooral bij ons bij agile de software kwaliteit redelijk is, maar documentatie en testing is minder belangrijk geworden.

[topcat1602]

Ik denk dat bedrijven al veel Inkomsten verloren zijn door de poging om scrum 100% toe te passen. Er scheelt altijd wel iets aan het rondkrijgen van een taak tegen eind van de sprint. Voor mij is scrum net zoals verkeerslichten op een autosnelweg, iedereen gefrustreed en plooien zich in bochten om de administratie en burndown in orde te krijgen. Net als iedereen in zn drive zit, stopt de sprint, begint de retro, demo, planning, enz en dan kan je weer aan de slag voor 3 dagen van de 2wekelijkse sprint. Achterblijvend met een nors gevoel omdat je teveel meetings hebt, terwijl je feature op eind van de sprint niet getest is of half afgewerkt. Met Kaban boards per team/ topic kan je tenminste een continue stroom garanderen. In ieder geval van alle bedrijven die scrummen, nog nooit een succes gezien. Net zoals patterns en architecturen moet je bekijken of het zinvol is voor jouw bedrijf en of je het geld wil investeren. Uiteindelijk komt het op 1 ding neer , de vraag hoeveel tijd/geld heb je nodig om een feature op te leveren. Dan kan je antwoorden met 5 punten.. 😅

[Joost1981_2]

Stop toch met scrum. Vandaag de dag leveren we continu.

scrum is anno 2025 echt een antipattern

[Ahrnuld]

Helemaal mee eens. En toch zien we nog heel veel mensen tot wie dit nog niet is doorgedrongen. Verandering gaat langzaam.

Scrum is een interessant stukje historie waar je zeker nuttige kennis uit kunt halen op weg naar iets beters. En zoveel organisaties ervaren weinig druk om te veranderen, en kunnen zo'n antipattern dus prima blijven toepassen zonder failliet te gaan.

Het is wat mij betreft een rode vlag in vacatures. Combineer dat in de praktijk met veel organisaties waar hard- en softskills als elkaar uitsluitende eigenschappen worden gezien, en je hebt een enorm uithangbord met 'kom hier niet werken' voor iemand die echt bij de tijd is. Maar genoeg mensen die wel in zo'n organisatie passen.

[Reactie gewijzigd door Ahrnuld op 23 oktober 2025 13:16]

[lennartvv]

Dit soort dingen lees ik graag. Weg met all de buzz words en opeenvolgende methodologieën om onze planning te maken en productiviteit te meten en vervolgens amper op te leveren. Doe eens allemaal terug normaal en laten we met ons gezond verstand plannen en opleveren.

Soms krijg ik echt genoeg van die corporate bullsh*t. Ik weet dat het allemaal niet snel zal verdwijnen, integendeel. Maar artikels als deze geeft mij hoop en bevestigt ook voor een groot deel wat voor een bubbel dit allemaal is.

We moeten misschien de agile scrum master evangelist die tijdens elke sprint retrospective ons holistic ecosystem alignment wil disrupten met thought leadership, even offboarden zodat hij elders zijn scalability kan optimaliseren.

Ik ben IT ontwikkelaar.

[djwice]

Komen jullie ook allemaal? Ik neem een trein simulator mee die echt gebruikt wordt om mensen op te leiden om het Nederlandse spoor. Dus niet een game, maar zo natuurgetrouwe simulatie.

[Reactie gewijzigd door djwice op 23 oktober 2025 14:41]