5 ms·

Oh boy. > tired of the "Agile"/"Scrum" > bullshit. Probably the best way to appreciate Scrum is to have worked on a commercial software product before

Oh boy. > tired of the "Agile"/"Scrum" > bullshit. Probably the best way to appreciate Scrum is to have worked on a commercial software product before it. Scrum exists to protect the developer. It explicitly says that estimates are inaccurate by their nature (estimating in story points, never time), estimating is hard and needs the intelligence of the team (planning poker), and the bigger the estimate the less likely it is to be accurate (fibonacci-ish estimate sizing). It allows developers to hide important tech debt removal inside stories by making stories explicitly stated in feature terms, and not in terms of items that a product owner can deprioritize. And it has a focus on making sure there's proper knowledge sharing (anyone works on any ticket, pair programming, dialy standups) so that you don't get a silo'd project where only one developer understands how one piece works.

couchand 10y ago
I know it's a tired phrase (and borders on no true Scotsman) but most developers I've known to have the OP's attitude about agile development have never seen real healthy agile in practice. Plenty of companies these days operate somewhat iteratively, meet for daily scrums, and put on other trappings of an agile process. But they usually fail the muster on every one of the agile preferences, particularly the "working software" one and the "responding to change" one.
- Tharkun 10y ago
  Most devs have never seen a healthy project, period. Regardless of methodology. Why would this longflow garbage be any different?
Tharkun 10y ago
Couldn't agree more. I stopped reading the "manifesto" after the "bullshit" statement.
jon-wood 10y ago
I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defended from the realities of the wider business, and they sure as hell shouldn't be hiding away work they'd like to do in what are nominally feature cards, what you're describing sounds more like the US legislation process of slipping funding for a coal power plant into a law which is designed to prevent discrimination so that the right person will vote for it. Trust is earned, and intentionally deceiving the product owner as to what they're going to get goes against that. A properly run and supported development team should be able to go to their product owner and make a convincing argument as to why they should be doing some work on paying down technical debt. If they can't convince the product owner in terms that are understood and taken on board that's a failing of the development team and the process they're working within. Or maybe the interest on that debt just doesn't outweigh the features that are being prioritised over it. In an ideal situation developers will be involved enough in the rest of the business to be able to see that without even bothering with pitching low value tasks as a priority. Equally my experience is that points based estimates don't really help anyone. The product owner is inevitably going to report to their management in terms that are more widely understood, namely time, and to do so they'll convert points into time. If you're lucky they'll use the current average rate of points/sprint to do that, if you're unlucky they'll just say 1 point = 1 hour and leave it at that. By extension that doesn't help the development team either, because they're doing estimates in points on the understanding that they don't directly map to time, and then get grief later when the points didn't directly map to time. Maybe I've just never seen Scrum done really well, and with sufficient buy in these aren't actually major issues, but my experience tells me no one is helped by adding a new language solely used for communicating the development team's plans and progress.
- peteretep 10y ago
  > Developers aren't actually > special snowflakes But generally, in a technical team, they're the experts on the technical stuff... > and they sure as hell > shouldn't be hiding away > work they'd like to do in > what are nominally feature > cards They should be mentally adding the postscript "in a way that leaves the project in a better state than I found it" to each feature, and estimating on that basis. That's their job. > then get grief later when > the points didn't directly > map to time If this happens at your workplace, either fix it or leave, much as you would if the promised health insurance your workplace offered turned out to be a spirit healer.
  - jon-wood 10y ago
    I did fix it. I replaced the error prone practice of using units other than time for estimation with the far more understandable process of estimating in hours, days, weeks, and months. That comes with an understood caveat that as the units get bigger so does the margin of error, and if people want more accurate estimates they need to allow time to break the task down.
