My question is this; what alternatives are there to agile? I know there is the waterfall method, but from what I understand we as an industry moved to agile because of the weakness of waterfall in the internet era. What other alternatives do you suggest? Where should we look for improvements?
It minimizes the time spent on unnecessary bureaucracy and ceremony, while still giving you the transparency and flexibility behind Agile. Supervisors and such can look at the board and see what the team is working on and what stage they're at. And when emergency things inevitably come up, that's when you pause what you're working on, temporarily put that in the "on hold" column, and work on whatever the new critical priority is before going back to your original work (usually) or else pivoting altogether (which often happens in more top-down orgs).
A Kanban is by nature not prescriptive, but after-the-fact descriptive. It respects people over processes – a fundamental part of the Agile philosophy that too often gets buried in dogma – by respecting each worker's autonomy while also giving the team as a whole flexibility. If you need to change things up, you just send a few messages or do a huddle instead of spending half the day arguing about points and then arguing about them again in the 2-hour retrospective.
In the most dysfunctional orgs I've been a part of, it wasn't really Agile anything or any particular tool that was the problem, it was that they were so middle-management heavy that most of the dev time was spent managing up instead of coding. That isn't a something tooling can in and of itself solve, but I've found that the heaviness of the tooling is often a good proxy for the dysfunction of the management layers. In that case I'd fight to simplify things and make work more efficient, or ask for a transfer to a more efficient team, or just leave the org altogether. When there's that many head chefs in the kitchen, every minor feature becomes a political battleground and no real work will get done, no matter your process.
If you look at all of the processes, tools and ceremonies available to ou from various agile methodologies - you can tailor things to your liking.
I was in teams where scrum actually worked, up to and including the story-pointing and backlog-requiment giving us accurate estimates of how long features will take to develop.
And then we had more ad-hoc/timely work for some quarters and we dropped most of the plan/sprint/refine structure in favor of more simple kanban board.
2. Programmer Anarchy by Fred George on YouTube is an interesting idea.
The beauty of PDCA is that it is an adaptive framework. Meaning how it’s applied to my team will be different than your team. That’s a healthy development that relates to the fact that different people will work together differently. (side note: agile is often used as a synonym with pdca and it can confuse thing bc Agile tm is what a lot of people have bad experiences with)
i wrote a bit about my experience using agile: https://hedgerider.substack.com/p/agile-for-anarchists
It's all about communication and hiring. I've found agile to ensure the bottom 10% participate in important discussions (stand-ups, refinement meetings, feedback on process in retros).
If you hire the right people that take initiative and over-communicate, a lot of process suddenly seems unnecessary.
New issues are added to the list based on priority. And only “emergency” issues can pause current work to be paused.
Everything else is done face to face as needed without formal meetings.
It’s simple. It works.
Second, don't pick a specific process. Develop a process. Select from the broad collection of ideas that go into processes, the components that you want based on their effectiveness or utility.
https://en.wikipedia.org/wiki/Software_development_process
The key things to decide when developing a process:
Feedback loops or no? If you don't like reality, then don't use feedback loops. For the rest of us, reality is what we live and work in so incorporate feedback loops. Don't use hard boundaries between phases with an assumption the previous work was correct. This means likely pushing for automated, regular testing (verification) and regular "customer" (whatever that means in your context) feedback (validation). Use the results to update plans, designs, requirements, and the system itself.
Small batch or big batch? The larger the work you deliver at once, the higher the risk. Delivery is when you get validation (that you built the right thing). If you have a team of 1k people building out your hot new shit and deliver after 2-3 years, you may find you spent a lot to build the wrong thing. Deliver smaller batches incrementally and you'll get validation (and verification, but critically validation) along the way. This also means you have to rollback less if there's an issue, if you have to roll anything back. Deploy a new validated (right thing) service after 2 years but find out you have a critical design flaw so it doesn't handle more than 1k concurrent users, well you may have to eat the scaling costs or rollback the release and fix the design. Smaller increments, better feedback, lower risk.
BDUF or no? Big design up front means committing (it's a design) to a lot of unknowns. Is the design even going to be relevant when you release? Is the time spent on it worthwhile? If you're delivering in smaller batches you get feedback and can adjust the design, but then why spend so much time designing everything? Design just enough between releases, how much is enough? Judgement. You know your team and market, you figure it out.
Waterfall: No feedback loops, big batch, BDUF. It's basically the highest cost, highest risk approach. It's stupid for any project that's going to last more than 6-12 months. (Any project that length or shorter that's not totally novel is likely to succeed or fail regardless of chosen process.)
Incremental (Classic): Waterfall with 6-12 month increments. Fixes the feedback loop and partially addresses batch size problem. Still has BDUF. Reasonable, but not great because you're still spending a lot of time on the design that could be invalidated.
Spiral (Classic): Incremental without BDUF. Some design and requirements at the start, but mostly done at the start of each increment which is still usually in the 6-12 month (maybe shorter) range. Addresses many of the issues of the above.
V-Model: Waterfall with much stronger emphasis on V&V, permitting some feedback as you go through the V&V portion of the work. Pair this with Incremental or Spiral and you actually have a somewhat reasonable model. Stick to V-Model as Waterfall with better V&V, you still have the big batch risks and BDUF problems.
If you look at the actual ideas in Agile and not just Scrum, you'll see that it ranges from somewhere along Spiral (just enough design and requirements to hit an MVP, evolve that toward your final product using feedback along the way) to the more extreme form of Kanban style where you work and deliver very, very small batches (potentially delivering every small change many times a day).
The big things to take away from every one of the models: Feedback loops reduce risk and increase the chance of success. Small batches reduce risk and increase the chance of success. Design up front, but not BDUF, reduces cost and some risks (that you build the wrong thing because the decision was made before it should have been).
Take those three things and then figure out the specific techniques (wherever they come from) that help you out. TDD is basically the tightest feedback loop you can get for software verification. Is it appropriate for everything? Maybe, maybe not. Things of that nature.
NB: Spiral and the various Agile methodologies and techniques work even in critical and safety systems. In aviation for a new aircraft, building a safety-critical LRU the first deliverable might just be a form and fit check that supplies canned messages over the avionics network (this is used in initial integration testing on the ground). The next deliverables will push toward meeting flight safety requirements for the first flight tests. Then the next series will add capabilities required for certification but not for flight test. The final series will be further "quality of life" refinements that the customer wants, or maybe to work with specific variants for specific carriers or nations.
You don't need Waterfall or BDUF for anything.