Is there an official word for the pre-Agile "just do whatever" methodology?

Question

Textbooks and training courses about Agile always compare it to Waterfall. I imagine that IBM in the 1960s used Waterfall, and there may well be some government agencies that use it, but in the small business world I have never ever seen Waterfall used for software development. I've only ever seen it used as a bad theoretical counterexample, specifically when talking about the value of Agile.

Is there a formal word for the kind of unstructured development that real-world small organizations actually do (or used to do, before Agile was taught in school)? It definitely isn't Waterfall.

Answer 1

Direct answer to the question: Other than "unstructured" there is no commonly accepted name for people "just doing it".

Deeper answer to your whole question:

There have been a number of different approaches to software projects and there are plenty of companies that do not apply any structure. I think no one really compares structured approaches to "just do whatever" approaches because we all assume that the challenges with a complete lack of structure with anything more than a handful of people are obvious. (it is worth noting that Scrum has a bottom limit on team size because it acknowledges that if you're just 2 or 3 people you should be able to self-organize fine without the overhead)

About Waterfall:

I hear plenty of people in the agile community conflate different terms when talking about Waterfall, but generally speaking, they mean TPM or Traditional Project Management as the whole family of project management approaches that focuses on sequential project phases, deep separation of responsibilities, individuals as resources, and single-release plans where you identify the entirety of what you are going to do before you build it. This grouping of project management approaches provides a useful contrast against Agile as a way to avoid confusion as people try to make the transition. For example, one of the most common misunderstandings I see across StackExchange and StackOverflow is questions about the testing phase in Scrum. This confusion comes because the person asking the question doesn't understand the contrast between the two approaches and that one has sequential phases and one does not.

Therefor, the goal is not to define other approaches to software development. Rather, the goal is to provide enough contrast to help people understand what Agile, Scrum, Kanban, etc are.

Answer 2

Before Agile was taught in school, people were doing Agile. There just wasn't a single name for it.

The start to what we call Agile was in February 2001, when seventeen people met in Utah to talk about the things that they found were working well in software development in a world where there were a lot of projects that were behind schedule, over budget, and maybe never even delivered. This meeting led to the Manifesto for Agile Software Development. But these seventeen people were doing these things for a while by this point - they had developed or were actively using methods such as Scrum, Extreme Programming, DSDM, Adaptive Software Development, and Crystal on real-world projects for real companies and delivering value.

Although not represented, I'm pretty sure that there were also others. A good candidate example would possibly be Lean Software Development, where the first book about it was published in 2003, but it seems unlikely that the Poppendiecks developed it, vetted it, and wrote a book about it in 2 years. I'm sure if you were to ask the seventeen people who were at Snowbird, they would be able to mention other people who were not only doing, but writing and talking about their approaches to building software.

However, waterfall was and still is used as a methodology for developing software projects, even though it is not only flawed (and identified as such in the 1970 Winston Royce paper titled "Managing the Development of Large Software Systems" that identified it). People as early as the 1960s were identifying that managing software projects isn't the same as managing other complex engineering projects and wanted to work toward iterative and incremental development and tight feedback loops with customers, and you can see this in the 1968 NATO Software Engineering conference.