Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest.
The rest just parrot on the same talking points with a different angle every week.
I was involved in the movement before the term "Agile" existed. I agree it is now on average horseshit, and have been saying so a long time. [1] But I think that one of the things that hasn't been broadly incorporated what is mentioned here: vigorously pursuing faster feedback loops.
So many places are so top-down and plan driven that their corporate structures and corporate cultures just don't let them take advantage of release-early, release-often approaches. Done right, it is hugely powerful because you get to learn ASAP when you are wrong. But in so many places people essentially don't want to know that. They would rather lose months or years to bad plans and bad practices than seek out the kind of real-world feedback that lets them know when something is wrong. People would rather feel smart and look smart than take the hit and learn from enough mistakes that they become actually smart.
Indeed, I think the reason that so much "Agile" is horseshit is that people reject the most important Agile changes such that they can keep on believing they're doing just great. They just don't want their process rub their noses in the fact that however fast they're going, it's not in the right direction.
[1] e.g., from 2011: https://williampietri.com/writing/2011/agiles-second-chasm-a...
Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out.
Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them.
When all else fails or when something feels off, get back to first principles.
I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.
It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.
So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?
There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level.
It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.
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.
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 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.
Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and often people who implement agile use Scrum, because scrum was very much in the minds of the creators of the agile manifesto. And this should not surprise anyone as the creators of scrum where also part of the group that created the agile manifesto.
Isn’t that what the name supposed to evoke? Two groups locked in a push in opposite directions.
I think "velocity" (from Scrum) actually evoked the correct idea, but most people seem to forget that velocity != speed. Velocity is a pair, speed and direction. Raw speed is useless if you're heading the wrong way (e.g., towards a solution for the wrong problem because you didn't bother validating along the way).
Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
Beck, Jeffries, Fowler, Hendrickson, and Wells are examples of Failing Upward(tm) rather than any example of good programming to be emulated.
>> rarely well implemented.
The Agile Manifesto was published in 2001, over two decades ago. After all this time, and the involvement of a lot of clever people, even Agile advocates are stating it is rarely well implemented. Doesn't that suggest that Agile, as a management technique, has failed?
True Agile is appears to be as elusive as the holy grail.
It's not evolving into a better system because it's under the new bureaucratic regime of project managers. They are an institution now within the tech industry and are a self preserving entity. It's idiosyncratic for them to change this bureaucracy.
If a developer were to say, "here is what I think about the process that governs me", the governors will laugh you out of the room with a delicate smile and sweet fuck you along the lines of "woah, that's great feedback!".
There has never been a better strategy for letting engineers steer the ship and make decisions that ship code instead of getting micromanaged by non-experts that generally bungle things up and insert a bunch of external priorities without reconciling them with reality.
The reality in my mind is that agile is the reaction to excess management, which is a massive problem in technology organizations.
I’m sure there are other things too. Some of the other comments are gold. But that’s my 2c.
HN is pretty much in agreement that lines of code per day is a bad measurement of progress/accomplishment, right?
We've seen so many bad variations on this concept:
* Butts in seats means work is being done
* Movement is progress
etc. It's all bunk, of course, and here we are with agile. Corporate types are collecting some metric and the larger the value the higher the developer speed. Or so they think.
Ideally, "speed" in this context is about direction. They are almost interchangeable. If you are going in the right direction, you have some amount of positive speed. Otherwise, it is negative or zero.
Next.
Seriously, there's very little substance to the article. It effectively says "agile doesn't work without customers."
I'm pretty sure "customer collaboration" mattered back when it was a developer movement and not some kind of training sold to management.
Duh.
The entire supposed premise of agile is defining goals and constructing a product iteratively, so misunderstandings and changes in design can happen more quickly.
The "quick" part being a change in direction.
Given a perfect definition of a program and skilled ciders and unified vision from the beginning, agile would be meaningless.
But I've always seen that somewhat orthogonal to team-level processes.
You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.
The saddest state of affairs, and most common, is when highly capable people have a high magnitude with an incorrect (or inconsistent) vector, leading them nowhere.
And it was sold as a good thing.
How about we just get the requirements and write the code, however that is best achieved in your org.
