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

71–80 of 121 posts

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

#71

Post by regularfry »

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)" as often as you can with a two week or a one week sprint.

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

#73

Post by Lutger »

icedchai wrote: post #57
2023throwawayy wrote: post #48

Earlier quoted context omitted.

> slight sense of urgency This is my biggest beef with agile. The urgency is false, stressful, and unnecessary. If you're always in a "sprint" you're never actually sprinting. No one can sprint forever.

The urgency is often fake. You complete your sprint, only to find out you built a feature nobody needed any time soon (or maybe ever.)

This is my biggest beef with deadlines in general and sprints in particular. The urgency is fake, but the cost is not.

It is not 'free' to set a random deadline. You will pay with productivity and quality and cause stress. There is no way around it, so do it for a sound reason.

These days if somebody sets a deadline I always probe them to find out why. "What happens if we are a week late, a month? Is there a reason for that date?" This often annoys people, which reveals me they don't really know what they are doing and it is not actually a real deadline. Just something that people think that project management is.

99% percent of deadlines could be replaced with something like: "this feature is worth a ballpark of 2 to 5 weeks of the team to me. Can we make it? Keep me posted if it doesn't work out, I want to know so I can consider dropping it and pivoting to something else, even when we already invested 4 weeks in it."

That is a reasonably thing a manager can ask, and more often than not developers can actually answer this in a much more efficient way than detailing and monitoring a sprint plan.

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

#74

Post by AndrewDucker »

regularfry wrote: post #67
AndrewDucker wrote: post #14

CI/CD only helps release often if you're only producing one component. 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. A sprint gives you a deadline for everything being releasable again. WIP limits are great until you're waiting for more information from a supplier on one ticket, feedback from a customer on another, and help from an…

> 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 take a few days to schedule. People may be doing other important things and not instantly free to drop everything to get you what you need. You may need to realise that you are not the center of the universe.

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

#76

Post by brainwipe »

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 success because only they truly know where to cut scope or what minimum viable release looks like. There should be no surprises, fast loops ("I don't love that feature but I can wait until next release, it's good enough for now") and financial realism.

How you then organise yourselves doesn't really matter. Right now I'm at a company that's multi-tenant kanban, we release when the code is ready. That could be every 2 days, it might be once every 3 weeks. The product manager, who is very close the customers, decides when to push what's been coded out. It gets merged and then into the test/UAT pipe. Releases are cheap, test has a lots of regression automation. I describe it to management as a river. Keep the tickets flowing like water. Get rocks out the river, make it wider with more people or faster with better tech/stack/devops/etc.

Everywhere I've worked that has had a strict SCRUM ended up being micro-waterfall where devs might story point 1 sprint but the management would plan out the next 5 to get to a release date, story points were converted into estimates, which were converted into deadlines, guesses became promises and scope could never be cut. Developers end up burning out and that vital domain knowledge is lost (the worst companies think devs are interchangeable). It was almost worse than waterfall because with waterfall the project managers got the blame, with SCRUM, it's the devs that carry the can. As one colleague said after a ridiculous meeting where our story point estimate was being compared with another team on another project in another country "it's just a stick to beat developers with". And he was right.

You mileage might vary! My experience only.

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

#77

Post by sys42590 »

cosmotic wrote: post #68
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…

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

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

#78

Post by Lutger »

wpietri wrote: post #56

Hi! I was involved in the Agile movement before the term existed. I came up through the "Extreme Programming (XP)" school of thought, and later on the "Lean" one (in the Poppendieck sense of the term). Here's my take. The "sprint" is an artifact of the transition away from waterfall. Getting people to go from an 18-month planning cycle to a 30-day planning cycle was an actual advance. But as you are seeing, it has it…

This rings true to me. The way scrum works in practice is a, forgive my language, perverse inversion where the process has become the goal and the outcomes are less important.

I worked with 4 weeks, 2 weeks and 1 weeks sprints, and with 'just kanban' as well. I now work with Shape-Up, where the build cycle is 4 to 6 weeks, but rather than having a backlog we just have a defined (and designed) problem solution and get to create user stories (or whatever) when we need it and often fill in a significant amount of detail as we start tackling the problem space.

We started working in pairs, sometimes but not always pair programming, so most of the planning work is just with your buddy and fairly ad-hoc, it doesn't cost the whole team. This works pretty well.

But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.

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

#79

Post by _jesse »

Nope, hate sprints. Continuous planning works much better in my experience because it is _actually_ agile. It lets you constantly reset what your current priorities are. It lets you plan out projects and think about the projects and what it's going to take to get them over the finish line, without the constraint of "well, what do we think will fit into the next two weeks"? Also, sprints totally strip autonomy from engineers, I don't know why anyone would argue that they give engineers more autonomy.

Honestly, I just really hate the arbitrary timebox and all the problems it brings. You totally don't need sprints to do anything that's a part of the scrum process. Want to be more introspective as a team? Schedule a meeting every few weeks to talk about problems you're facing as a team and how to solve them. Want to plan out your work in advance? Cool, do that for every project you're going to be tackling.

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

#80

Post by dragonwriter »

Lutger wrote: post #78
wpietri wrote: post #56

Hi! I was involved in the Agile movement before the term existed. I came up through the "Extreme Programming (XP)" school of thought, and later on the "Lean" one (in the Poppendieck sense of the term). Here's my take. The "sprint" is an artifact of the transition away from waterfall. Getting people to go from an 18-month planning cycle to a 30-day planning cycle was an actual advance. But as you are seeing, it has it…

This rings true to me. The way scrum works in practice is a, forgive my language, perverse inversion where the process has become the goal and the outcomes are less important. I worked with 4 weeks, 2 weeks and 1 weeks sprints, and with 'just kanban' as well. I now work with Shape-Up, where the build cycle is 4 to 6 weeks, but rather than having a backlog we just have a defined (and designed) problem solution and get…

> But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.

This is the heart of agile, but rarely gets implemented, in part because the Agile advocacy was not largely directed at the people who make the decisions that make implementation possible, but at people who lack that power.

Post reply on HN