4 ms·

Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basic

Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basically only gonna accelerate how poorly we research "the problem space" as I called it. She replied that we weren't gonna do waterfall and that the data supported agile as the company wide prerogative. I replied that what I was asking for wasn't necessarily waterfall, but I also had no other term to describe it, and so she shut down the conversation completely by going, "I'm sorry, but the data supports agile. This conversation is over." It struck me at first as "What the fuck, seriously!?" but then I considered she probably wasn't the one who made that decision or pushed it, but also that I wasn't maybe being clear. So it's helpful to hear that this a bigger issue throughout the industry from a vet Ave not just local to the company I started my career at and so have no other frame of reference

sepranu 7y ago
No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.
- acephal 7y ago
  I don't, and my coworkers laughed at me when I relayed that conversation to them, I feel vindicated the issue around requirements gathering, and the effect that has on development, isn't unique to my company.
thristian 7y ago
The best justification I've heard for the success of approaches like Agile is that they slow the software development process down and give stakeholders a chance to adjust to changes. If you ask a user what they want, their answer depends on how their current system has developed. Maybe there's a good idea that they hate because in the current system it would require too great a compromise. Maybe there's a terrible idea that they love, because they haven't understood the horrible corner-cases. The real strength of the agile approach is to help the customer figure out their requirements through experimentation, instead of asking them to deduce everything from first principles. Once everybody understands the actual requirements, the actual implementation should be fairly straight-forward, engineers can comfortably make design trade-offs, etc. Of course, there's a lot of cargo-cult Agile, and buzzword-compliant Agile, and that might be more trouble than it's worth, so it's not a guaranteed cure-all. Even good agile can be ruined if the customer or management doesn't see the value, or doesn't understand the core "refine requirements through iteration" rule. Your mileage may vary, but that core idea is still a good an important one.
- hinkley 7y ago
  Yeah that was always how it was sold to me too. But then the Dark Times came. It still works a bit that way, but the parts you can really see are all of the metric dysfunction. And I blame Schwaber for setting this avalanche off. Of all of the Agile processes, Scrum seems to have the most surface area for attack by metric dysfunction. I didn't think I'd end up missing Jeff de Luca so much. He banished story size estimates a long time ago, making Scrum feel like a step back to me. I've only recently heard of people rediscovering that you only have to split up stories that are 'too big' and you can still do fairly accurate estimates and projections based on the aggregate behavior of 100's of stories. What I see missing or unstated in virtually every discussion is that time isn't the constrained resource. It's energy. There are lots of tasks I could complete in half an hour, but the strain of doing so would still mean I'd only get 2 things done that day. There are also things I can do in 4 hours that still leave me spent for the day. And plenty of managers who will try to make you question your self worth for not volunteering to do 2 of those things in one day because 4+4=8. Think about that the next time you catch yourself on Hacker News and you scold yourself for wasting time. I'd lay even odds you're either recuperating from something you just finished, or frustrated by something (or being blocked by something) and taking a break. Think about it when you're trying to articulate why you accepted 60 hours of work this week because they're trivial stories with a lot of wait time built in. They're trivial because they're intellectually and emotionally 'cheap' tasks. There are boring tasks that take every fiber of your attention and you will refuse to double up on those. Because it's energy, not hours. Always has been. And you know what else takes a ton of energy and social capital? Arguing with some fucknut about whether a story is 3 points or 4.

sepranu 7y ago

No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.

acephal 7y ago
I don't, and my coworkers laughed at me when I relayed that conversation to them, I feel vindicated the issue around requirements gathering, and the effect that has on development, isn't unique to my company.

thristian 7y ago

The best justification I've heard for the success of approaches like Agile is that they slow the software development process down and give stakeholders a chance to adjust to changes. If you ask a user what they want, their answer depends on how their current system has developed. Maybe there's a good idea that they hate because in the current system it would require too great a compromise. Maybe there's a terrible idea that they love, because they haven't understood the horrible corner-cases. The real strength of the agile approach is to help the customer figure out their requirements through experimentation, instead of asking them to deduce everything from first principles. Once everybody understands the actual requirements, the actual implementation should be fairly straight-forward, engineers can comfortably make design trade-offs, etc. Of course, there's a lot of cargo-cult Agile, and buzzword-compliant Agile, and that might be more trouble than it's worth, so it's not a guaranteed cure-all. Even good agile can be ruined if the customer or management doesn't see the value, or doesn't understand the core "refine requirements through iteration" rule. Your mileage may vary, but that core idea is still a good an important one.

hinkley 7y ago
Yeah that was always how it was sold to me too. But then the Dark Times came. It still works a bit that way, but the parts you can really see are all of the metric dysfunction. And I blame Schwaber for setting this avalanche off. Of all of the Agile processes, Scrum seems to have the most surface area for attack by metric dysfunction. I didn't think I'd end up missing Jeff de Luca so much. He banished story size estimates a long time ago, making Scrum feel like a step back to me. I've only recently heard of people rediscovering that you only have to split up stories that are 'too big' and you can still do fairly accurate estimates and projections based on the aggregate behavior of 100's of stories. What I see missing or unstated in virtually every discussion is that time isn't the constrained resource. It's energy. There are lots of tasks I could complete in half an hour, but the strain of doing so would still mean I'd only get 2 things done that day. There are also things I can do in 4 hours that still leave me spent for the day. And plenty of managers who will try to make you question your self worth for not volunteering to do 2 of those things in one day because 4+4=8. Think about that the next time you catch yourself on Hacker News and you scold yourself for wasting time. I'd lay even odds you're either recuperating from something you just finished, or frustrated by something (or being blocked by something) and taking a break. Think about it when you're trying to articulate why you accepted 60 hours of work this week because they're trivial stories with a lot of wait time built in. They're trivial because they're intellectually and emotionally 'cheap' tasks. There are boring tasks that take every fiber of your attention and you will refuse to double up on those. Because it's energy, not hours. Always has been. And you know what else takes a ton of energy and social capital? Arguing with some fucknut about whether a story is 3 points or 4.