Hacker News Reader

It's not just a biased study, it's an article about a study of which the data is not published, so it's impossible to tell if there's any merit to it.

The excerpts of the study published in the article do not inspire confidence either:

1. Agile ("Agile Requirements Engineering") is defined as: Development starts before clear requirements, no complete specification, significant changes late in development.

I think even those who are opposed to Agile would agree that's a severely lacking if not completely incorrect characterisation of Agile development practices. It sounds more like a list of things that would cause an Agile project to fail.

2. Impact Engineering is defined as: Use of all engineering practices studied which increase success rates.

Why doesn't the author dare to give any properties of Impact Engineering up front? This sounds like he's just baiting for people to buy the book so they could learn what magical engineering practices are studied therein. It smells scammy.

Yep, and the big companies basically use Agile as an excuse for not thoroughly planning and vetting ideas. Just build it and figure it out as you go. Then rebuild everything in 2 years since you're left with outdated and unmanageable spaghetti code and you burnt out all your SMEs so they took the knowledge with them.

Do they ever rebuild things? Or just add features ontop of features till the whole thing creaks.

generally they wait until something explodes or they cannot add any features to the unmaintainable mess and they have no choice :)

Yep, this is what my experience is. It could be a cost explosion too, like using expensive mainframes and migrating to something else before the MIPS cost explodes.

Did somebody successfully migrated from a mainframe? Asking for a friend.

Yes, I've heard of some systems successfully migrating from the mainframe at my company. It tends to be a painful process. There are still some apps that need to be migrated.

Several years after a project completes when the system is finally sort of working and the end users know what to expect new management will come in at a high enough level and demand everything be rebuilt using their tech stack of choice because they need the resume entries.

Then of course you'll get a buggy second system that is back at square 0 which the business doesn't understand/hates and the developers hate because they're constantly fighting fires.

You make it sound like Waterfall had full plans and completely vetted ideas.

It didn't.

> Just build it and figure it out as you go.

That sounds like hundreds of waterfall projects that I was pulled into after they hit the 1/2 way mark and we're running behind because of unexpected scenarios.

It had better plans than the way Agile has been done on the teams I've been on. You can certainly misuse either. In my experience, planning is neglected more Agile.

Waterfall and spiral model failed in the general case for the reason of plan everything in advance, so unless it's a safety critical system I'd say Agile is still better.

I say this because no matter what methodology is used there will be spaghetti code regardless, mid tier devs like to over engineer solutions, junior devs don't know better and do whatever is first on stackoverflow.

Business execs also don't ever know what they want so change a system half way through when they see prototypes so then you still end up with Franken-systems.

To that end, you might as well start with a half spec'd system as it saves time.

Good observation.

Having been on the “customer” side in such companies, I’d say the improvement is the result of more frequent interaction which improves mutual understanding.

The internal customers are forced to think through requirements in detail (albeit in pieces). The developers are forced to explain what they are doing.

Too many projects I’ve seen suffered from a lack of communication. Customers would hand things off (“just build x”, lots of customization requests that aren’t thought through). Developers would start guessing and working in the wrong direction, often going on complicated tangents as a result of the customizations).

Consulting Agile as you call it really helps both sides to understand what’s actually needed and how to get there.

I have observed that there are two kinds of Agile.

"Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile.

"Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.

I largely agree with you, but when it comes to evaluating competing methodologies, what you refer to as “agile in spirit” turns quickly into No True Scotsman. “If you project failed you mustn’t have been doing agile correctly.”

To me the single most common evidence of failure to perform "Agile in spirit" is management holding specific teams responsible for missing a deadline after a feature or due date was changed. It shows that the management doesn't understand software development. If you think you can add features or move delivery dates to the left without consequences, you've misjudged your entire industry.

Yeah, my former wannabe-boss was very surprised to realize that splitting the company in two and selling one part during my onboarding period might have a negative effect on my productivity.

We're not doing a very good job of picking the right people to manage things; quite the opposite, in many cases whatever success is despite the leadercrap we have to deal with.

There is some virtue to your criticism, but it is also not entirely true. There are things you can check to see if a team is doing Agile for real, like, what's the last process change you experimented with to see if it improved your outcomes? What experiment failed and was dispassionately removed from the process because it didn't work out? When your team's workload nature changed (e.g., from new development to maintenance), how did you adapt your processes to match? Do your processes come up from the team and their experience or do they source from above with effectively no feedback?

At that point, if you are doing those things, there is a certain amount of validity to the criticism that if it didn't work, you really weren't doing it right. Either something external jammed you up so you weren't able to adapt and truly follow agile, your team was personally unable to execute on the adaptation for some reason (structure, personality issues, experience levels, being simply too large to be able to be this flexible because large teams simply need more structure), or the task was simply too hard in the first place for some reason (such as "it doesn't matter how agile and smart the team is, you're not getting 4 people to produce a standards-compliant browser that is also an office suite in six months").

The problem with "Agile in spirit" is that if adopt it and don't get the desired results, Agile aficionados will quickly remind you that you weren't actually doing Agile.

This is a common refrain, but I don’t think it’s true. “Agile in spirit” people will recognize the failure and look for ways to adapt so similar failures are less likely to occur. Rejecting that opportunity to reflect and adjust is where “not actually doing agile” comes into the discussion, and it doesn’t really have anything to do with “agile” at that point.

If you applied the same reasoning to any other iterative self-adjusting process, you’ll find they all tend to fail before the iterative aspect has been applied. Because that’s their nature, they’re iterative processes as a mechanism to respond to failure.

As another commenter said, it’s difficult to compare “Agile in spirit”, but I’ve found that remarkably successful

Evolving the methodology to suit the team, product, and company in an additive way seems the best outcome I’ve seen.

Rarely will I have daily meetings, we can slack. Maybe twice a week hop on a call.

For story points I’ve seen models of using Fibonacci sequence, having 4 categories rated which then convert to points, or even (less desirable) 1:1 mapping to days of work. Personally I like the 4 categories approach, it feels less subjective as a whole despite each category being subjective to a degree

And in the end, if process gets in the way of productivity, I say go for it, we’ll either go back and document what happened or refine the process later (though rarely if ever have we skipped QA for good reason)

> Evolving the methodology to suit the team, product, and company in an additive way seems the best outcome I’ve seen.

This to me is the core of agile: the people doing the work have the flexibility to adjust to match their goals and needs. So much of the consultant-industrial complex comes down to finding ways to helping business people who aren’t willing to give flexibility or clear requirements ways to not do that which don’t sound like saying no.

Big A, small a.

Agile — scrums, scrum masters, epics, stories

agile — http://agilemanifesto.org/principles.html

Agile is a bunch of rules and processes to follow.

agile is an ideal to strive towards, and never perfectly reach.

—-

Edit — this bit from the article is probably the important line

> However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves.

Agile is not the same as agile.

At least in this humble dev’s mostly irrelevant opinion.