[eksemplar]

It also works better than agile when you’re buying software and you can’t just sign on on something without knowing what it’ll cost. Which is 99% of the time in the real world.

I think the golden middleway is somewhere in between, where you do the upfront analysis and figure out what to do, why you’re doing it and with whom, but don’t lock everything down tight in an unchangable requirement specification.

I think methologies like service design can be really great, if you don’t know what you’re trying to do. I think agile methologies are decent for the actual development of software, but a software project is so much more than that, including benefit realisation.

I think it’s embarrassing that we can plan and build a organic house for thousands of employees, and deliver on time and within budget, but we can’t build a piece of software to handle the digital workflow of labelling and storing documents.

Hell, we plan city infrastructure and succeed, every year without going over budget. But building a piece of software to digitise vacation registration? Fuck no, that’ll go one year over time and cost four times what we expected, even though you could rightly build the same thing in a few months as a single focused developer.

I’ve seen all sorts of project management models in action, none of them work for software. But agile is especially stupid from the buyers perspective. When I buy a new house I wouldn’t sign a contract for an unknown amount of finished rooms within the agreed upon timeframe and budget either.

Mostly though, I think software developers just need to do better work, and stop blaming the project management for their own inability to deliver good work in a timely manner.

[walrus1066]

'Mostly though, I think software developers just need to do better work, and stop blaming the project management for their own inability to deliver good work in a timely manner.'

Even if this is the case, PM still responsible for blown deadline, because they did not estimate their teams delivery velocity correctly.

They should either:

a) give longer estimate, if their team quality is low.

b) pay more to hire better, more productive developers.

A good PM will also account for uncertainty in devs estimation, by padding etc

Predictability of delivery is what ultimately counts, not giving optimistic deadlines.

[Agathos]

> When I buy a new house I wouldn’t sign a contract for an unknown amount of finished rooms within the agreed upon timeframe and budget either.

You hope you don't. But halfway into construction, everyone might realize the blueprints attached to that contract don't cover some detail you really need. Then if you want that done, you'll have to pay extra. That's why change orders are so common in construction.