pdimitar 10y ago
Apologies, but to me your argument sounds like "but nobody has implemented a REAL capitalism yet!" -- ideal definitions will always exist and conversely, will never be implemented. Maybe the fact that most developers never really see well-implemented Scrum process says something extremely important about Scrum and the human nature. Namely that they don't click well together. I wonder why are people so stubborn when it comes to having to take a step back and re-evaluate their process?
- peteretep 10y ago
  > deal definitions will always > exist and conversely, will > never be implemented I would estimate more than half of the projects I've worked on have done Agile pretty decently. > Maybe the fact that Calling an anecdote a fact does not make for a strong argument, nor make the rest of your comment especially compelling.

couchand 10y ago

I know it's a tired phrase (and borders on no true Scotsman) but most developers I've known to have the OP's attitude about agile development have never seen real healthy agile in practice. Plenty of companies these days operate somewhat iteratively, meet for daily scrums, and put on other trappings of an agile process. But they usually fail the muster on every one of the agile preferences, particularly the "working software" one and the "responding to change" one.

Tharkun 10y ago
Most devs have never seen a healthy project, period. Regardless of methodology. Why would this longflow garbage be any different?

Tharkun 10y ago

Couldn't agree more. I stopped reading the "manifesto" after the "bullshit" statement.

jon-wood 10y ago

I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defended from the realities of the wider business, and they sure as hell shouldn't be hiding away work they'd like to do in what are nominally feature cards, what you're describing sounds more like the US legislation process of slipping funding for a coal power plant into a law which is designed to prevent discrimination so that the right person will vote for it. Trust is earned, and intentionally deceiving the product owner as to what they're going to get goes against that. A properly run and supported development team should be able to go to their product owner and make a convincing argument as to why they should be doing some work on paying down technical debt. If they can't convince the product owner in terms that are understood and taken on board that's a failing of the development team and the process they're working within. Or maybe the interest on that debt just doesn't outweigh the features that are being prioritised over it. In an ideal situation developers will be involved enough in the rest of the business to be able to see that without even bothering with pitching low value tasks as a priority. Equally my experience is that points based estimates don't really help anyone. The product owner is inevitably going to report to their management in terms that are more widely understood, namely time, and to do so they'll convert points into time. If you're lucky they'll use the current average rate of points/sprint to do that, if you're unlucky they'll just say 1 point = 1 hour and leave it at that. By extension that doesn't help the development team either, because they're doing estimates in points on the understanding that they don't directly map to time, and then get grief later when the points didn't directly map to time. Maybe I've just never seen Scrum done really well, and with sufficient buy in these aren't actually major issues, but my experience tells me no one is helped by adding a new language solely used for communicating the development team's plans and progress.

peteretep 10y ago
> Developers aren't actually > special snowflakes But generally, in a technical team, they're the experts on the technical stuff... > and they sure as hell > shouldn't be hiding away > work they'd like to do in > what are nominally feature > cards They should be mentally adding the postscript "in a way that leaves the project in a better state than I found it" to each feature, and estimating on that basis. That's their job. > then get grief later when > the points didn't directly > map to time If this happens at your workplace, either fix it or leave, much as you would if the promised health insurance your workplace offered turned out to be a spirit healer.
- jon-wood 10y ago
  I did fix it. I replaced the error prone practice of using units other than time for estimation with the far more understandable process of estimating in hours, days, weeks, and months. That comes with an understood caveat that as the units get bigger so does the margin of error, and if people want more accurate estimates they need to allow time to break the task down.

pdimitar 10y ago

Apologies, but to me your argument sounds like "but nobody has implemented a REAL capitalism yet!" -- ideal definitions will always exist and conversely, will never be implemented. Maybe the fact that most developers never really see well-implemented Scrum process says something extremely important about Scrum and the human nature. Namely that they don't click well together. I wonder why are people so stubborn when it comes to having to take a step back and re-evaluate their process?

peteretep 10y ago
> deal definitions will always > exist and conversely, will > never be implemented I would estimate more than half of the projects I've worked on have done Agile pretty decently. > Maybe the fact that Calling an anecdote a fact does not make for a strong argument, nor make the rest of your comment especially compelling.