When organizations try to improve, scale Agile, or scale the organization itself, the first question is often:
“What should we implement?”
A framework. A scaling model. A transformation roadmap. Something documented, repeatable, and widely recognized.
For decision-makers, these provide reassurance.
For organizations under pressure, they promise speed.
For managers who value predictability and control, they promise exactly that.
For everyone involved, they create a sense of progress, success, and possibility.
Unfortunately, implementation-first thinking is also one of the most common reasons improvement efforts fail.
Defined in sociology originally, roles have been used in organizations large and small. The term role in sociology describes a set of expected behaviours and obligations associated with a particular position. For instance, I may play the role of a wife, a mother, a trainer, a coach, a daughter, a friend, a customer, etc. Each comes with a set of expectations and obligations as you can see.
Roles not only lay out a blueprint to guide behaviour, but they also delineate the goals to pursue, tasks to carry out, and how to perform for a particular scenario. In addition to guiding behaviours, roles also influence our beliefs as the theory holds that people will change their attitudes to be in line with their roles. One example can be people changes their views on parenting once they become parents.
There are a few changes people may face with roles.
Organizational improvement of any kind is deeply contextual. Agile, by nature, is contextual. Scaling, whether of teams, products, or decision-making, is contextual as well.
Yet many scaling initiatives treat improvement as a mechanical rollout. Teams are reorganized. Roles are renamed. Ceremonies are added. Metrics are introduced.
All of this often happens before a more fundamental question is asked:
What problem are we actually trying to solve?
Organizations differ in product complexity, technical architecture, market dynamics, leadership maturity, and culture. Scaling Agile without acknowledging these differences assumes improvement is predictable and uniform. In practice, it rarely is.
Implementation-first scaling produces familiar symptoms:
Agile practices exist, but decision-making remains slow
Teams attend ceremonies, yet dependencies persist
Metrics improve, but customer outcomes do not
Leaders believe Agile is in place, while teams feel constrained
At first, progress appears visible. Structures exist. Language spreads. Training is complete. Over time, however, friction grows as people adapt the system just to get work done.
Eventually, leadership is forced to confront problems created by the scaling initiative itself.
This is not a failure of Agile. It is a leadership challenge.
When leaders focus on what to implement rather than why it’s needed, they unintentionally optimize for compliance instead of learning. Scaling becomes something done to teams, rather than something built with them.
Effective Agile scaling requires resisting the urge to “install” solutions. It demands investing time in understanding constraints, bottlenecks, decision-making patterns, and human behavior.
In the next post, we’ll explore how working with patterns, rather than implementations, offers a more effective way to scale Agile without losing context.
Or you can join our upcoming Certified Agile Scaling Practitioner (CASP) program, where we will explore context specific organizational improvements, from scaling, to organizational assessment, from scaling to descaling, and more.
