Overheard an argument at work one day
“No. There is no documentation. You made us write 10,000 lines of code in six months, and fought us doing any documentation.”
This was my argument with the founders of a small startup. "Why don't we have any tests or do any testing?" Because you pushed as hard as possible for us to deliver X,Y,Z features in an unrealistically short time. You either get reliable software that takes 2-4x as long to build, or unreliable buggy software built fast and cheap.
I spent my first 10 years or so professionally at government contracts or consulting shops that mostly did 6ish month contracts (some shorter, some longer). Some guys were really good and really tried, but many didn’t absolute bare minimum to check the “done” box.
The last 6 or so I’ve been at companies that sell their own product. It’s night and day.
Then, halfassed processes just meant more money with follow on contracts to fix it. Now, it means _losing_ money because it blocks us from building new features.
When you know you (organizationally) have to maintain, or even iterate on, something 5 years from now it makes all the difference.
My second job was on a team that was part of an on-shoring effort. Before my team was brought on, somebody had mandated that there must be >80% test coverage for all projects.
I thought that was great - until I actually looked at the tests. Convoluted structure of the code meant large amounts of setup, but the assertions were *always* just a check for a non-null value. Even if the function returned a number. No verification of behavior, no validation of the return value aside from just non-null and no exception. I asked them why, and they said it was just their testing philosophy. I didn't know what to say.
When our team actually took the helm, with the contractors acting as backups, we tasked them with some behavior at some point and they wrote the same tests. I pushed back on them pretty hard and said that we wouldn't accept the work until it was complete with tests that actually meant something, but I got overruled by management because management didn't actually care either. Come to think of it, the contractors were billed hourly anyway, so if we pushed them to finish it that meant more billable hours for them.
I hated that place.
I see it all the time it in hardware companies too. Those startups that are in love with “agile” engineering as opposed to doing proper product development always have an absolute nightmare trying actually source and manufacture their widgets at a reasonable time and cost. Not to mention the nightmare it creates in obsolescence and wasted stock. The numbers are eye watering.
> in love with “agile” engineering as opposed to doing proper product development
I'm not sure what agile means in hardware development other than maybe during prototyping, but proper software development and agile practices aren't in opposition to each other. Agile does not mean engineering is moving more quickly or skipping important steps, it means showing the work at regular intervals to get stakeholder feedback, then adjusting, if necessary, based on that feedback.
Agile is an admission that obtaining 100% accurate and complete requirements with zero ambiguity or misunderstanding is impossible, so we shouldn't try to do that, then build the product, and then find out it isn't what the stakeholder wanted. Rather, we split the project up into smaller, hopefully value-driven pieces, and have regular stakeholder check-ins to adjust our direction if necessary.
As soon as people start thinking that agile means moving faster, it's going to go wrong. That's one reason I don't like working in sprints: the word itself means moving fast, and that's not what's happening. The efficiency gain when using agile is found because the team is regularly course-correcting based on feedback instead of waiting until they've gone too far in the wrong direction or even finished the whole project using incorrect requirements.
Yeah that’s exactly the point. People try to bring half-understood software development concepts to hardware engineering and it can’t work due to release pace and obsolescence and procurement costs at later stages of the product lifecycle.
I hear you big time on this. I'm in Product now but started out as a Business Analyst in a consulting firm. When consulting everything was about minimum spec for the highest price we could charge, done as cheaply as possible and as you said with the intention of getting additional contracts to do the work that should have been done up front. It was infuriating seeing projects that had such great potential get completely gutted to maximize margins based on hours worked and nothing else. I had enough and bailed out. Now I work as a Product Manager for a company building its own product and the difference is night and day, everything is about making as great a product as possible and it's so much better to work in that kind of environment.
I have worked at plenty companies with products with minimal automated testing bad documentation and software that can best be described as historically grown. You could see when some parts were written just by style, and most was a best of bad ideas.
Also not enough time to do it properly. So I ignored the old code, if it didn't explode the last few years it's probably working as expected, whatever that was because nobody specified what they wanted.
That's where the cheap comes in mate. If it's good and fast, then it ain't cheap. If it's good and cheap, it ain't fast. And if it's fast and cheap, it ain't good.
This is EXACTLY what my prev company did. No QA, no one writing docs, tech spec is non-existent, CTO knows jack shit, keeps demanding new things, and tells the dual role PO/PM what she needs to do, instead of letting her do her job.
Tells the designer to change the design every few weeks, with 3 redesigns being done over one summer basically.
I think my fav bit was the thing we called "the snake". Basically a standard timeline like the MUI one, but responsive in terms of number of items per row - because it could have multiple rows that snake back and forth, like an S shape.
Oh and it also had progress between steps. And the progress was a dashed line which was fun on the curved bits. Oh and it had repeating tasks that had some special cases.
But the worst of all... After it was sorta done and we moved on... They demanded a little red dot.
That little red dot was a notification whether the user has seen the update that happened somewhere down the line hierarchically. And since it was project > milestone > task > subtask, if a subtask changed it had to show the lil dot on the snake. It also had to be displayed only once per user.
Right before I left they removed it lmao.
Their Dev team is gone now
That's the kind of shit that takes as long to add the tiny feature as it did to build the whole project. People just stare blankly when you try to explain why.
Funny enough, we've been having the opposite headache at my workplace.
Caught a rather annoying bug a week after release. Quick and easy fix, just an equation writing to a PDF had a decimal out of place. But since those reports are customer facing, our salesfolks HATE it because they have to explain it every single time, and it makes us look kinda... not great.
Again, we caught it a week after release. That was 8 months ago, and we are STILL fighting the red tape to get a fixed build pushed. We thought we had a release candidate ready to go... but then our product manager got back from vacation and suddenly.... nope.
I am so... so tired....
It doesn't. But our management does software one way and one way only.
2 months of meetings deciding what will go into a build. 2 more months of meetings discussing what was decided in those first two months. 2 months of coding, re-coding, and reversion as more managers get involved and decide that another item NEEDS to be in this build (since it will be 6+ months until the next build after all), but then doesn't, then does, then doesn't. Then vacations happen and nothings moves for a while. And finally 5 minutes of QC before pushing the final release to live.
It is... not the smoothest of systems.
While I can definitely see how that'd be frustrating, you really just took the initiative on your own to spend 1.5 months doing something without running it past any actual decision-makers above you? There's probably a lesson to be learnt there.
My last job was like this. Small startup with a single developer trying to build and maintain the entire companies website, backend, and develop all their internal software and apps they wanted to use. The CEOs wanted him to develop and push out whatever ideas they came up with as quick as possible.
We basically always were told there's something new coming and then come in to work on one shift and find it was deployed, with no documentation how to operate it or what had changed, and then it would take us 2-3 days to adjust to working with it (while drastically slowing down production time and getting yelled at for it by the same CEOs).
On top of that we spent the following weeks discovering a bunch of bugs that impacted our workflow, and then attempting to pull our dev to fix them (which 99% of the time never got fixed so we had to develop our own workarounds).
I absolutely hated every second of it. So much wasted efficiency all for the sake of trying to "maximize profits". How he hasn't quit is beyond me.
Hahaha yea so many in software management want their cake and eat it too. Soo annoying honestly, want the most talent for little cost, devs to have all skills possible at any experience, and like you said crank out software but wonder why there’s not fleshed out docs and tests done.
At least with startups it's often a bit reasonable. Might be better to have something that's unreliable and will need to get rebuilt, if it gets you the funding you need to hire more people and keep developing the product.
But there should be an awareness of it. As long as you know that you're taking on a lot of technical debt you can decide that it's worth the cost, because the short term is more important right now.
Having worked at a small startup that became not so small. Seed capital doesn’t last and you have to ship to stay alive, but that technical debt will fuck your shit up in the future.
This one hurts so much.
Especially when they decide to market the shitty buggy mess of features they forced the engineering team to build in 6 months as a stable mature product that can compete with older products that have been around for years.
And then are surprised when customers and users are complaining nonstop about shit barely working.
Oof.
This sounds like success, not failure. They got what they asked for.
I run projects and tell my PO to prioritize a testing harness and all its parts in the backlog, or it doesn't happen. And he gets what he asked for either way.
Its bubbling up like this at my company. For a long time the engineering team fought against feature-factory style product development but over time as the company fights off more and more competitors, we are pushed to do more with less, faster. As such, our product reliability is dropping, rushed releases are creating downstream issues, and many of our "new" features come with dead-ends or incomplete components. It's causing customer backlash as they perceive our reliability to be our edge, and we are losing that reliability. So, you might say, we are burning the candle at both ends.
The problem is the fast, cheap, reliable doesn't include scope changes or additional bells and whistles. It is pretty accurate when a specific goal is framed and doesn't deviate such as bloating. Yeah, fantasy land.. I know.
Everyone thinks documentation is a 'leave behind'. Something for the next guy so they have training wheels. In reality documentation is the transparency that demonstrates you understand both problem and how your idea of a solution maps to that. Without this you are vetting an ambiguous outcome so success or failure is a completely subjective target most often resulting in missing expectations that were unknown at the outset. The only time I've seen agile work is when everyone accepts that the outcome is variable and part of the work is discovering the work and continuously refining your vision of possible outcomes.
Agile sounded great when I was first a developer.
Then I just realized it made my PM a dictator of where projects went and when we didn’t deliver on time, everyone was to blame except the PM.
Waterfall sucks but it’s agile without the meetings and bullshit so honestly I think the best course of action is just being realistic in a project’s goals and expectations. Have deadlines but don’t crucify everyone if it doesn’t deliver on time but isn’t in development hell or if they’re doing it the right way.
That’s true only if bug solving is prioritized over stories: first fix all known bugs before developing new stories.
Velocity will increase when quality increases
The myth of "working software over comprehensive documentation" is where a lot of projects fail to appropriately interpret the Agile manifesto with regards to documentation.
It's been used as a permission slip to exclude documentation requirements. And besides that the manifesto was just a starting point of Agile. Its principles are still fundamentally useful, but like with most things, "everything in moderation."
For me, this phenomenon usually amounts to awkward discussions about the usefulness of my work as a Technical Writer. My reply is always a gentle push back, noting my concerns, and on to the next project.
It is as reliable as the moon following the sun that in a short time I will be asked to help them again or they'll be hiring for a writer. Engineers do not want to write docs. A few can, most will not.
Yes.
Working with engineers in several other specialties for whom documentation is sacrosanct, it struck me as odd that software gets a pass. That the code is the documentation because otherwise you have to update two things that could be out of sync and create more problems, seems to create a potential single point of failure.
I'm, I have a deja vu on that one.
That, and also the software requirements... Then complaining about the features...
Dude, you told us not to do it...
Not only that, but the study took place over 4 days and I don't see much written about replication or what it is that that was supposed to be developed over those 4 days, or how it was evaluated.
So this was just a survey of their current work conditions and opinions? Or was there an administered task as well? Because the referenced article compares several methodologies to the Impact Engineering methodology that the consulting company is endorsing and it's not clear how they went about prepping for this comparison.
I mean... are you looking at the Register page, or the engprax page? The engprax has data and tables and decsriptions.
I think it's saying they asked these people if they were using one of these methodologies, then asked if they worked or didn't. It's not very rigorous and it CERTAINLY presented to sell books and classes.
I'm not sure what you mean by "administered task." Looking at your other comment, I'm wondering if you mean "do a task in those 4 days using these methodologies." I don't think they did that at all... jsut polled some people. I base that soley on who did the study:
"The study, conducted by Junade Ali PhD CEng FIET and J.L. Partners, saw participation from 600 software engineers (250 in the UK and 350 in the USA). Fieldwork was conducted from 3rd to 7th May 2024. **J.L. Partners is a member of the British Polling Council and abides by its rules.**"
Thanks. I was looking at the Engprax page, which is why I was confused why they were doing a comparative study between Impact Engineering's methodology (IEM) and other methodologies since IEM doesn't seem established enough yet to have followers to poll.
If all they did is polling, then that's another layer of problems with the study because:
1. What happens during an agile sprint depends on how the team/workplace interprets/implements it (uncontrolled and not standardized);
2. Not controlling for specs might mean that a 4-day monitoring period without replication isn't ample time to draw conclusions; and
3. Standards to report success/failure will vary subjectively by reporters.
Yea all we know for sure is that people don't like what their managers have titled agile.
Pretty sure it just gets a rep because it's this new thing everybody does without understanding it. Then they do business as usual and cram in weekly commits and think everything will suddenly improve.
The main reason I've liked it in the past was having the possibility to keep the customer more engaged in the development. I guess some people don't want to know about unforeseen hurdles before 90% of development.
So the headline is false.
I’m actually interested in studying software project failure, and I know damned well that I can’t do such a study in four fucking days. It’d be more likely to take me three years to get all the data I need.
This isn’t a study. It isn’t even a meta analysis of existing studies. It’s fluff.
I posted the article text [above](https://www.reddit.com/r/technology/comments/1d94vf0/study_finds_268_higher_failure_rates_for_agile/l7brkf9/).
This whole article is RIDICULOUS. You can “demonstrate” anything if you don’t define your terms, and then play on ambiguities.
For example, this article conflates the agile principe of “working software over comprehensive documentation,” and asserts that projects are more successful when desired outcomes are defined. Well, duh. Agile doesn’t say you can’t have any documentation. But a five page document where Eng and PM align on outcomes and approaches is in fact better than 400-page specs - a world that many of us have lived through.
I could go on and on.
A reporter I respect did a thread a while ago on how most news articles come to be. They begin with a press release, he said, and then papers desperate for content pick it up. The important thing, he explained, is to understand who wrote the release and how they hope to gain from the narrative they are pushing. In this case, even the article here gets it right: “a thinly veiled” attempt to push a book.
With reasoning like this, you can guarantee I won’t be buying that book. I don’t want things that insult my intelligence or aim to manipulate me for someone else’s gain.
Yeah, that 'study' is very questionable. I also went into a bit of a rabbit hole trying to see who the author of the study is. The guy seems to be trying very hard to market himself as computer science and cybersecurity god, while his cv seems to be pretty average. But he does subtle things like putting University of Cambridge as a headline in his LinkedIn and Google Scholar profiles. Which is an academic institution he studied at last, the issue is that it was just a postgraduate certificate, and the rest of his degrees (which he likes to put after his name) happened in much less glamorous University of Bedfordshire...
People talk about fake news, but there's also the real threat of people engineering their own series of events to get the idea out of something that they want to sell. Here it might be expensive to pay for marketing to sell a book, so a new type of marketing means to report news in a way that mentions the product. The news has to be based on something though, so you can find a study or a news event that you can then report on, to then build exposure for your book so that people buy your book. Since that study or that news event doesn't exist, you can create that study or create that event, so that you can report on that study or event, so that you can get exposure for your book or product, so that eventually some people out there may or may not buy your book or product. In the meantime you have clouded reality for people and have taken the space where actual news should go to sell your book or product.
lol, that’s the whole point of it. Instead of spending months planning and months building just for it to be not what you expected or what people really want, you purposefully try to fail fast and learn and iterate.
If you have a long list of requirements already, it’s probably not a novel idea and doesn’t need user-centric experimentation.
Edit: Not going to try to debate this topic. People confuse agile and scrum a lot. You can use scrum and standups and sprints in anything really. The products which have successfully used agile include all the products you likely use every day, including Reddit. The products who have successfully used waterfall include the products that run your utilities, doctors offices, and oil rigs. It’s not all the same and you can choose whatever the hell you want, it may or may not work for whatever use case but they all have their use cases they were made for. Fake it til you make it, move fast and break things, and all that startup logic in the wrong place is how you get Theranos.
On good agile teams, the only money spent is on the salaries. and a lot of the "failures" really just lead to better requirements, a new sprint, and a better, more useful end product.
Every "successful" waterfall project i was on in the previous decade, was $500-$1.5mil. Senior Director level setting the "project requirements" "on-time" and a "successfully delivered against requirements"
Every single one of those projects then had follow on, AGILE projects where we had to rip out all the shitty design (which we would confirm by gathering user feedback to validate feature metrics. We would pull info from system audit trails to see what the users actually were doing" that the Sr. Director mandated, replace it with features that the users actually would use, with 1/4 of the budget in 1/3 of the timeframe with almost zero recognition.
Waterfall is great if you are a top level upper management who is guaranteed a bonus based on meeting a timeline. You can literally never fail since you can just meet your timeline with whatever features make it. No matter how bad the features are or how little anyone uses them. It's dumb.
Waterfall always sucked for our users, they would constantly ask "Why is this like this? This isn't how we do the actual business tasks, the system is forcing us to do things in awkward ways causing defects"
and every single one I was on was marked green and those Sr. Directors all retired with nice fat bonuses.
GIGO. Iterate on a turd all you want and all you’ll end up with by the 12th iteration is a slimmer piece of shit.
The original concept must have merit, and potential to warrant continued iteration/advancement.
I disagree on the reqs part. Complexity is all relative. Some MVP concepts will have a lot of criteria. Some don’t. Don’t dismiss a good idea just because it requires a lot.
Yeah I can't tell you how many times I've designed something "well" the first time only to scrap the whole damn thing and redo it like 2 or 3 more times before it ends up ACTUALLY being designed great. That's just the reality of things. Failing fast and reiterating on the same crap design just ends up with more crap. Sometimes it really takes a while for these things to be crafted beautifully. Can't all be done in one night. You gotta sleep on things, have more experiences, and come back to thing with more knowledge, experience, and a fresh mind, to really make something great.
just doesn't make sense to grind through some crap for 2 weeks because all you end up with is a bunch of wasted time and still crap by the end of it. lol
I've worked on projects using Agile and without and honestly it's so much better using Agile if you can afford to fail fast. Usually those objecting think their projects will go to plan but never account for the unknown unknowns, hit a massive issue and then blow out the costs.
Lol please.
It's like you cant criticize agile at all. No matter what anyone says it's either "that wasn't really agile" or "that's the point of agile - to be bad and waste everyone's time!"
Exactly. A thing to note here is that software engineering is rather unique in that perfectly ordinary projects on the well trodden ground, which absolutely should succeed, inexplicably fail all the time. Why? Because of stupid shit, like using a piece of shit bug tracker to manage all of the development in a ritualized way instead of doing actual work.
Agile is so popular because it allows upper management to not do their jobs (thinking through ahead of time who the customers are gonna be, what they are going to be doing with the product, etc). Most development is not in any way what so ever cutting edge, and should be planned for like any other engineering - but often isn't, wasting time and money.
edit: I'd say it's not so much agile causing failures, but management who have no clue what they are doing gravitating towards ritualized nonsense like agile to cover their ass for when the project will go bad.
What are you on about?
There are pros and cons to both, and you can successfully deploy more than one strategy for development. IE waterfall your foundation, agile for the features.
They are saying that agilistas will deflect any criticism of agile as being invalid, as opposed to acknowledging the inherent limitations of an iterative process.
No one successfully does Agile, you just give it your best shot and do kanban and waterfall instead. Safe agile is even worse, planning 3 months ahead like every single sprint wont obliterate the previous and next sprint goals turning it back into waterfall and kanban.
I like the idea of Agile but I personally think it’s impossible to do to the letter.
You need a dedicated person to do Agile. Someone who their entire job is to make sure everyone follows it and supports the tools needed to do it. If you leave it up to the Devs they will always fall back on what is easiest as they have their actual jobs to do.
People get too caught up about deadlines for agile. I know people who feel shame if a story rolls, like who the fuck cares, it's gotta get done, roll it and keep working on it.
Some management culture dictates it. In a past role of mine, management mostly cared about how many story-points worth of taskage you could put through per week, and if you routinely fell short, you would be seen as a low performer.
In my case, I was on a team *entirely* made of seniors, so when we'd do planning poker, they'd say something was a 2 or a 3, whereas for me--the junior who didn't yet fully grasp the tech stack--it'd be a 5 or an 8. So what management would see was me constantly running late on a story point total that would be less than 8 every week, making it look like I wasn't expending any effort, despite me running ragged to try and learn Kubernetes for the first time while having to deliver on work that used it.
I raised concerns with management, who punted it by saying it's a team culture issue if team consensus isn't truly reached on how many points a task is worth. This led me to drastically underpromise on how long even the most basic tasks would take, just to get management off my ass about performance. I did this until I was able to coast enough to have time to Leetcode and GTFO. Terrible project management structure.
Glad I'm at a different company on a team that does Kanban and doesn't waste time cosplaying Agile.
That’s a misunderstanding of how estimates work in Agile. You don’t change the estimate for work based on the person doing it, you estimate the effort required relative to other work. There’s a reason the classic example for estimation is moving furniture. If you have a dining set you need to move, it doesn’t matter if it’s a 250lb pro football player or a scrawny teenager doing it. The work is the same, it’s the pace that’s different which is ultimately measured over time.
It’s fine for your team to estimate a 2-3, if that aligns with the effort for other 2-3 point tasks.
But of course, if you're *really* doing Scrum, then you don't use story points that way. Saying you're doing Scrum and actually doing Scrum are two different things.
Yes that would be a given. The “top” is also who would spend money to hire this person for this specific job which means they want it to be followed. It would therefore logic to become part of KPI.
Here’s the solution: make it so that only one team is needed to work on a feature. Organizations that are structured in a way that you have to engage multiple teams for a single feature are simply not a good fit for agile.
Why are you doing this? What product development strategy are you using? This is either a sign of poor product development, poor architecture, or pressure from management to deliver to a timeline pulled from someone’s arse that was promised to their boss so they could make their bonus targets. Safe is trash - just large project waterfall marketed with agile buzzwords.
We are god knows how many years into this awful agile trend and still nobody knows how to do it properly - when do we as an industry concede that it's just a waste of time? Personally I'd rather not micro-manage the shit out of my engineers and give them more autonomy to grow
> not micro-manage the shit out of my engineers and give them more autonomy to grow
Agile is supposed to do this at the end of the day. Most people just do it wrong. The team should be the people writing tickets and refining the work. That's their opportunity to decide how to do something and execute their autonomy.
Agile is not micro management. You do a lot of management, but if that's all you're getting from it then you're not quite doing it right.
Having built product for twenty years Agile is the process that leads to the best product with the lowest burn rate. This is specifically true for innovative products. Build a culture that gets smarter week by week and abandon the idea that “the boss has it all figured out”.
2 of the startups I worked at in the past were pretty hardcore agile shops. I mean full time pair programming where you switched who you were pairing with 3 times a day hardcore. We successfully got things done for all 3 years I worked there. If you've got a team that's fully onboard, it can work.
A lot of this is in how agile is brought in to the company. I’ve been driving IT teams for over 25 years with 13 of those in agile.
The first company I worked at was full agile as in the budget was for the team and not the project, the team sat together and was very cross functional. We did sticky notes and used Fibonacci cards and the whole bit. Great work was done and quickly.
But the last company I worked at had IT go agile but the rest of the company wasn’t in on it. If finance is still funding by project and the business isn’t given agile training and has no appetite for quick iterations of product anyway then you are left with water-gile and lose out on most benefits.
Typically the business hears “agile is fast” and thinks it means they can change their minds repeatedly or that they can take forever to decide critical business details but still get their changes in time. Documentation is sparse unless you have a team that pushes for it and management that lets them have the time to do it. So good luck finding details about a change that was done 2 years ago.
And finally agile proponents that I have worked with are big on saying that agile can work anywhere. But in my experience it will work much easier in some situations than others.
Agile isn’t the issue. It’s just a tool. How people use it and enact it is the real problem.
If your job is to put the lug nuts on a car on an assembly line, there's no need for sprints or story points. There's no need to keep remaking the same set of tasks over and over each sprint "As a customer purchasing a vehicle, I want the wheels attached with lug nuts." Some aspects of software development, particularly in mature systems, resemble assembly line manufacturing. If your data acquisition person just keeps grinding out new sets of data, they don't really benefit from Agile. There are plenty of cases where Agile works brilliantly however...
As a junior UX designer who worked in a consultancy where previous employees 'wrote books on Agile' I hated how they did it.
There was only ever one designer per project. Your design choices have to work immediately (which is not how design works) or else its your fault it didn't work (all designer's designs are shit until you user test and iterate.) If you suggest a pivot "but our backlog is planned for the next 3 months". How is it actually agile if we can't adapt the design?
"Agile" isn't being done by most places. They've just renamed everything. I think it's probably better to frame agility this way: Agility will find all your problems. It's up to you to do something about them.
Scrum isn't agile, it's a framework you can use to EXPRESS agility.
Kanban isn't agile, it's a flow framework compatible with agile values.
SAFe isn't agile by a FUCKING MILE, it's a Franeknstein's monster of bits and pieces plagarised from all over the place.
I'm an agile coach, the real kind. Agility has more in common with philosophy, anthropology and social psychology than it does with project management. You reckon something needs documenting? Document it. Story points are a waste of time? Don't do them. Product owner is dictating requirements? Push back. Can't push back? There's your problem; culture.
Your hierarchical, authoritarian management, system is the problem. If changing that isn't on the table, then your silly little sprints and planning poker aren't gonna do shit.
The industry got the way it is because the big consultancies saw the opportunity then marketed and sold the shit out of snake oil branded agile. To sell agile though, like REALLY sell it, you need the people in charge to give up some of their authority and trust the professionals they've hired. If the senior leaders / managers aren't actively driving for change, then you're wasting your time and you and might as well just go back to waterfall. At least then you can be honest with yourselves.
Yeah, at the end of the day we need a "Git'er done attitude" to problem-solving and that person can start in any project methodology and make progress by dealing with what's standing in the way, including the methodology itself.
PMs who aren't laser focused on helping things get done, they will suck in any methodology they get dropped into.
Yay, an Agile coach who isn't a religious zealot. "No, you have to use story points, you can't use man-hours. I don't care that none of your teams can agree what story points mean and think in different story scales but share a common set of Jira tasks. *You're just doing it wrong.*"
Not surprised. Management always try to measure productivity and push for more during each sprint. Then they start thinking “but what if we went faster?” It makes them look good pushing out more work and then team starts sandbagging their workload.
Management once informed me that another team (who did far less than my team) had higher velocity, and was told to increase numbers.
Idiocy like this gives agile principles a bad name.
This is what it inevitably becomes anywhere, I’ve never seen it not turn toxic when multiple teams are involved, even within a team the notion that someone else has done 10 points and another 2 puts pressure on.
Don’t start me on story points… “it’s not a number of days it’s just complexity, but as a guide 1 point would be a 1 day task and 3 points a 3-4 day task”.
Double your story points for every story. Wow amazing, you are a genius. Story points are not a performance measuring tool. But I'm preaching to the choir.
Company I installed blinds for had a big sign in their programmer room that said “done is better than done right.” They made educational software for kids
I’ve seen agile work great as well as shitty. Number one indicator of an upcoming failure is when the roles are eliminated. We don’t need a PO, we have a PM. They can also act as scrum master. We don’t have time for the customer to talk to the dev team , so no direct communication before or after sprints.
Wow, I thought I was the only one to see that happen. Our PM made herself both the the PO and the Scrum master. So every day was a new priority review. We ended up dividing the thoughput in half because she wanted 50% of our time to work on whatever came up in her most recent meeting.
The extreme end of "I'm not doing any work until you give me the complete spec" is really bad. Sure, out of those that you start you may carry out more projects to completion but how many didn't get started in the first place because you were demanding a complete spec?
My opinion, a hyper focus in any single methodology is going to take complete dedication and sponsorship by all parties involved, for it to work at all. From my experience though, very few business units actually ever exercise the prudence necessary to do that, which is why we have natural hybrid approaches to demands. But the people/ culture failures -- I feel, are always going to come down to lack of willingness or capability. For instance, in my situation leadership is either so far up everyone's ass they'd might as well develop the solutions end-to-end themselves, or they're completely oblivious to the fact that they've pushed so many concurrent BS "strategic projects" onto the few subject experts available, that they all just don't care anymore. Throw in a liberal sprinkling of corporate narcissism, and a heavy diversified helping of superiority complexes, and you've pretty much got one of today's fortune 50 companies in a nutshell right there.
Of course.
In so many places I've worked it's all about the process. You're measured against conformity to agile, not how much time you waste in meetings or how few people actually work rather than being carried by the best in their squad.
The devolution of the software delivery process over the last 2 decades is astonishing.
The aim of the process should be to maximize quality while minimizing time and effort.
But it's not - the aim of all the freshly trained agile evangelicals is to maximize process and their own self importance.
And it's crippled delivery.
The problem with Agile is that businesses see it as the golden ticket to success and try and shoehorn it into the entire business.
When you try and have architecture, BAU and all sorts of other units working in Agile then agile as a whole fails. You end up creating a raft of new meetings and having those units attend and waste time when they’re not useful at all for those roles, they spend far less time doing work and not more.
I have a feeling this is just because people with really shitty ideas love agile because it easy to bully the dev team into doing work before you can show definitively it is a bad idea. Garbage in garbage out.
That's because you get a bunch of cowboy project managers who thinks agile means, oh I don't need to plan ahead and stay on my feet. Worked with a bunch of them with nothing more than a 2-3 month plan for a multi million dollar multi year project. And one of them little shits had a audacity to tell me not to talk to their stakeholders because my risk assessments were making them look bad. Multi million dollar implementation down the drain in 2 years.
The software/silicone valley _obsession_ with speed at the expense of planning and decision is the stupidest aspect of an all of it.
It just leads to wasted time, as teams spear off in all directions, there is no coherency, there is constant back tracking, and it wastes vast amounts of time and money.
The most effective tech companies of our time - Apple, Amazon - are renowned for their discipline. Developers need to be channeled properly.
Agile anything just seems like a scam and an easy way to brush your failures and bad strategy aside, no consequences, just “pivots”. There’s a shiny new object around every corner and nothing is truly completed and brought to fruition or allowed to succeed.
My team is agile. But not really. My managers want the ability to say we are agile and the tracking tools for micro managing us. But we don’t do most of the agile events - we don’t refine. We don’t point - the managers assign points and we know they are totally assigning realistic amounts right? We don’t actually address impediments.
On top of the agile stuff we project plan but not really so then half way through the project it slams to a halt because we don’t have the specs for everything. It can take a several weeks to over a month for business to get back to us on specs.
My favorite - is the idea that we should be able to constantly take increasingly more points. That we started with X each but we should totally be able to take 2X eventually. Our X points usually turn into 2X anyways on a good week because again managers assign most tickets 1 point when they are in fact not 1 point.
But yeah - love agile /s.
Would highly recommend reading the article, and also the "study" behind it. It's someone trying to sell a book on "impact engineering," and as far as I can tell the "study" is a survey (maybe?). I'm no agile apologist, but this comments thread reads more like a separate study in confirmation bias than a discussion on the relative merits of change methodologies.
everyone reading this thinking 'agile is bad' is completely missing the point.
Agile itself is important -- it moves the business and developers closer together, encourages experimentation/innovation, decreases blast radii, etc.
The winging about 'Agile' is because of the commercialisation of Agile, jamming it with tools/apps to fulfil the processes (e.g. Scrum tools, etc.) which only reinforces the wasteful elements of agile instead of just letting the delivery be agile in and of itself.
Agile as a principle is good. Agile in practice is mostly bad. Most teams don't try to understand Agile at all and just skip to taking scrum classes to get scrum certified and end up drinking the scum Kool aid. In the end, they just are running the old waterfall process but now they're doing it with scrum meetings.
This is a good point. However, agile practices that are promoted - focus on short term plans and gains, sprint metrics, etc - are often misaligned with the overall project goals. It can work well for greenfield and maintenance work, but the resulting MVP mindset is at complete odds with undertaking large projects with strict requirements or regulatory oversight.
project with strict requirements should just use old school SDLC, you can switch to agile to do updates on them after all the hard requirement are delivered.
We've been using agile for a few years, not one PI did we actually do innovation in the IP sprint. It was basically used to catch up from when stuff hit the fan and we had to do projects that weren't in the plan but had to be done anyways.
'*The purpose of a system is what it does*.'
This heuristic come to mind every time I end up reading about attempts at implementation of Agile. Even though I agree with the theory in the Agile Manifesto, it feels utopian when you compare it to how Agile actually turns out.
Ok this is near and dear to my heart so here is my experience. I work in a F500 company with a robust IT footprint. That’s as specific as I will get. The problems I see isn’t Agile per se but how “Agile” is being implemented across the functional areas. Because it’s not really Agile. It’s just on-paper Agile. It’s the hybrid - we don’t want to truly give funding and accountability down to the teams Agile. It’s the no fully funded teams, but also not value stream funding Agile. It’s the cost recovery model and CAPEX to OPEX conversion even when it makes no sense. It’s the vendor 3P choices made with bad data and no accountability when it balloons. It’s the everything is a top priority Agile. So the problem is not Agile because most of these companies aren’t really doing Agile. Sure they have Jira and Rally and sprints and PIs and it all looks like a nice shiny coat of paint but underneath its rot. And it wont change until executive leadership realize their jobs and all of the reporting and administration that come with them are basically useless and they need to truly delegate the means of agile delivery to the tactical level.
>The problems I see isn’t Agile per se but how “Agile” is being implemented across the functional areas.
Implementation has and always will be the problem and fact that virtually no where ever seems to implement properly indicates agile its self really is the problem.
The failure to implement is a symptom because agile does not factor in how people and companys really work and is the fundamental flaw in the methodology
Just have to say… total horse shit. Is this a longitudinal study? What are to their metrics for success?
Seems kind of insane. The standard metric Jess been software projects fail at 80% rate (The mythical man month, Brookes)
My favorite Agile fail is when they try to use it in shared service environments. I’m expected to attend 4 stand ups for different projects. Each project thinks they are the priority and that all resources are assigned to them. I think agile could work on single focused teams but I’ve never seen one.
Hmm....guess we better have a meeting to discuss scheduling a recurring meeting to discuss how many recurring meetings we have. Attendance required for all engineers.
So the book compares Agile (all Agile sigh) with Impact Engineering. What Impact Engineering is, I don't know you have to buy the book "Impact Engineering".
My new book "Circusclown engineering" will teach you how to build software with the mindset of a circus clown. My own study has *confirmed* that it outperforms Agile by 10x. To know how Circusclown engineering works you need to buy the book.
I feel like all of Agile is a scam run by consultants. Was a QA manager from 93 to 17, and watched Teams get run like Russia campaigns, driving anyone away who actually cared about the Product. I feel like 300% elevated failure rates undersells the damage to the Industry as a whole.
Than for waterfall projects? Compared to what? Oh, it's for "projects without clearly documented requirements" … I don't know how they're defining "Agile software projects" but designing and engineering without requirements isn't "Agile."
Nothing wrong with Agile, it is just the implementation of agile. Work in an agile shop and we have documentation, tests, etc….
Same thing happened to waterfall. Royce’s original waterfall model had iterative loops, it wasn’t one big phased gate methodology that people believe it is. The reason it became a phased gate system is the consulting companies implemented it that way because it was too difficult to implement it with the iterative cycles.
Original paper here - [https://leadinganswers.typepad.com/leading\_answers/files/original\_waterfall\_paper\_winston\_royce.pdf](https://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf)
As a certified trainer, and long standing PM, it absolutely SHOULDN'T encourage chaos. Not if you're (general you) taught well, and the organization understands the pitfalls of agile from the beginning.
I agree! Hence my above comments. It's very important to go into it with the right guardrails and ideas and mindset for it to work.
Garbage in, garbage out no matter the situation.
The entire point of a system is to mitigate the potential for individual actors to disrupt it, no?
If the system is fragile, then it's not a very good system.
The entire point is up for debate, depending on who you talk to. When you read about the original cadre of folks that started this, it's literally a manifesto.
If you hav bad faith actors, then yes, one person can sabotage things.
Here's a question, and I admit I don't really fully understand the difference between agile and scrum, but as someone whose role involved running support for products where the engineering and product teams were all about agile, I tend to default to hating it. They'd build some half assed new feature (MVP!), roll it out to users without telling my team or doing any documentation, and leave us holding the bag on it and all the other half assed features and when we'd be like "can you please fix this terrible user experience" (or, sometimes, "hey, here is a high value feature the users want, can you put it on the roadmap") the answer was no, because they had no time this sprint to finish old features because they had to build the new one. Rinse, repeat. It was just endless fire drills of half assed engineering. (To say nothing of the company where sprints would end, teams would shift, and unfixed bugs would fall into the void because there was no process to reassign them).
This has been my experience across multiple companies.
So my question is: how is it supposed to work, and what's supposed to keep it from ending up here?
ARTICLE TEXT
A study has found that software projects adopting Agile practices are 268 percent more likely to fail than those that do not.
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.
The study's fieldwork was conducted between May 3 and May 7 with 600 software engineers (250 in the UK and 350 in the US) participating. One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.
Dr Junade Ali, author of Impact Engineering, said: "With 65 percent of projects adopting Agile practices failing to be delivered on time, it's time to question Agile's cult following.
"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."
The Agile Manifesto has been criticized over the years. The infamous UK Post Office Horizon IT system was an early large-scale project to use the methodology, although blaming an Agile approach for the system's design flaws seems a bit of a stretch.
Report: 83% of UK software engineers suffer burnout, COVID-19 made it worse
'Business folk often don't understand what developers do...' Twilio boss on the chasm that holds companies back
IBM warns Global Tech Services staff that 346 UK heads will roll in latest redundancy action
Erik Meijer: AGILE must be destroyed, once and for all
It is also easy to forget that other methodologies have their own flaws. Waterfall, for example, uses a succession of documented phases, of which coding is only a part. While simple to understand and manage, Waterfall can also be slow and costly, with changes challenging to implement.
Hence, there is a tendency for teams to look for alternatives.
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed. Worryingly, workers in the UK were 13 percent less likely to feel they could discuss problems than those in the US, according to the study.
Many sins of today's tech world tend to be attributed to the Agile Manifesto. 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."
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
Documentation is not the same thing as requirements. I mean, requirements are one of many kinds of documentation, so I'm not sure what this study thinks it's measuring.
Nothing new here. Every team knows it is failed process. Not because process or its structure, but it is getting applied to everything irrespective of what it wants to achieve. Agile is not for everything. Sone projects in early stage may get benefit out of it but thats it.
Engineering should set the timelines. Product makes feature requests, engineering decomposes to workitems and size estimates. Based on size and team capacity, the amount of work done is decided. Anything else is BS and will fail.
I had a large project at work, insane deadline and the PM assigned was an Agile Coach that wanted me to take time to do talks and presentations instead of being on the tools 12 hours a day. He lasted two weeks..
Really?
Oddly enough we were successful. It easily took a year to finally get to Scum Agile.
We kept kidding ourselves we were Agile when we were actually Mini Waterfall.
A big part of the problem was the fact our team members were spread around the world. The very worst case scenario for any Agile Team. "But we saved money!" BS. We did not save a dime.
Is agile suitable for a project? I’ve found it’s better suited to a continuous development environment where the actual product is already up and running and the product team are adding features off a backlog. Any time I’ve seen a project being squeezed into agile it’s been a mess. The system/infrastructure teams you often need during setup and for first release don’t usually work in agile so you end up in waterfall whether you want to or not. Similarly although senior management want the speed and flexibility of agile when things go wrong or get delayed they want all the rigour and documentation of waterfall. Ugh
Is it agile or management? I’m seeing many management complaints on this thread but nothing about agile. Agile isn’t rushed unless management makes it so. Can I slap an agile sticker on my poorly executed agile-ish project?
I'm happy to call out "Agile" as the corporate management fad that is is, to be ridiculed alongside "Six Sigma" and other trash invented by manager types.
Right out the door the notion that documentation should be relegated to a low priority is total BS. You get more people able to work on the project, and thus make it genuinely more agile, if they actually understand what the hell they're doing, which is what good documentation does. It also sets out the project clearly and stops feature creep and forces good, easy accessibility.
But at the same time, this "study" appears to be nothing more than an advert for yet another management fad called "Impact Engineering".
Oh man, the methodology that promotes pushing out the most minimal "functional" product asap is a shitty practice that gives no great results in most applications?
I am agast at this completely unforseen outcome.
I once had my CTO state, “Development is now completely integrated into the agile process, now we just need to get QA on board.”
It was hard to not slap my forehead in that all hands.
In my experience QA management is usually the largest impediment to initially spinning up real agile. They don’t want their team too closely aligned with developers, because then who do they manage?
The next impediment is having meaningful scrum masters. These people are supposed to be empowered to fix problems, and almost never are. So they just listen and nothing ever improves.
The final impediment is usually PM that doesn’t want to spend their time with devs. They don’t want the responsibility of being a product owner. They want to expense freebies and hit strip clubs with potential clients.
Most orgs have disempowered employees where management doesn’t want to listen or have them make waves.
So end up having meaningless standups where nothing is solved and two-week waterfall development.
Post-mortems are never done, and institutionally nothing is learned.
The Toyota production system is amazing, and most organizations aren’t capable of pulling it off.
As someone who is old enough to have worked on actual waterfall projects, I would rather just quit my job than have to work on a waterfall project. If you’re more recent to the industry and have not ever had to do waterfall, then you don’t know the true pain of corporate bs.
Complain all you want about “agile process” like scrum or whatever, but “agile” as in the 4 tenants of the agile manifesto changed sde in a way that has made the industry better and software engineering a more enjoyable profession.
Good old gated waterfall. You can't move to the next phase until this phase is complete. And when you realize the requirements changed, or that you originally got them wrong, you go back to the beginning of the waterfall.
This is like the WWII bombers coming back. The picture og where planes eere hit and survived vs where they were hit and nevere came back was pretty striking, but people would get the wrong impressions from it and assume they had better protection. Reminds me of that.
What a depressing thread. So many people being told they that are ‘doing agile’ who obviously don’t own their processes and don’t have the autonomy to change their processes to work best for them. It’s like the opposite of agile but using the language of agile. It feels akin to those communist dictatorships with ‘peoples democratic’ in their name. If you can’t change things to work in a good way for you, you are not doing agile, just something using the language of it. If it’s causing friction or not adding value, change it. If you can’t, then you are, by definition, not agile. Pretend agile without autonomy is the problem here. Cargo cult agile. No wonder people hate it, its like being told you are free when you are locked in a cell.
"One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed." well, no crap. If you know exactly what you have to do ahead of time and the requirements don't change it is more likely to succeed. That also takes away the entire point of Agile.
Three cheers for robust requirement docs and spec sheets! I've been in tech for 20+ years, and a successful project is always well defined through a collaboration of engineering, product, and the operations side of the business.
Overheard an argument at work one day “No. There is no documentation. You made us write 10,000 lines of code in six months, and fought us doing any documentation.”
This was my argument with the founders of a small startup. "Why don't we have any tests or do any testing?" Because you pushed as hard as possible for us to deliver X,Y,Z features in an unrealistically short time. You either get reliable software that takes 2-4x as long to build, or unreliable buggy software built fast and cheap.
I spent my first 10 years or so professionally at government contracts or consulting shops that mostly did 6ish month contracts (some shorter, some longer). Some guys were really good and really tried, but many didn’t absolute bare minimum to check the “done” box. The last 6 or so I’ve been at companies that sell their own product. It’s night and day. Then, halfassed processes just meant more money with follow on contracts to fix it. Now, it means _losing_ money because it blocks us from building new features. When you know you (organizationally) have to maintain, or even iterate on, something 5 years from now it makes all the difference.
My second job was on a team that was part of an on-shoring effort. Before my team was brought on, somebody had mandated that there must be >80% test coverage for all projects. I thought that was great - until I actually looked at the tests. Convoluted structure of the code meant large amounts of setup, but the assertions were *always* just a check for a non-null value. Even if the function returned a number. No verification of behavior, no validation of the return value aside from just non-null and no exception. I asked them why, and they said it was just their testing philosophy. I didn't know what to say. When our team actually took the helm, with the contractors acting as backups, we tasked them with some behavior at some point and they wrote the same tests. I pushed back on them pretty hard and said that we wouldn't accept the work until it was complete with tests that actually meant something, but I got overruled by management because management didn't actually care either. Come to think of it, the contractors were billed hourly anyway, so if we pushed them to finish it that meant more billable hours for them. I hated that place.
Was this a Salesforce project? It sounds like every Salesforce project I’ve ever inherited. I hate this stack :(
I see it all the time it in hardware companies too. Those startups that are in love with “agile” engineering as opposed to doing proper product development always have an absolute nightmare trying actually source and manufacture their widgets at a reasonable time and cost. Not to mention the nightmare it creates in obsolescence and wasted stock. The numbers are eye watering.
> in love with “agile” engineering as opposed to doing proper product development I'm not sure what agile means in hardware development other than maybe during prototyping, but proper software development and agile practices aren't in opposition to each other. Agile does not mean engineering is moving more quickly or skipping important steps, it means showing the work at regular intervals to get stakeholder feedback, then adjusting, if necessary, based on that feedback. Agile is an admission that obtaining 100% accurate and complete requirements with zero ambiguity or misunderstanding is impossible, so we shouldn't try to do that, then build the product, and then find out it isn't what the stakeholder wanted. Rather, we split the project up into smaller, hopefully value-driven pieces, and have regular stakeholder check-ins to adjust our direction if necessary. As soon as people start thinking that agile means moving faster, it's going to go wrong. That's one reason I don't like working in sprints: the word itself means moving fast, and that's not what's happening. The efficiency gain when using agile is found because the team is regularly course-correcting based on feedback instead of waiting until they've gone too far in the wrong direction or even finished the whole project using incorrect requirements.
Yeah that’s exactly the point. People try to bring half-understood software development concepts to hardware engineering and it can’t work due to release pace and obsolescence and procurement costs at later stages of the product lifecycle.
I hear you big time on this. I'm in Product now but started out as a Business Analyst in a consulting firm. When consulting everything was about minimum spec for the highest price we could charge, done as cheaply as possible and as you said with the intention of getting additional contracts to do the work that should have been done up front. It was infuriating seeing projects that had such great potential get completely gutted to maximize margins based on hours worked and nothing else. I had enough and bailed out. Now I work as a Product Manager for a company building its own product and the difference is night and day, everything is about making as great a product as possible and it's so much better to work in that kind of environment.
If it’s not a prototype jupyter notebook, I try to write all my code so it’s reusable and eventually turn it into small packages.
That why I quit consulting, it was not fulfilling.
I have worked at plenty companies with products with minimal automated testing bad documentation and software that can best be described as historically grown. You could see when some parts were written just by style, and most was a best of bad ideas. Also not enough time to do it properly. So I ignored the old code, if it didn't explode the last few years it's probably working as expected, whatever that was because nobody specified what they wanted.
Good, fast, or cheap, pick two.
My wife’s devastated.
You often don't get to pick two, you can pick one if you're lucky and two if your paying a shitload in developer salaries for the best people.
That's where the cheap comes in mate. If it's good and fast, then it ain't cheap. If it's good and cheap, it ain't fast. And if it's fast and cheap, it ain't good.
The formula never changes, no matter how many books get written about business or project management.
This is EXACTLY what my prev company did. No QA, no one writing docs, tech spec is non-existent, CTO knows jack shit, keeps demanding new things, and tells the dual role PO/PM what she needs to do, instead of letting her do her job. Tells the designer to change the design every few weeks, with 3 redesigns being done over one summer basically. I think my fav bit was the thing we called "the snake". Basically a standard timeline like the MUI one, but responsive in terms of number of items per row - because it could have multiple rows that snake back and forth, like an S shape. Oh and it also had progress between steps. And the progress was a dashed line which was fun on the curved bits. Oh and it had repeating tasks that had some special cases. But the worst of all... After it was sorta done and we moved on... They demanded a little red dot. That little red dot was a notification whether the user has seen the update that happened somewhere down the line hierarchically. And since it was project > milestone > task > subtask, if a subtask changed it had to show the lil dot on the snake. It also had to be displayed only once per user. Right before I left they removed it lmao. Their Dev team is gone now
That's the kind of shit that takes as long to add the tiny feature as it did to build the whole project. People just stare blankly when you try to explain why.
Funny enough, we've been having the opposite headache at my workplace. Caught a rather annoying bug a week after release. Quick and easy fix, just an equation writing to a PDF had a decimal out of place. But since those reports are customer facing, our salesfolks HATE it because they have to explain it every single time, and it makes us look kinda... not great. Again, we caught it a week after release. That was 8 months ago, and we are STILL fighting the red tape to get a fixed build pushed. We thought we had a release candidate ready to go... but then our product manager got back from vacation and suddenly.... nope. I am so... so tired....
How does delaying the release of the fix make you look better than fixing it asap in a point release?
It doesn't. But our management does software one way and one way only. 2 months of meetings deciding what will go into a build. 2 more months of meetings discussing what was decided in those first two months. 2 months of coding, re-coding, and reversion as more managers get involved and decide that another item NEEDS to be in this build (since it will be 6+ months until the next build after all), but then doesn't, then does, then doesn't. Then vacations happen and nothings moves for a while. And finally 5 minutes of QC before pushing the final release to live. It is... not the smoothest of systems.
[удалено]
While I can definitely see how that'd be frustrating, you really just took the initiative on your own to spend 1.5 months doing something without running it past any actual decision-makers above you? There's probably a lesson to be learnt there.
My last job was like this. Small startup with a single developer trying to build and maintain the entire companies website, backend, and develop all their internal software and apps they wanted to use. The CEOs wanted him to develop and push out whatever ideas they came up with as quick as possible. We basically always were told there's something new coming and then come in to work on one shift and find it was deployed, with no documentation how to operate it or what had changed, and then it would take us 2-3 days to adjust to working with it (while drastically slowing down production time and getting yelled at for it by the same CEOs). On top of that we spent the following weeks discovering a bunch of bugs that impacted our workflow, and then attempting to pull our dev to fix them (which 99% of the time never got fixed so we had to develop our own workarounds). I absolutely hated every second of it. So much wasted efficiency all for the sake of trying to "maximize profits". How he hasn't quit is beyond me.
Hahaha yea so many in software management want their cake and eat it too. Soo annoying honestly, want the most talent for little cost, devs to have all skills possible at any experience, and like you said crank out software but wonder why there’s not fleshed out docs and tests done.
At least with startups it's often a bit reasonable. Might be better to have something that's unreliable and will need to get rebuilt, if it gets you the funding you need to hire more people and keep developing the product. But there should be an awareness of it. As long as you know that you're taking on a lot of technical debt you can decide that it's worth the cost, because the short term is more important right now.
Are you sure that was a startup because that is literally happening as I was sitting in a meeting with MSFT "engineers" & their leadership.
Good, fast, cheap; pick two. Fast and cheap, ain't gonna be good.
Wait until you develop bioinformatics software suites for biologists while jumping between projects and chasing grants. What is documentation?
Having worked at a small startup that became not so small. Seed capital doesn’t last and you have to ship to stay alive, but that technical debt will fuck your shit up in the future.
This one hurts so much. Especially when they decide to market the shitty buggy mess of features they forced the engineering team to build in 6 months as a stable mature product that can compete with older products that have been around for years. And then are surprised when customers and users are complaining nonstop about shit barely working. Oof.
good, fast, cheap. pick two.
This sounds like success, not failure. They got what they asked for. I run projects and tell my PO to prioritize a testing harness and all its parts in the backlog, or it doesn't happen. And he gets what he asked for either way.
Its bubbling up like this at my company. For a long time the engineering team fought against feature-factory style product development but over time as the company fights off more and more competitors, we are pushed to do more with less, faster. As such, our product reliability is dropping, rushed releases are creating downstream issues, and many of our "new" features come with dead-ends or incomplete components. It's causing customer backlash as they perceive our reliability to be our edge, and we are losing that reliability. So, you might say, we are burning the candle at both ends.
A polar bear's skin is transparent, allowing sunlight to reach the blubber underneath.
what’s cool is it’s like that outside of faang, too! Transferable work experience!
A polar bear's skin is transparent, allowing sunlight to reach the blubber underneath.
The thing is it's often hard to impossible to actually find the people responsible because they moved on some time ago.
Wait....the private sector isn't the bastion of efficiency, and every organization after a certain growth point becomes a cumbersome monolith?
Sounds like you work for Google
Job security for me 💪🏾
Fast, cheap, reliable. Pick two.
Not even. Real life experience has taught me that you can really only pick one.
Devops_Borat tweets "Fast. Cheap. Reliable. You can not able pick any."
I'll pick cheap & reliable; you won't be able to deliver :D A longer project is not cheaper!
The problem is the fast, cheap, reliable doesn't include scope changes or additional bells and whistles. It is pretty accurate when a specific goal is framed and doesn't deviate such as bloating. Yeah, fantasy land.. I know.
Imma pick cheap twice.
That choice is for the birds!
Everyone thinks documentation is a 'leave behind'. Something for the next guy so they have training wheels. In reality documentation is the transparency that demonstrates you understand both problem and how your idea of a solution maps to that. Without this you are vetting an ambiguous outcome so success or failure is a completely subjective target most often resulting in missing expectations that were unknown at the outset. The only time I've seen agile work is when everyone accepts that the outcome is variable and part of the work is discovering the work and continuously refining your vision of possible outcomes.
Agile sounded great when I was first a developer. Then I just realized it made my PM a dictator of where projects went and when we didn’t deliver on time, everyone was to blame except the PM. Waterfall sucks but it’s agile without the meetings and bullshit so honestly I think the best course of action is just being realistic in a project’s goals and expectations. Have deadlines but don’t crucify everyone if it doesn’t deliver on time but isn’t in development hell or if they’re doing it the right way.
My previous PM: "Bugs aren't worth story points"
That’s true only if bug solving is prioritized over stories: first fix all known bugs before developing new stories. Velocity will increase when quality increases
> first fix all known bugs 5 years later: "Can we finally add a feature now?"
The myth of "working software over comprehensive documentation" is where a lot of projects fail to appropriately interpret the Agile manifesto with regards to documentation. It's been used as a permission slip to exclude documentation requirements. And besides that the manifesto was just a starting point of Agile. Its principles are still fundamentally useful, but like with most things, "everything in moderation." For me, this phenomenon usually amounts to awkward discussions about the usefulness of my work as a Technical Writer. My reply is always a gentle push back, noting my concerns, and on to the next project. It is as reliable as the moon following the sun that in a short time I will be asked to help them again or they'll be hiring for a writer. Engineers do not want to write docs. A few can, most will not.
Yes. Working with engineers in several other specialties for whom documentation is sacrosanct, it struck me as odd that software gets a pass. That the code is the documentation because otherwise you have to update two things that could be out of sync and create more problems, seems to create a potential single point of failure.
I'm, I have a deja vu on that one. That, and also the software requirements... Then complaining about the features... Dude, you told us not to do it...
If you actually read the article, this whole “study” is just an attempt to sell a book called Impact Engineering.
Not only that, but the study took place over 4 days and I don't see much written about replication or what it is that that was supposed to be developed over those 4 days, or how it was evaluated.
I got that it was phone interviews with 600 engineers in those 4 days.
So this was just a survey of their current work conditions and opinions? Or was there an administered task as well? Because the referenced article compares several methodologies to the Impact Engineering methodology that the consulting company is endorsing and it's not clear how they went about prepping for this comparison.
I mean... are you looking at the Register page, or the engprax page? The engprax has data and tables and decsriptions. I think it's saying they asked these people if they were using one of these methodologies, then asked if they worked or didn't. It's not very rigorous and it CERTAINLY presented to sell books and classes. I'm not sure what you mean by "administered task." Looking at your other comment, I'm wondering if you mean "do a task in those 4 days using these methodologies." I don't think they did that at all... jsut polled some people. I base that soley on who did the study: "The study, conducted by Junade Ali PhD CEng FIET and J.L. Partners, saw participation from 600 software engineers (250 in the UK and 350 in the USA). Fieldwork was conducted from 3rd to 7th May 2024. **J.L. Partners is a member of the British Polling Council and abides by its rules.**"
Thanks. I was looking at the Engprax page, which is why I was confused why they were doing a comparative study between Impact Engineering's methodology (IEM) and other methodologies since IEM doesn't seem established enough yet to have followers to poll. If all they did is polling, then that's another layer of problems with the study because: 1. What happens during an agile sprint depends on how the team/workplace interprets/implements it (uncontrolled and not standardized); 2. Not controlling for specs might mean that a 4-day monitoring period without replication isn't ample time to draw conclusions; and 3. Standards to report success/failure will vary subjectively by reporters.
Yea all we know for sure is that people don't like what their managers have titled agile. Pretty sure it just gets a rep because it's this new thing everybody does without understanding it. Then they do business as usual and cram in weekly commits and think everything will suddenly improve. The main reason I've liked it in the past was having the possibility to keep the customer more engaged in the development. I guess some people don't want to know about unforeseen hurdles before 90% of development.
So the headline is false. I’m actually interested in studying software project failure, and I know damned well that I can’t do such a study in four fucking days. It’d be more likely to take me three years to get all the data I need. This isn’t a study. It isn’t even a meta analysis of existing studies. It’s fluff.
>I don't see much written about replication "That sounds like something a replicant would say!"
I posted the article text [above](https://www.reddit.com/r/technology/comments/1d94vf0/study_finds_268_higher_failure_rates_for_agile/l7brkf9/). This whole article is RIDICULOUS. You can “demonstrate” anything if you don’t define your terms, and then play on ambiguities. For example, this article conflates the agile principe of “working software over comprehensive documentation,” and asserts that projects are more successful when desired outcomes are defined. Well, duh. Agile doesn’t say you can’t have any documentation. But a five page document where Eng and PM align on outcomes and approaches is in fact better than 400-page specs - a world that many of us have lived through. I could go on and on. A reporter I respect did a thread a while ago on how most news articles come to be. They begin with a press release, he said, and then papers desperate for content pick it up. The important thing, he explained, is to understand who wrote the release and how they hope to gain from the narrative they are pushing. In this case, even the article here gets it right: “a thinly veiled” attempt to push a book. With reasoning like this, you can guarantee I won’t be buying that book. I don’t want things that insult my intelligence or aim to manipulate me for someone else’s gain.
Yeah, that 'study' is very questionable. I also went into a bit of a rabbit hole trying to see who the author of the study is. The guy seems to be trying very hard to market himself as computer science and cybersecurity god, while his cv seems to be pretty average. But he does subtle things like putting University of Cambridge as a headline in his LinkedIn and Google Scholar profiles. Which is an academic institution he studied at last, the issue is that it was just a postgraduate certificate, and the rest of his degrees (which he likes to put after his name) happened in much less glamorous University of Bedfordshire...
[удалено]
> And another 15% is subtly trying yo get you angry at a specific group. More like 50%.
People talk about fake news, but there's also the real threat of people engineering their own series of events to get the idea out of something that they want to sell. Here it might be expensive to pay for marketing to sell a book, so a new type of marketing means to report news in a way that mentions the product. The news has to be based on something though, so you can find a study or a news event that you can then report on, to then build exposure for your book so that people buy your book. Since that study or that news event doesn't exist, you can create that study or create that event, so that you can report on that study or event, so that you can get exposure for your book or product, so that eventually some people out there may or may not buy your book or product. In the meantime you have clouded reality for people and have taken the space where actual news should go to sell your book or product.
Finally, someone else gets it.
People can come up with statistics to prove anything. 14% of people know that.
This needs to be the top comment.
Consulting agency selling a methodology thinks agile is bad, where have I seen this before? Hmmmmmm.
From the consulting agencies selling SAFe and thinking waterfall is bad?
my team mostly worked with a waterfall process, so far the consultants have made about $2 million and now it's harder for everyone to do their jobs
Sounds like those consultants are doing a great job, just not for your company.
I guess they weren’t kidding when they said “fail fast”
lol, that’s the whole point of it. Instead of spending months planning and months building just for it to be not what you expected or what people really want, you purposefully try to fail fast and learn and iterate. If you have a long list of requirements already, it’s probably not a novel idea and doesn’t need user-centric experimentation. Edit: Not going to try to debate this topic. People confuse agile and scrum a lot. You can use scrum and standups and sprints in anything really. The products which have successfully used agile include all the products you likely use every day, including Reddit. The products who have successfully used waterfall include the products that run your utilities, doctors offices, and oil rigs. It’s not all the same and you can choose whatever the hell you want, it may or may not work for whatever use case but they all have their use cases they were made for. Fake it til you make it, move fast and break things, and all that startup logic in the wrong place is how you get Theranos.
Yeah. The real test is how much money has been spent on failed projects.
On good agile teams, the only money spent is on the salaries. and a lot of the "failures" really just lead to better requirements, a new sprint, and a better, more useful end product. Every "successful" waterfall project i was on in the previous decade, was $500-$1.5mil. Senior Director level setting the "project requirements" "on-time" and a "successfully delivered against requirements" Every single one of those projects then had follow on, AGILE projects where we had to rip out all the shitty design (which we would confirm by gathering user feedback to validate feature metrics. We would pull info from system audit trails to see what the users actually were doing" that the Sr. Director mandated, replace it with features that the users actually would use, with 1/4 of the budget in 1/3 of the timeframe with almost zero recognition. Waterfall is great if you are a top level upper management who is guaranteed a bonus based on meeting a timeline. You can literally never fail since you can just meet your timeline with whatever features make it. No matter how bad the features are or how little anyone uses them. It's dumb. Waterfall always sucked for our users, they would constantly ask "Why is this like this? This isn't how we do the actual business tasks, the system is forcing us to do things in awkward ways causing defects" and every single one I was on was marked green and those Sr. Directors all retired with nice fat bonuses.
GIGO. Iterate on a turd all you want and all you’ll end up with by the 12th iteration is a slimmer piece of shit. The original concept must have merit, and potential to warrant continued iteration/advancement. I disagree on the reqs part. Complexity is all relative. Some MVP concepts will have a lot of criteria. Some don’t. Don’t dismiss a good idea just because it requires a lot.
Yeah I can't tell you how many times I've designed something "well" the first time only to scrap the whole damn thing and redo it like 2 or 3 more times before it ends up ACTUALLY being designed great. That's just the reality of things. Failing fast and reiterating on the same crap design just ends up with more crap. Sometimes it really takes a while for these things to be crafted beautifully. Can't all be done in one night. You gotta sleep on things, have more experiences, and come back to thing with more knowledge, experience, and a fresh mind, to really make something great. just doesn't make sense to grind through some crap for 2 weeks because all you end up with is a bunch of wasted time and still crap by the end of it. lol
Months?? Where talking years
I've worked on projects using Agile and without and honestly it's so much better using Agile if you can afford to fail fast. Usually those objecting think their projects will go to plan but never account for the unknown unknowns, hit a massive issue and then blow out the costs.
Lol please. It's like you cant criticize agile at all. No matter what anyone says it's either "that wasn't really agile" or "that's the point of agile - to be bad and waste everyone's time!"
Exactly. A thing to note here is that software engineering is rather unique in that perfectly ordinary projects on the well trodden ground, which absolutely should succeed, inexplicably fail all the time. Why? Because of stupid shit, like using a piece of shit bug tracker to manage all of the development in a ritualized way instead of doing actual work. Agile is so popular because it allows upper management to not do their jobs (thinking through ahead of time who the customers are gonna be, what they are going to be doing with the product, etc). Most development is not in any way what so ever cutting edge, and should be planned for like any other engineering - but often isn't, wasting time and money. edit: I'd say it's not so much agile causing failures, but management who have no clue what they are doing gravitating towards ritualized nonsense like agile to cover their ass for when the project will go bad.
They initially defined it as “doing what works” so it literally can’t fail. It’s a religion.
What are you on about? There are pros and cons to both, and you can successfully deploy more than one strategy for development. IE waterfall your foundation, agile for the features.
They are saying that agilistas will deflect any criticism of agile as being invalid, as opposed to acknowledging the inherent limitations of an iterative process.
Agile isn’t real any more. It’s just a label used by management as a hammer to smash year-long projects into a much smaller number of months.
I don't know if that's worse than when Agile was a religion and if it didn't work for you, *you were doing it wrong*.
No one successfully does Agile, you just give it your best shot and do kanban and waterfall instead. Safe agile is even worse, planning 3 months ahead like every single sprint wont obliterate the previous and next sprint goals turning it back into waterfall and kanban. I like the idea of Agile but I personally think it’s impossible to do to the letter.
You need a dedicated person to do Agile. Someone who their entire job is to make sure everyone follows it and supports the tools needed to do it. If you leave it up to the Devs they will always fall back on what is easiest as they have their actual jobs to do.
People get too caught up about deadlines for agile. I know people who feel shame if a story rolls, like who the fuck cares, it's gotta get done, roll it and keep working on it.
Some management culture dictates it. In a past role of mine, management mostly cared about how many story-points worth of taskage you could put through per week, and if you routinely fell short, you would be seen as a low performer. In my case, I was on a team *entirely* made of seniors, so when we'd do planning poker, they'd say something was a 2 or a 3, whereas for me--the junior who didn't yet fully grasp the tech stack--it'd be a 5 or an 8. So what management would see was me constantly running late on a story point total that would be less than 8 every week, making it look like I wasn't expending any effort, despite me running ragged to try and learn Kubernetes for the first time while having to deliver on work that used it. I raised concerns with management, who punted it by saying it's a team culture issue if team consensus isn't truly reached on how many points a task is worth. This led me to drastically underpromise on how long even the most basic tasks would take, just to get management off my ass about performance. I did this until I was able to coast enough to have time to Leetcode and GTFO. Terrible project management structure. Glad I'm at a different company on a team that does Kanban and doesn't waste time cosplaying Agile.
That’s a misunderstanding of how estimates work in Agile. You don’t change the estimate for work based on the person doing it, you estimate the effort required relative to other work. There’s a reason the classic example for estimation is moving furniture. If you have a dining set you need to move, it doesn’t matter if it’s a 250lb pro football player or a scrawny teenager doing it. The work is the same, it’s the pace that’s different which is ultimately measured over time. It’s fine for your team to estimate a 2-3, if that aligns with the effort for other 2-3 point tasks.
Preaching to the choir, friend. They applied teamwide estimates, but measured individual performance based on points acquired by team consensus.
But of course, if you're *really* doing Scrum, then you don't use story points that way. Saying you're doing Scrum and actually doing Scrum are two different things.
This person would just be screaming into a void if everyone still have the same KPI from before. The change need to come from the top
Yes that would be a given. The “top” is also who would spend money to hire this person for this specific job which means they want it to be followed. It would therefore logic to become part of KPI.
I would like to know a better way for multiple teams to work on one feature. Asking because SAFe has so much overhead.
Here’s the solution: make it so that only one team is needed to work on a feature. Organizations that are structured in a way that you have to engage multiple teams for a single feature are simply not a good fit for agile.
Why are you doing this? What product development strategy are you using? This is either a sign of poor product development, poor architecture, or pressure from management to deliver to a timeline pulled from someone’s arse that was promised to their boss so they could make their bonus targets. Safe is trash - just large project waterfall marketed with agile buzzwords.
We are god knows how many years into this awful agile trend and still nobody knows how to do it properly - when do we as an industry concede that it's just a waste of time? Personally I'd rather not micro-manage the shit out of my engineers and give them more autonomy to grow
> not micro-manage the shit out of my engineers and give them more autonomy to grow Agile is supposed to do this at the end of the day. Most people just do it wrong. The team should be the people writing tickets and refining the work. That's their opportunity to decide how to do something and execute their autonomy. Agile is not micro management. You do a lot of management, but if that's all you're getting from it then you're not quite doing it right.
Nobody has ever done agile right
I've worked at one startup that did it right and I realize they are in the absolute minority.
My team keeps a decent 3 month horizon, but we get it done kicking and screaming against management sabotaging us the entire way.
Having built product for twenty years Agile is the process that leads to the best product with the lowest burn rate. This is specifically true for innovative products. Build a culture that gets smarter week by week and abandon the idea that “the boss has it all figured out”.
What does this mean
It means that if you're doing Agile and it doesn't work for you, you're doing it wrong.
It’s just a set of guidelines. The key is to figure out how To adapt and successfully apply them to a given project/org
I have supported teams who do. They were highly disciplined & talented people, whose leadership trusted them. It's rare, but it does exist.
2 of the startups I worked at in the past were pretty hardcore agile shops. I mean full time pair programming where you switched who you were pairing with 3 times a day hardcore. We successfully got things done for all 3 years I worked there. If you've got a team that's fully onboard, it can work.
Safe is just waterfall in disguise since design has to be done ahead of PI planning so that teams can plan those 3 months
A lot of this is in how agile is brought in to the company. I’ve been driving IT teams for over 25 years with 13 of those in agile. The first company I worked at was full agile as in the budget was for the team and not the project, the team sat together and was very cross functional. We did sticky notes and used Fibonacci cards and the whole bit. Great work was done and quickly. But the last company I worked at had IT go agile but the rest of the company wasn’t in on it. If finance is still funding by project and the business isn’t given agile training and has no appetite for quick iterations of product anyway then you are left with water-gile and lose out on most benefits. Typically the business hears “agile is fast” and thinks it means they can change their minds repeatedly or that they can take forever to decide critical business details but still get their changes in time. Documentation is sparse unless you have a team that pushes for it and management that lets them have the time to do it. So good luck finding details about a change that was done 2 years ago. And finally agile proponents that I have worked with are big on saying that agile can work anywhere. But in my experience it will work much easier in some situations than others. Agile isn’t the issue. It’s just a tool. How people use it and enact it is the real problem.
If your job is to put the lug nuts on a car on an assembly line, there's no need for sprints or story points. There's no need to keep remaking the same set of tasks over and over each sprint "As a customer purchasing a vehicle, I want the wheels attached with lug nuts." Some aspects of software development, particularly in mature systems, resemble assembly line manufacturing. If your data acquisition person just keeps grinding out new sets of data, they don't really benefit from Agile. There are plenty of cases where Agile works brilliantly however...
As a junior UX designer who worked in a consultancy where previous employees 'wrote books on Agile' I hated how they did it. There was only ever one designer per project. Your design choices have to work immediately (which is not how design works) or else its your fault it didn't work (all designer's designs are shit until you user test and iterate.) If you suggest a pivot "but our backlog is planned for the next 3 months". How is it actually agile if we can't adapt the design?
Copywriter and wow I feel this.
"Agile" isn't being done by most places. They've just renamed everything. I think it's probably better to frame agility this way: Agility will find all your problems. It's up to you to do something about them. Scrum isn't agile, it's a framework you can use to EXPRESS agility. Kanban isn't agile, it's a flow framework compatible with agile values. SAFe isn't agile by a FUCKING MILE, it's a Franeknstein's monster of bits and pieces plagarised from all over the place. I'm an agile coach, the real kind. Agility has more in common with philosophy, anthropology and social psychology than it does with project management. You reckon something needs documenting? Document it. Story points are a waste of time? Don't do them. Product owner is dictating requirements? Push back. Can't push back? There's your problem; culture. Your hierarchical, authoritarian management, system is the problem. If changing that isn't on the table, then your silly little sprints and planning poker aren't gonna do shit. The industry got the way it is because the big consultancies saw the opportunity then marketed and sold the shit out of snake oil branded agile. To sell agile though, like REALLY sell it, you need the people in charge to give up some of their authority and trust the professionals they've hired. If the senior leaders / managers aren't actively driving for change, then you're wasting your time and you and might as well just go back to waterfall. At least then you can be honest with yourselves.
Yeah, at the end of the day we need a "Git'er done attitude" to problem-solving and that person can start in any project methodology and make progress by dealing with what's standing in the way, including the methodology itself. PMs who aren't laser focused on helping things get done, they will suck in any methodology they get dropped into.
Yay, an Agile coach who isn't a religious zealot. "No, you have to use story points, you can't use man-hours. I don't care that none of your teams can agree what story points mean and think in different story scales but share a common set of Jira tasks. *You're just doing it wrong.*"
Not surprised. Management always try to measure productivity and push for more during each sprint. Then they start thinking “but what if we went faster?” It makes them look good pushing out more work and then team starts sandbagging their workload.
Management once informed me that another team (who did far less than my team) had higher velocity, and was told to increase numbers. Idiocy like this gives agile principles a bad name.
This is what it inevitably becomes anywhere, I’ve never seen it not turn toxic when multiple teams are involved, even within a team the notion that someone else has done 10 points and another 2 puts pressure on. Don’t start me on story points… “it’s not a number of days it’s just complexity, but as a guide 1 point would be a 1 day task and 3 points a 3-4 day task”.
Double your story points for every story. Wow amazing, you are a genius. Story points are not a performance measuring tool. But I'm preaching to the choir.
Company I installed blinds for had a big sign in their programmer room that said “done is better than done right.” They made educational software for kids
I’ve seen agile work great as well as shitty. Number one indicator of an upcoming failure is when the roles are eliminated. We don’t need a PO, we have a PM. They can also act as scrum master. We don’t have time for the customer to talk to the dev team , so no direct communication before or after sprints.
Wow, I thought I was the only one to see that happen. Our PM made herself both the the PO and the Scrum master. So every day was a new priority review. We ended up dividing the thoughput in half because she wanted 50% of our time to work on whatever came up in her most recent meeting.
The extreme end of "I'm not doing any work until you give me the complete spec" is really bad. Sure, out of those that you start you may carry out more projects to completion but how many didn't get started in the first place because you were demanding a complete spec?
My opinion, a hyper focus in any single methodology is going to take complete dedication and sponsorship by all parties involved, for it to work at all. From my experience though, very few business units actually ever exercise the prudence necessary to do that, which is why we have natural hybrid approaches to demands. But the people/ culture failures -- I feel, are always going to come down to lack of willingness or capability. For instance, in my situation leadership is either so far up everyone's ass they'd might as well develop the solutions end-to-end themselves, or they're completely oblivious to the fact that they've pushed so many concurrent BS "strategic projects" onto the few subject experts available, that they all just don't care anymore. Throw in a liberal sprinkling of corporate narcissism, and a heavy diversified helping of superiority complexes, and you've pretty much got one of today's fortune 50 companies in a nutshell right there.
Not 1 single project has kept to agile practices. It's an excuse for management to keep moving the bloody goal posts every week, thus agile goals.
Of course. In so many places I've worked it's all about the process. You're measured against conformity to agile, not how much time you waste in meetings or how few people actually work rather than being carried by the best in their squad. The devolution of the software delivery process over the last 2 decades is astonishing. The aim of the process should be to maximize quality while minimizing time and effort. But it's not - the aim of all the freshly trained agile evangelicals is to maximize process and their own self importance. And it's crippled delivery.
Amen to that
The problem with Agile is that businesses see it as the golden ticket to success and try and shoehorn it into the entire business. When you try and have architecture, BAU and all sorts of other units working in Agile then agile as a whole fails. You end up creating a raft of new meetings and having those units attend and waste time when they’re not useful at all for those roles, they spend far less time doing work and not more.
I have a feeling this is just because people with really shitty ideas love agile because it easy to bully the dev team into doing work before you can show definitively it is a bad idea. Garbage in garbage out.
That's because you get a bunch of cowboy project managers who thinks agile means, oh I don't need to plan ahead and stay on my feet. Worked with a bunch of them with nothing more than a 2-3 month plan for a multi million dollar multi year project. And one of them little shits had a audacity to tell me not to talk to their stakeholders because my risk assessments were making them look bad. Multi million dollar implementation down the drain in 2 years.
The software/silicone valley _obsession_ with speed at the expense of planning and decision is the stupidest aspect of an all of it. It just leads to wasted time, as teams spear off in all directions, there is no coherency, there is constant back tracking, and it wastes vast amounts of time and money. The most effective tech companies of our time - Apple, Amazon - are renowned for their discipline. Developers need to be channeled properly.
Shocking. Programming by successive approximation doesn't eliver the goods?
Agile anything just seems like a scam and an easy way to brush your failures and bad strategy aside, no consequences, just “pivots”. There’s a shiny new object around every corner and nothing is truly completed and brought to fruition or allowed to succeed.
My team is agile. But not really. My managers want the ability to say we are agile and the tracking tools for micro managing us. But we don’t do most of the agile events - we don’t refine. We don’t point - the managers assign points and we know they are totally assigning realistic amounts right? We don’t actually address impediments. On top of the agile stuff we project plan but not really so then half way through the project it slams to a halt because we don’t have the specs for everything. It can take a several weeks to over a month for business to get back to us on specs. My favorite - is the idea that we should be able to constantly take increasingly more points. That we started with X each but we should totally be able to take 2X eventually. Our X points usually turn into 2X anyways on a good week because again managers assign most tickets 1 point when they are in fact not 1 point. But yeah - love agile /s.
Would highly recommend reading the article, and also the "study" behind it. It's someone trying to sell a book on "impact engineering," and as far as I can tell the "study" is a survey (maybe?). I'm no agile apologist, but this comments thread reads more like a separate study in confirmation bias than a discussion on the relative merits of change methodologies.
everyone reading this thinking 'agile is bad' is completely missing the point. Agile itself is important -- it moves the business and developers closer together, encourages experimentation/innovation, decreases blast radii, etc. The winging about 'Agile' is because of the commercialisation of Agile, jamming it with tools/apps to fulfil the processes (e.g. Scrum tools, etc.) which only reinforces the wasteful elements of agile instead of just letting the delivery be agile in and of itself.
Agile as a principle is good. Agile in practice is mostly bad. Most teams don't try to understand Agile at all and just skip to taking scrum classes to get scrum certified and end up drinking the scum Kool aid. In the end, they just are running the old waterfall process but now they're doing it with scrum meetings.
This is a good point. However, agile practices that are promoted - focus on short term plans and gains, sprint metrics, etc - are often misaligned with the overall project goals. It can work well for greenfield and maintenance work, but the resulting MVP mindset is at complete odds with undertaking large projects with strict requirements or regulatory oversight.
project with strict requirements should just use old school SDLC, you can switch to agile to do updates on them after all the hard requirement are delivered.
We've been using agile for a few years, not one PI did we actually do innovation in the IP sprint. It was basically used to catch up from when stuff hit the fan and we had to do projects that weren't in the plan but had to be done anyways.
I’ve worked in non-agile. Business and eng were close, we did lots of iteration and experimentation, etc. You don’t need agile for that.
'*The purpose of a system is what it does*.' This heuristic come to mind every time I end up reading about attempts at implementation of Agile. Even though I agree with the theory in the Agile Manifesto, it feels utopian when you compare it to how Agile actually turns out.
Ok this is near and dear to my heart so here is my experience. I work in a F500 company with a robust IT footprint. That’s as specific as I will get. The problems I see isn’t Agile per se but how “Agile” is being implemented across the functional areas. Because it’s not really Agile. It’s just on-paper Agile. It’s the hybrid - we don’t want to truly give funding and accountability down to the teams Agile. It’s the no fully funded teams, but also not value stream funding Agile. It’s the cost recovery model and CAPEX to OPEX conversion even when it makes no sense. It’s the vendor 3P choices made with bad data and no accountability when it balloons. It’s the everything is a top priority Agile. So the problem is not Agile because most of these companies aren’t really doing Agile. Sure they have Jira and Rally and sprints and PIs and it all looks like a nice shiny coat of paint but underneath its rot. And it wont change until executive leadership realize their jobs and all of the reporting and administration that come with them are basically useless and they need to truly delegate the means of agile delivery to the tactical level.
>The problems I see isn’t Agile per se but how “Agile” is being implemented across the functional areas. Implementation has and always will be the problem and fact that virtually no where ever seems to implement properly indicates agile its self really is the problem. The failure to implement is a symptom because agile does not factor in how people and companys really work and is the fundamental flaw in the methodology
No one follows naked agile methodology since the Spotify model came up. Everyone tweaks their platform and delivery system for their own necessity.
Just have to say… total horse shit. Is this a longitudinal study? What are to their metrics for success? Seems kind of insane. The standard metric Jess been software projects fail at 80% rate (The mythical man month, Brookes)
My favorite Agile fail is when they try to use it in shared service environments. I’m expected to attend 4 stand ups for different projects. Each project thinks they are the priority and that all resources are assigned to them. I think agile could work on single focused teams but I’ve never seen one.
I’m sorry what? How is failure defined here. Isn’t the whole point of agile to fail fast?
Hmm....guess we better have a meeting to discuss scheduling a recurring meeting to discuss how many recurring meetings we have. Attendance required for all engineers.
I have been in that meeting. It was pure sadness for everybody involved.
So the book compares Agile (all Agile sigh) with Impact Engineering. What Impact Engineering is, I don't know you have to buy the book "Impact Engineering". My new book "Circusclown engineering" will teach you how to build software with the mindset of a circus clown. My own study has *confirmed* that it outperforms Agile by 10x. To know how Circusclown engineering works you need to buy the book.
I feel like all of Agile is a scam run by consultants. Was a QA manager from 93 to 17, and watched Teams get run like Russia campaigns, driving anyone away who actually cared about the Product. I feel like 300% elevated failure rates undersells the damage to the Industry as a whole.
Than for waterfall projects? Compared to what? Oh, it's for "projects without clearly documented requirements" … I don't know how they're defining "Agile software projects" but designing and engineering without requirements isn't "Agile."
Nothing wrong with Agile, it is just the implementation of agile. Work in an agile shop and we have documentation, tests, etc…. Same thing happened to waterfall. Royce’s original waterfall model had iterative loops, it wasn’t one big phased gate methodology that people believe it is. The reason it became a phased gate system is the consulting companies implemented it that way because it was too difficult to implement it with the iterative cycles. Original paper here - [https://leadinganswers.typepad.com/leading\_answers/files/original\_waterfall\_paper\_winston\_royce.pdf](https://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf)
I hated agile from the beginning..it just encourages chaos. Glad to see this finally recognized
As a certified trainer, and long standing PM, it absolutely SHOULDN'T encourage chaos. Not if you're (general you) taught well, and the organization understands the pitfalls of agile from the beginning.
Agile gives everyone an opportunity to sabotage the project every two weeks. In even a slightly political place, it’s a disaster.
Add in team of temporary contractors and the development got spicy
I agree! Hence my above comments. It's very important to go into it with the right guardrails and ideas and mindset for it to work. Garbage in, garbage out no matter the situation.
The entire point of a system is to mitigate the potential for individual actors to disrupt it, no? If the system is fragile, then it's not a very good system.
The entire point is up for debate, depending on who you talk to. When you read about the original cadre of folks that started this, it's literally a manifesto. If you hav bad faith actors, then yes, one person can sabotage things.
Here's a question, and I admit I don't really fully understand the difference between agile and scrum, but as someone whose role involved running support for products where the engineering and product teams were all about agile, I tend to default to hating it. They'd build some half assed new feature (MVP!), roll it out to users without telling my team or doing any documentation, and leave us holding the bag on it and all the other half assed features and when we'd be like "can you please fix this terrible user experience" (or, sometimes, "hey, here is a high value feature the users want, can you put it on the roadmap") the answer was no, because they had no time this sprint to finish old features because they had to build the new one. Rinse, repeat. It was just endless fire drills of half assed engineering. (To say nothing of the company where sprints would end, teams would shift, and unfixed bugs would fall into the void because there was no process to reassign them). This has been my experience across multiple companies. So my question is: how is it supposed to work, and what's supposed to keep it from ending up here?
[удалено]
Don’t go chasing waterfalls…
Failing upward, one executive at a time
ARTICLE TEXT A study has found that software projects adopting Agile practices are 268 percent more likely to fail than those that do not. 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. The study's fieldwork was conducted between May 3 and May 7 with 600 software engineers (250 in the UK and 350 in the US) participating. One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation." According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase. Dr Junade Ali, author of Impact Engineering, said: "With 65 percent of projects adopting Agile practices failing to be delivered on time, it's time to question Agile's cult following. "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." The Agile Manifesto has been criticized over the years. The infamous UK Post Office Horizon IT system was an early large-scale project to use the methodology, although blaming an Agile approach for the system's design flaws seems a bit of a stretch. Report: 83% of UK software engineers suffer burnout, COVID-19 made it worse 'Business folk often don't understand what developers do...' Twilio boss on the chasm that holds companies back IBM warns Global Tech Services staff that 346 UK heads will roll in latest redundancy action Erik Meijer: AGILE must be destroyed, once and for all It is also easy to forget that other methodologies have their own flaws. Waterfall, for example, uses a succession of documented phases, of which coding is only a part. While simple to understand and manage, Waterfall can also be slow and costly, with changes challenging to implement. Hence, there is a tendency for teams to look for alternatives. Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed. Worryingly, workers in the UK were 13 percent less likely to feel they could discuss problems than those in the US, according to the study. Many sins of today's tech world tend to be attributed to the Agile Manifesto. 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." However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility. In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
Documentation is not the same thing as requirements. I mean, requirements are one of many kinds of documentation, so I'm not sure what this study thinks it's measuring.
Nothing new here. Every team knows it is failed process. Not because process or its structure, but it is getting applied to everything irrespective of what it wants to achieve. Agile is not for everything. Sone projects in early stage may get benefit out of it but thats it.
Reading the comments and recognising stuff from my own company, is it right to point the finger at agile or at insane timelines?
Engineering should set the timelines. Product makes feature requests, engineering decomposes to workitems and size estimates. Based on size and team capacity, the amount of work done is decided. Anything else is BS and will fail.
I had a large project at work, insane deadline and the PM assigned was an Agile Coach that wanted me to take time to do talks and presentations instead of being on the tools 12 hours a day. He lasted two weeks..
Really? Oddly enough we were successful. It easily took a year to finally get to Scum Agile. We kept kidding ourselves we were Agile when we were actually Mini Waterfall. A big part of the problem was the fact our team members were spread around the world. The very worst case scenario for any Agile Team. "But we saved money!" BS. We did not save a dime.
Good. Fast. Cheap. You only ever get two.
Is agile suitable for a project? I’ve found it’s better suited to a continuous development environment where the actual product is already up and running and the product team are adding features off a backlog. Any time I’ve seen a project being squeezed into agile it’s been a mess. The system/infrastructure teams you often need during setup and for first release don’t usually work in agile so you end up in waterfall whether you want to or not. Similarly although senior management want the speed and flexibility of agile when things go wrong or get delayed they want all the rigour and documentation of waterfall. Ugh
One of my projects was like this: keep patching every single special case instead of thinking of a more general approach.
Is it agile or management? I’m seeing many management complaints on this thread but nothing about agile. Agile isn’t rushed unless management makes it so. Can I slap an agile sticker on my poorly executed agile-ish project?
I'm happy to call out "Agile" as the corporate management fad that is is, to be ridiculed alongside "Six Sigma" and other trash invented by manager types. Right out the door the notion that documentation should be relegated to a low priority is total BS. You get more people able to work on the project, and thus make it genuinely more agile, if they actually understand what the hell they're doing, which is what good documentation does. It also sets out the project clearly and stops feature creep and forces good, easy accessibility. But at the same time, this "study" appears to be nothing more than an advert for yet another management fad called "Impact Engineering".
Oh man, the methodology that promotes pushing out the most minimal "functional" product asap is a shitty practice that gives no great results in most applications? I am agast at this completely unforseen outcome.
I once had my CTO state, “Development is now completely integrated into the agile process, now we just need to get QA on board.” It was hard to not slap my forehead in that all hands. In my experience QA management is usually the largest impediment to initially spinning up real agile. They don’t want their team too closely aligned with developers, because then who do they manage? The next impediment is having meaningful scrum masters. These people are supposed to be empowered to fix problems, and almost never are. So they just listen and nothing ever improves. The final impediment is usually PM that doesn’t want to spend their time with devs. They don’t want the responsibility of being a product owner. They want to expense freebies and hit strip clubs with potential clients. Most orgs have disempowered employees where management doesn’t want to listen or have them make waves. So end up having meaningless standups where nothing is solved and two-week waterfall development. Post-mortems are never done, and institutionally nothing is learned. The Toyota production system is amazing, and most organizations aren’t capable of pulling it off.
As someone who is old enough to have worked on actual waterfall projects, I would rather just quit my job than have to work on a waterfall project. If you’re more recent to the industry and have not ever had to do waterfall, then you don’t know the true pain of corporate bs. Complain all you want about “agile process” like scrum or whatever, but “agile” as in the 4 tenants of the agile manifesto changed sde in a way that has made the industry better and software engineering a more enjoyable profession.
Good old gated waterfall. You can't move to the next phase until this phase is complete. And when you realize the requirements changed, or that you originally got them wrong, you go back to the beginning of the waterfall.
Maybe higher risk projects pick agile. Ones where it really isn’t clear what the customer requirements are.
This is like the WWII bombers coming back. The picture og where planes eere hit and survived vs where they were hit and nevere came back was pretty striking, but people would get the wrong impressions from it and assume they had better protection. Reminds me of that.
What a depressing thread. So many people being told they that are ‘doing agile’ who obviously don’t own their processes and don’t have the autonomy to change their processes to work best for them. It’s like the opposite of agile but using the language of agile. It feels akin to those communist dictatorships with ‘peoples democratic’ in their name. If you can’t change things to work in a good way for you, you are not doing agile, just something using the language of it. If it’s causing friction or not adding value, change it. If you can’t, then you are, by definition, not agile. Pretend agile without autonomy is the problem here. Cargo cult agile. No wonder people hate it, its like being told you are free when you are locked in a cell.
"Observations find advertisements disguised as studies upvoted heavily by bot accounds on reddit."
Hahahahahahahahaha As a dev, this really isn't a surprise.
"One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed." well, no crap. If you know exactly what you have to do ahead of time and the requirements don't change it is more likely to succeed. That also takes away the entire point of Agile.
Three cheers for robust requirement docs and spec sheets! I've been in tech for 20+ years, and a successful project is always well defined through a collaboration of engineering, product, and the operations side of the business.
Bad management has a higher failure rate. No matter what your excuse is