Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm skeptical about retrospectives.

We've certainly done them, identified problem points and then solved them (and it does feel good to do that..) but it doesn't actually seem to make things better.

Lets compare it to say, personal estimations:

When you estimate, execute and reflect, you can tangibly improve your estimation process.

You can quantitatively observe an improvement in estimations on tasks when people go through this process.

Previously; estimated 20 hours for (task). Took 10 hours. Repeat... soon, your estimates are for 10 hours, and you're quantitatively, objectively able to make consistently better estimates.

Retrospectives in my experience don't do that.

You can sit through 50 retrospectives and each one identify a problem area and then fix it and yes that does feel good, but objectively when I reflect over the defect rate as a result of the process, I feel like retrospectives make zero impact on the rate at which technical debt accumulates.

There's something missing in the way they work; all you (well, all we, I suppose, this being my personal experience...) ever do is find things that are wrong and fix them. Objectively when you look at it, there's no closing of the loop where the defect rate drops.

There's no process improvement that generates less problems in the future... all it ever is is band-aiding to prevent technical debt spiraling totally out of control and devastating the project.

There must be a better way, where you somehow measure how technical debt was created and work to incrementally prevent it happening... but I've never seen that actually happen in practice.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: