Ask HN: Is it time to retire Agile?

The two things that I believe (from observation and experience, not a formal study) are essential regardless of your processes and practices: Communication and knowledge sharing.

If you have knowledge silos and overly strict communication channels (or absent channels) you are in for trouble in the future. You will not be able to adapt.

My anti-solution process: Always be adapting. Learn all the processes and practices under the sun (this doesn't mean you can do them or recite them cold, high level, also I exaggerate, not all of them). Select from them as if from a toolbox.

I'll point to Brooks' Mythical Man Month and the idea of the surgical team for an example. His idea was to model the team structure on the internal management of an operating room, you have a lead who directs much of the action going on. Doling out tasks and requirements to everyone else, in practice in software this may be the Senior Architect who creates the high level requirements and some of the low level ones and distributes to specific individuals or teams the job of doing the coding, but they don't get to inform the design (significantly).

This process can actually work. But don't cement it in stone. This process can fail spectacularly when you have too many senior people or you don't have an actual senior person to run it or for various other reasons. Ossification, cementing a process, is the thing that has to be fought against constantly. A process can work today, on this project, with these people, and for that customer. Take that same process and change any factor and it will often lose effectiveness, maybe even become grossly ineffective and bordering on professional malpractice when used.

Over time, that surgical team approach with the same people working on the same kinds of systems will start to show its age. Unless you hired a bunch of dunces, the junior people and specialists will be growing over time, improving in their capabilities. They will want or need more autonomy. Depending on the complexity of the system and capability of the individuals. This may happen very early or very late (which may mean never in practical terms since people do eventually at least retire or die, especially if you did hire a bunch of dunces). Your processes have to adapt to reflect this.

Similarly, in reverse, a process that overindulges in autonomy may struggle when inundated with new hires (especially very junior professionals) who don't know the system or even the industry well enough to properly exercise that autonomy. You may need to go back to a more structured form.

The relative immaturity of the software industry and also its incredible breadth of domains both serve to exacerbate this problem. People want solutions, they want to be handed a way of working that just works. But it doesn't, generally, exist. It may exist one day, but we aren't there yet. And even if we find The Way for one particular domain, it may not transfer to others.

This is a constant problem with my recent employers. They want to apply practices suited for information system developers and operators to embedded systems. I'm sorry, but Kubernetes is useless to me as an embedded systems developer. That isn't to say it couldn't be used, sure if we could develop a farm of servers connected to devices to run a bunch of tests we could probably use Kubernetes. Or a build farm. Or other similar tasks. But on the system itself, it's useless, and we've got people trying to apply it to our individual devices (fortunately they aren't pushing too hard). And in reverse, I would not use the approach that we take with our embedded systems (a big-design upfront approach) and apply it to most information systems. Their deployment costs approach zero, so they can iterate much more rapidly than we can and should make use of processes that encourage and enable that kind of iteration.

I'm kind of tired of writing, hopefully I've written something clear.