It’d be hard to be a software developer these days without hearing about “being agile”. Agile is a popular software development process. It is intentionally loosely defined, though that naturally leads to many many different opinions about what it is. The spectrum varies from those who think there are some rules that absolutely must be followed in order to be considered agile to those who use it to justify a lack of process.
The version I believe is that agile at its very core means to use as much process as you need. No more. No less. Every software project is different. There is no magic “do this and all your software dreams will come true” method. The most efficient development process will be different for a 3 person team working on a simple mobile game than there would be for a team that builds software for rockets. When the mobile game team has a bug, they just fix it. No big deal. When the rocket software team has a bug, millions if not billions of dollars could be at stake and lives could potentially be lost.

What this means is that in agile, if you need a type of document, then make it. After a few weeks, you evaluate if it has been useful or not. No? Get rid of it! Yes? Then figure out how to make it even more useful. The same goes for daily/weekly meetings about topic X and various software productivity tools. That’s why it’s tough to have a set of rules governing what is agile or not. Being agile means adapting to the situation instead of blindly following a rule book. That’s not to say that the literature about agile is garbage, but everything should be treated as a tool or guideline: to be used when appropriate and put away when not.

There are those who use agile as an excuse to not plan ahead though. This is a direct counter to the “waterfall” process in which software goes through a set life cycle: get requirements -> design software -> build software -> test software -> maintain software. It sounds sensible except decades of software development has shown that it doesn’t work. What do you do if the requirements missed an error message in testing? Just release the software where it crashes in certain cases because hey, the software was built to spec? What if a new business need arises because a competitor did something? Do you just keep going building software to the original spec, even though you know the software is going to get killed by a competitor’s product? Or do you start all over, in which time your competitor may release something even better.

There’s lots of reasons why waterfall doesn’t work, however that does NOT mean it isn’t worthwhile to plan ahead! Most folks like to work in 2-4 week cycles because it allows enough time to get a meaningful amount of work done, while providing for a frequent interval to step back and reflect on the work being done to make sure it is still the right thing to do. Some people use this as justification to not plan more than 2-4 weeks ahead because hey, if waterfall doesn’t work then planning is pointless!

That just leads to shoddy software being built. Everything in software should be malleable, but some things ARE harder to change than others. Database schemas are one of those things that are trivial to change during development, but become exponentially more difficult once users are on the system. (True story: I was at a company that took it’s website down for 24 hours to handle a big data migration. Can you imagine Amazon being down for 24 hours?) Software developers need to accept that life is filled with surprises and they will need to deal with things that don’t go according to plan. However, HAVING a plan first makes it easier to adapt to those surprises. The very act of planning forces you to think about different scenarios and the more scenarios you think about, the easier it gets to adapt to scenarios you haven’t thought about. If you’ve planned for 12 different ways the project could go, you have plenty of experience to help resolve the 13th. Or at least you’ll be better off than if you only thought of one way the project could go and you are given a second.

One of my favorite quotes from Eisenhower:

In preparing for battle I have always found that plans are useless, but planning is indispensable.