Merge Agile Roles Into Other Roles

This past week a highly experienced software development manager, who had recently transitioned from being an Agile coach, wrote to us in an email (emphasis added),

“There is more to the part about me deciding to change jobs from [Agile coach] "back to" Engineering Manager (that is relevant to Agile 2)...I had fallen into the Agile [point of view] …about hierarchies being bad, ... basically thinking we don't need/ want leadership from "high up" and my observation was they (the [senior] "leaders") don't really know what's going on anyway. So that's one reason I didn't aggressively seek being or really put a lot of value in [senior] leaders (of product/ [software] development). I felt it was close to the dev teams, on the ground where the action was (and it is).

“But...at the same time I was always frustrated too that it seems those [senior] leaders thought they could just outsource/delegate/ assign "being Agile" to some Agile specialists. I felt instead that the direct leaders/ managers personally need to know it and drive it and do it. So, I think Agile 2 helped me reconcile these two points of view and realize that we do need the various types of leadership (from individuals) and I think it should come from those directly responsible/ accountable, i.e., the managers, not relegated to [Agile Coaches] and [Scrum Masters] and [Product Owners].”

Indeed.

People in leadership roles, throughout an organization, need to exhibit behaviors that promote agility. Agility cannot come from compartmentalized “Agile” job roles. It needs to permeate the culture of the organization. Having specific “Agile” roles is antithetical to that.

That means that instead of coaching teams, it is leaders who need coaching and training. It is leaders who need to internalize the behavior that leads to agility – and to effectiveness in general. Leaders create the expectations for how people behave. Leaders create psychological safety – or the lack of it. Leaders establish what is considered acceptable for “how we do things”.

Our examination of companies that are highly agile – agile in a true sense, not in the sense of using so-called “Agile” frameworks – revealed to us that agility is mostly a result of the behavior that is expected of people, and what is considered the norm and “how we do things”. Agility – and in fact effectiveness in general – is not a result of using specific workflows or job roles. Agility is behavioral at its core.

To describe what we were seeing, we created a model of organizational agility, which we ended up calling Constructive Agility, as a nod to “Constructive” culture, as described by the Human Synergistics organizational culture model. A highly simplified depiction of our model is shown in the figure.

We are helping organizations to re-think their leadership roles, and find ways to merge agility directly into those roles. This requires behavioral change and learning. The learning is not “Agile”, however. It pertains to what is known from research about leadership, behavioral psychology, and cognitive science. This is because agility is mostly behavioral, and these fields tell us what the latest research tells us about behavior in a range of contexts.

Agility – and effectiveness – are not completely behavioral, however. Remember, we said “agility is mostly a result of the behavior that is expected of people”. We did not say that agility is 100% behavioral – we said “mostly”. The remainder is still not about workflow processes.

The remainder is knowledge. Agility arises when people react quickly and effectively to changing circumstances, in every sense. That’s behavioral first and foremost; but it also requires that they have the knowledge that they need to solve the problems that the new circumstances present.

The knowledge required depends on the situation; but some areas of knowledge that are pretty generally applicable are “Lean” patterns for organizing work. When people need to quickly change what is being worked on and what is being delivered to customers, they can then draw on their knowledge of those patterns. Lean patterns for organizing and managing work are flexible and adaptable, so when people react in an agile manner, the existing work process do not get in the way: they can be adjusted without too much trouble.

Lean approaches do not create agility: they enable it. Agility is still behavioral.

And that behavior needs to start with people who are in leadership roles.