Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spiral.
Now, there are tools in agile that I'll vehemently defend, such as continuous integration and retrospectives. I'm a fan of most of the principles, such as "Continuous attention to technical excellence and good design enhances agility." But we are now at a point that if we're going to argue that "agile doesn't work," we've had enough time as an industry to gather around an alternative.
Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it.
There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.
You argue in favor of not calling things things, and then go on to call a lot of things things. You demonstrate why we need to name things: to talk about them more effectively.
What makes sense to one person may not make sense to another. I agree that each team should decide based what's right for them based on the people and the problems. But to do that beyond the trivial, we need to name things.
You don't need to do any other process. You can just talk to people as problems arise and do that "in stead".
Hold up.
You mean to tell me that someone just pulled stories, story points, point poker, scrum, and the master of the scrum, burn down charts, spikes, iterations, sprints, and retrospectives ... all out of their ass?
This blend of mindless contrarianism gets tiresome. If this discussion was about hand-writing, you'd be accusing left-ti-right languages of being pulled out of the ass as well just because it's the standard shared by most.
People feel the need to plan work, estimate work effort, and allocate resources to get stuff done. Some people adopted these methods and they get value out of them. Not everyone has the luxury of picking up tickets created by magic and "it's done when it's done".
If you have a better way of doing this then be my guest and use it, but I have a nagging feeling you'd shit on that too just to feel smarter than everyone.
For example, story points are always being converted back to wall time because in the real world you have resources who can work x amount of hours and you need to plan around that.
What's the point of using an intermediate unit?
So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in a culture that values output over outcome, you may not have a choice, and clearly plenty of projects succeed with GANTT charts and whatnot.
I'm new to this. Are we agile?
To me, the agile movement, at least initially, was about empowering teams to get things done for users. I came out of the Extreme Programming end of things, which had a dozen practices to start with. But the people behind it said that they offered that set of practices as a place to start. From there, teams were supposed to use the short feedback loops to inspect and adapt.
So in my opinion, that is not agile. However, as I've written about elsewhere [1], I think the Agile movement got taken over by something that was more marketable to executives with a top-down orientation.
So in short, I think what they're saying sounds like bunk to me. The way I used points was as purely relative estimates. Point velocity per iteration was a measured quantity, used mainly to make sure the team didn't oversubscribe an iteration. E.g., if the team did 10 last week, this week we'd take on 10. If we thought we might get done early, we could always pull another card in.
But alas, it sounds like you're trapped in what I think of as mini-waterfall, where people who have waterfall biases have broken their big thing down into two-week-sized waterfall lumps.
For what it's worth, I long ago stopped doing estimates entirely except in special circumstances. I now prefer the Kanban-style approach where there's a backlog of modestly sized units of work and the team has a limit of the number of things that can be in progress at once (my starting point is half of the number of team members). You then release each thing as it's done.
[1] E.g., https://williampietri.com/writing/2011/agiles-second-chasm-a...
But then you aren't doing Agile!
The whole thing is just stupid terminology for existing things and distils down to "make a todo list and work through it"
In a way it reminds me of a cult. You do a series arcane rituals that have no scientific evidence behind them, none of the process is data-driven or statistically proven. Frankly, it can’t die soon enough but as we all know some new hype will simply take its place to give busybody managers a reason to exist.