[cassianoleal]

The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out.

Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them.

When all else fails or when something feels off, get back to first principles.

[simplotek]

> The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.

It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.

So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?

[cassianoleal]

If the so called "standard approaches" are in the way of my delivering quality software, I'm absolutely going to call it out and do my best to change it. Most times, if that's impossible, the correct course of action is to leave rather than delivering poor quality.

[majormajor]

It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between.

There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level.

It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.

[cassianoleal]

https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobo...