Recently, I reviewed "Agile is dead" by Dave Thomas, one of the authors of the Agile Manifesto, and after a few years of reviewing it again, I still have some new insights because of my different role (from developer to architect).

While the topic is "Agile is dead," a more accurate statement is that Agile has survived in a wrong form. Agile hasn't died; it's merely subsisting.

Back to the root of the problem, Agile is essentially a spirit, a concept, or more precisely, an adjective rather than a noun. Thus, the essence of an Agile development process lies in the development process itself, not in Agile methodologies. The key is not in frameworks like Scrum, Kanban, or various other methodologies but in how to get things done quickly.

With this understanding, we realize that achieving speed in work varies based on organizational structure and existing practices. Therefore, any "general rules" provided by Agile experts or books lack reference value because:

• No rules are universal.
• All rules need context.

There are no one-size-fits-all rules; Agile practices should be adjusted according to the needs of the organization. Agile is not something that can be achieved by hiring a consultant for a short period of time, the key is to find a reasonable direction of evolution by grasping the spirit of Agile.

The conclusion of the entire talk can be summarized as follows:

• Agile is not about what you do.
• Agility is about how you do it.

Translated into concrete steps (not specific processes), it might be the following process:

1. Identify the problem.
2. Review historical experiences.
3. Make small adjustments and observe the results.

In fact, this aligns the familiar DevOps’ The Three Ways.

Additionally, the talk introduces another compelling point, especially given my current role as an architect:

• Don't let the turkeys get you down.
• All experts are turkeys.

When I was a developer before, I used to dislike authoritative figures coming in to give directions and then leaving after stirring up the situation. They were always clean-cut, directing those in the mud from the safety of the shore. Thus, now as an architect, I try to avoid making the same mistake.

Most of the time, I provide a few suggestions and highlight the pros and cons of various solutions based on the context, allowing the engineering team I collaborate with to have a blueprint. But they need to weigh it against their own measurements themselves. Because, in the end, I am also a turkey.

This also echoes the commonly mentioned chicken and pig story in Agile.