Hacker News Reader

Comment by GiorgioG | Hacker News Reader

Sprints? I love sprints...I feel like I'm on a hamster wheel day in, day out.

Seriously, screw scrum and 'agile'

Yeah. The notion of sprints doesn’t seem to be healthy at all. There’s always the next big thing on the horizon. No time to reflect on what you’re doing. Closely tracking velocity, knowing full well that it’s a futile exercise in controlling what’s happening.

>inb4 “you’re doing it wrong” If so many people get it wrong, I see it a problem inherent to scrum, not its various implementations.

Not everyone is doing it wrong. My current sprint team is pretty laid back. I put my foot down against tracking velocity as a performance metric early on, though. But my argument against it was mostly that it was stupid and counterproductive.

Interesting. Tracking during sprint or generally speaking?

Tracking it is fine. Using it to measure team or individual performance is terrible.

This has nothing to do with scrum and agile. Or if it does, then they are part of the solution, because one of the rules is that you don't do overtime. If there's too much work to include all features before the deadline, you drop some of the features. Scrum is meant to help estimate based on real work by developers, rather than on overly optimistic planning by managers. They empower the developer and give them the autonomy to do the job the way they see fit.

In theory, there is no difference between theory and practice.

In practice, there is.

Isn’t that a theory?

It's funny that some managers give the deadline first and then direct the developers to do Scrum to figure out how to do it in that timeline.

“But we need to know how much it will cost us”

“External factors demand we implement feature X by that date”

“Let’s just hire more people, preferably more PMs”

“We have many more ideas in our pipeline. In order to orchestrate these, we need precise estimations.”

My last job kept hiring more PMs and no techs. It was horrible. I kept having to tell the customers "Sorry we can't get the projects done, we have 5 project managers and only 2 techs."

A laugh riot, it is.

Not really. Developers are just held accountable or feel accountable for their own forced guesstymates. It was better when managers were guessing becouse they also have the means to change scope.

There's a very good reason why story points in scrum do not directly relate to time worked. You guess story points only in relation to each other. Over time, you can see how many story points you finish per sprint. By seeing how many story points are still on the backlog, you can estimate how long it will take. Add one or two sprints for unforeseen problems, and there's your estimate. Not based on anyone's guess, but on the time it takes to do actual work.

This, in short, is the core of value that Scrum adds to the ideas of Agile.

The only problem is that people insist on misunderstanding these simple ideas and try to do Scrum as wrong as possible. The problem isn't Scrum, the problem is people insisting on doing it wrong.

If nearly everyone is doing it wrong, the problem is Scrum.

It’s a very naive thing to say. The problem is usually management misunderstanding what scrum is supposed to be. It’s a variant of ‘estimates become deadlines’.

I'm not sure any system's going to do better. There aren't a ton of people who are good at applying (let alone thinking up) systems such that they work effectively and as intended. Too many will slice up and build atop a system then wonder why it's working so poorly, because they didn't understand the purpose of the parts they removed, or why the things they added will screw it up. "Well this is great, but we really need to..." NO. No you fucking don't. Unless you want to screw it up. But the people who get that, and who have the independence of action to prevent others from screwing up their processes, are uncommon. Even in management, which is exactly where that kind of thinking should be extremely valuable.

But not everybody is doing it wrong. Most companies I've worked for have invested in understanding Scrum, and have applied it very successfully.

The problem here is toxic corporate culture. Scrum and Agile are not magic spells that miraculously turn idiots into reasonable people. Sure, they could be used as levers to change that culture, but the culture absolutely needs to change, otherwise it's not going to work.

And that's something you can throw in their face: that they're not taking Scrum and Agile development seriously. If they say they want Scrum and Agile, then make sure you understand what they really mean, and hammer on it every time they trample on the autonomy of the developers. Every time they ask why things aren't done, tell them management is interfering with the process.

Maybe. My guess is that Agile etc are suitible for some fields of programming and not others.

I'm just fed up with this Agilescrum thing. My present RnD workplace have been transitioning to it in the last years and it's really bad. The prior V-iteration process was good enough. We are mostly just making up estimates and report time accordingly to make the burndown chart look good.

> story points in scrum do not directly relate to time worked

Except in the minds of absolutely every single person who applies them to anything.

No. Not in the minds of people who grok the point of scrum.

Just start pointing this out to people every time this comes up. It's not an exact time estimate, it's an abstract complexity estimate. Insist that the idiots get some actual training in Agile before they start corrupting it beyond recognition. If they want Agile, then they should invest in training people for it, and in spreading the culture that goes along with it. Because Agile is perhaps more about culture than about process.

Accurate software estimation is a technical skill that can be learned like any other. It's disappointing that so many developers don't take it seriously or make disciplined efforts to improve their skills.

https://stevemcconnell.com/books/

I feel like this is misleading. There’s no magic bullet for software estimation. McConnell’s book talks about various techniques but the takeaway is that you know very little at the beginning of the project. There various techniques for estimation but you can never get away from the essential unknown unknowns.

Exactly. To make accurate estimates of how long it's going to take, you need to know how the team estimates the complexity of the work that still needs to be done, how they estimated the past, and how much they actually did in the past. In this particular team, with this way of working.

Only then do you have the information to make a halfway reliable estimate. Without that, it's just going to be guess work.

> "Scrum is meant to help estimate based on real work by developer."

Sure, but the problem is that, aside from one job, I've never seen any organization that actually does that. Instead, agile/scrum is used as a micromanagement tool and developers get hammered if they don't close their Jira tickets in a timely fashion. It's an total perversion of what agile was intended to be.

