Scrum is the Symptom, not the Problem

There's a lot wrong with this post, especially the first few paragraphs. That part mostly just repeats a lot of tired myths and straw-man arguments w/r/t Scrum. There's nothing new or interesting there.

For an example of what I mean, consider this:

After the manifesto appeared, Scrum quickly declared itself to be “agile” in spite of its ...

But Scrum existed before the Agile Manifesto was created, and the creators of Scrum - Ken Schwaber and Jeff Sutherland - are signatories of the Agile Manifesto. So no, Scrum didn't just "declare itself Agile"... Scrum was part of the Agile movement from day 0.

But towards the end the post does get to an interesting point, which the author summarizes as:

If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies.

There's something to be said for that. I've always said that a lot of the core issue here is exactly the "impedance mismatch" between the way engineers see things, and the way "the business" sees things. One way to resolve that - albeit perhaps not the only way - is what the author proposes above.

> "Conclusion

If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!"

===

My previous comment on the subject still seems appropriate.

https://news.ycombinator.com/item?id=41080195

The big problem is "How do I connect the money to the work". In large corporations, this becomes project -> plan -> work. The project gets a budget based on the plan, then you do the work based on the plan. The problem is the link between plan and work. As you work, you learn. That is the primary activity of software development. Learning is a menace to planning. As you learn, you have to replan, but your budget was based on the original project plan.

You can talk about engineering and culture and whatever you want, but if you're working for money, the problem remains of connecting the work to money and the money to the work.

I'm reminded of the Oxygen Catastrophe - https://en.wikipedia.org/wiki/Great_Oxidation_Event - we need oxygen to live, but it also kills.

> Developers have no real power or seat at the table. They are not peers engaged in a common creative enterprise — they are hired, replaceable machinery, no different than the computers and monitors they use all day.

This is correct. Scrum (and all of the other PM rituals) exist because the people controlling the money need to attach budgets to projects in order to figure out whether they're worth doing or not (or more loosely to teams, to figure out if they're profitable or not). Once a project has a budget, then it needs to be tracked.

It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude. Either it's your money that's slowly being incinerated, or you have to go back to investors and tell them that you decided to spend on X, and X is only 1/3rd as far along as the tech lead told you it would be.

But it's also frustrating to be on the developer's side of the table. We're not generally included in the business strategy meetings, because we don't generally have MBAs. (Also because we're expensive, and having us sit in "irrelevant" meetings, especially when we're "behind" anyway, seems like a poor use of resources.) As a result, we're two steps removed from the decisions that matter - and not in the room when we could potentially have suggested a better approach to solving the original problem.

Personally I'm done with the corporate software world - I'm riding the fractional/freelance bus until retirement. But, I wonder if these kinds of dysfunctional dynamics could be fixed with multidisciplinary teams. E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.

I think you'll find "distributed decision-making" is no panacea. I joined a company recovering from a distributed governance model, and the big challenge was that nobody had enough decision-making authority for the firm to change quickly and respond to the evolving outside world. Bringing a whole room to consensus is a lot tougher than getting a few people to disagree-but-commit and move on with their day.

Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.

This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.

[0]: https://signal.org/blog/the-ecosystem-is-moving/

This post resonates a lot with me, enough that I want to comment. After 5 years working with a full-time SM (3 different ones) in my team, I still have no idea what value they are supposed to provide, or how they fill their day once the daily meeting is over. As the author states it is completely demotivating to feel like you are carrying a parasite on your back ("robs engineers of their productivity and self-esteem").

Note that among the devs at my company, I'd say more than half don't seem to have a problem with it, or at least go with the flow, so I might be in the minority but I feel strongly enough about it to consider trying freelancing, I just hope I can demonstrate enough technical skills to be able to "insist on being in control of how [I] work" and still be hired...

Developers should become owners! It is much easier for a developer to learn the business side of startups than it is for a business founder to learn how to code. Not only will learning the business side allow developers to become founders, it will improve their development decision making, allowing them to communicate better with customers and the rest of the company about priorities and strategic decisions. Once you know how to talk the language, it becomes easier to convince people that technical factors are important to strategic decisions. Even if you don't become an owner, learning the business side of business will allow you to play a larger role in the decision making.

Ok, but here me out - I think many things are missed in this take. This one immediately jumps out at me (from the manifesto): "Build projects around motivated individuals"

