Live data from Hacker News

Agile is a Sham

williamedwardscoder.tumblr.com

61–70 of 189 posts

Re: Agile is a Sham

#61
This kind of somewhat understandable but ultimately clueless ranting just tells me one thing: no way in hell I'm ever going to trust a programmer who cannot (or can not be bothered to) distinguish between marketing bullshit and the real thing.

This kind of attitude will show up in other matters, most importantly understanding what actually needs to be developed, what the priorities are and why they are important.

I'm surprised how many people here seem to be ignorant of Agile. Take for instance the certification scam accusation that is liberally thrown about: only Scrum has certification, and even that has always been controversial. As far as I know, no other Agile flavor tries to sell certification. But even so, Red Hat sells certification, does that make Red Hat Linux a scam?

There are scammers and greedy consultants in every area of IT. None of that has fuck all to do with Agile in particular. So why are people so hell bent on using this against Agile?

Re: Agile is a Sham

#62

Earlier quoted context omitted.

Agile and other processes go much much further than your contrived example of checks and balances in a typical hospital. It would be like hospital directly interfering into the daily doctor/patient interaction or say stipulating that no surgery can be longer than 2 hours. You want to do 9 hour heart transplant surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure progress after each to make sure y…

You're messing up agile and Scrum. Scrum has the restriction that every task has to fit within a single iteration. And even with scrum, that limit is self-proscribed. If you regularly have tasks that dont fit in a single iteration and you can't cut those down to smaller tasks then you're free to choose longer iterations. Scrum just says "make iterations, measure progress during iterations to get an estimate how much…

I'm not really confusing the two, I know perfectly well the distinction. However, agile is usually sold exactly like that, as a solution that will improve/solve problems.

Generally, few teams in any organization have so much autonomy to choose their own process. If they did and they decided on their own to do some kind of agile, so be it. But agile is usually imposed externally (because it's in currently) but so is any other process. By the way I'm not criticizing agile per se, I'm criticizing the idea of process as solution.

Re: Agile is a Sham

#63

I personally think Agile is mostly a scam built around some very small nuggets of common sense wisdom, which has then been propagandized by legions of clueless methodology consultants to mediocre teams and management, and spun into mediocre books and conferenceware. Just my personal opinion, ymmv etc. That said, this is a badly written article which doesn't convey much useful information or convincing argument. I am…

True, the article is basically a rant, but I tend to agree. I've felt like the agile train left my station long ago and it wasn't for trying. After being invited to attend a free 'workshop' from one of the holiest purveyors of agile out there, I left with the feeling that it definitely was all for those who did not know how to actually 'do the work'. The trends I've been seeing and trying to do are as follows: * full…

> full stack responsibility. You own the task front (js/html) to back (db), including testing.

Unless you are 1337 with all of those you end up with silos instead of properly defined layers and reusable code.

> Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong.

Awesome, I'll get around to telling my boss that, the very same one that hired me.

Re: Agile is a Sham

#64
post #25

No. Process is important; it's necessary. There are at least two prongs to this problem: one is you can't manage what you don't measure, and process gives you a way of tracking functionality implemented, defects, defects resolved, etc. There's nothing inherent to programming that gives your manager or your team any sort of knowledge about how far along you are, or just as importantly, when you will be done. You can h…

I would like to add one thing to that: Process is necessary, but it should never be the solution.

This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.

Re: Agile is a Sham

#65
Just because something doesn't have a name and isn't written down anywhere doesn't mean it doesn't exist. If you don't like agile, it doesn't mean you have no process. It just means you are following another process. Assuming you have a project that actually involves interacting with multiple programmers, your ability to interact with them is a key part of getting the job done.

If you're a lone cowboy doing it all alone, then good for you, but please state that upfront in your blog posts about how the software world is doing it wrong so we know you are evaluating things from a very unusual position.

If you aren't a sole programmer, then you've got a process. Maybe it's better than agile processes. If so, please, tell us what that process it.

This whole article reads like a racecar driver dismissing automotive technology because the only thing that matters is the skill of the driver.

Re: Agile is a Sham

#66
I'm surprised no one has brought up Steve Yegge's Good Agile, Bad Agile [1], which speaks well to both Google culture and scaling (good) Agile. One of the comments on that post mentions it. It's worth reading (and being Yegge, that'll take awhile).

Agile is like anything else: some well-meaning (and arguably useful) principles that get warped by bad managers and bad companies. The natural evolution for any such idea is to turn it into an industry and there are any number of people who are willing to sell you training, lectures, books and programs for Agile (with a capital-A). You need to separate the industry from the idea.

[1]: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...

Re: Agile is a Sham

#67
In the last few companies I have worked for, Agile was not lightweight, and became a significant hindrance to productivity. In fact, there was an "Agile consultant" brought in to make us more agile at one company I worked for. He ended up making our process 3-4x more convoluted and process intensive. He also succeeded in making the work not fun anymore. In my last job, "Scrum" meetings could take 30 minutes or more on many occasions, and our "sprints" would regularly change scope or be canceled mid way through.

I know that isnt Agile, but the problem is that many managers(and apparently consultants) think that is the way to do it. In my opinion, work getting done is not because you implement a process or methodology. Work gets done when you have a good team in place and trust them to do their job. Many companies seem to think that they can promote a non technical person to manage a development team. The problem with this is that they have no idea how software is built so implementing a methodology that promises consistent results no matter what the inputs are seems reasonable to them.

I am by no means representative of anyone other than myself, but I find I am most productive when a) I know the problem domain inside and out b) I am given some leeway with architecture and design c) I am not bogged down in process.

As projects get larger, its not as easy to allow for those conditions, so getting smart people on board is imperative. Agile should allow for managers to get some transparency and a view into the process, but little more...

Re: Agile is a Sham

#68

[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is be…

> [Obligatory plug and disclaimer: Agile professional You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right. Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yours…

Interesting. So how do you build things that take thousands of programming hours to complete? What about projects involving complex rulesets requiring legal input and/or HR input?

Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.

Re: Agile is a Sham

#69
post #51

Earlier quoted context omitted.

> [Obligatory plug and disclaimer: Agile professional You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right. Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yours…

Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...

Funny thing is, both this guy and the author of the TFA touch the same problem in passing: regardless of the process, there are too many incompetent people plaguing our industry. Instead of addressing the problem, managers usually exacerbate it by trying to "fix it" with a "correct process".

No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality.

[1] http://en.wikipedia.org/wiki/Infinite_monkeys

Re: Agile is a Sham

#70
post #13
post #10

Let me say this. I have found scrum in particular to be used as a management tool (report back tool), and not a developer tool. It doesn't matter where i go. It starts with the greatest of intentions, and ends up where management are sticking there fingers in the pie half way through. And by that I mean they don't use priorities on the backlog to manage the process. They use the standup meetings as a moan session whe…

Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.

Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
Post reply on HN