Hacker News Reader

Comment by incepted | Hacker News Reader

> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones

Or maybe they have identified Agile for what it is: a snake oil methodology that's completely unproven, which sometimes works, sometimes doesn't and, regardless of the outcome is never blamed if the project fails.

Bit like a religion.

View on HN

This is likely the number one reason for rejecting agile: it has already failed. I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. What's worse, the process degrades into 30-60 minute "stand-ups" or "scrums" or whatever, eating into a good chunk of the day for absolutely negative gain (as it's mostly people talking about shit that's irrelevant to 90% of the team and wasting everyone's time because the "process" says they should). I've also seen it degrade into another reason for management to enforce deadlines in all places, including places that only employ deadlines when development is really behind schedule (as is all software development I've ever seen in the business world).

And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.

> I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do.

Agile is, if it is anything, a set of values for selecting what you do, not a set of things you do. And a weakness in the Agile literature is that there is a lot that talks about things you could do (and a lot of it conflicts), but there is a lot less about how you make the values of the Agile manifesto concrete in selecting and adapting what you do (while its not specifically "Agile", there's a lot written on this that is applicable in an Agile context in the Lean methods literature -- Lean and Agile are directed at largely similar values, but Lean has stronger roots in process engineering and seems to have more focus on understanding why things work and how you know that they work.)

I agree. So I'll add that none of those places had any values aligned with agile at all, despite spending time, money, and effort on agile. Maybe that's because values don't come from processes and trying to implement a process to instill values into people is patently absurd.

> I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do.

> I think it's time to acknowledge the process doesn't work

Sure, if you don't actually do it, it doesn't work.

For example, you could say: "I've worked at over a dozen places claiming to be linux shops, but they don't have linux installed anywhere. I think it's time to acknowledge linux doesn't work."

Does this mean that agile itself is bad? No, it can and does work. It's just much harder to do correctly than it seems (eg: it takes more than reading a book, putting a Kanban board up, and having a daily "standup" meeting).

Here's a new methodology I invented (that's about as useful as agile): perfection. Do everything perfectly. However, no one has managed to implement this amazing new methodology in a way that works yet. It's so simple. So many have tried and failed. Surely it's not the perfection methodology that's at fault because that's perfect. It must be the idiots trying to implement it, who haven't actually implemented perfection, that are failing to implement perfection. If only they could implement perfection, they'd see how perfect perfection is! But I don't see perfection anywhere! WTF?

I can appreciate where your comment probably comes from - it's absolutely been oversold at many organizations and there's an industry of scrum trainers and the like that oversell it. Against the standard of perfection no methodology works and none ever will I think. Software development is messy and complicated and difficult to put in a box.

Still agile doesn't claim to be a silver bullet. It's a loose collection of ideas about how to adapt to change and communicate better during development. Its just about strategies to contain the mess. Thats it.

On my teams I've seen great benefits from some things like sprint reviews but it has not magically produced high quality code or made customers love every product. We didn't try to saddle it with that expectation though. For me its enough that it's less painful than gigantic specs that are never quite correct but more visble than everyone just winging it and it gives us some checkpoints to tweak the process regularly to improve the way we work. That's an improvement imo.

If you treat it as a religion then yes it's going to be a big disappointment. The same is true for any methodology.

>they have identified Agile for what it is: a snake oil methodology that's completely unproven

Is this a common line of thought? I recently started working for a company that follows Agile and I thought it was generally accepted as the "next step" so to speak in software development. I didn't know that there was any resentment for it. Care to elaborate? Do others feel this way as well?

Agile would be good if it existed as described and was a stable organizational mode.

In reality, every "Agile" place I've worked for really uses Agile-for-name-value-only, which amounts to daily half-hour long status reports on what you did yesterday and project deadlines that come from on high that have to be ratified pro forma by the engineering team.

Yes, I know that's not true Agile. Just like the USSR wasn't true socialism! Agile can never fail, it can only be failed.

Do you also reject democracy because all brutal dictatorships call themselves The Democratic Republic of X?

Yes.

It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fixing things only to find out that while that's all been happening the internets been invented and the original product has no purpose.

Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure.

EDIT: To add:

If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to?

Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase.

I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point.

I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ).

If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.

i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt (or any other for that matter). in any non-agile corp i've been, projects are usually a mix, where analysis doesn't finish when dev starts, testing is ongoing with dev, just shifted a bit. and when these projects go fubar, it's usually caused my forces far away from delivery team. rarely, it's really fault of team not delivering, but agian, situation is so complex and uncontrollable, that putting everything and everybody (including all stakeholders) into agile wouldn't probably make a big difference in go/nogo call.

agile approach brings quite a few aspects that developers like and they just feel right (or at least better), but frankly, it's overhyped. just another tool/approach to certain set of situations, in certain conditions

> i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt

I work in Pivotal Labs.

I happen to be working on such a project with one of the world's largest financial firms. Across the hall from me is another team working with that company. Behind me are three teams working for a retail giant, in front two teams working for a large insurer.

In the same office I've seen everything from iphone scroller games, to startup apps, to microservice migrations, to entire product categories, being created this way.

Collectively, Pivotal Labs has helped develop thousands of products for hundreds of clients with a collective business value in the billions.

I invite you to visit any of our offices to see it for yourself. Email me: jchester@pivotal.io and I'll set it up.

Where I work it seems to be a bit of a cargo cult, rather than an ethos of actively solving problems. We do standup meetings because sit-down ones wouldn't work. We use post-it notes on whiteboards because just writing on the whiteboard wouldn't work. We have sprints because just doing the job wouldn't work. All the trappings of agile, none of the results.

I'm not hostile to agile per se - it clearly does work. But not where I am, it's just another fad which will eventually be replaced by some other magic methodology.

It's important to remember the historical context for Agile. Agile grew up and started where there was Waterfall. From that viewpoint of Agile != Waterfall, it is a step forward.

There will always be resentment towards agile. There are too many botched attempts at making a methodology work from well-meaning but inept individuals that have effected lives and workplaces.

What's insane is the marketing around Agile and more specifically Scrum.

This is just not historically accurate at all. There was a wide variety of methodologies before agile came along - Spiral, Cleanroom, OOP, TSP, RAD, RUP, et al. These are not all waterfall - waterfall was never really a prescribed method of development, see [1]. Many of these methodologies have proven track records and some even have fairly strong empirical support.

The resentment isn't resentment - it's people who have actually used something other than Agile listening to this made-up history and the catastrophizing of up-front planning, and seeing it for the nonsense it is. Agile isn't right for many or even most organizations, and it's failure doesn't seem like the problem of a good idea bungled in the wrong hands. Just very inexperienced people suckered in by good marketing into picking an inferior tool.

All that being said there are many good things about agile. It's helped bring a human focus into the industry, and introduced some decent ideas. For a fairly balanced look I'd see [2].

[1]: https://leanpub.com/leprechauns [2]: http://www.amazon.com/Agile-The-Good-Hype-Ugly/dp/3319051547

Agile isn't a methodology, so it can't be a snake oil methodology. However, it's also not a set of quantifiable, unambiguously decidable metrics for evaluating a set of methodological choices, either, so a lot of different methodologies, some of them snake-oil, get sold as Agile (and some which aren't snake-oil get sold in a way which obscures the actual indications for use, which turns then into effectively snake-oil even when they have, underneath, something fundamentally sound.)

In your experience, what kind of methodology do you think works?

M'fcking programming. Never failed me.

Reply on news.ycombinator.com