Why Development Teams Struggle to Deliver on Time, on Budget, or at All

More charitably, they're an opportunity to introduce system 2 slow thinking on the team.

There are certainly novel engineering problems that simply won't yield to estimation, but there are also lots of well-solved problems that will. Managing the latter isn't desperate, its just sound practice toward reproducible results (ideally deployed only where reproducible results create value).

You're identifying what the outcome of good planning looks like, not how it's done. What prevents this is that teams read "agile" as "make it up as you go along," when in reality if you're spending more than 10 minutes discussing a feature, make planning that feature a sprint task.

> In my experience most deadlines are movable and a strong PM/Eng team can convince management to push a deadline back.

It's not generally the team in that room discussing those deadlines, though, it's software development manager and product manager. The worst managers are software engineers who get promoted to management, and when they get into those meetings they look at their shoes and are railroaded by upper management.

You really do need a manager who has the intestinal fortitude to go to bat for you.

The budget isn't there.

For many, building software is a race to the bottom. I've worked at countless places, from "Wagile" places that run spiral methodologies mixed with agile, to fully agile agencies that deliver well but crumble the second a client gets pissy about something taking longer/costing more than it should.

In my view, the most basic problem in software is that we're committing to too much for too little, which is why I see development to be similar to working in a skilled trade. If you pay good money for a renderer, you'll get the outside of your house rendered nicely with good advice on what to use, what looks good. They'll also tell you how long it'll take, and if you say you want it sooner they'll tell you it'll either cost a lot more to get more manpower, or they'll decline the job. If you are cheap about it, you'll probably get someone that'll take longer than expected, will make a mess of the job, and you'll be left with something you're not entirely happy with.

A solid methodology will probably help with delivering software on time and on budget, but if you are unrealistic with either metric then it doesn't matter what methodology you use. You'll take liberties with it, decide that it's bullshit, and continue to cowboy your way towards a duct-taped mess of a solution.

It's something few want to talk about, probably because there isn't really a solution to it outside of:

* Paying a premium for a development team with a track record of recent success

* Having people that know the full software lifecycle be involved in all parts of the process

* Actually embracing the fact that when requirements change, to the point where budgets and timescales are flexible.

* Not joining the race to the bottom.

https://minnenratta.wordpress.com/2017/01/25/things-i-have-l...

I hear that it doesn't work that well for buildings either, as you end up with people in the field detecting bugs in the plans and having to improvise fixes without input from the designers.