It’s not all about the team.
For Agile to work in a large program or a large organization, the cross-team issues are even more important than how well teams function individually. This is a common phenomenon in the world: that relationships between things are even more important than the things.
Teams are not constrained by how much they can learn. They are constrained by how much they are allowed to try, as well as by how much they don’t know what they don’t know.
When Agile adoption struggles in a large organization, it is almost always because managers are in the way—that is, teams are blocked by rules or upper level decisions—as well as because teams don’t know that there are better ways than what they are accustomed to doing. Those are the two predominant kinds of constraint on performance that one tends to see.
Rules exist for a reason: to manage risk. It is therefore unreasonable to expect that managers will just say “Do whatever you think is best”. To say that would be to abdicate their responsibility to manage risk for the organization. Doing that would also lead to chaos: each team would invent its own methods, and so the organization would cease to be one: it would devolve into a collection of tiny tribes.
There is a trend today that I find troubling: non-technical release train engineers, Agile coaches, or others in Agile leadership roles who are non-technical, leading the way for Agile ceremony planning without including technical thought leaders who know the technical side of Agile (which today is CI/CD).
Technical practices are the backbone of Agile. It is the technical practices that make Agile possible. If you don’t center discussions around technical enabling practices, you are wasting your time.
Don’t get me wrong: there are non-technical things about Agile. Things like a Lean Portfolio, retrospective, and backlog grooming. But if you want to improve those processes, you have to include a discussion of the technical enablers that make improvement possible.
