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

331–340 of 459 posts

Re: I don’t believe in sprints

#331

Post by dolmen »

usrusr wrote: post #308
tanseydavid wrote: post #284

Earlier quoted context omitted.

>> could have it right now if you add 2 days to the sprint. Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.

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.

Re: I don’t believe in sprints

#332

Post by the_af »

mgkimsal wrote: post #320
the_af wrote: post #276

Earlier quoted context omitted.

> In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal. > The system is only as good as the weakest participant. I…

> 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.

Re: I don’t believe in sprints

#333

Post by jrs235 »

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.

>stakeholders weren't onboard with no fixed cadence of deliveries.

Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)

Re: I don’t believe in sprints

#334

Post by the_af »

peteradio wrote: post #330
the_af wrote: post #217

Earlier quoted context omitted.

That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing. When done well, any iterative method is meant to provide ear…

If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.

With sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise.

More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.

Re: I don’t believe in sprints

#335

Post by kortex »

samatman wrote: post #229
kortex wrote: post #90

Earlier quoted context omitted.

I thought "sprint" was dumb at first, for exactly this reason, it's not a sprint if it's week after week. But over time it's just become jargonized, a term of art for me. It's just a unit of organization.

My high school mentor loved to say "beware of inconvenient fictions!". The most boring choice would be "section", and boring might be good here. We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round". I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling…

Absolutely, I completely agree with every point in this comment. Round would have been a much better and more neutral term for "one unit of agile work". "Sprint" is tantamount to "bursty and not sustainable".

Same with "ceremonies", that one bugs me too, though not as much.

I still don't know WTF a scrum is however (not even sure that's an agile-specific term).

> The fundamental unit of scrum is a small team of people, consisting of a product owner, a scrum master, and developers. The team is self-managing, cross-functional and focuses on one objective at a time: the product goal. [1]

Like, what? I feel like I know less after reading that. That just sounds like...a development team with a team lead and a manager.

1 - https://en.m.wikipedia.org/wiki/Scrum_(software_development)

Re: I don’t believe in sprints

#336

Post by _ea1k »

HelloNurse wrote: post #156
websitescenes wrote: post #69

Earlier quoted context omitted.

I think maybe there is a conflation being made between Agile and Scrum.

An almost deliberate confusion between the agility of making changes to software easy and the agility of running like hell because you are chased by deadlines.

Since when was scrum about deadlines?

Re: I don’t believe in sprints

#337

Post by dasil003 »

groby_b wrote: post #293
shagie wrote: post #237

Earlier quoted context omitted.

Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all. The sprint forces a "this is what we're d…

Hot take: If you take three months planning , either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest) And the third paragraph kind of lays bare the problem with sprints: The PM…

Exactly this. That is why the Agile Manifesto said to favor "Individuals and interactions over processes and tools". The problem is that approach only works when you have a team of experts with clear goals and enough space to address them. It doesn't necessarily lend itself to being quantifiable or standardized across multiple teams (depending on the problem), so the bean counters and middle managers get nervous. This is an environment ripe for agile consultants to swoop in with the siren song of the silver bullet process du jour.

Re: I don’t believe in sprints

#338

Post by coryfklein »

One could write a solid critique of sprints and how they help or don't, and where time is wasted, but this article is overzealous and comes off as motivated more by anger than reasoning.

If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0].

[0] https://www.youtube.com/watch?v=QVBlnCTu9Ms&t=7s

Re: I don’t believe in sprints

#339

Post by HelloNurse »

_ea1k wrote: post #336
HelloNurse wrote: post #156

Earlier quoted context omitted.

An almost deliberate confusion between the agility of making changes to software easy and the agility of running like hell because you are chased by deadlines.

Since when was scrum about deadlines?

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

Re: I don’t believe in sprints

#340

Post by js8 »

robertlagrant wrote: post #245
js8 wrote: post #126

Earlier quoted context omitted.

OK, I take it your answer for visibility is management reporting, I am not sure about predictability, you didn't really answer it. SW development is as predictable as much you're willing to invest into research/planning, and that very much overlaps (as observed in Kanban) with doing the actual work. When I started SW development in 2005, we had one meeting a week (Friday) with our boss, where we summarized what progr…

> OK, I take it your answer for visibility is management reporting, I am not sure about predictability Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.

If you want to know how long it will take to develop a feature, just create a task for this research/design/planning and schedule it as usual in Kanban. Still, no sprint required.
Post reply on HN