The manifesto is predicated on this basis - that the individuals are motivated and capable of delivering when empowered. In a large corporate environment, can you make that assumption? Is your hiring always that good? Can you provide the type of environment that always produces high morale?

I'm no fan of scrum, but I've also seen what happens when "unmotivated" individuals are given too much free reign - nothing. How do you, as a large business, address that? Mass firings, or more "active" process? Perhaps business can't get over the risk mitigation that scrum provides?

I don't know the author, but these complaints about ownership make me worry if they are not a team player.

By "not a team player", I mean they can't easily subordinate themselves to the rest of the team's consensus, to the enterprise culture/standards, to the limitations of the legacy codebase, to their product owner's direction, or to the laws of physics.

This programming stuff takes humility, and everything is hard to do. Non-team players make everything harder with the friction they add to every decision and the morale drain they put on the rest of the team with their sourpuss nature.

I try to win these folks over with love and help them to add many small wins to their name, but they're often energy monsters and they quickly exhaust me. It's often a relief when they remove themselves from the team.

My strategy is to negotiate down the amount of mandatory work I have to do and spend my extra cycles doing what I know needs to be done.

It's not necessarily the best way to get ahead, but it's worth it knowing that I can take pride in what I'm doing.

From my experience, the same people who love using Scrum are the same ones who post cringy stuff on LinkedIn. You just can’t reason with them. One time, I tried to reason with a middle manager who insisted on using it. He had no previous experience or education in project management, whereas I’m a certified PM. I tried my best to explain that just because a tool worked in some scenarios, it doesn’t mean it will work here. Long story short, it was dismissed, and Scrum was implemented because “all successful big companies are using it!” Less than a year later, three of the best engineers on his team left.

Where scrum gets in trouble it is because there is a breakdown in trust. You can't fix trust problems with this process or that process.

Seize the means of production comrades.

> Engineers naively believed their appeals to reason would eventually fix the industry.

high key cap

So many posts with X is not the problem, it's a symptom... they're always wrong. It's the problem. It might not be the only problem, but that doesn't make for a bait title.

This post contains a lot of truth. Developers have always complained about the processes that companies employ to direct and manage software development.

It correctly identifies that what preceded scrum was also poor for developers (big design up front), and that if anything replaces scrum, it will also be unpleasant for developers, because all these processes do not exist to make developers happy. They exist to control and manage software development.

So yeah, if you want to control how you write software, you have to be in control. But I strongly suspect that (other than for small, very high performing teams), you will inevitably create processes to manage it as you grow, and developers will then bitch about your process.

> I am looking at you Jira!

Jira is like Java, many people think of their experience in 2000-2010s in some ugly corporate environment, not being aware how good it can be in agile environment where people are really above the processes.

> It doesn’t take much googling to find a vast number of developers griping about it on their blogs

It also doesn't take much googling to find a vast number of people convinced that vaccines are bad.

Scrum is the most popular development methodology because nothing is more popular. It's not like there's some development methodology out there that all engineers like and its just the bad managers stopping us from using it.

> So what is the real solution? Engineers need meaningful ownership. If engineers could acquire enough ownership to represent a significant percentage of the company, they could demand to be part of decision making.

That rings a bell, where did I hear such a thing? Oh yes, "workers should own the means of production" – I don't know if the author realizes this, but he's making a good case for Marx.

I think the less layers of management in the company, the better. The flatter the hierarchy, the more freedom the developers have, more stuff they get done, the happier they are. But for that you need trust and good developers.

Every single post of this type is wrong. You don't need to read beyond the first line. "Scrum is horrible" - no, it's not (at least not necessarily) and asserting that you somehow know that this is true for _everyone_ is patently ridiculous. The author is taking their experience, finding others that validate it, ignoring those who disagree with them, and making sweeping assertions that make absolutely no sense.

Focusing on whether Scrum, Kanban, XP, etc. are good or bad misses the point entirely. They are neither good nor bad in principal: they are either good or bad for different teams in different situations, and even then depending on the specific implementation. There are very happy teams using scrum and performing excellently as a result. You cannot tell them they are doing it wrong. They're not.

My teams don't run scrum, but I consult for many who do, and I know how well they're doing and how happy they are with their situation. I also know of others who hate it.

I don't know why it's so difficult for engineers to understand this. Your experience is not universal. You don't know everything.