> On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common
In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall.
Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement.
You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.
This entire discussion or dichotomy is just a massive and sad misdirection. Its explicitly cargo-culting. In what other world do we spend half of our time talking about and conforming to various 'methodologies'. If we just find the right sprint cadence. If we just do retros better. Maybe some kanban-scrum hybrid. If we just _reallly_ limit standups to 15 minutes. If we clap three times at the end instead of two - then perhaps we will be able to deliver software.
There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.
> In what other world do we spend half of our time talking about and conforming to various 'methodologies
Remember that this is largely about consultants selling advice to executives. This is not about getting stuff done.
BUT software is also a young industry. We just don’t know yet the right way to do it so we discuss and share what’s worked for us. Just like it took a while to find the right manufacturing processes in other industries.
That's because the "right way" needs to vary depending on what you're building. You don't build a garden shed the same way you build a skyscraper. Likewise, you don't build a twitter client the same way you build an implantable pacemaker.
And for that matter you don’t build a twitter client the same way you built a backend for twitter clients to connect to. In my experience every team and project has a unique way of working and that could be encouraged.
In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall.
Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement.
You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.