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

Coconut Headphones: Why Agile Has Failed

mikehadlow.blogspot.co.uk

Post reply on HN
Print view View original

21–30 of 133 posts

Re: Coconut Headphones: Why Agile Has Failed

#21

Post by nnq »

allochthon wrote: post #20

> Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation. Well said.

Yep. Good software companies tend to get this. But the zillions on creative digital-media agencies that popped up recently, and realized that yes, what they are doing is software development and nothing else, and that their "creative secret sauce" only contributes 10% max to the business fail to get his big time!

Re: Coconut Headphones: Why Agile Has Failed

#22

Post by donretag »

asdkl234890 wrote: post #4

I worked for a large corporation which used a hard core water fall method to produce software. And yet it called it Agile. Why? Because why not.

I worked in a similar environment. Sprint 1 is requirements gathering. Sprint 2 is coding. Sprint 3 is testing. Water fall really is agile!

Re: Coconut Headphones: Why Agile Has Failed

#23

Post by mikevm »

jdlshore wrote: post #18
wpietri wrote: post #7

As somebody who has been involved in the Agile movement since before the term existed (I was using Extreme Programming in 2000 or 2001), I agree 100% with this. I definitely think the consultants get a good chunk of the blame. But as I explain in detail elsewhere [1], I think that happened because executives, the consultants' customers, were mainly interested in buying BS. Not consciously, but when they were offered…

This. So much this. I got involved with Extreme Programming in 2000. Loved it. Best thing since sliced bread, yadda yadda. I was completely spoiled for other kinds of work. So when that contract ended, I went looking for other opportunities to do XP. But guess what? In 2001, there weren't any. So I started teaching people how to do it. Bam! I'm a consultant. Several lean years later (I don't mean Lean, I mean ramen),…

So for someone that wants to study the non-watered down management version of "Agile", which books would you recommend?

And just out of curiosity, are there any popular Agile books that you would not recommend?

Re: Coconut Headphones: Why Agile Has Failed

#24

Post by jdlshore »

mikevm wrote: post #23
jdlshore wrote: post #18

Earlier quoted context omitted.

This. So much this. I got involved with Extreme Programming in 2000. Loved it. Best thing since sliced bread, yadda yadda. I was completely spoiled for other kinds of work. So when that contract ended, I went looking for other opportunities to do XP. But guess what? In 2001, there weren't any. So I started teaching people how to do it. Bam! I'm a consultant. Several lean years later (I don't mean Lean, I mean ramen),…

So for someone that wants to study the non-watered down management version of "Agile", which books would you recommend? And just out of curiosity, are there any popular Agile books that you would not recommend?

I'm fond of, um, mine. :-D http://www.jamesshore.com/Agile-Book/

It has a section in the front that describes which pieces to read depending on which role you're in.

Re: Coconut Headphones: Why Agile Has Failed

#26

Post by hpaavola »

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand.

I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time.

The reality is that the company has a bunch of developers who are mediocre at best (and maybe one or two good ones) and managers who do not understand the situation. And of course the budget is already been eaten.

They want to ship their product and make some money with that so they can continue to live their life. If I go there and say hey, you need better developers, more rapid prototyping and managers who are technical enough, nothing will change. Nothing will change because there aren't "rock star" developers avaialble, there isn't time to find new managers and definetly no motivation to change everything right now.

Sure in some sense I might be correct to say so, but my goal is not to show my superiority, but to improve the situation.

But if I teach them a little Scrum, help them setup some CI and so on, they almost always perform better.

And then this statement "Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation."

No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need. "Agile" helps even the shitties companies to meet the needs of their customers.

Re: Coconut Headphones: Why Agile Has Failed

#27

Post by brightsize »

carsongross wrote: post #16

To the extent that I've seen development methodologies work, they appear to mostly fix organizational barriers that get in the way of The One Thing That Actually Works[1]: hire a small group of extremely talented developers and product designers and then let them work. [1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.

> hire a small group of extremely talented developers and product designers and then let them work.

Spot on. Whenever I go into one of my own anti-"Agile" rants, among my main points is that formal organizational process is simply unnecessary with talented, motivated development teams. In my long experience across many start-ups (which tend to get the aforementioned sorts of teams), if you just put a bunch of really smart people (devs) in a room with a project to do, Good Things happen. They know what needs to be done. They know how to do it. Any kind of formal development methodology just gets in the way. Management in those environments (and I've done that) is about care and feeding and listening and gaining consensus. It's not about religion or process. When I first read the Manifesto, not long after it came out, my reaction was YES! But in no time the Formal Methodologists came out of the woodwork and hijacked the whole thing, turning an attractive philosophy into just another management fad, one with nearly as much religious orthodoxy as what it replaced. Agile, with a capital "A", can't die quickly enough.

Re: Coconut Headphones: Why Agile Has Failed

#28

Post by briantakita »

IMO, the worst meeting you can have is the "agile inception". Do not allow a consultant who has no skin in the game to lead an inception. Do not allow them to have a louder voice than the engineers in the project. They can set a tone which is not coherent with the engineering team, which is bad, bad, bad.

I've been involved with a few inception meetings. Two of them had terrible consequences for the life of the project. I got into a disagreement with a high level company executive in one and an "inception master" consultant in the other. They had no accountability for their "guidance" and they nearly killed the projects from the start.

Re: Coconut Headphones: Why Agile Has Failed

#30

Post by watwut »

wpietri wrote: post #9
eliasdelatorre wrote: post #5

I'm stuck trying to finish a project as a vendor. The original team in charge of selling the project has put a guy as Project Manager that takes pride everytime he says: "As you know, I'm not a technical guy" just before explaining something completely wrong from the technical standpoint, or agreeing into something that can't be delivered as explained. I can't agree more on the quote that says "Please don’t put non-t…

I think the problem isn't with who you put in charge. I think the problem is the notion of "in charge". One of the best things for me about teams that were working well is that everybody was in charge. Everybody felt responsible for the outcome. Everybody cared. Everybody knew they could make things happen, and that differences of view were resolved through collaboration and experimentation, not power. You can see th…

I had very bad experience with "everybody in charge". We oscillated between nobody makes decisions and war for power and decision making. The project was simultaneously pulled in multiple directions and there was no such thing as shared priorities. Every team member had his own.

It got hell when the company hired very smart and capable guy who turned out to be very lazy. Nobody is in charge in that case means also that it takes too long time until someone in charge finds out about the situation.

Post reply on HN