4 ms·

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 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
It is definitely not the only way and the hardest one. Solution is actually trivial: talk to engineers about business more. There’s an anti-pattern of a god stakeholder who decides on everything providing very detailed requirements about “how” and “what” to build. Functional requirements should be “written” by engineers after they learn “why”, i.e. see the problem with the eyes of business. They don’t have to be founders for that.
- cauch 2y ago
  I agree with that. But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Bad scrum practices are, in my experience, very often the consequences of the devs themselves. I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough". I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
  - ivan_gammel 2y ago
    > But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Why not? In such situations it is always possible to show them the door. If they need a translator, they are 0,5x engineers and cost too much.
jokethrowaway 2y ago
It doesn't matter what you sign. Scrum is process over people. It's the opposite of the agile manifesto. But don't trust me: read the agilemanifesto.org and then go and read "What is Scrum" from scrum.org
- mindcrime 2y ago
  I've been doing "agile" since before "Agile" was a thing, and I am a Scrum.org certified PSM. I don't need to go read anything to know that you're misrepresenting the situation here. But to indulge you, here's what scrum.org says, in part: If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Continuous experimentation, adapting with feedback, and learning and improving as you go? That doesn't sound like "process over people" to me. Note also that the Agile Manifesto never says anything about not having some process. I think almost everybody would agree that a certain amount of process for the sake of consistency is a Good Thing. The problem is when people over-elevate the process to where it's seen as its own end unto itself, rather than a tool to help the team deliver the $THING they are trying to deliver.
  - ath3nd 2y ago
    Hey kids, Do ya love sprinting? Wanna never stop? Wanna play with cards shouting numbers with no meaning not unlike old ladies playing Bingo? Wanna have a mini CEO, who, for some reason bosses around people far more qualified than themselves, implying that they are just nerds that can't be trusted to speak to the outside world? Wanna appoint one of your team members each week (or, even better, hire a dedicated member of your team) to whine about you adhering to all of the rules you just made up? If you love all of the above, you'd love Scrum. And, if your idea of good time is being in meetings about meetings, you'd love SAFe even more. > If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, The reality is that if you are just getting started, think of Scrum as a way to talk about work and have rituals about work, preventing you from doing actual work. I have never, in my long career, seen Scrum work. Unless your idea of it working is chasing away good developers and making the mediocre ones thrive (in following the process, not in actual achievements). Scrum is just terrible and should be killed with fire.

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

It is definitely not the only way and the hardest one. Solution is actually trivial: talk to engineers about business more. There’s an anti-pattern of a god stakeholder who decides on everything providing very detailed requirements about “how” and “what” to build. Functional requirements should be “written” by engineers after they learn “why”, i.e. see the problem with the eyes of business. They don’t have to be founders for that.

cauch 2y ago
I agree with that. But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Bad scrum practices are, in my experience, very often the consequences of the devs themselves. I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough". I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
- ivan_gammel 2y ago
  > But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Why not? In such situations it is always possible to show them the door. If they need a translator, they are 0,5x engineers and cost too much.

jokethrowaway 2y ago

It doesn't matter what you sign. Scrum is process over people. It's the opposite of the agile manifesto. But don't trust me: read the agilemanifesto.org and then go and read "What is Scrum" from scrum.org

mindcrime 2y ago
I've been doing "agile" since before "Agile" was a thing, and I am a Scrum.org certified PSM. I don't need to go read anything to know that you're misrepresenting the situation here. But to indulge you, here's what scrum.org says, in part: If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Continuous experimentation, adapting with feedback, and learning and improving as you go? That doesn't sound like "process over people" to me. Note also that the Agile Manifesto never says anything about not having some process. I think almost everybody would agree that a certain amount of process for the sake of consistency is a Good Thing. The problem is when people over-elevate the process to where it's seen as its own end unto itself, rather than a tool to help the team deliver the $THING they are trying to deliver.
- ath3nd 2y ago
  Hey kids, Do ya love sprinting? Wanna never stop? Wanna play with cards shouting numbers with no meaning not unlike old ladies playing Bingo? Wanna have a mini CEO, who, for some reason bosses around people far more qualified than themselves, implying that they are just nerds that can't be trusted to speak to the outside world? Wanna appoint one of your team members each week (or, even better, hire a dedicated member of your team) to whine about you adhering to all of the rules you just made up? If you love all of the above, you'd love Scrum. And, if your idea of good time is being in meetings about meetings, you'd love SAFe even more. > If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, The reality is that if you are just getting started, think of Scrum as a way to talk about work and have rituals about work, preventing you from doing actual work. I have never, in my long career, seen Scrum work. Unless your idea of it working is chasing away good developers and making the mediocre ones thrive (in following the process, not in actual achievements). Scrum is just terrible and should be killed with fire.