14 ms·

Scrum is the Symptom, not the Problem

77 points by aard 2y ago

danjl 2y ago
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.
- HalcyonicStorm 2y ago
  I definitely want to become an owner and learn about the business. I've even conceived and executed projects to improve the bottom and top line revenue. That being said, as a developer in a small business, the thought is that I'm too expensive an employee to not be coding even if I had a lot of impact on my own initiatives. The thinking is that a lot of people can think about strategy but very few people can code so I get pigeonholed into just executing. This has been my experience at multiple startups at various stages of their lifecycle.
  - hattmall 2y ago
    Sure, but the reverse of that is, you as the developer, are the owner, and you just hire the people to think about strategy, etc. What you are saying is true, because coding is the high value work that relies heavily on the individual effort and productivity. The team effect of coding is effectively the sum of each coders productivity. The business side is the opposite, it can be much lower value individual work, but the team efforts combined is exponential. If you want good software you can't really just throw more developers at something, in fact doing so can often lead to declining returns. But this is the idea behind things like SCRUM, Agile, Stand up etc. It's a way to try and figure out how to scale development by effectively just adding more manpower. It simply isn't a fit for development though. On the business side however you can scale just by adding more people. At the end of the day you can have excellent software that makes no money, and you can also have excellent business strategy that makes money and fails to deliver a product.
    - HalcyonicStorm 2y ago
      Coding will only be held as high value if its a product led growth company. Its a cost center otherwise.
- yieldcrv 2y ago
  As a tech feudalist myself, I think software developers could be the best at accounting, tax and corporate entity structures too, which can guide the business decisions as well. I generally see a segregation of those interests, but as business owners the interdisciplinary nature can become clearer
- nradov 2y ago
  That only works in some business domains. If, for example, you're trying to build products for a complex healthcare use case it takes years for most developers to start making a positive contribution as product owners. A lot of customer requirements are counterintuitive and don't make sense to anyone without deep domain experience.
deleted 2y ago
[deleted]
_se 2y ago
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.
- lfourunderscore 2y ago
  Sounds like you indeed didn't read beyond the first line - this article argues that it is not scrum (etc.) which is horrible, but the context in which these systems are used.
  - _se 2y ago
    The first 4 paragraphs were enough to know that it isn't worth the time. You can't spend 50% of the article being so off base and have the rest be worthwhile.
- squiffsquiff 2y ago
  I haven't read the article but in response to your comment here: Scrum is widely used and also widely disliked. I find that apologists for scrum generally excuse the dislike as 'that's not how scrum is supposed to be implemented' - just as you have here. It's exactly the same form of argument you get from apologists for Marxism or Communism when confronted with the widespread dislike for those systems. If something has generally failed wherever it has been implemented, it's not because it hasn't been implemented properly, it's because it is fundamentally broken.
csours 2y ago
> "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 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 https://en.wikipedia.org/wiki/Great_Oxidation_Event - we need oxygen to live, but it also kills.
- nradov 2y ago
  Scaled Agile Framework (SAFe) deals with that by funding value streams instead of projects. https://scaledagileframework.com/lean-budgets/ https://scaledagileframework.com/lean-budgets/
  - knappe 2y ago
    SAFe, as I have seen it practiced is just waterfall by a different name.
    - nradov 2y ago
      It it certainly possible for incompetent managers to misuse SAFe, as with any other methodology. I've seen that if actually implemented as written it tends to work pretty well in large enterprises, at least in the sense of being the least bad option that allows product delivery with the level of consistency and reliability necessary to meet external commitments. Comparisons to "waterfall" are a rather silly strawman. Do you have a specific criticism of the SAFe budgeting model, or a specific alternative to propose?
mindcrime 2y ago
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.
- teaearlgraycold 2y ago
  If you want something done right you really do need to do it yourself.
  - j45 2y ago
    And learn to understand and balance business wide considerations and how difficult that might be outside of a software-first lens.
    - racional 2y ago
      Right, but time was when one could develop and practice that wisdom without all the hooey rituals, sucking up, and insipid make-work that are Scrum. A million, trillion years ago.
      - j45 2y ago
        I don't know if politics didn't ever exist. I do agree it's toxic. And a productive workplace is often a turn off to certain kinds of employees. Scrum done a certain way too often is a waterfall in a different way to manage developers and features. Scrum/Agile are helpful where there is little to get consistent results out of team members with varying skillsets, but it doesn't mean it works for high flying team members. For example, using trunk based development for a startup with senior devs is far more efficient, with the understanding that will slow down and including more and more people will mean helping the best parts of your agility remain. Jumping all in to all ceremonies without understanding a 'why' makes a big difference. Anyhow, I get to be quiet now and learn lots from the other comments in this thread, experience has taught me that experience is a great teacher.
