Agile. XP, Scrum, SAFe. Software development methods. Agile software development methods. They all have their trademarks. Processes and artifacts that you should do and produce that will lead you to high performance. Just follow the rules and it will happen for you.
There’s a basic assumption in there that may or may not be correct though. As Tolstoy put it,
All happy (high performing) families (teams) are alike; each unhappy (low performing) family (team) is unhappy (low performing) in it’s own way.
It’s that assumption that drives the methods. All high performing teams are the same, so if you do those things you’ll be a high performing team.
But is that really true? It Depends. It depends on how you look at it. From the outside all the happy families/high performing teams look the same. They get things done. They exceed expectations. Meanwhile, at the other end of the spectrum you might see internal fights, distrust, lack of direction/purpose, sullenness, or just plain anger.
If you look a little deeper though, you might have some different insights. The highest performing teams have figured out what works best for them. The right balance of collaboration, autonomy, agency, and direction. It’s going to be different for every team. Because teams are made up of individuals. And every individual is different. And the combination of those different individuals is even more unique.
On the other hand, many (most? all?) low performing teams have a lot in common. The biggest is that they’re often not a team, but a collection of individuals. Without common purpose and goals. Without a shared vision. So while the specific, outwardly visible signs might be different for each of them, the internal issues that are the root cause of the low performance are the same.
It seems to me that if you want to end up at that high performing state, what it really comes down to is the way the team operates being agile. That means some variation of the “inspect and adapt” principle. Look at what you did. Think about what you want. Adjust things to be closer to what you want.
Not closer to some externally defined process/norm/ideal, but closer to what the team (and the customer) defines as ideal.