We all knew it
Pbpbpbp…agile fails fast by design.
The counter from the article is you need a specification first, and if you reveal the system wasn’t going to work during requirements gathering and architecture, then it didn’t count as a failure.
However, in my experience, architects are vastly over priced resources and specifications cost you almost as much as the rest of the project due to it.
TLDR…it’s a shit article that confuses fail fast with failure.
Feels like the old php metric. PHP had a ton of great code and successful projects but it also attracted very bad devs as well as very inexperienced devs leading to a real quality problem.
Honestly kinda see thing in a lot of JavaScript applications these days. Brilliant code but also a ton of bad code to the point I get nervous opening a new project.
My point? It may be a tough pill but it’s not the project framework that makes projects fail, it’s how the project is run.
I witnessed a huge number of failed projects in my 25-year career. The cause was almost always the same: inexperienced developers trying to create a reusable product that could be applied to imagined future scenarios, leading to a vastly overcomplicated mess that couldn’t even satisfy the needs of the original client. Made no difference what the language or framework was or what development methodology was utilized.
I feel like that’s the same underlying issue: The requirements are not understood upfront.
If a customer cannot give you any specific information, you cannot cut any corners. You’re pretty much forced to build a general framework, so that as the requirements become clearer, you’re still equipped to handle them.
I guess, the alternative is building a prototype, which you’re allowed to throw away afterwards. I’ve never been able to do that, because our management does not understand that concept.
I feel like that’s the same underlying issue: The requirements are not understood upfront.
Actually on most of these failed projects the requirements of the original customer were pretty clear. But the developers tried to go far beyond those original requirements. It is fair to say that the future requirements were not well understood.
the alternative is building a prototype, which you’re allowed to throw away afterwards
Lol I’ve done many prototypes. The problem is that management sees them and says “oh, so we’re finished with the project already? Yay!”
I’ve seen a lot of contractors over promising timelines too. “No matter how hard you push and no matter what the priority, you can’t increase the speed of light.”
But yeah exactly.
Preach brother!
Yeah, look at the most prolific language at a given time. There’s your crappy projects or your soon-to-be-crappy projects. What are the universities and ‘coding academies teaching’? That’s going to be the crappiest stuff in the world when those students come out.
So too it goes with ‘management’, the popular ‘self-help’ style crap of the moment is what crappy teams will adopt, and no matter what methodology it is, that crap team is still crap, and it will reflect on that methodology.
Personally, I was never great with agile projects. I get that it’s good for most and sort of used it when I was a CTO but as a solo developer, there are days when I’d rather eat a bowl of hair than write code and then some days, I’ll work all night because I got inspired to finish a whole feature.
I realize I’m probably an exception that maybe proves the rule but I loathed daily stand-ups. Most people probably need the structure. I was more of a “Give me a goal and a deadline and leave me alone, especially at 9am.” person. (Relatedly, I was also a terrible high school student and amazing at college. Give me a book and a paper to write and you’ll have your paper. If you have daily bullshit and participation points, I’ll do enough to pass but no more.)
It’s very likely that as a sole developer you are actually practicing agile as it’s intended and not corporate “agile”.
There isn’t a problem with agile there’s a problem with it being mislabeled and misused as a corporate & marketing tool for things that have nothing to do with agile.
Stand-ups can become so proforma. What did you do yesterday? I coded. What are you doing today? I am going to code. Do you have any blockers? No. It gets a little repetitive after a while.
I did twice a week when I was management: once at the start of a sprint, once on the first Friday where we only identified blockers, and once the following Wednesday where we talked about what can ship and be ready for QA.
The goal was to have a release fully ready on Thursday so Friday could be for emergency bug fixes but most releases are fine. If everything is perfect, great! Everyone go have a three day weekend. If QA catches a bug or two, we fix it and then ship.
If a deadline is gonna slip, just tell me when you know. It’s not usually a big deal.
I found them to be useful because I usee to be in an erratic team where people either get a lot done or drag projects on for years. At least the project draggers had no place to hide when needing to report their project daily.
In my current job we only have these stand-up type meetings once weekly which made a big difference because many people had more interesting things to report and it wasn’t some kind of lip service, instead people were genuinely haring progress.
I think you are missing the part where you help others with their blockers.
In my workplace, that happens in the moment of the blocker being incurred. When people are continually in communication, the daily standup is redundant and frequently for the sake of some manager/project manager who “technically” shouldn’t be part of the standup.
If someone is blocked I’d be pretty cranky if they waited until the next day to mention it. Blockers are to be dealt with swiftly and with extreme prejudice.
Yeah. I can see in your case a stand up could be replaced with a status update message.
Does that surprise me? Not at all. “Agile” was never about making programming better. It was a management buzzword from the start.
We once had a manager who came to me with the serious idea “to make the development process agile”. He had heard of this in a discussion with managers from other companies. The problem? I’m the only person in this department. I program everything alone. How the F should I turn my processes “agile”?
I’m all for and good eye rolling at institutional Agile (basically checkered with bad management who doesn’t know what to do, but abuses buzz words and asserts Agile instead), but this article has a lot of issues.
For one, it’s a plug for someone’s consultancy, banking on recognition that, like always, crappy teams deliver crappy results and “Agile” didn’t fix it, but I promise I have a methodology to make your bad team good.
For another, it seems to gauge success based on how developers felt if they succeeded. Developers will always gripe about evolving requirements, so if they think requirements were set in stone early, they will proclaim greatness (even if the users/customers hate it and it’s a commercial failure).
Cries in waterfall.
The article even states this is a thinly veiled ad for some other “method”.
The agile manifesto is fantastic. Scrum can work wonders as a means for providing a framework to hang “agile principles” onto.
Most organizations don’t do “scrum” well or quickly lose sight of the “why” behind it.
Companies are gonna company at the end of the day. Process + bureaucracy + buzzwords + ill-informed management + vendors promises + shit customers/product owners = late projects.
Agile done right, works. The benefit agile has over waterfall(the process it replaced in a lot of places), imo, is that it’s predicated on working software, responding to change and working collaboratively/iteratively.
Imo waterfall is an imagined beast for most software devs today. I worked on many successful waterfall projects. It was nowhere as bad as the caricature that people imagine.
No to all cults in general, as a rule of thumb
I’m always sceptical about results like these. I was told that waterfall always failed when I’d worked on successful waterfall projects with no fails. The complaints about waterfall were exaggerated as I think are complaints about agile. The loudest complaints seem to always be motivated by people trying to sell sonething
As someone who practices agile software development I find this baffling. I’ve never started a new project without at least 3 weeks worth of research and requirements gathering (and obviously more as the project rolls on). There are seriously companies out there who are like, “Mmm, I feel like this is gonna be an Electron project. Let’s just lay the groundwork and we’ll flesh out the nitty gritty in a week or so.” 😱
Not gonna read it because we, elsewhere in engineering land, have been forced to eat Agile shit from the water hose to make us better and faster. Fucking hell! I can’t re-compile a mirror if it comes out wrong!
I hope “New Impact” includes hammers.
It seems very biased to say the least. A title like that would be ok if it was comparing agile to pre-existing models like waterfall. A valid title for this would have been "new sw development methodology seems to have a much lower failure rate than agile dev. "
ALSO I would like to see the experiment repeated by independent researchers.
"new sw development methodology seems to have a much lower failure rate than agile dev, claims people who stand to make money if new sw development methodology has a lower failure rate. "
Move fast and break shit!
An Agile Project eh. Like an Agile Waterfall process? cool. Cool cool cool.
I know PMI has an Agile thing but by and large Agile can’t be “projects” and vice versa.
