How do you know someone is an agile believer? They tell you! (every single day at the stand up)
Why do some developers consider Agile development to be nonsense?
41–50 of 147 posts
Re: Why do some developers consider Agile development to be nonsense?
#42Earlier quoted context omitted.
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long…
An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful.
And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...
Re: Why do some developers consider Agile development to be nonsense?
#43Earlier quoted context omitted.
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
Only 2--4 hours? I wish.
Re: Why do some developers consider Agile development to be nonsense?
#44The term has been hijacked. It is useless. There is merit in the idea that it once encapsulated, but it has long since been co-opted to mean something almost completely the opposite of its original intention.
Yeah. Scrum doesn't make management disappear, it amplifies it. I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you could…
The problem is that, to them, "Agile" is Candyland: No responsibility or accountability for their own job (making stable plans/requirements), but hyper-accountability/scrutiny for the devs that have to spring to their every half-baked whim. It amounts to a DDOS attack on the dev process. It's just waterfall without the top part of the waterfall where they are responsible for requirements. I'd rather go back to waterfall.
Re: Why do some developers consider Agile development to be nonsense?
#45This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-softwar…
A good policy is to not estimate bug fixes, to not associate any points at all with them. It creates a drag on velocity, but it's honest.
If you need to fix a bug, it means that you are correcting an error from a past (implicit or otherwise) user story that shouldn't have been accepted as complete anyway.
Re: Why do some developers consider Agile development to be nonsense?
#46The term has been hijacked. It is useless. There is merit in the idea that it once encapsulated, but it has long since been co-opted to mean something almost completely the opposite of its original intention.
Yeah. Scrum doesn't make management disappear, it amplifies it. I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you could…
Intriguingly you've not mentioned 2/3rds of the people in a Scrum team - the Product Owner and the Scrum Master - both of whom are supposed to be the ones who handle many of the problems you list. Build servers being on fire feels like a perfect example of an impediment. People who aren't actually developing anything feel like the perfect example of people who shouldn't be at standups, and certainly shouldn't be speaking at them.
Again Scrum relies on empowerment, with the Product Owner being the "single wringable neck" whose career is tied to the project and who has the buyin from management to get stuff done. The point being that it is in their interest to have a happy and productive development team doing what they say.
Finally there's also a really good point about internal and external metrics. I've always been a fan of management getting the stats they ask for, not being provided with access to the team's internal metrics which should really be short term to address perceived issues. If we count defects for a few sprints to reduce our defect count that is good, providing them for evermore to management is bad. Separating the two out lets your Scrum Master / line managers have a good conversation about what management are concerned about and how to effectively measure it.
As you said - bad managers won't do any of this, but then flagging up that you have bad managers is A Good Thing (TM) overall.
Re: Why do some developers consider Agile development to be nonsense?
#47This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-softwar…
"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." . I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is so…
Depends on the bug, sure.
It's my job [or used to be :-)] to give estimates of bug fix times to management.
It usually broke down to:
- trivial (about an hour)
- nearly trivial (maybe half a day or a day)
- "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).
Re: Why do some developers consider Agile development to be nonsense?
#48Earlier quoted context omitted.
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long…
If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea.
That's technically true but not useful. There are much better questions to ask, namely:
- Will gozzlewog or foofaraw take longer to implement?
- Is the difference minor or is it an order of magnitude?
- Will shipping gozzlewog or foofaraw make a bigger impact on the business?
- Is that difference small or large?
Re: Why do some developers consider Agile development to be nonsense?
#49Earlier quoted context omitted.
> It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. The vast majority of work environments cannot be described as relaxed and friendly (hell, most of them probably aren't all that collaborative). Far more could be described as pressured hot houses.
That's the point. Managers often use management techniques that encourage that. It works if your on simple assembly tasks. I.E Worried if you gonna be fired if you don't make 200 widgets. Doesn't work if you're on knowledge work. A lot of people approach agile as its an extension of those approaches. When in fact it was a reaction to it, by trying the opposite approach.
So, what are you saying, then? That Agile isn't suitable for the majority of workplaces?
Re: Why do some developers consider Agile development to be nonsense?
#50Earlier quoted context omitted.
"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.