Photo by Cristina Gottardi on Unsplash
It's interesting to study and compare Agile scaling frameworks, but it's even more rewarding to try to understand how people think and name things. This is a follow-up on my previous post about scaling Scrum, because scaling Agile and naming things are closely related.
To sell or buy a tool, and to praise (or blame) it, it needs a name. What if the tool doesn't have a name, or it's overloaded with different meanings? How do you package a mindset?
How do you call your team of teams? Release Train, Requirement Area, Tribe, Scrum of Scrums, Nexus, or just Teams that talk with each other regularly, sharing the same Product Backlog? Are you product-led?
Do you call "dependencies" dependencies (you're powerless), or constraints/opportunities (you're empowered)? For the former, the implication is that perhaps the organisation and the way the work is done needs to change. Do you scale Agile to avoid descaling the organisation?
Do you still call people "resources"?
Do you adapt the method to suit your mindset, or do you adapt your mindset to the method?
The language you use matters. Your language reflects your mindset. It reveals how aware and intentional you are about your Agile product development at scale. It reveals how you see other people. And it goes without saying that it affects the outcome you seek.