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

I find it works well in two situations:

1. Protecting a software team in a non-software organization. In this situation the team has no voice in prioritizing work, is under constant pressure to deliver, and is generally viewed as a cost-centre by leadership.

Taking a lead role and introducing an agile/scrum-like process is a way to deflect unreasonable demands off of the team. The goal is to convince leadership that deadlines aren't as important as progress. Demonstrating regular progress and having check-ins is a way to console the existing leadership and build trust with them while the team gets breathing room to address their concerns and learn to prioritize what needs doing with what users want to be done.

Don't get too invested in it. The incumbent leadership might try to wrest control of the process back from the development team. If they get involved you'll notice more meetings, new job roles, and presentations with charts and diagrams explaining how the scrum/agile process works. This is plain old Taylorist micro-management sneaking its way back in. Be prepared to give up on agile/scrum before it gets to this point or make sure that your team is in control of the process and not external stakeholders.

2. Establishing a new team with customers in the absence of management. In this situation the customer is basically your manager. And they will want deadlines because money. Similar to the first situation, agile/scrum here is about managing expectations and getting parties on two sides with different priorities to work together and trust one another. If you can build up that trust you can ease off on the agile/scrum stuff as needed.

In every case the important part is that the development team, the people writing the software, are in control of prioritizing what work gets done and how it gets done. As soon as you have diagrams and presentations and several layers of "managers" involved in directing a software team you've entered into the Agile Industrial Complex and have dropped the ball.

Caveats: you will find that some developers will refuse to work with customers. They do not want to co-operate with management. They only want to write code and view any process to manage work as a waste of time. The important thing to remind them of is that you don't need to use any of the scrum/kanban/whatever processes forever. The goal is to get management off your backs by showing them your team can deliver results by shipping stuff on a regular cadence. Once things get into place you can change the process to whatever works for your team as needed. That's the whole point of being "agile." No need to cargo-cult rituals for the sake of performing work. Do it until you get the trust you need to get back to work.

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 through review on. If I have to be 100% delivered at the end of the sprint that means I have to budget to be finished with all work and just be sitting around herding PRs the last 2-3 working days.

We don't do sprint planning until the first day of the new sprint so I can't really start speculatively executing on next sprint. So I usually overcommit a bit just so I will have stuff in progress at the end of the sprint, and then just eat the PM stinkeye when we don't burn it all down.

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

If you keep turning up the dials, as the XP folks tend to do, you get to weekly cycles. Those are about the smallest effective "sprints". I like them a lot better than monthly sprints, which are much more likely to be mini-waterfall in orientation.

At a weekly cadence, you can start to see what might be beyond that. For me that generally involves a weekly meeting schedule, but otherwise a Kanban-ish flow of work with strong WIP limits and aggressive effort to keep work unit size to be well under a week.

So yes, I think you're correct that continuous delivery (which was invented well later than the original Agile methods) means that sprints no longer have a release-related reason for existing, especially when you have a good feature flag practice.

In practice, I think humans do need some regular rituals and that some planning work is better off batched, so I'm ok with keeping some sprint-like rituals, like a weekly planning meeting and a weekly retro. But I think high-functioning teams treat those as convenient sync points with flexible adaptation of plans as new learning happens over the course of the week.

And yes, I think the Agile community broadly got stuck in a mini-waterfall space rather than what I think of as actual agility, so your read there is correct too. I think the main driver of this is managerialist ideology [1], which centers managers as the vital actors in business. In contrast, flow-based processes like you describe make managers mostly irrelevant. Unfortunately for those of us who like to actually get things done, managerialism is the dominant ideology in American business, so much so that its tenets are not only mostly unspoken, but that alternatives can be unthinkable to many. So I expect things like "scrummerfall" and SAFe to continue to dominate large-company software development for the forseeable future.

[1] See https://en.wikipedia.org/wiki/Managerialism and https://www.amazon.com/Confronting-Managerialism-Business-Ec...

Sprints do give faster feedback, early value and autonomy, but only in contrast with planning the complete project upfront in utter detail and committing to a deadline. It's a compromise. Instead of planning a whole project we just do two weeks and go from there.

Its a nice idea but it often doesn't pan out in practice. The sprint is way too detailed, the team gives too much time and attention to planning the next two weeks and too little to what comes after, often people don't really know what to do when they finish early or don't make the sprint, etc. But most of all, everything becomes this game of predicting the sprint and finishing it rather than solving the most important business problems right now. It becomes a bureaucratic thing (in a bad sense).

For me, two weeks is usually too small of a timeframe to get something really meaningful done, so the sprint goals feels like a collection of random things we stuffed in two weeks. Most people also adhere religiously to the goal of 'achieving the sprint', which pushes the team to planning together in way too much detail. Not achieving the sprint feels like failure and you will get 'punished' if only by disapproval. We should take it as feedback and rejoice in the opportunity to hone our estimation skills, but in reality it functions as a reverse gamification mechanism making devs conservative and risk avoidant.

In an ideal situation, what sprints give you is control over delivery schedules. But this control always comes with a price, and two weeks into the future isn't far enough by far. It's never free to set a hard deadline. So you pay with lower productivity in order to get higher control over schedule.

I think its better to set looser goals, have a course roadmap of things you will be working on, problems you want to solve, but don't fret over 'velocity' and 'story points', just like you are not counting lines of code produced per day. Story points are meaningless, what matters is if you have solved some problem. That is what gives you autonomy, value and feedback, not 'achieving the sprint'. Nobody cares about that.

So, for some adversarial reading, I recommend taking a look at: https://basecamp.com/shapeup (The digital copy is free) I'm 100% sure that the CTO is a megalomaniac and that the actual author of the book was fired for idiotic comments...but the book has some pretty wild alternative ideas of how you can plan and accomplish work that are focused on delivering work rather than charts for CTOs. The book does make some base assumptions though: 1. You have good workers who think independently. 2. Your org allows you to have task-based teams, that is: Teams made up of a designer, an accomplisher, and a manager. 3. It works better when work can be done without external factors impeding it. 4. Your leadership takes the time to set the vision in stone and agrees to it. (This is generally the biggest issue with sprinting: You are allowed to change direction too rapidly so larger projects rarely get accomplished on time as priorities flip-flop.)