ivan_gammel 2y ago
> 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.
- gosub100 2y ago
  I can't wait for the first post showing Jira to be turning complete. Followed by the first Fizz Buzz written in Jira.
  - yieldcrv 2y ago
    Probably can with those awful workflows
    - j45 2y ago
      Haha, that's funny and might even be true. I once went looking into "how did this ever become to be". The underlying workflow system in JIRA is based unsurprisingly on an existing workflow management library. And so much made sense about 'why' is it this way. It also reminded me why most JIRA "replacements" only replace whatever the origin story of the creator of the software is, where they're at, what their priorities are, and how to get there.
- asdfman123 2y ago
  The problem isn't the processes, the problem is the people. The good news is that in a good environment, you can earn trust after a few years and gain a little more freedom. You are basically then solving the "people" problem by fixing the only person you have control over: yourself. (Of course, I understand not everyone is working in healthy environments. Some micromanagers will never be satisfied!)
  - ivan_gammel 2y ago
    Healthy environment is not the one where you need to gain trust to get more freedom, it’s where you are free from the beginning and follow (and develop) best practices instead of obeying the rules. It is a combination of trust by default and safety net, where mistakes are made, but they don’t kill the business and are corrected quickly.
vngzs 2y ago
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/ https://signal.org/blog/the-ecosystem-is-moving/
asdfman123 2y ago
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.
yieldcrv 2y ago
> Engineers naively believed their appeals to reason would eventually fix the industry. high key cap
throwaway290232 2y ago
[dead]
MattPalmer1086 2y ago
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.
- bitwize 2y ago
  Indeed. To develop large information systems requires discipline and organization -- and programmers resist discipline as a mustang resists the bit. So what you have to do is break your programmers the way you break a horse -- enforce discipline upon them. They'll complain but it'll be worth it in the end. As an example, programmers often have cluttered desks citing the aphorism that "a cluttered desk is a sign of a brilliant mind" (when it's really just a sign of sloppy thinking). What you will find at highly effective software shops is that management will insist that the programmers keep a tidy desk, going so far as to bin any clutter they leave lying around -- because "neatness counts". For as much as it's maligned, "big design up front" is just common sense. The most successful methodologies for software development are derived from engineering, manufacturing, and construction -- and in those fields, having a clear idea of your requirements and a complete design or blueprint before you build, before you even prototype, is just table stakes. Anything else is stupid.
  - MattPalmer1086 2y ago
    I honestly don't care one bit how tidy someone's desk is. I've seen very good results from taking a more iterative approach as opposed to BDUF. Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want. So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is.
bandana 2y ago
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...
- baal80spam 2y ago
  > I still have no idea what value they are supposed to provide, or how they fill their day once the daily meeting is over. Hey, my SM can configure JIRA swimlanes! /s
ccppurcell 2y ago
Seize the means of production comrades.
andrewmutz 2y ago
> 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.
- OutOfHere 2y ago
  Scrum is liked by managers, not developers. It is a managerial approach, not a legitimate engineering approach. Kanban, for example, is less negative to developers than is Scrum.
dwoldrich 2y ago
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.
- fmbb 2y ago
  I don’t understand how you get from someone critiquing company ownership to believing they cannot play nice with consensus or be humble. There is no relation there.
  - cauch 2y ago
    I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership. It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time. I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
  - dwoldrich 2y ago
    Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing. The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it. The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
smallerfish 2y ago
> 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.
- Traubenfuchs 2y ago
  How did you get started with freelancing? The old "startup" I am working for is dying and I need to plan my next move…
  - smallerfish 2y ago
    Upwork to start - set rates high enough and you'll find a steady stream of reasonable positions coming through. It's a bit of a slog until you build a reputation. Eventually word of mouth and your network kicks in.
PaulHoule 2y ago
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.
kolme 2y ago
> 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.
- Kinrany 2y ago
  What means of production? Every senior developer already owns a computer.
  - latentnumber 2y ago
    lol.
deleted 2y ago
[deleted]
tamimio 2y ago
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.
- deleted 2y ago
  [deleted]
flappyeagle 2y ago
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.
cacois 2y ago
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?

77 points by aard 2y ago

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.

HalcyonicStorm 2y ago
I definitely want to become an owner and learn about the business. I've even conceived and executed projects to improve the bottom and top line revenue. That being said, as a developer in a small business, the thought is that I'm too expensive an employee to not be coding even if I had a lot of impact on my own initiatives. The thinking is that a lot of people can think about strategy but very few people can code so I get pigeonholed into just executing. This has been my experience at multiple startups at various stages of their lifecycle.
- hattmall 2y ago
  Sure, but the reverse of that is, you as the developer, are the owner, and you just hire the people to think about strategy, etc. What you are saying is true, because coding is the high value work that relies heavily on the individual effort and productivity. The team effect of coding is effectively the sum of each coders productivity. The business side is the opposite, it can be much lower value individual work, but the team efforts combined is exponential. If you want good software you can't really just throw more developers at something, in fact doing so can often lead to declining returns. But this is the idea behind things like SCRUM, Agile, Stand up etc. It's a way to try and figure out how to scale development by effectively just adding more manpower. It simply isn't a fit for development though. On the business side however you can scale just by adding more people. At the end of the day you can have excellent software that makes no money, and you can also have excellent business strategy that makes money and fails to deliver a product.
  - HalcyonicStorm 2y ago
    Coding will only be held as high value if its a product led growth company. Its a cost center otherwise.
yieldcrv 2y ago
As a tech feudalist myself, I think software developers could be the best at accounting, tax and corporate entity structures too, which can guide the business decisions as well. I generally see a segregation of those interests, but as business owners the interdisciplinary nature can become clearer
nradov 2y ago
That only works in some business domains. If, for example, you're trying to build products for a complex healthcare use case it takes years for most developers to start making a positive contribution as product owners. A lot of customer requirements are counterintuitive and don't make sense to anyone without deep domain experience.

deleted 2y ago

[deleted]

_se 2y ago

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.

lfourunderscore 2y ago
Sounds like you indeed didn't read beyond the first line - this article argues that it is not scrum (etc.) which is horrible, but the context in which these systems are used.
- _se 2y ago
  The first 4 paragraphs were enough to know that it isn't worth the time. You can't spend 50% of the article being so off base and have the rest be worthwhile.
squiffsquiff 2y ago
I haven't read the article but in response to your comment here: Scrum is widely used and also widely disliked. I find that apologists for scrum generally excuse the dislike as 'that's not how scrum is supposed to be implemented' - just as you have here. It's exactly the same form of argument you get from apologists for Marxism or Communism when confronted with the widespread dislike for those systems. If something has generally failed wherever it has been implemented, it's not because it hasn't been implemented properly, it's because it is fundamentally broken.

csours 2y ago

> "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 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 https://en.wikipedia.org/wiki/Great_Oxidation_Event - we need oxygen to live, but it also kills.

nradov 2y ago
Scaled Agile Framework (SAFe) deals with that by funding value streams instead of projects. https://scaledagileframework.com/lean-budgets/ https://scaledagileframework.com/lean-budgets/
- knappe 2y ago
  SAFe, as I have seen it practiced is just waterfall by a different name.
  - nradov 2y ago
    It it certainly possible for incompetent managers to misuse SAFe, as with any other methodology. I've seen that if actually implemented as written it tends to work pretty well in large enterprises, at least in the sense of being the least bad option that allows product delivery with the level of consistency and reliability necessary to meet external commitments. Comparisons to "waterfall" are a rather silly strawman. Do you have a specific criticism of the SAFe budgeting model, or a specific alternative to propose?

mindcrime 2y ago

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.

teaearlgraycold 2y ago
If you want something done right you really do need to do it yourself.
- j45 2y ago
  And learn to understand and balance business wide considerations and how difficult that might be outside of a software-first lens.
  - racional 2y ago
    Right, but time was when one could develop and practice that wisdom without all the hooey rituals, sucking up, and insipid make-work that are Scrum. A million, trillion years ago.
    - j45 2y ago
      I don't know if politics didn't ever exist. I do agree it's toxic. And a productive workplace is often a turn off to certain kinds of employees. Scrum done a certain way too often is a waterfall in a different way to manage developers and features. Scrum/Agile are helpful where there is little to get consistent results out of team members with varying skillsets, but it doesn't mean it works for high flying team members. For example, using trunk based development for a startup with senior devs is far more efficient, with the understanding that will slow down and including more and more people will mean helping the best parts of your agility remain. Jumping all in to all ceremonies without understanding a 'why' makes a big difference. Anyhow, I get to be quiet now and learn lots from the other comments in this thread, experience has taught me that experience is a great teacher.

ivan_gammel 2y ago

> 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.

gosub100 2y ago
I can't wait for the first post showing Jira to be turning complete. Followed by the first Fizz Buzz written in Jira.
- yieldcrv 2y ago
  Probably can with those awful workflows
  - j45 2y ago
    Haha, that's funny and might even be true. I once went looking into "how did this ever become to be". The underlying workflow system in JIRA is based unsurprisingly on an existing workflow management library. And so much made sense about 'why' is it this way. It also reminded me why most JIRA "replacements" only replace whatever the origin story of the creator of the software is, where they're at, what their priorities are, and how to get there.
asdfman123 2y ago
The problem isn't the processes, the problem is the people. The good news is that in a good environment, you can earn trust after a few years and gain a little more freedom. You are basically then solving the "people" problem by fixing the only person you have control over: yourself. (Of course, I understand not everyone is working in healthy environments. Some micromanagers will never be satisfied!)
- ivan_gammel 2y ago
  Healthy environment is not the one where you need to gain trust to get more freedom, it’s where you are free from the beginning and follow (and develop) best practices instead of obeying the rules. It is a combination of trust by default and safety net, where mistakes are made, but they don’t kill the business and are corrected quickly.

vngzs 2y ago

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/ https://signal.org/blog/the-ecosystem-is-moving/

asdfman123 2y ago

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.

yieldcrv 2y ago

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

throwaway290232 2y ago

[dead]

MattPalmer1086 2y ago

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.

bitwize 2y ago
Indeed. To develop large information systems requires discipline and organization -- and programmers resist discipline as a mustang resists the bit. So what you have to do is break your programmers the way you break a horse -- enforce discipline upon them. They'll complain but it'll be worth it in the end. As an example, programmers often have cluttered desks citing the aphorism that "a cluttered desk is a sign of a brilliant mind" (when it's really just a sign of sloppy thinking). What you will find at highly effective software shops is that management will insist that the programmers keep a tidy desk, going so far as to bin any clutter they leave lying around -- because "neatness counts". For as much as it's maligned, "big design up front" is just common sense. The most successful methodologies for software development are derived from engineering, manufacturing, and construction -- and in those fields, having a clear idea of your requirements and a complete design or blueprint before you build, before you even prototype, is just table stakes. Anything else is stupid.
- MattPalmer1086 2y ago
  I honestly don't care one bit how tidy someone's desk is. I've seen very good results from taking a more iterative approach as opposed to BDUF. Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want. So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is.

bandana 2y ago

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...

baal80spam 2y ago
> I still have no idea what value they are supposed to provide, or how they fill their day once the daily meeting is over. Hey, my SM can configure JIRA swimlanes! /s

ccppurcell 2y ago

Seize the means of production comrades.

andrewmutz 2y ago

> 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.

OutOfHere 2y ago
Scrum is liked by managers, not developers. It is a managerial approach, not a legitimate engineering approach. Kanban, for example, is less negative to developers than is Scrum.

dwoldrich 2y ago

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.

fmbb 2y ago
I don’t understand how you get from someone critiquing company ownership to believing they cannot play nice with consensus or be humble. There is no relation there.
- cauch 2y ago
  I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership. It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time. I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
- dwoldrich 2y ago
  Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing. The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes. The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it. The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.

smallerfish 2y ago

> 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.

Traubenfuchs 2y ago
How did you get started with freelancing? The old "startup" I am working for is dying and I need to plan my next move…
- smallerfish 2y ago
  Upwork to start - set rates high enough and you'll find a steady stream of reasonable positions coming through. It's a bit of a slog until you build a reputation. Eventually word of mouth and your network kicks in.

PaulHoule 2y ago

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.

kolme 2y ago

> 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.

Kinrany 2y ago
What means of production? Every senior developer already owns a computer.
- latentnumber 2y ago
  lol.

deleted 2y ago

[deleted]

tamimio 2y ago

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.

deleted 2y ago
[deleted]

flappyeagle 2y ago

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.

cacois 2y ago

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?