We all knew it
… I cannot count the number of times at my different workplaces where we had an agile process, dailies and everything else of the agile BS for projects which where either trivial or not solvable. No worries, the managers, product owners and agile coaches made money and felt good, we developers went for greener pastures…
Agile is a scam, nothing they do is based on any facts and when you challenge agile coaches / other people which profit it is always ‘I believe’ or ‘proven by anecdote’.
Combine this with the low quality of people in the average software projects and you have a receipt for failure.
Writing the requirements first at least forces people to think trough a project (even if only superficial), so I am not surprised the success rates for this projects goes up.
Agile has its uses, but like everything you need a bit of both. You need a bit of both waterfall and agile.
Example : you need to have your requirements before development, yes. But how far do you go in your requirements? If i were to make all the requirements for my current project ill still be busy in 3 years and will have to redo bits due to law and workflows changing. however , we need requirements to start development. We need to know what we need to make and what general direction it will be heading to a make correct software/code design.Agile also teaches you about feedback loops, which even with waterfall, you need to have to know that what youre developing is still up to spec with what the product owner is expecting. So even with waterfall, deliver features in parts or sit together at least once every x weeks to see if youre still good with the code/look/design.
Pure agile is bullshit, but so is pure waterfall. Anything that isnt a mix is bullshit and in the end, it all depends on the project, the team and the time/money constraints.
Good points, and I mostly agree with you, especially with feedback loops!
Still, I never argued for waterfall. This is a false dichotomy which - again - comes from the agile BS crowd. The waterfall UML diagram upfront, model driven and other attempts of the 90s/early 20s were and are BS, which was obvious for most of us developers, even back then.
Very obviously requirements can change because of various reasons, things sometimes have to be tried out etc. I keep my point, that there has to exist requirements and a plan first, so one can actually find meaningful feedback loops, incorporate feedback meaningfully and understand what needs to be adapted/changed and what ripple effects some changes will have.
Call it an iterative process with a focus on understanding/learning. I refuse to call this in any way agile. :-P
Exactly!
I worked at one Agile place they had all their sprints and milestones in a Gantt Chart waterfall. They also did big design up front and a lot of process. They had do all kind agile and scrum training, but it was the most process heavy place I worked.
Im currently trying to steer a product team to have this kind of process. They are working with an ancient piece of software that is slowly being replaced. However, we need to replace piece by piece while the main app is still being maintained because of law and workflow changes. This is why i want them to set the requirements and designs up front a bit so we can make a good analysis of it before development starts so no technical difficulties or questions arise mid development! However, nothing is set in stone and after each small piece ( aka after each sprint ) we have our review and product owners and stakeholders see what we have made and can chime in, causing us sometimes to pivot what we were making.
Best of both worlds!Rewrites are great. You have a specification that is so defined it is literally code.
When it’s blue sky, it’s harder. Plans will be wrong. The users don’t understand really what they need or want. It all ends up evolving. Anything with a GUI is worse because users/customers need (want) things moved about, re-themed, with no regard to what’s below. Best to nail them to mock up designs they signed off on. Same with API interfaces. If they signed off on the design, you can then point out “spec change” and get more time/money. It’s more about ass covering than using the outcome or process.
Agreed. Depending in what branch or situation youre in you need handle appropriately and cover your arse but also make it work. If i was to work on a timed project, and the project is set to not make the deadline due to spec changes i will report that ahead of tine to cover the teams arses, but at least we can pivot and deliver something that will be useful and up to spec depending on the feedback :)
I don’t think there is a way that always works.
It’s not always possible to get a clear spec and do big design up front in R&D. The whole point can be to work out what can be done and how.
Correct! Hence why i said it all depends on the product, the team, the time, money, project, …
Many factors that decide on how to tackle things and the problems :)
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.
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’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!
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!”
Agile falls into the category of how the project is run
No it’s a set of tools you can use to run a project.
My point is that a lot of people use “agile” to mean not planning or don’t put guard rails on scope and they fail. That’s not agile, it’s just bad PM
Agreed.
Being Agile is being flexible. To do that you need to plan for multiple contingencies. Resulting in more planning, not none.
“agile” is being flexible. Being “Agile” more often than not means your company’s incompetent management paid some hack consultants to come in and bless your flavor of stupid bureaucracy as “Agile”.
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.
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
Ignoring the success and failure of agile and waterfall. Waterfall was just a way more enjoyable development experience for me. That would probably change if the cycle was lower though. Also doesn’t help that many managers I’ve had don’t follow the rules of agile/SCRUM. Seems like people use it as an excuse to be able to change things on any given day but those cycles are supposed to be planned, not the plans.
Yeah actually i hadn’t thought about that aspect of it, but I did enjoy waterfall projects much more.
My crazy wacko conspiracy theory - software development is just a really weird discipline, most of the people in the field are bad at it, and it doesn’t have the same amount of standardization and regulation that other engineering fields have, so doing it “right” looks a lot fuzzier than doing, say, civil engineering “right”.
The biggest thing though is that most people are bad at it. It’s really hard to evaluate high level organizational concepts like waterfall vs. agile when we still have developers arguing over the usefulness of unit tests.
I so agree with you. Especially that software engineering is not like actual engineering. Ironically that’s the first point of the agile manifesto - is all about the people and interactions, not the tools and processes. That’s why I’m leery about these grand claims about agile failures when half the time they mean scrum and just doing scrum isn’t agile (see point one of the manifesto)
I think it’s more that they are trying to solve the problem by changing the dev team processes, when the biggest factor of success is developing the RIGHT thing. But since most tech managers have risen up from the ranks of devs, and they have a hard time understanding that other people have valuable skills they don’t, they have no idea how to hire good designers and refuse to listen to them when they happen to get one.
Move fast and break shit!
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.)
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.
Removed by mod
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 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.
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.
Wtf is Agile ? I can’t get my head around that.
It is a methodology to develop software quickly. It has some good things about it. But it can be very heavy on meetings and agile idealists are not very flexible. As many of the other comments say, a mixture of agile and some other methodology or starting with agile and developing your own process that works for your team or project is the best way of managing a project. I don’t understand why so many people don’t seem to write requirements when using agile. Even with agile I will not start coding until I have relatively clear requirements. It is not too bright to start speculative development without really knowing where you are going. https://agilemanifesto.org/
I like your point about the idealists. IMHO, agile has some merits, rooted in psychology. For example, during stand up to say what your plans are for the day. Same for the sprint and quarter. It helps with communication. I don’t like the thing where everything needs to be a deliverable thing. I’ll poke my eyes out if I need to sit through another example of building a skateboard, scooter, bike, truck. Try that example with something real like a bridge or house. It ends up in a lot of throwaway work. Now try doing that in a highly regulated field like government or finance where you really can’t iterate due to oversight and regulatory compliance.
Oops, this turned into a rant. Well at least agile pays the bills. There’s a lot of money to be made in prolonging the problem.
But it can be very heavy on meetings and agile idealists are not very flexible.
Seems a little ironic haha
Right? I find agile purists to be some of the least flexible people I’ve ever met. They are the exact opposite of agile. To be fair though, I have found that a good scrum master can be worth their weight in gold. You always know the status of a project and the individual stories. It can be very, very helpful.
I don’t understand this… How do you code if you don’t know where you’re coding for? Am I the only one that thinks that sounds crazy?
Commonly you will have a relatively broad goal of providing some functionality by the time a project is done. Every sprint, commonly two weeks, you concentrate on producing a piece of functionality that will get you closer to that goal. At the end of a sprint, many teams are expected to have what’s called a minimally viable product that is technically usable. The problem with that concept is MVP almost always becomes production. That results in poor coding that is hard to support. It almost always involves rework later on, often when something is already in production. And you are not crazy. Not having a clear idea of what you’re coding for is wasteful and very inefficient.
Agile is not about being quick, it’s about delivering what the customer actually wants. When you do Waterfall you gather all the requirements, then you sit down and code the thing. Only to find out months or years later that you delivered crap as the customer didn’t even know themselves what they wanted.
With agile you take it one step at a time. What is important now? Get the requirements for this feature, deliver it in the next two weeks (or at least a part of it). Then the customer, which can be an actual customer, or your internal Product Owner, or a Product Manager looks it over. If the whole thing is perfect? Nice, carry on to the next thing.
Often you find out some detail was overlooked, or a new requirement came up, or the design didn’t fully work out. So pack it into the next sprint and do it better. You’d never get this feedback if you gather “all” requirements first and then just try to go from start to finish.
Agile certainly has its upsides when done right, unfortunately there’s not a lot of companies who manage to do so (like most I’ve been part of). Despite being messy at times, it’s still better than Waterfall. There’s too many meetings either way.
Traditionally (as in 20+ years ago), software got developed according to the Waterfall model or V-model or similar. This required a documentation of all the requirements before a project could be started. (Certain software development fields do still work that way due to legal requirements.)
This was often a failure, because the requirements did not actually match what was needed, not to mention that the real requirements often shifted throughout development.
Agile, on the other hand, starts out development and figuring out the requirements pretty much in parallel. The customers get a more tangible picture of what the software actually looks like. The software developers also take over the role of requirements engineers, of domain experts, which helps them make more fitting software architecture decisions. And you can more easily cancel a project, if it turns out to not be needed anymore or whatever (which is also why a cancellation percentage is misleading).
The trouble with Agile, on the other hand, is that projects can get started with really no idea what the goal even is, and often with not enough budget reserved to actually get them completed (obviously, that may also be a failure state; if the project is promising enough, customers will find the money for it somewhere).
Also, you do spend a lot of time as a software dev in working out those requirements.But yeah, basically pick your poison, and even if people like to complain about Agile methology, it’s what most of the software development world considers more successful.
Oh well, time to switch back to the waterfall model I guess
lol, no.
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.
Fail fast is the whole point and the beauty of agile. Better to meet with clients early and understand if a project is even workable rather than dedicating a bunch of resources to it up front and then finding out six months in (once the sunk cost fallacy has become too powerful)
Thanks for pointing that out so I didn’t have to.
What’s the alternative? Waterfail?
Yeah because business requirements and technology is changing at an ever slower rate…
Fun mental exercise - remove the formalism behind agile methodologies out of software development. How is that any different from driving another human being mad?
I have altered the specifications. Play I do not alter them any further.
Today, new research conducted for a new book, Impact Engineering, has shown that 65% software projects adopting Agile requirements engineering practices fail to be delivered on time and within budget, to a high standard of quality. By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
All you need to know about this study.
It almost sounds like a project team that is actually and actively looking to solve known and recurring problems instead of “just do whatever everyone else is kind of doing” might be why they are successful.
It’s the difference between “how should we go about this” vs “see how we go” regardless of what you label those approaches as.
I think the take away should be:
new research conducted for a new book, Impact Engineering,
By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
So the people who want to sell you ‘Impact Engineering’ say ‘Impact Engineering’ is better than Agile… Hardly an objective source.
Even if they have success with their ‘Impact Engineering’ methodology, the second it becomes an Agile-level buzzword is the second it also becomes crap.
The short of the real problem is that the typical software development project is subject to piss poor management, business planning, and/or developers and that piss poor management is always looking for some ‘quick fix’ in methodology to wave a wand and get business success without across the board competency.
Oh yeah. I totally agree that the source has its own objective. I wasn’t supporting their specific approach at all.
You are right that the key take away is somene saying “I think my own idea, which I happen to be selling a book about, is great, here are some stats that I have crafted to support my own agenda”
The point I was making was simply that people who care enough to try something, anything, with thought (like looking for a new methodology to try out) are likely to be more successful.
Like a diet. The specific one doesn’t matter so much. It’s the fact that you are actually paying attention and making a specific effort.
Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
It’d be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn’t actually experienced in project management.
Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.
I’d say it’s more about continuously milking customers on projects that never seem to end. I’ve never done software project management, but I have seen it’s “tenets” applied to other types of projects. The results were arduous - to say the least.
I’ve seen it being done even on internal projects though. Things within an organization.
It tends to be that they start developing a feature and then someone comes along and says, ooh wouldn’t it be nice if it did x, so they modify it to have x feature. Then someone decides it should be able to sync with Azure (there’s always someone that wants that), so Azure sync is added, but now that interferes with x, so that has to be modified so that it can sync as well. Then we get back to original product development which is now 3 weeks behind schedule.
Repeat that enough times and you can see why a lot of this stuff fails.
Even internal projects have a facet of ‘milking customers’ even those customers are internal. There’s a rather large internal team that has managed to last years by milking the fact their stuff always sucks but any moment when they are challenged about their projects they always have a plan to fix all that’s wrong within ‘3 months’.
During my project management days one of the things I learned the hard way is to nail down exactly what something has to deliver and getting everybody involved to sign onto it in black and white - if you don’t, disaster follows.
Agile seems literally designed to make this impossible.
Agreed. We follow agile, and we have a team of product owners who know where the project is likely headed in the next 3 years. Our sprint to sprint is usually pretty predictable, but we can and do make adjustments when new requirements come in. The product team decides how and when to adjust priorities, and they do a good job minimizing surprises.
It works pretty well imo, and it hinges on the product team knowing what they’re doing.
I’d say it’s that people tend to use Agile because consultants tell them they can be piss poor managers dealing with the crappiest developers and stupid business ideas and still make awesome stuff if they just make everything buzzword compatible.
I’d say projects without much of an upfront project plan can still be very successful, but it’s all about having a quality team, which isn’t something a two week ‘training and consultancy’ session isn’t going to get you, so there’s no big marketing behind that sort of message.
In my experience It’s not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.
No to all cults in general, as a rule of thumb
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.
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. "
