I'm in the business of building complex software systems, and I think another way to improve software development is to fire all the agile coaches, use the money saved to hire more developers, and use those developers to give the team more help to fix defects and add features. I really cringe when a project management type comes in and points out the obvious. This kind of stuff only works if you are building simple software like a CMS system or a basic CRUD app. Building complex software is an exploration in and of itself. In the old telecom days, months would be spent writing precise feature specifications and design documents. That's how much time it takes. Does ANYONE have that time today? Aside from safety critical systems where you have no choice but to put in the time, I think the answer is no. The software development process has shrunk significantly, and as an industry we have decided to meld design, architecture, feature specification, coding and testing. Bugs are a necessary end product of this stupidity.

FYI, I'm not a project management type. I've build numerous continuous delivery pipelines for enterprise clients and helped them deliver multiple features per week. I have current skills in writing Java, C# and Node.js. I've written my own testing frameworks (Check out Chimp.js), I coach developers on how to write better code, as well as business people on how to create better specs.

I typically try to stay away from CRUD applications where possible as I find them too simple. I prefer to work on meaty domain-driven applications using CQRS and Event sourcing, but that's just my tech preferences.

I too worked in telecoms and was part of the development team that did the AOL LLU from BT in the UK. The old-world you speak about has a ton of wisdom in it, that much I agree with you on, however it was also riddled with stupidity of its own.

The amount of time you put into the specs is not where the trick is in my view, it's about splitting the specs down into manageable chunks (something the old world never understood) and then making sure those chunks get the necessary time (something often missed these days).

If you think the solution for your company is not to have any advisors, and that you have all you need, then by all means hire more developers. They are the smartest people around ;)

I didn't mean a personal attack on you btw. Your track record suggests you know your stuff and would likely be an asset on a large/complex project. My comment is informed by my bad experiences at two previous employers - both parachuted agile coaches to "help" when the problems were obviously a runaway feature list and not enough developers. Surely, you must know of charlatans in connection with agile. I think we all need to educate management that agile is not a silver bullet or a panacea. It is a process with good and bad. Great if welded by adults but very easy to abuse by non-grownups. To many of my developer friends, agile is a synonym for daily status updates, which is absolutely not what it is supposed to be.

Thanks for the clarification and totally agree. I have seen project managers turn their gantt-chart sideways, have 1 hour standup meetings and call themselves Scrum Masters! So I know exactly what you mean.

Nowadays I never say the A word in a companies for the exact reasons you mention. Now I say "let's start producing higher quality, faster" and go from there.

> about enforcing a strict and logical classification system.

But that is something so common place that even pretty poorly run software organizations which ship crap do it.

The rhetorical Everyone has a bug database with features, enhancements, low priority bugs and "blockers". That plus version control is the bare minimum requirement for having any kind of process distinguishable from total chaos.

This is an article about water being wet.

Perhaps, but having worked for a government sub-contractor that had precisely this problem, I don't think it's as universally true as you would think.

At that particular company, everything was a "task" and tasks were just thrown at employees as they came. This wasn't just limited to software development either...this applied to customer support and service as well.

Their solution, and the solution the customer (government contractors) was to schedule numerous and regular meetings in order to touch base and monitor progress...which only contributed to the problem.

Also the article itself is actually a case study...