Naming Things
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. Naming things and scaling Agile 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.
Originally published at https://www.akikoo.org on September 2, 2022.
