Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three things I don’t like in the agile community

andybrandt.net

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Three things I don’t like in the agile community

#11

Post by Vic-nyc »

I am a developer, and in the past I used to be a proponent of "agility". These days if I am interviewing for a job and I hear that the company is using "Agile practices", I generally try to avoid it like the plague.

I believe there are 3 main factors for software projects to succeed: one is the technology and the skill level of the tech team; the second, very important, are the business requirements (are we building the right thing, and with the right priorities?); the third is the level of communication between team members. Now "Agility" (Scrum/etc) really addresses only the 3rd point.

And herein lies the dogmatism that others have mentioned -- a lot of these companies who do "Agile" usually do so because they have serious problems, and they think "Agile" is a magic bullet that will solve them. This is extremely wrong and dangerous - if your problems are caused by crappy technology or (very often) by the fact that you don't understand what you're trying to build, then throwing scrum meetings at developers will alienate them even further.

What I also see in these companies that are so adamant about Scrum/etc, is management who doesn't understand technology. Therefore they use the "Agile" weapon as one of their only ways to give them a sense that they are in "control" of the situation. They neglect the other parts because they don't understand them.

Re: Three things I don’t like in the agile community

#12

Post by mattmcknight »

TamDenholm wrote: post #4

I worked a 2 month contract at a company that employed agile techniques and i found them to be nothing but superfluous minutia. Thats not to say they dont work for the company as a whole, but i was 1 guy working on 1 project by myself. I was brought in to tackle a specific problem and sort it out, i was just given what i needed and i got on with it, but was forced to partake in the daily stand up meetings and weekly…

Two hour weekly team meetings aren't part of any agile method that I am aware of. Scrum standups are supposed to be for people working together. Those aren't agile principles.

Re: Three things I don’t like in the agile community

#13

Post by mattmcknight »

duncanj wrote: post #8

I think I can explain some of the dogmatism seen with XP practitioners. XP is a set of practices for customers, developers, and communication. XP consultants think that teams should try all the practices. Most XP people don't oppose removing or modifying a practice, but they don't see why you should remove it before you've tried it, especially when the reason is something like, "Pair programming will never work here.…

Another aspect of XP is that pair programming is a replacement for code review. If you drop pair programming, you should consider a compensating practice.

Re: Three things I don’t like in the agile community

#14

Post by jdp23 »

raganwald wrote: post #10

Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest that other agile practices are doing it wrong. And unless I misunderstand the original Agile Manifesto, it's all about valuing certain things over other things, not about saying the other things are wrong, and certainly not really about specific practices. The analogy I would draw is to the relationship between ideals of code beauty and des…

my experiences match yours: I've worked with a lot of agile practitioners and most of them are very respectful of different agile practices regardless or their preferences.

Re: Three things I don’t like in the agile community

#15

Post by westajay »

raganwald wrote: post #10

Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest that other agile practices are doing it wrong. And unless I misunderstand the original Agile Manifesto, it's all about valuing certain things over other things, not about saying the other things are wrong, and certainly not really about specific practices. The analogy I would draw is to the relationship between ideals of code beauty and des…

My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars.

I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the only way out is more consulting guidance. In fact, I worked for some time at a consultancy where I am sure this was their business model.

There's more than one path to the finish, and "agile" sold itself out as a vapid marketing term years ago.

Re: Three things I don’t like in the agile community

#16

Post by Ramone »

westajay wrote: post #15
raganwald wrote: post #10

Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest that other agile practices are doing it wrong. And unless I misunderstand the original Agile Manifesto, it's all about valuing certain things over other things, not about saying the other things are wrong, and certainly not really about specific practices. The analogy I would draw is to the relationship between ideals of code beauty and des…

My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars. I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the…

I'd be interested to hear about (1) that scrum failure in the 10's of millions of dollars, and (2) what you prefer instead of Agile.

(I'm a developer on a scrum team and really think it helps us, but I'm not dogmatic about it or anything... I'd like to hear about the other side. I'm surprised that a huge scrum failure is possible because the customer is generally shown everything at regular small intervals, so it's hard to imagine how a project could get so far off course.)

edit: grammar

Re: Three things I don’t like in the agile community

#17

Post by raganwald »

westajay wrote: post #15
raganwald wrote: post #10

Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest that other agile practices are doing it wrong. And unless I misunderstand the original Agile Manifesto, it's all about valuing certain things over other things, not about saying the other things are wrong, and certainly not really about specific practices. The analogy I would draw is to the relationship between ideals of code beauty and des…

My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars. I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the…

Question: If you take your own comment and replace the word "Agile" with "BDUF," does it still ring true? Why? Why not??

p.s. To be clear, I know many ineffective consultants who sell a variety of snake oils, both Agile and BDUF. I'm wary of falling into the "No True Scotsman" fallacy of claiming that what they sell isn't Agile or isn't BDUF. Really, I have no evidence that there is any methodology that turns a bad consultant into a genius, or allows a great consultant to turn a bad development team into software shipping superstars. I don't claim that anything works. But then again, I don't claim that anything "doesn't work," either.

Re: Three things I don’t like in the agile community

#18

Post by raganwald »

Ramone wrote: post #16
westajay wrote: post #15

Earlier quoted context omitted.

My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars. I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the…

I'd be interested to hear about (1) that scrum failure in the 10's of millions of dollars, and (2) what you prefer instead of Agile. (I'm a developer on a scrum team and really think it helps us, but I'm not dogmatic about it or anything... I'd like to hear about the other side. I'm surprised that a huge scrum failure is possible because the customer is generally shown everything at regular small intervals, so it's h…

I don't know about that SCRUM failure, but the original XP project was a well-documented failure:

https://secure.wikimedia.org/wikipedia/en/wiki/Chrysler_Comp...

One way to explain things is to say that teams like Agile whether it's effective or not (for some definition of effective). Another way to explain this is to say that Agile can't make you succeed, but it's the fastest and cheapest way to fail.

When I'm selling snake-oil, I prefer the latter explanation.

Re: Three things I don’t like in the agile community

#20

Post by adambyrtek »

TamDenholm wrote: post #4

I worked a 2 month contract at a company that employed agile techniques and i found them to be nothing but superfluous minutia. Thats not to say they dont work for the company as a whole, but i was 1 guy working on 1 project by myself. I was brought in to tackle a specific problem and sort it out, i was just given what i needed and i got on with it, but was forced to partake in the daily stand up meetings and weekly…

I claim that the daily stand-up is the single most beneficial agile practice, and also the simplest one to implement on any project. It's absolutely worth to spend 15 minutes each day to learn what others are working on, what problems did they encounter, how does it overlap with your tasks and what is the overall progress. Noticing only the perceived time expense without taking into account the big picture is very short-sighted.

Of course all of this makes sense only when you work as a team, not on your own (although the iterative approach is desired even in such case).

Post reply on HN