> Given a standard of quality, what can we ship in 60 days?

Others have said it, this is a methodology, and quite an aggressive one that causes a lot of questions to be asked, and if you don't, you'll end up in a mess. It requires planning, discussion, size estimation, design, maybe even prioritization (if you have two things that each take 45 days, one needs cutting and a 15 day one needs picking up, or you need to cut the scope down to 30 days each, and so on).

I get it, people are bored of being managed to an inch of their lives, but I'm going to be contrarian here:

We need to grow up as an industry a bit on this one.

If you walk onto a construction site, you will see methodologies. The methods you see will not be the same ones as you might have used to build a lego house, or even a sandcastle on a beach. There will be Gaant charts, and project managers, and discussions, and plans, and estimates, and meetings. They do all that, because they don't want the building to fall down. These methods give us some assurances that the right things are happening in the right order and at the end, the building will function as designed and not kill anyone.

When you walk into Airbus (let's leave Boeing to one side on this one), they aren't sat around making paper planes or models like they did when they were kids. They're not throwing designs together as they feel like it: there are methods, projects, and people to co-ordinate them. They do this because they want to be sure that the aircraft they build do not fall apart, even in marginal conditions they could have accounted for.

Yet, for some reason, perhaps because its an industry where people first get involved in coding as a hobby, or for personal fulfillment, or some other personal reason, we seem to reject all this.

We all want to be left alone, artisans in our attics, cutting the code we want to cut, for the features we think are needed, the way we want to build them, because we're special, and managers "don't understand".

Perhaps even worse, many people really learn the fundamentals of the industry from academic applied mathematicians, who think the work is thinking alone in an office, writing a paper and occasionally teaching people - this isn't how software is built in industry. We have much to learn from professors of computer science, but we should not model our work behavior on their work behavior.

The software we build can really hurt people. We owe it to others that we actually engineer it, not just hack it. Our software can easily do a bad enough job that the company - or customers' companies - fail and people lose their jobs. In some cases, failing to ship on time, or to a good enough quality might lead to even bigger consequences, up to and including death.

There is an entire subsection of the industry pointing out the security risks created by software badly designed and badly built, due to a lack of engineering talent and appropriate oversight. We should all want to fix that, and I don't believe letting engineers sit in corner ignoring basic engineering best practices is going to be a successful path to that outcome.

We need to be more like the construction sites, the aircraft builders, the ship yards submarines get built in, the real grown-up engineering disciplines. We need to come down from our little pillars and talk to people about what needs doing, and by when, and then have adult conversations about constraints and risks.

Nobody wants everyone in meetings all day. Perhaps those conversations are weighted more heavily towards more senior engineers, which is what happens in most industries outside of software. Nobody wants to be micro-managed, but at the same time it is reasonable for the people paying you many multiples of the national median salary to ask you what it is you're doing right now, if you're blocked, and what you plan to work on next - and make suggestions about changing that plan if the company paying you needs you to change that plan.

I agree that the agile certifications need to go - or radically change - and that engineers need to be trusted more, but trust is earned. The constant push back on anything that looks like reasonable organization to any other industry or to any manager, makes the industry as a whole - and those who shout the most about the pain of it all - lose trust in the eyes of the people who we need to invest in it.

We just need to grow up, stop pretending that what worked when we were making sandcastles works for employers, and look to successful engineering disciplines away from software and learn from them.