undefined | Better HN

0 pointsmgkimsal3y ago0 comments

> How would it be better without sprints, though?

kanban, deliver something when it's done (even incremental when possible), fast feedback...

The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting.

You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.

0 comments

the_af3y ago

Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology.

Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.

mgkimsalOP3y ago

And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments are worth it or not.

Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.

the_af3y ago

Agreed, but is anyone arguing that the team shouldn't decide?

mgkimsalOP3y ago

Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.

The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.

j / k navigate · click thread line to collapse

0 comments

the_af3y ago

Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology.

Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.

mgkimsalOP3y ago

the_af3y ago

Agreed, but is anyone arguing that the team shouldn't decide?

mgkimsalOP3y ago

The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.

j / k navigate · click thread line to collapse