I also find this to be the case. Developers have a minimum number of tickets / points we have to close every week. The number of points per ticket is decided by committee and in that committee there are developers of vastly different skills but all have the same minimum.

But despite all of this, the release deadline does not change and the developers always end up working insane hours fixing last minute bugs discovered by QA days / hours before release.

Although this could just be an issue with where I work as opposed to scrum / agile. :)

Yeah, this has nothing to do with scrum/agile. The number of points needs to be decided by the team of developers that's going to pick up those stories. There's to minimum number of tickets or points, you pick up what you can, and the number of points you average over a couple of sprints, helps to estimate how much time future work will take.

It seems a lot of companies are cargo-culting scrum.

I like some of the principles of agile but like the problem is the ceremonies chew up so much time. I have an none technical project manager who is absolutely in love with everything agile. I am in a project where basically 3 of us are going to do the work. I sit next to one of the people but we still have to have daily stand ups. I am one of those people who works in longish chunks, I can sit for two solid hours or more and not move if I am in the zone. But now because Agile says we need all these meetings and ceremonies I feel like half my week in is in the agile meetings or preparing for these meetings. Yes I have raised these issues but been overwritten by management. I am in Africa so I cannot just get another job.

Ceremonies are part a process to get shit done. Being agile doesn’t mean to follow a strict process but to create a process that suits all stakeholders and the dev team in particular.

I’m trying to say your team isn’t agile, it’s using a cookie cutter process template most likely. Print out the agile manifesto and tape it to the cofee machine.

That's all well and good if you don't work in a large organization. Taping anything to the coffee machine in my organization requires committee approval.

In Scrum, and doubly so in Agile, meetings should not be taking up much time. Meetings are to make clear what needs to be done, because otherwise you end up wasting time on things that don't need to be done. Dailies should take a maximum of 15 minutes. Sprint review, retrospective and planning take more time, but that's only once per sprint, and they're still meant to be productive meetings. If the process isn't working for you, the retrospective is the time to bring that up, and together you can decide how to change your process so that it works better for you.

If your concerns are being overridden by management, your process is neither Agile nor Scrum.

Nobody falls for this anymore.

Scrum are agile are extremely effective at fostering micromanagement and overworking and burning out developers.

It's almost always pushed by management, consultants, PMs rather than the ones that have to carry the weight.

"You are doing it wrong, we are here to help" is an old trick.

Tell them to leave you alone. Have your PO keep the stakeholders at bay if they don't know how to behave. Take advice on scrum and agile only from people who actually know what they're talking about. Everybody else is just amateurs.

Employees cannot choose who to take advice from when decisions are imposed by management - to benefit management.

> nothing to do with scrum and agile.

Well, I know what you’re trying to say, and technically, you’re correct - if any shred of the agile manifesto were observed, you would be actually correct, too - but “agile as practiced by everybody who practices it” is, for all intents and purposes, “agile and scrum” now, so we may as well stop pretending it’s in any way related to what it was supposed to be. Once the phrase “agile” got some mindshare, it was bastardized and twisted into the unholy abomination that we suffer today: that is, the exact same thing that came before it. If somebody were to come along and put together a perfect, workable, realistic, livable, maintainable, achievable software development methodology - say, the “pwrlma” method - it would be twisted back into what “agile and scrum” are today by the same people who can only reason by analogy. Software will always be managed as if it were a building construction effort and programmers will always be treated as slightly more educated bricklayers.

That is far too defeatist for my taste, and not my experience at all. The problem is that people subject themselves to bad managers and toxic corporate culture. Then Agile comes along and throws them a lifeline, and they let the bad managers take it, instead of taking it for themselves.

Real Agile is out there, and is being practices very effectively, but you've got to take it and apply it, and not let poor managers corrupt it. And there are many companies that do not have this toxic culture. Or start your own; software developers are in a better position to start their own business than most other professions.

The feeling of never finishing anything is probably the thing I hate must about agile. Just little bits completed off an ever growing backlog.

Wasn’t it exactly how ancient Greeks imagined hell? (Sysiphos, Tantal).

I work in BI building data marts and reports. First we used to have what I would term technical user stories. Build this report, change that cube, build that mart... Then we added analysis stories and off late we now have design user stories. Our sprints are two weeks. One sprint ended up being the developer checking a tick box. But it took a whole month to complete because we had a two week analysis sprint and another two week "implementation" sprint. But guess what we successfully completed all our user stores.

Beyond a certain point, if your backlog is continuously growing then your product owners simply aren't doing their job. The backlog should only contain thinks that can realistically be implemented within the next year or so (maybe two). Keeping anything in the backlog beyond that is pointless because by the time you get to it the customer requirements will have changed. So competent product owners need to actively purge backlog user stories which are no longer needed, and act as gatekeepers to limit what gets into the backlog in the first place.

"Sprint Planning" -> "How much work can we overextend our developers with"

"Sprint Retrospective" -> "How much did we screw up from overextending so much"

What does the part of planning that calculates velocity and time budgeting look like in this context?

"We don't have time for that, we're too far behind!"

I always thought it was very strange to call them "sprints" since in my experience you start one immediately after finishing another. In real life following sprinting with more sprinting would be a good way to make yourself pass out (or worse) before too long

But what about the relief of getting a release out to production? Immediately followed by the crushing stress of getting started on the next impossible sprint.

yeah, agile is not fun.

You’ll love Lab Rats by Dan Lyons. Highly recommended.

Reply on news.ycombinator.com