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

Ask HN: Do Agile 'Sprints' Benefit Software Developers?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 121 posts

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#81

Post by rajvarkala »

regularfry wrote: post #71
fidotron wrote: post #30

Capital 'A' Agile has become a total anti-pattern, and the most revealing signs of this are the two-week sprint, excessive meetings, and lack of technical leadership. By far the most productive teams I've worked with have been on six week iterations, with an at least approximate idea of what they're supposed to achieve in the next 90 days. One week out of that six is basically given over to demo, retro, and working o…

And that's great if your organisation has an attention span resembling something other than the usual squirrel on crack. The failure mode of iterations that long in my experience is incessant "can you just take a look at X, we need it for next week" interruptions that balloon out to consume the team's attention. With a 90 day iteration you can't say "let's get that into the next sprint (and leave me alone until then)…

[dead]

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#82

Post by peteradio »

agloe_dreams wrote: post #64
sys42590 wrote: post #40

I've worked agile for quite some years now. Please repeat after me: 1. The sprint goal is not a contract. The mental and physical well being of the developers always takes precedence over the sprint goal. The sprint goal is merely a guidance. 2. Not completing all stories at the end of the sprint should not make you feel bad. A sprint is always filled using estimates which never will be correct, and are often way to…

lol on #2: We had a funny situation where leaders were mad that tickets were getting carried over every sprint. We would then say that the velocity works out to the original planned velocity, the reason tickets would get carried over was that the devs would complete their tasks, then pull in tickets while the tasks went to QA for verification. Next sprint's ticket that would get pulled in would get done when it was s…

Lol, honestly how fucking stupid. Here you have managers failing to understand the most fundamental basic part of their job.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#83

Post by peteradio »

sys42590 wrote: post #77
cosmotic wrote: post #68

Earlier quoted context omitted.

It's remarkable how many people hurt themselves and their teams by considering sprint goals as must-complete. "We must complete the work we committed to!"

There are so many reasons sprint goals are abused, it can be it bad management culture trickling down, people in charge not understanding even the simplest points of the Agile Manifesto, or even weird companywide KPIs linked to Scrum or Kanban completion metrics that you can so easily pull out of most agile management software (e.g. Jira).

Our scrum lord told us his bonus is tied to these metrics so you can guess why managers and scrum lords behave the way they do in spite of the manifesto. Throw the manifesto out the window its complete bullshit because they say one thing and do another.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#84

Post by bick_nyers »

fidotron wrote: post #30

Capital 'A' Agile has become a total anti-pattern, and the most revealing signs of this are the two-week sprint, excessive meetings, and lack of technical leadership. By far the most productive teams I've worked with have been on six week iterations, with an at least approximate idea of what they're supposed to achieve in the next 90 days. One week out of that six is basically given over to demo, retro, and working o…

I am definitely more productive on the 6 week cycle, the 2 week cycle was too much overhead and friction for me, however I do recognize that some individuals (who were more senior than me) were more productive after our org. transitioned to the 2 week cycle, although I suspect this was more a result of higher oversight/scrutiny in their day to day more than anything.

I tend to view the work that I do as more engineering than it is development, frequently having to pull out the paper and math it out, so I think the problems I tend to work on are just fundamentally more difficult to corral into 2 week estimation chunks, but that could just be ego talking. When I started making investigation/research its own estimate that helped a bit. I think it's harder to investigate, justify, and perform significant refactors (or rewrites) on the 2 week sprint cycle, but not every team needs to do that all the time.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#85

Post by JohnBooty »

Me: 5-6 years doing Scrum (more or less) at 3 companies. 25 total years doing software dev.

First:

    Agile
"Agile" has no meaning on its own to me. Typically an ad-hoc free for all with a Kanban style board in my experience. It's a way for companies with no process to feel like they have a process. I'm not saying this is wrong but since the term is so amorphous I feel it is impossible to discuss.

To me Scrum is a specific flavor of "agile" with some specific ceremony and convention. I will be talking about Scrum below unless otherwise noted.

TL;DR -- I think one's opinions of Scrum largely depend on how good or bad one's experiences outside of Scrum are. If you have been on amazing and healthy teams, then Scrum surely seems like a bunch of unnecessary bullshit. Sadly I'm not in that boat, so I have found Scrum to be a net gain.

    Overcomplication, with an entire industry of 
    trainers, books, and seminars evolving around it

    [...] sprint planning seems overly complex
For most engineering efforts, we're going to need some meetings, planning, review, and collaboration no matter what -- right? At some point we have to herd the cats.

My experience is that Scrum does not represent an increase in ceremony/meetings relative to the somewhat chaotic and meeting-filled reality I have experienced outside of Scrum.

I don't think that Scrum is perfect, but I appreciate that it is a somewhat standardized process. It's like MVC or Git or 90% of the other shit we use. It's not perfect but there is value in a standard thing that is more or less understood by everybody in the industry.

    Autonomy. I'm not sold on this either.
I find Scrum almost entirely orthogonal to developer autonomy.

I have generally found that management/product rams shit down developers' throats no matter what. Scrum doesn't help here but I don't find that it hurts.

