We have known for over twenty years that most problems with software come from the requirements phase.

We need to stop accepting that we are the guilty party and trying to get our house in order while the one next door is engulfed in flames.

The problem is not in how we track our time. In how we organize tasks, in how we deal with technical debt, long-term maintenance, engineering disputes. Documentation.

Our problem is in being ill-informed consumers of requirements information. In accepting it instead of sending it back to be done over and refusing to start on anything other than basic R&D until it's sorted. If people aren't told in a clear manner why what they've done is wrong how will they ever improve? And if they know we'll do it anyway, why would they bother changing?

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

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.

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.

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.

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.

I love this idea. But I fear I’ll be shot for executing it. :)

I've found that ideally all product changes should be developed in close collaboration between a product owner, a UI/UX-person, and a developer. The design shouldn't be made upfront and handed to the developer, it should be made iteratively with the developer providing feedback. And the same goes for the product owner, giving input about user needs and their mental model. The developer should provide feedback about what is feasible and easy instead of just being expected to code up a design that's thrown over the wall. If you allow any of these parties to do most of their work before the others, then you'll get a local optimization that will either constrain the others to do sub-optimal solutions for their areas, or force the final result to break out of the optimum from the first area. The best result comes by having each side provide input in each iteration. Getting a team to work like this is rare though, in my experience - I guess that's part of what makes unicorns so valuable, since they'll integrate several of these roles in one person.

> All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion.

What other opinion are they supposed to "lean towards"? Their boss' opinion is the only one that actually carries any sort of authority -- you implement it whether you agree with it or not.

Haha! It is not us it is the engineering team blaming culture