Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don’t believe in sprints

robinrendle.com

Post reply on HN
Print view View original

341–350 of 459 posts

Re: I don’t believe in sprints

#341

Post by pevey »

LtWorf wrote: post #176
pevey wrote: post #63

Earlier quoted context omitted.

I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.

That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.

You never know if you have really completed the "figure it out" task until the "get it done" task is completed.

Re: I don’t believe in sprints

#342

Post by didgetmaster »

Like every trade, software engineering depends on a set of tools designed to help 'get the work done'. These tools can be hardware (e.g. laptops, servers, test equipment), software (e.g. languages, compilers, source control), or methodologies (e.g. agile, waterfall).

Each tool should be evaluated (and periodically re-evaluated) to see what its 'leverage factor' is for your situation. For every unit you put into it (time, effort, money) how much do you get out of it? The best tools give you a 10x or better leverage factor. If a tool gets in the way (i.e. it has a 1x or lower leverage factor) then it should be ignored.

Some tools are just bad (they take more time and effort to learn and to use than they save you) and are generally weeded out. Some are great for certain situations but bad for others.

If sprints (or any other tool) are not helping you and your team, then try to figure out why. Is the tool just not a great fit for our situation (e.g. using a hammer to try and fix a car engine)? Are we using it wrong? Is there something better?

Too many companies and managers go for the 'one size fits all' approach. "This worked at my last company so it must work here too!"

Re: I don’t believe in sprints

#343

Post by mgkimsal »

the_af wrote: post #332
mgkimsal wrote: post #320

Earlier quoted context omitted.

> 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 s…

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.

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.

Re: I don’t believe in sprints

#344

Post by RamblingCTO »

gbro3n wrote: post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

If you do scrum properly you shouldn't have a lot of meetings for "planning and ceremonies". We follow "scrum and xp from the trenches" quite closely. We have four meetings: - scrum planning (max 1h/week of the sprint)* - dailies (max 15 minutes per meeting)* - demo (we like to call it sprint review, because it's interactive, not one-sided). takes about 30 minutes - retro (takes an hour)

*most of the times we use a lot less

So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.

Re: I don’t believe in sprints

#345

Post by _ea1k »

HelloNurse wrote: post #339
_ea1k wrote: post #336

Earlier quoted context omitted.

Since when was scrum about deadlines?

Managers are about deadlines, and I'm afraid Scrum is about managers.

Its weird how far things have come from the original goals: https://en.wikipedia.org/wiki/Agile_software_development#The...

I'm seeing a lot of processes and tools over people and interaction in more recent iterations of Scrum implementations.

Sprint commitments were originally the opposite of imposed deadlines.

Re: I don’t believe in sprints

#346

Post by manmal »

droopyEyelids wrote: post #270
manmal wrote: post #252

Earlier quoted context omitted.

> I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.

Are you asking because you read dbingham as saying sprints were a requirement for that? I didn't interpret 'necessary' in there at all- but rather that method of organizing work tended to produce that type of result.

My question still stands - how are they related to each other? I can see what others are working on by looking at the issue board or just asking. And I haven't experienced that sprints contribute to devs having a say in anything.

Re: I don’t believe in sprints

#347

Post by b3morales »

dolmen wrote: post #331
usrusr wrote: post #308

Earlier quoted context omitted.

Do you "modulate" a sprint's length once a year, once a month or once a week? I've seen open sprints named after a pair of calendar weeks multiple months in the past. And for some reason those were still called "sprint". I'd call unwillingness to modulate rather low on the cargo cult scale.

We modulate sprint length based on resources available. There is no point to keep a strict 2 week sprint if during one week most of the team will be on vacation (ex: Christmas), so we make the sprint duration to 3 weeks.

I am curious why you would change the duration rather than changing the workload. Sprint velocity is a ratio of both components: either can be adjusted to preserve it.

Re: I don’t believe in sprints

#348

Post by marcosdumay »

the_af wrote: post #283
mgkimsal wrote: post #225

Earlier quoted context omitted.

A more fluid "here's what we're prioritizing next" approach. is that 'kanban'? (I think so?) Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases.…

Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology? Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.

> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!"

Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban.

Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won't save you.

Re: I don’t believe in sprints

#349

Post by etblg »

ejb999 wrote: post #100
kixxauth wrote: post #56

Earlier quoted context omitted.

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.

And with the same result, you can't expect someone building your house to finish it on time, on budget, the same way you expected it to be built going in to it. Construction projects in the real world end up the same way software projects end up -- with ~ ~ unforeseen ~ ~ delays and complications.

Re: I don’t believe in sprints

#350

Post by marcosdumay »

pnut wrote: post #178
bluGill wrote: post #149

Earlier quoted context omitted.

Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release. It doesn't matter if you have sprints of kanban, if there is a…

Funny how whenever I've done kanban, top tech debt items always are eternally pushed down to #5 or 6 in the backlog, never to see the light of day. I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.

Do not let formal debt and improvements compete on the same ranking.

Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.

Post reply on HN