Agile and Scrum was great when it was introduced bottom-up and then accepted top-down.

"We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together.

The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database). Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.

The top-down recognition was useful - not only did projects go noticeably better, managers could also boast that they, too, are now doing this new Agile thing! And they didn't even need to do something!

That was all before Scrum of Scrums, SAFe, LeSS, you name it.

As you said, we've come full circle in many aspects. It's ironic.

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.

At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.

I think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.)

I love a provocative essay as much as the next person.

But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need:

- they are the customer to a great extent, so they don't need to involve external customers to discover what is needed.

- they are fast followers (an OSS WorkOS competitor[1]), so can rely on product need discovery from other competitors. That's not a bad thing (I've done the same!), but it isn't sustainable forever.

- they have a small team, which means everyone has autonomy and knowledge.

- at the size of 2, they don't have other departments with schedules and deadlines and goals. Process is critical to getting input and coordinating across departments to achieve company goals.

All of these factors mean process is an impediment without any benefit.

Not every company is like this company. Not every dev team is like this dev team. My opinion is that this company in three years won't be like this company is now.

I'd wager that in 3 years, if ssoready is successful, there'll be process. It'll be an impediment but a necessary one, as the attributes they currently have won't be enough to keep delivering.

Happy to bet on that if either Ned or Ulysse is reading :)

0: According to https://www.ycombinator.com/companies/ssoready they were founded in 2023 and have 2 employees.

1: https://news.ycombinator.com/item?id=41111136

Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm going to make this project succeed." Much easier to say, "we're using best practices and modern processes."

This is a consequence of failing to train managers, especially in the moral dimension of management, which is entirely about accepting responsibility, and of promoting into management individuals who are not prepared to do so.

> Well, right from the Agile manifesto

The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with them and complain that they get cold.

Agile is not on size fits all, sometimes you need comprehensive documentation for instance. In this case, just don't do Agile, the manifesto is really explicit in that it is not the right methodology for you. But for some reason, Agile is fashionable, so you take it anyways and try reshape it into the V-model you should have used in the first place and get the worst of both.

Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.

Parent is close to what I argued here:

https://zwischenzugs.com/2017/10/15/my-20-year-experience-of...

The fundamental issue, I think, is that there is a strong tendency for management to value process (measurable) over progress (often seems like nothing for weeks or months and then bam out of “nowhere” revolutionary new features.

Agile, scrum, etc al are supposed to be guidelines for engineering teams to maintain coherence on progress, but they describe a process, so inevitably management either interjects in the process, tries to use it as a handle to control the process, or pulls engineers out of the project to “manage” the process… all at the expense of progress.

Management can’t see progress, but they can see process. So naturally, they become focused on what they can see, and conflate the process for progress.

Any extreme has it's own inefficiencies.

Take a hopelessly disorganized team, apply any, literally any, management framework on top of that team and productivity will increase.

Since management frameworks do not contain intrinsic fixpoints, keep applying the framework and things will halt to a stop, because whole effort will be spent serving the framework. Ditch the framework, start doing random stuff and productivity will magically increase.

The pendulum continues to swing, unbothered.

well observed. Why do we keep going in cycle?

I think because there are lots of different type of humans.

The motivated developer. The descipline strict developer. The unfocused. The learner. The over the line stepper who wants more. etc

One process can not serve them all.

> I wonder how we can break the cycle.

Make management consulting illegal.

All developers know all the wisdom. Everyone who had a manager knows the problems in any process.

The only ones who seem to not know or see or understand the problems are various layers of management. This is weird because ostensibly that is their one job.

I can understand how a junior manager who only worked one year in the industry can get fooled into believing in the rigid processes with pointless artifacts.

But if you worked building software for five or even two or three years, I cannot possibly imagine how one goes about their day managing a software project in this fantasy land.

By “manager” I mean all the chickens that decide how the pigs work, and all the chicken in pigs clothing. I do not mean all kinds of management.

> I wonder how we can break the cycle

"Hire former software engineers at management positions" would be the answer, but of course there are various factors that makes it difficult to do so.

In theory, management should be held accountable for getting in a way, but it is not possible either because of the nature of software development: one cannot really measure productivity because it is to a more-or-less large extent a research activity.

I think probably the best option is to introduce some more democracy (or rather "technocracy" in the literal sense, "power to those who build") in the mix: management evaluated and chosen by the engineers. Call me communist all you want...

> So it sounds like we've come full circle.

I think the issue with Agile was that it was named. After something is named and codified it becomes a thing and everyone can mangle the thing to fit their desires until it becomes antithesis of the initial intents.

This guy doesn't name or codify his approach. So it's fine, there are only intents, there's barely anything to mangle.

I agree, it’s a new/old methodology disguised in a rant.

To your last point that we’ve come full circle.

Maybe that’s exactly how things evolve. Start small, get large and complex, cut back to become simple again.

While it might sound like a circle, I believe that it’s an evolution. Things improve over time with each iteration.

There is no breaking cycles. Humanity is on an approximately periodic 20-year oscillation around the mean. Just look at programming languages, ai cycles, web iterations, etc.

It's just human nature - we deplore the tools our parents used.

However, as long as that mean drifts in the right direction!

If your team has high alignment on what needs to be done and how to do it, then yeah, no processes are needed.

But if you ever want to hire more than a handful of engineers, you need to processes to train them up and build alignment.

I didn't take the article as a "lack of organization" is best. I took the overall theme as that most methodologies are a distraction to what is most important, building things.

I can't even imagine how Scrum could ever align with the Agile values for it to be abused and transformed. IMO, that part is impossible, and Scrum was always a "bad-management by the numbers" framework.

Anyway, I've hear phrases like your example since some time around 2001. Agile was practically born with a parasitic consulting market intent on having the one true way to do it, and that way being what middle-managers adept of micro-managing want it to be. In fact, I think those consultants were the ones that pushed the word around, without them we wouldn't even have heard of the manifesto.

That's to say that, yeah, I do agree with your comment, but the actual problem is deeper, and harder to fix. Scrum and bad processes are just symptoms here.

> But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight.

Agile is agile the same way the People’s Democratic Republic of Korea is a democracy. And like most dictatorships with these names, I’m sure they also have a founding myth that claims a genuine concern for Democracy and the People.

Software developers are concerned with developing software. The people with the time and energy to develop and sell methodologies like Agile are not in the business of developing software; they’re in the business of selling methodologies. Maybe they’re consultants trying to sell clients on the methodology as a selling point for their consultancy (much of Agile seems geared to this), or maybe they’re trying to train people to be Certified Scrum Masters or whatever. Either way, you can’t actually sell people a methodology that boils down to reducing methodology because then you have nothing to sell.

I know I sound cynical, but the reality is that human behavior is driven by incentives and anyone who genuinely cared about making processes lightweight has little incentive to hang around the Agile scene fighting with the grifters.

> The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology.

Nailed it. “Your heuristic is bullshit, here have a heuristic to know when.”

What is BS is a fixed, one size fits all methodology. As fast as you write it down and proclaim „this is out procces”, it starts to be BS.