One small exception: if management has bought into these concepts, story points + sprint velocity do provide a somewhat objective or quantitative way to measure developer work. Again, I'm comparing this to the alternative, which is "the industry has never figured out a way to measure this." If management has bought into the concept, it can provide a way to push back against their demands when it comes to deadlines and scheduling work. Thus, some small boon to autonomy.

    we want a drama-free, predictable, and coordinated 
    work environment where we're respected
Well, Scrum adds to the predictability for sure IMO.

The other attributes... well, they have not typically existed in this industry anyway IME.

    If so, why and how do you make [sprints] work?
A common failure in agile/Scrum/sprints whatever is pressuring developers to estimate work (story points, whatever) before they have had a chance to really explore what needs to be done. For example, adding a feature to some legacy code the developer isn't familiar with... will it be easy or hard? No way to know until they've done some spelunking and maybe even an initial POC.

It's actually a fundamental concept in Scrum and I guess "agile" in general. However, I see teams absolutely dooming themselves with a failure to understand it all the time.

https://www.agile-academy.com/en/agile-dictionary/spike/

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#86

Post by bick_nyers »

sys42590 wrote: post #40

I've worked agile for quite some years now. Please repeat after me: 1. The sprint goal is not a contract. The mental and physical well being of the developers always takes precedence over the sprint goal. The sprint goal is merely a guidance. 2. Not completing all stories at the end of the sprint should not make you feel bad. A sprint is always filled using estimates which never will be correct, and are often way to…

Sounds like every team also needs a therapist to do agile correctly.

Only half joking!

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#87

Post by bick_nyers »

incognos wrote: post #70
cliff_badger wrote: post #22

Earlier quoted context omitted.

Isn't the task itself time boxed by the points you assign to the story? > "It is a 2 point story, why have you taken three weeks to complete it?"

Because sometimes you stumble on a graveyard and you end up cleaning out the corpses of developers past.

Beautifully put.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#88

Post by mydriasis »

freedomben wrote: post #65
mydriasis wrote: post #2

I like sprints because they're discrete. We agree to a certain bit of work that can get done in a certain period, and we do our best to complete it. It helps us to think about breaking up our tasks, and how tasks can be broken up. At the end of the sprint, we get to take a bit of a breath, and prepare for more upcoming work. Kanban style means that it's just a marathon. There's no time to stop and take a breath, ther…

Do you actually get to take a break or a rest when finishing the sprint work early? In 10+ years of doing sprints, I don't think that's ever happened to me or my team. In practice if we finish early (which is rare, maybe 1 in 5 sprints) then we try to jam in some refactor or performance fix or bug fix or something, and that ends up taking at least the remaining sprint time. There is never a chance to catch a breath.

No -- that's not quite what I meant -- more of a "logical break" in the work. A chance to come up to the surface and gasp a moment before diving back in for more on the same project or set of tasks because there was a clear breakpoint.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#89

Post by regularfry »

AndrewDucker wrote: post #74
regularfry wrote: post #67

Earlier quoted context omitted.

> If you're changing multiple different components then you need to sync them all up so that they're all releasable at the same time You don't need to sync them all up at all. In the majority of cases it's feasible to release multiple changed components one by one. Doing so results in better outcomes than trying to aim for big bang releases. > WIP limits are great until you're waiting for more information from a supp…

Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? I do not think I want to work with people like that. Things can not always be done instantly to fit the whims of developers. The customer may need to get together a few people and discuss what they want, which may t…

> Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do?

It depends on context, but I won't write it off.

Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%.

If you actually don't care about WIP, sure, pick up the work.

> Things can not always be done instantly to fit the whims of developers.

It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do.

> I do not think I want to work with people like that.

That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.

Re: Ask HN: Do Agile 'Sprints' Benefit Software Developers?

#90

Post by JohnBooty »

PaulHoule wrote: post #5

Positive: The alternative to sprints is frequently no process at all, not the strawman waterfall. If you can't plan two weeks of work there is no way you can plan six months work of work. Sprints mean that conflicts get surfaced regularly and not "kicked down the can" for eight months. Teams that don't release regularly don't know how to release. so they'll plan to spend six months developing something and think they…

     The alternative to sprints is frequently no 
     process at all, not the strawman waterfall.
Yeah. I see criticism of agile/sprint/Scrum practices all the time and I just think: to what are these people comparing these practices? Developing a solo hobby project where there's no collaboration, scheduling, or management to worry about?

My experience over 25 years in this industry has been that it's a fairly chaotic place, filled with meetings and management and overhead. Every shop, manager, and team generally had its own ad-hoc and ever-shifting "process" or lack thereof.

I find that Scrum, while highly imperfect, is generally a step forward over that mess.

    I've worked on others where it was debugging, 
    understanding existing code, research, and resolving 
    circular situations and in those cases [estimation
    is impossible]
Yeah. The only resolution to this is a healthy respect for the time it takes to produce an accurate estimate. That process must be viewed and respected as a separate task, with an according amount of time allocated to it.

This is actually a fundamental concept of Scrum: https://www.agile-academy.com/en/agile-dictionary/spike/

But in my experience, teams absolutely shit the bed when it comes to this. Management wants estimates but does not want to allocate the time needed to come up with good ones.

Post reply on HN