6 ms·

This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rati

by Hasu 1y ago

This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rational for a company to say, "This is valuable to us if it can be built in three weeks, but if it takes longer, we don't want it." Because three weeks of paying your team costs a certain amount of money, and a cost higher than that puts the value of the work underwater. If you cannot forecast whether it can be built in three weeks and then deliver against that forecast, you aren't doing your job. > Wasn't agile created to solve this BS? Agile sets regular deadlines for shipping to customers, that is literally the core idea. Instead of one big deadline 6 months from now, you have a small deadline every two weeks for the next 6 months. It's still a deadline.

Spivak 1y ago
I think the person you replied to would consider your description of agile to be === "it gets done when it gets done." Despite the term "deadline" used to describe "expected completion date" in agile they're not actually deadlines--you don't throw the work away because it's useless if it's not completed in time.
agentultra 1y ago
You want milestones and progress over estimates and deadlines. The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive. "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
- Hasu 1y ago
  > The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective. > "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time. I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can. I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.
  - agentultra 1y ago
    If you don't care, I can't help change your mind. I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue. There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation. I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play. However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.

by Hasu 1y ago

Spivak 1y ago

I think the person you replied to would consider your description of agile to be === "it gets done when it gets done." Despite the term "deadline" used to describe "expected completion date" in agile they're not actually deadlines--you don't throw the work away because it's useless if it's not completed in time.

agentultra 1y ago

You want milestones and progress over estimates and deadlines. The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive. "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.

Hasu 1y ago
> The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion. There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective. > "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time. I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can. I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.
- agentultra 1y ago
  If you don't care, I can't help change your mind. I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue. There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation. I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play. However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.