The Agile Manifesto turns 20: what's next?
The Agile Manifesto is twenty years old. It feels like agility has been around for an eternity, which is certainly also due to the fact that teams have been practicing agility for much longer. Twenty years ago, the child was simply given a name and systematized, which has dramatically raised the profile of agility. Of course, not all teams practice agility. And not everything that someone calls "agile" is agile.
But I find the question much more exciting: are we "through" with agile? And if so, what comes next?
On our own behalf: This week sees the launch of my new section in the HOOD Group blog: SEcKI - Systems Engineering with Artificial Intelligence. New SEcKI articles will be published every three months. Read the first article SEcKI: Why Systems Engineers should get involved with Artificial Intelligence now >>
The Agile Manifesto
The introduction of software into product development is a matter of urgency, agile to work, drastically intensified. In the classic development process have been working with iterations for a long time. However, since hardware could not be changed so quickly (at least at that time), a comparatively long cycle for the iterations was acceptable.
The problem in the time before the Agile Manifesto, however, was that managers were looking for the solution to their problems in the wrong place. This is exactly what the Agile Manifesto is about: correcting the wrong course. Until then, managers tried to solve challenges with processes, documentation, contracts and plans. The hope of managers was that more of the same would eventually lead to a breakthrough.
Publishing the Agile Manifesto was like pulling the emergency brake: "We're on the wrong track".
It worked, and from this point of view, the Agile Manifesto is a complete success. The manifesto is criticized in many aspects, sometimes rightly so. However, this has to do with the fact that the Agile Manifesto was conceived as a provocative quatrain to point out a major problem. The authors did not see it as something new and revolutionary. Instead, it was intended to signal: "Back to the roots".
The agile transformation continues
The transformation to agile values, to put it this way, is still a long way off. After all, agility is a mindset that is needed wherever there is a high level of complexity. Traditional approaches have always worked well where complexity is manageable - and still work well there. This is why complexity is the driver for agility: complexity of products, processes, organizations and much more. Agility gives experts the freedom to solve problems as they see fit.
The agile transformation is far from over and began long before the Agile Manifesto.
The Agile Manifesto is not true!
Since the Agile Manifesto was an emergency brake, the authors also exaggerated its wording. What's more, some people misread it - both intentionally and unintentionally. The classic is to use the manifesto as an excuse not to write any documentation at all. Of course we need documentation, but it must not become an end in itself.
The same applies to tools. Modern products can no longer be developed without tools. However, I myself remember the time at the end of the nineties when many tools were overly complicated, which meant that their added value quickly disappeared into thin air.
The future: tools, modeling and traceability
I would venture the following hypothesis for the future: the transformation to agility will be with us for a long time to come. However, the Agile Manifesto is no longer valid in its current form because it was a child of its time.
In order to be able to implement agility for modern products, we absolutely need models. But models contain (among other things) a large amount of documentation. If modeling is practiced correctly, documentation, for example, can be generated directly from the model. Furthermore, the model is a form of documentation for all stakeholders. A model gives us the opportunity to generate the appropriate view for each stakeholder, which makes the model all the more useful as living documentation. Used correctly it is of course much more.
A model is also essential for mastering complexity, as the meaning and relationship of the model elements to each other is clearly defined. Even today, we already have clearly defined relationships, such as those provided by every requirements management tool. However, the meaning of the model elements is not clear here; they are simply blocks of text that can contain anything.
The content of requirement texts cannot easily be processed by machines. One solution to this problem is the automatic processing of written language with AI, such as I am currently doing with my development Semiant pursue.
Semiant - Virtual Quality Assistant
Another problem today is traceability. Many tools support traceability in a clearly defined area. For example, a platform such as gitHub enables traceability between user stories, code commits and issues. But a Cross-tool traceability is still difficult to realize.
Both challenges - modeling and traceability - can only be mastered with the appropriate tools.
