This 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…
Why do some developers consider Agile development to be nonsense?
31–40 of 147 posts
Re: Why do some developers consider Agile development to be nonsense?
#32Earlier quoted context omitted.
I've been in a lot of standups and that's never come up. (Yes, I know, the plural of anecdote is not data.)
OT, but I'm stealing that quote! Made my morning :)
(I prefer "The plural of anecdote is Gladwell" but that's because I can't stand his lame books.)
Re: Why do some developers consider Agile development to be nonsense?
#33The title is completely mangled. The original (rather long) title is "Why do some developers at strong companies like Google consider Agile development to be nonsense?", and it seems it was shortened. There's a spurious "at" left in there now which breaks it.
Re: Why do some developers consider Agile development to be nonsense?
#34IF teams are using Agile like that there doing it wrong. It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. If your goal is to use Agile to push developers to their limits, you've already failed the Agile Test. You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it bei…
> 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.
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.
Re: Why do some developers consider Agile development to be nonsense?
#35This 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…
Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile…
That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").
Re: Why do some developers consider Agile development to be nonsense?
#36Re: Why do some developers consider Agile development to be nonsense?
#37Scrum-English Dictionary:
* "sprint": artificial crisis
* "end of sprint": abandonware
* "Scrum master": resume credit for my planned escape to a new company
* "stakeholder": someone you can't get away with externalising your costs onto
* "simplified": doesn't implement any of the actual business requirements
* "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works
* "easy": project was born circling the drain (and doesn't implement any of the actual business requirements)
* "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it
* "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts
* "retrospective": blamestorm incoming!
* "stand-up": getting the blamestorming in early
* "We'll put that on the backlog": hahaha fuck you
I do enjoy some of the jargon. "empowered": do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that yourself."
Seriously: every good idea is turned into a bad one by the relentless management quest to Taylorise clue.
Re: Why do some developers consider Agile development to be nonsense?
#38This 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…
Re: Why do some developers consider Agile development to be nonsense?
#39Re: Why do some developers consider Agile development to be nonsense?
#40This 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…
I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong.
If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you.
Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.