Managers everywhere: “Okay team, recent research has shown that agile has serious flaws, so we’ll switch to Scrum.”

When people talk about Agile, they’re referring to one of two things: the manifesto, or the popular “agile” process.

Problem is: the popular process breaks a lot of the manifesto’s principles. The concept of “sprints” goes directly against the manifesto’s call to a sustainable pace. And in practice, the popular process tends to be documentation- and beurocracy-heavy.

This article is drawing some unsubstantiated conclusions from a very small sample size, and they don’t seem to consider many other explanations. For example, it may be that companies are more likely to use an agile methodology when they’re expecting changing requirements or limited input, so it makes sense they’d have a higher failure rate. Correlation != causation.

The article only touched on the real issue: companies that employ agile (especially the largely-ineffective popular process) are often the types that use it as an excuse to skimp on other areas. Agile or not, any project without clear direction and some documentation up front is going to struggle (and the manifesto’s emphasis on working software over documentation wasn’t referring to high-level requirements).

Overall, 2/10 article.

I wonder how failure is defined (maybe it’s in the article). Because SW companies don’t really care about making SW work, the only measure of success is selling SW teams to bullshit customers for as long as possible.

Oh wow so this “impact engineering” methodology seems like it could be interesting, let me just look it up.

Hmm.

Odd the only results are this article and articles like it based on a press release for a book that is seemingly the only source of any information on this methodology.

Oh <insert Willem Defoe tapping forehand meme> it was click bait all along.

This is the best summary I could come up with:

Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.

“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”

A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.

The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!