You cannot understand a team from the outside, and you cannot understand it by looking at one layer of it. I have never managed to assess a team properly without spending real time inside it first.
The teams I work with are usually software or DevOps, so I am reading several things at once and none of them are sufficient alone.
There are the humans. Whether people have energy left, whether they rely on each other, whether the quiet person in the retrospective has always been quiet or has recently gone quiet.
There is the technical picture. Architecture, how the codebase is put together, how testing is done, what technical debt exists and whether any of it is being paid down. The decisions matter less than the reasons behind them, and those are rarely written down anywhere.
Then there is how work arrives and moves. Whether retrospectives produce change or just recur. Whether the backlog is ordered and cared for or simply exists. Whether anyone owns the product properly, or whether requests turn up already shaped in a way that cannot be built well.
These layers explain each other. A codebase tells you about the pressure people were under when they wrote it. A retrospective that raises nothing tells you what the team believes about whether change is possible.
I also have to be honest about my own position. Early on, what I am told reflects how much trust I have earned rather than how things really are, and taking week one answers at face value has led me to the wrong conclusion more than once.
This is why I stopped comparing teams. What moved the needle with one can be the wrong intervention entirely for another, and the only way to tell the difference is to be inside it long enough to see.