Thread by @mobbsy

It's 2019 and, unbelievably, we still need to talk about Agile.

A couple of conversations in the past week have made me realise that people still don't understand Agile, and are still struggling to apply it.

So, my reductive definition of Agile:

Agile is a risk mitigation approach for building complex systems that attempts to improve the quality of the delivered system by efficiently incorporating new information during system development.

Software developers stumbled across this a couple of decades ago and came up with various heuristic strategies to be Agile.

These have since congealed into a cargo-cult approach to software development that isn't awful but fails to understand why the practices exist.

Systems Engineers and architects still seem to struggle with Agile. This isn't surprising since they've historically had a different set of strategies for mitigating the same risks, and those are deeply embedded in the training and culture of Systems Engineering and architecture.

Agile isn't a project management methodology and metrics (as I've heard some claim), nor is it simply the rituals of two-week sprints, daily stand-ups and user stories.

Agile is about designing efficient cybernetic feedback loops into engineering processes.

The trick isn't to simply import the Software developers' methodology blindly.

Adapt processes, practices and tools to emphasise malleability. Deliver meaningful discrete pieces of work for stakeholder evaluation and ensure you can efficiently incorporate feedback.

Potentially accept some local inefficiency for global efficiency, but don't allow the processes to skew the deliverables.

That is to say, don't feel a need to artificially divide work into artefacts deliverable in two week "sprints" if that doesn't reflect the real needs.

The goal is mitigating risks to system qualities, don't introduce new risks through mindless adoption of fashionable process.

Analyse what needs to be achieved and what changes to processes and practices will help you achieve that and what the implications of those changes are.

Tooling may also need to change. If a change to deliverables takes weeks of manual effort to produce then you can't possibly be Agile.

A model-based approach may help; models are more malleable than documents or structured requirements.

Culture may need to change. All stakeholders need to accept more uncertainty early in the development process. Engineers responsible for delivery need to work out how to deliver value to stakeholders in a manner that allows new information to be determined and fed back quickly.

Metrics may need to change, but with careful accounting for Goodhart's Law.

Measure the behaviour you're trying to incentivise. This critically includes overall efficient delivery of the system and the ability of the delivered system to meet its quality goals.

Make decisions at the "last responsible moment", with the emphasis on "responsible". If you can efficiently defer a decision do so and hope there will be more information later. If you can avoid a decision entirely, even better. Try to make decisions revokable if possible.

If possible, change the core processes to allow deliverables to be what is more Agile. Deliver models rather than documents, structure deliverables to be built iteratively, focus on thin vertical slices through the system rather than large layers across it.

To re-iterate; Agile is an approach to mitigating risks that negatively affect system qualities by efficiently incorporating new information.

Work out how to best achieve those goals in your environment. Examine what works in other environments, but don't cargo-cult into yours.