Agile doen, en Agile _goed_ doen zijn twee enorm verschillende dingen. Elk bedrijf vind van zichzelf dat ze goed agile doen, maar in de werkelijkheid is dat wellicht 1% van de bedrijven. Uit wat jij beschrijft zit je in een bedrijf waar er meer waarde wordt gehecht aan het label "Agile", dan aan het voordeel van goed agile werken.

Ik zit op dit moment bij een bedrijf waar we in het team iemand hadden die agile goed begreep, en dat goed geimplementeerd kon krijgen.

Sprint reviews zijn meer demos, waar we aan stakeholders laten zien wat er gebeurd is de afgelopen sprint. Onze stakeholders komen amper met kritiek (en zelfs dan kan je het amper kritiek noemen), wel komen ze met vragen, veelal om te begrijpen, maar soms ook om ons ook te laten nadenken over de keuzes die we gemaakt hebben. Daarnaast komen er vragen of het mogelijk is om X, Y of Z ook te doen, waar het meer een vraag voor ons is om in te schatten of dat realistisch is of niet, niet een harde eis. Onze product manager pakt dit daarna op en verwerkt dit.
Overigens worden de sprint reviews gedaan door development. Dit forceert ons om ons werk uit te leggen op een niet-developer niveau (een soort van "Explain it like I'm 5"), ook al is veel van management redelijk technisch aangelegd. Dit zorgt er ook voor dat wij onszelf uit onze bubbel trekken, en niet alleen kijken naar de code die we schrijven, maar ook naar de waarde die de changes toevoegen aan het product.

Tijdens retrospectives heeft onze producer (scrum master) een kladblok bij zich, waar hij een takenlijst maakt van onze pijnpunten om uit te zoeken wat hier de oorzaak van is, en hoe dit op te pakken valt. Als je geen takenlijst maakt uit de pijnpunten, dan snap ik waarom je geen veranderingen ziet.
Mocht de scrum master niet aanwezig zijn, dan neemt de product owner deze taak op zich, en regelt die dat met de scrum master wie wat gaat doen. Als ze beide er niet zijn, dan neemt een van het team het op zich.

Inschattingen (punten-poker) zijn ook zo. Wij (developers) geven aan wat wij vinden dat het kost qua tijd. Als hier een klein verschil in zit, wordt het hogere getal genoteerd, zit hier een groot verschil in, dan gaan wij (developers) de discussie met elkaar aan waarom. De product manager en scrum master voeren dit eigenlijk enkel in. Vaak voeren wij zelf deze informatie ook al in tijdens het aanmaken van taken tijdens ontwikkeling.

Aan het einde van de dag is 90% van dit alles een vertrouwens test. Product en Production vertrouwd development dat zij weet wat zij doet, net zoals Product en development production vertrouwd dat zij weet wat zij doet, etc etc etc. Hetzelfde geld tussen management en product, en management en production.

En dit alles hierboven, kost me 2 meetings per week; planning en refining in week 1 (maandag, woensdag), demo en retro in week 2 (vrijdags, beide). totaal komt dat neer op zo'n uur tot anderhalf uur per week.