Live data from Hacker News

Agile Ruined My Life

whattofix.com

31–40 of 137 posts

Re: Agile Ruined My Life

#31
post #16

Earlier quoted context omitted.

The biggest determinant of success that I've seen is the skill of the programmers on the team. No McMethodology can make crappy programmers write good code. Period. (However, really bad management can make good programmers write crappy code too...)

Exactly! Factors contributing to the success of a development project, in decreasing order of importance: 1. the skill of the team 2. the determination of the team to succeed 3. appropriate choice of technologies 4. process In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Every…

They're forgetting it because they want to forget it.

Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.

This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.

Re: Agile Ruined My Life

#32

Hey Daniel, Some of your advertising is running a little haywire on you. > My cousin called me up and was telling me about all the weight he's lost on this strange new diet. He was really excited. So I dug around and found the link to share: Dr. Siegal's Cookie Diet - More than 500,000 people have used his cookies to lose weight. Now it's your turn! This page contains a single entry by DanielBMarkham published on Sep…

Thanks. I'll fix that.

Geesh.

Re: Agile Ruined My Life

#33

As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away. I don't want to be sold a product. The fact that it led people to t…

The name probably makes more sense for people who wrote software before it came about. Even "non-agile" development processes have evolved in response in the last 8 or so years.

Re: Agile Ruined My Life

#34
post #2

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…

Did you even read the article?

Re: Agile Ruined My Life

#35
post #4

Amen. The greatest success I've had is using a hybrid approach of agile and waterfall. But, let's face it, Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.

Software development can never truly be waterfall or agile. The best development always lies somewhere in between.

If the process were only waterfall, the project would never even be started because all the specs would take forever to write out.

If the process were only agile, there would be chaos because there is no long-term thinking involved.

Re: Agile Ruined My Life

#36
post #26

i read the comments here and wonder if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile? my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.

Perhaps Scrum (and Scrum alone) is dangerous, in the sense that it's difficult to adopt without careful, disciplined technical practices already in place and the whole team's understanding that scrum scheduling and management is very different from the so-called traditional approaches.

Re: Agile Ruined My Life

#37
post #15
post #4

Amen. The greatest success I've had is using a hybrid approach of agile and waterfall. But, let's face it, Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.

Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book. There is a delicious irony here. The first bullet point of the Agile Manifesto is that individuals and interactions matter more than processes and tools. (See http://agilemanifesto.org/ if don't know what I'm talking about.) The heart of the Agile…

* The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!" *

Would you hire someone to manage your software development process who's only qualification is sitting through an expensive three-day seminar?

Would you trust an organization which does so?

If not, why the surprise that such projects struggle?

Re: Agile Ruined My Life

#38
You know, I'm really beginning to regard the "Agile is led by consultants who don't know what they're doing" and "TDD is a crutch for beginners" crowds as being like the Rush Limbaughs of programming. There's a grain of truth to their points of view, but that's it: just a grain. They get their strength just from being loud enough to make people notice.

To be fair though, I think of the Bob Martins out there as being like the Keith Olbermanns of programming. Again, just a grain of truth but loud.

Die hard Haskell programmers get the distinction of being the Ron Pauls: hip, opinionated, and doomed to an existence of never being taken seriously.

Can't we all just accept that different people work different ways rather than being constantly at each others' throats?

(For the record, I'm not in any of these camps. In fact, I try to avoid joining any camps.)

Re: Agile Ruined My Life

#39
post #2

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…

The gaping vulnerability in the traditional ad-hoc waterfall approach is management is constantly interrupting work in progress and changing the priorities, then wondering aloud why nothing ever seems to get done.

Agile is certainly worth the bureaucratic hassles it adds because agile protects developers from the tyranny of ever-changing priorities. At the start of each iteration (every 4 weeks or so) the management team must agree that these issues, and only these issues, will be the entirety of what the team works on for that iteration, no exceptions, no additions, no interruptions. A good management team will respect that agreement and protect the team from interruptions.

Re: Agile Ruined My Life

#40
post #7

Here's how "Agile" has worked for me. Start with a big list of features you wan to implement. Product Owner/Manager keeps list in proper order of importance. Every 2 weeks team gets in a room for 1 hour and marks off what they have done and picks off what needs to be done for the next iteration - generally you try to pick off less work then you think you can do. We'd let you pull in additional work as the "iteration"…

My experience is similar, but based more on Sprints and more frequent, shorter meetings. We also utilized "Post-It Driven Development", meaning that all our tasks were written on post-its, with an estimated time-to-completion (rough, like 2 hours, 8 hours, 2 days, etc.)

We would meet for 10 minutes or less each morning, and each person would move their post-its as necessary -- we had 4 columns, not started, started, finished or roadblocked. Each day the post-its got moved over to where they needed to go, and anybody who looked at the board could see exactly who was working on what, how much work was remaining, how much work was completed, and who was or wasn't doing a good job of time estimations.

New feature requests would be queued by the product manager until all of the previous sprint's features were implemented (or delayed, or resolved in some other way), and then we'd start over.

Post reply on HN