Live data from Hacker News

I don’t believe in sprints

robinrendle.com

301–310 of 459 posts

Re: I don’t believe in sprints

#301
post #178

Earlier quoted context omitted.

Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release. It doesn't matter if you have sprints of kanban, if there is a…

Funny how whenever I've done kanban, top tech debt items always are eternally pushed down to #5 or 6 in the backlog, never to see the light of day. I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.

Agreed.

As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!

Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.

I don't know of a better way. Perhaps it comes down to human factors such as limited focus.

Re: I don’t believe in sprints

#302

I think the (unpopular) reality here is that there just really isn’t a lot of traction for one-size-fits-all project management. Methodology and even terminology has too much marketing budget attached to it to be trusted. There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of…

> Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”.

Unpopular? On the contrary, I'd think that position would be popular with us hackers because it's saying what we want to hear, about how special we are. For that reason alone, I'm not sure I buy it.

Re: I don’t believe in sprints

#303

Earlier quoted context omitted.

In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile. The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our compan…

I tend to think of communism as a comparison. Aren't proponents of "agile" similar to those saying "we've never had real communism"? Both have manifestos. I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.

Well put... Animal Farm is really about Agile.

All engineers are equal, but some are more equal than others!

Re: I don’t believe in sprints

#305
post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules.

Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.

We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.

It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.

Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.

I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.

Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.

Re: I don’t believe in sprints

#306

I'm a PM and PO. I have a scrum team of 5 engineers and 4 QA. Sprints are killing me. It's so exhausting. No rest, ever. And the retros are almost purely negative.

PM is a full-time job on its own, and it doesn't match up well at all with being a PO! You should probably try and find someone else to do one of those roles.

If your retros are super-negative, then try limiting everyone to one positive and one negative comment/post-it each per retro, and when you discuss the retro comments, talk through the negative ones first and the positive ones last so the retro ends on a positive note. Limiting people to a small number of comments forces people to consider the things that really got in the way rather than raising every little moan they have.

There are lots of different ways of doing retros, and as PM you are ultimately in charge of facilitating a useful retro. If the retro is overly negative then it becomes less useful.

Re: I don’t believe in sprints

#308

Earlier quoted context omitted.

I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months. It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.…

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

Re: I don’t believe in sprints

#309

"Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles". I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I…

> "Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles".

Agree. Actually, my first experience with Agile used the term "iteration" instead of "sprint" which I thought made much more sense. Everywhere else I've been has used the word "sprint". I suppose a "sprint" does includes three parts: start, run, stop; parallel to an iteration of the development cycle: branch, develop, reintegrate.

My paranoid, anti-management brain still thinks the fact that sprint for most people is associated primarily with speed rather than starting/stopping is a feature, not a bug. In this case idea of always being in a "sprint" is inherently stupid and insulting.

Anyway, another word to file alongside "grooming" for Agile words with unpleasant associations.

Re: I don’t believe in sprints

#310

Earlier quoted context omitted.

> When a sprint starts, what QAs people are expected to do ? Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.

We may not call people QA, but in the end each person has different skills, and the same problem will arise inside developers. Anyway, the same happens for any multi-phase cycle. Like with code review. When there are dependencies between people, you are going to need extra items to work on while waiting, and this fights with the requirement that everything should be done at the end of the SCRUM sprint.

There is no requirement that everything should be done at the end of the sprint.
Post reply on HN