Live data from Hacker News

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

news.ycombinator.com

101–110 of 121 posts

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

#101
post #99

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…

^^^ This here everybody! The much bemoaned waterfall is not a development methodology, it's a project management methodology. The developers had no process at all. That's an important point missed by developers who've never known anything other than agile development. From a developer's perspective it's not agile or waterfall, it's agile or nothing at all (typically). Agile, with its warts and all, is far better than…

    Agile, with its warts and all, is far better than nothing at all. 
Yeah. You see criticism of agile, all of which is generally totally valid, but I never see alternatives mentioned short of "have a team of top X% developers with a clear shared understanding of all objectives and essentially no interference from management and no unreasonable deadlines."

Which, well... I mean, great if you can get yourself into a situation like that. That sure is better than agile. It is the ideal I yearn for as an engineer.

I just don't think that's realistic for most engineering endeavors. At some point, engineers need to recognize that interfacing with the rest of the company (product owners, etc) is a big part of the job and really embrace it. It's also typically the only part of our job that is not easily outsourceable, so it is in our best interest to embrace this.

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

#102
post #37

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?"

This is only a guideline, don’t treat it like a hard rule. There could easily be good reasons why a 2 point story took three weeks. Also gotta stop the negative bias. People will want to complain easily if your 2 point story takes you three weeks, but no one will be singing praises if your 5 or 8 point story is done in a day.

    There could easily be good reasons why a 2 point story took three weeks.
If it was because you were interrupted and given other priorities, that is totally valid.

If it was an estimation failure, that really needs to be looked at and learned from.

I find that this is typically a problem with management and/or process, not the engineer. We as an industry typically do not respect the time it takes for engineers to produce an accurate estimate. This time itself needs to be treated as a first-class concept and time needs to be allocated to it which, in practical terms, often means it needs its own task/card/story/ticket/whatever in the framework of one's choice.

There are nearly always unknowns (typically some kind of externality or legacy code) to explore before we really know how much time something will take.

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

#103
In my experience, a continuous stream of frequent iterations is very effective, but the driver for the early iterations must be "eliminate risk", not "deliver value". Sources of risk include novel functionality, the architecture's ability to support the functional and non-functional requirements, dependencies on external teams/tools/services, and politics.

Focusing on value delivery before the big risks are eliminated often results in facing a nasty decision: rip up a lot of already-laid track, or live with a sub-optimal organization and/or project structure.

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

#104

I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?" I do NOT like the idea of a hard beginning/end of sprint, it's a pipeline stall. I generally like to have something I'm planning, something I'm working on, and something I'm working t…

    "here are the things I'm committed to for the next 
    two weeks. Which of them should I not do to make 
    room for this new priority?"
Yeah. People will scoff at this and say that you don't need agile or sprints for this. And they're correct, but naive.

Certainly I have successfully done this in the past without fancy agile religion or ceremony. In fact it's a valuable skill for any job in any industry.

But it has always been hard to do and I'm sorry, but most people (both engineers and managers) are bad at it most of the time. The industry clearly needs help with this concept.

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

#105

I've done waterfall and agile over 20 years and have yet to see a SCRUM like system deliver for either the business or the developers. Agile (regardless of SCRUM, Sprints, LEAN, KANBAN etc) only works where the whole project breathes it from business client to support. The contract can't be fixed term, fixed price and fixed scope and be agile. The closer you get the client to the project, the higher the chance of suc…

I have seen all of those things happen! They are real pitfalls!

But I truly do not follow your reasoning here. What you are describing here are truly odious management practices that violate just about every tenet of those methodologies.

This seems to be like blaming a recipe instead of a cook who willfully, knowingly contradicts the recipe at every possible moment.

Thoughts?

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

#106

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…

How does a 6 week cycle work for planning? We do 3 weeks but each HOUR has to be assigned to a developer which obviously isn't accurate.

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

#108

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…

How does a 6 week cycle work for planning? We do 3 weeks but each HOUR has to be assigned to a developer which obviously isn't accurate.

I mean, you know this, but 3 or 6 weeks isn't going to help if your problem is unrealistic micromanagement.

The underlying management problem there is they're more concerned about hours worked than work completed.

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

#109

After over a decade of this, I'm convinced "agile" (scrum, really) was created to provide more jobs for product managers and create fluff roles like "agile coach." It may have more value for less experienced teams. More experienced developers will become frustrated by the ceremonial nonsense. I prefer the kanban style.

Much how we all fear Windows: an MBA's worst nightmare is nerds hogging all the good tech jobs. If a few adjacent roles get invented for a friend so be it, why spoil the party over a few implementation details?

Mostly because it wastes time (and money, for the company.)

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

#110
Scrum is a method to allow agile development to sort-of work within a management structure that needs waterfall. It provides observability of work getting done by developers, without as much up-front external design as waterfall. It's not intended to make developer's lives easier, it's entirely for management's benefit. It reduces the ability to respond to change, but in return provides management with easier scheduling.

That extra scheduling is sometimes not important, but often it is. If you have external vendors or contractors they'll have their own schedules; your company will be paying them for their time whether you can keep them working or not. Predictable delivery can be very important. E.g. if you're making a hardware device, you'll have a "slot" in a factory schedule. If your firmware is late, you're still usually paying for that time slot (the factory employees still get paid), and you're paying extra to get another time slot (as well as for any downstream delays).

Post reply on HN