The best characterization of agile is that it's an adjective, not a noun. It's why it has become so completely meaningless. Because everybody wants to do things with at least some pretense of agility. And often it's the people proclaiming their agility the most that you need to scrutinize the hardest when it comes to their proclaimed agility. As soon as you start talking about agile as if it is a noun, you are effectively bullshitting. It's not a thing (literally). It never was.
The software crisis, is the notion that software is hard to produce on a schedule. People indeed noticed that early on before there even were compilers. Hidden in that notion is a thing that is problematic with software. In order to even have a timeline for "it" to be delivered, you'd have to specify what "it" is. That's a notion that is quite hard. Often such specifications are a combination of wrong, incomplete, and not very useful. And it leads you to an engineering mentality where specifying the thing up front in excruciating detail becomes a mandatory thing. If there's one thing we can learn from the last seven decades of software engineering it is that that is indeed extremely hard and probably futile with the exception of a few domains where anything less is just not acceptable.
The notion of waterfall, which was popular with people that did not read the original paper by Royce (he does not mention the word waterfall but is often blamed for inventing the methodology) in full. Waterfall is the notion of specifying requirements upfront, designing the software, and then implementing it. Royce actually called out in his paper that going through this process multiple times yields better results. So, the key paper on waterfall actually suggests we might want to "iterate". Still worth a read more than 50 years later. Among all the agile nonsense, this is actually a good paper. But you have to read it in context.
You might think of writing software as the actual process of specifying what the software does. The best specification is the source code you produce. It's executable and complete. Whatever it specifies, it does. You might be unhappy with the level of detail but it is a specification.
The contribution of the agile manifesto was acknowledging that reality and the notion that it is more productive to talk about modifying this specification than to come up with some meta specification. You have to build in some moments of reflection and adjustment. So most of the time you are actually specifying changes relative to the existing system rather than the entire system. The only moment that is not true is when you have not written any software yet.
Specifying software changes is what an issue tracker is used for. Bugzilla was one of the first widely used ones and it launched a few years before the agile manifesto got penned down. The insight at the time was a that a good issue tracker (and maybe a wiki) were really all the tools you needed to orchestrate software development. All the rest (scrum, kanban, sprints, planning/estimation meetings, velocity, etc.) was just retrofitted around that notion.
That's it. If you can wrap your head around iterating, you are agile, just like everybody else. The smallest possible iteration is: write an issue, write some code, create a pull request, wait for someone to merge it. Pull requests are great. Most modern software development features multiple pull requests being worked on independent from each other at the same time. Of course the notion of concurrent iterations that aren't coordinated centrally makes the heads of most scrum proponents explode.
There's a lot of great software that gets produced by large organizations, or even distributed organizations (like open source projects), seemingly without a lot of ceremony (scrum or otherwise). Open source is basically software development stripped to its bare essentials. There are no estimation sessions. No sprint plannings. No sprints even. Work happens concurrently with very little central coordination. All there is is an issue tracker, a code repository and exclusive access for those allowed to merge pull requests. Some great software gets produced that way. And I don't think it's accidental either. Some projects seem very consistent with maintaining a predictable frequency of releasing, high quality standards, etc. In fact they put many corporate "agile" teams to shame. Mediocrity is the norm, not the exception in our industry. The software crisis still exists; but mostly in supposedly agile teams still insisting on disguising waterfall as agile. The louder they talk about being agile, the less they generally are.
The software crisis, is the notion that software is hard to produce on a schedule. People indeed noticed that early on before there even were compilers. Hidden in that notion is a thing that is problematic with software. In order to even have a timeline for "it" to be delivered, you'd have to specify what "it" is. That's a notion that is quite hard. Often such specifications are a combination of wrong, incomplete, and not very useful. And it leads you to an engineering mentality where specifying the thing up front in excruciating detail becomes a mandatory thing. If there's one thing we can learn from the last seven decades of software engineering it is that that is indeed extremely hard and probably futile with the exception of a few domains where anything less is just not acceptable.
The notion of waterfall, which was popular with people that did not read the original paper by Royce (he does not mention the word waterfall but is often blamed for inventing the methodology) in full. Waterfall is the notion of specifying requirements upfront, designing the software, and then implementing it. Royce actually called out in his paper that going through this process multiple times yields better results. So, the key paper on waterfall actually suggests we might want to "iterate". Still worth a read more than 50 years later. Among all the agile nonsense, this is actually a good paper. But you have to read it in context.
You might think of writing software as the actual process of specifying what the software does. The best specification is the source code you produce. It's executable and complete. Whatever it specifies, it does. You might be unhappy with the level of detail but it is a specification.
The contribution of the agile manifesto was acknowledging that reality and the notion that it is more productive to talk about modifying this specification than to come up with some meta specification. You have to build in some moments of reflection and adjustment. So most of the time you are actually specifying changes relative to the existing system rather than the entire system. The only moment that is not true is when you have not written any software yet.
Specifying software changes is what an issue tracker is used for. Bugzilla was one of the first widely used ones and it launched a few years before the agile manifesto got penned down. The insight at the time was a that a good issue tracker (and maybe a wiki) were really all the tools you needed to orchestrate software development. All the rest (scrum, kanban, sprints, planning/estimation meetings, velocity, etc.) was just retrofitted around that notion.
That's it. If you can wrap your head around iterating, you are agile, just like everybody else. The smallest possible iteration is: write an issue, write some code, create a pull request, wait for someone to merge it. Pull requests are great. Most modern software development features multiple pull requests being worked on independent from each other at the same time. Of course the notion of concurrent iterations that aren't coordinated centrally makes the heads of most scrum proponents explode.
There's a lot of great software that gets produced by large organizations, or even distributed organizations (like open source projects), seemingly without a lot of ceremony (scrum or otherwise). Open source is basically software development stripped to its bare essentials. There are no estimation sessions. No sprint plannings. No sprints even. Work happens concurrently with very little central coordination. All there is is an issue tracker, a code repository and exclusive access for those allowed to merge pull requests. Some great software gets produced that way. And I don't think it's accidental either. Some projects seem very consistent with maintaining a predictable frequency of releasing, high quality standards, etc. In fact they put many corporate "agile" teams to shame. Mediocrity is the norm, not the exception in our industry. The software crisis still exists; but mostly in supposedly agile teams still insisting on disguising waterfall as agile. The louder they talk about being agile, the less they generally are.