The first thing to check is that we are not reading the principle too quickly, but actually reading it and absorbing the detail that’s written.
The best
architectures, requirements, and designs
emerge from self-organizing teams
The pace of technological advancement began to accelerate in 1990 and has continued to do so since, but in 1990 conventional wisdom was that production of new products was slow and so experience mattered and seniors guided juniors through their tasks. This made sense when mistakes in a product could not be quickly repaired and so risks had to be managed. The most influential convention was with seniority came expertise, whereas today technology comes and goes in a matter of years.
Recognition of the multiverse of disciplines required to deliver software, this principle isn’t saying it’s the only way, just that it is the best, it also recognises that a discipline need not be a role, but can be a function of a team. Most of all this principle promotes the need for these disciplines to manage themselves and this requires peer-to-peer communication, not management command.
Intent-based leadership and iterative processes, visualisation that allows team members to pull outcomes, along with rituals and ceremonies for self-management are central to the implementation of this principle. However, the most impactful change is the establishment of small cross-functional teams and team metrics.
Scrum provides a framework that is popular due to its success but can still be implemented badly and when this is so you might see,
Workflow on Kanban boards to manage work from person to person.
Mini waterfall with function per sprint
Team members committed only a % of time
Any reliance on skills outside the team
Management, and the push of tasks by a leader
Scrum is the best framework when implemented well, when it’s not then it’s neither Agile or worth not doing waterfall.