Today’s Agile Roles Are a Dead End

Jan 23

Last week Capital One Bank laid off all of their Agile roles – about 1100 people by some estimates.

This is actually a trend. It is not just the recent tech layoff: companies are giving up on Agile.

We at Agile 2 Academy are not surprised. In fact, at this moment we are helping one of our clients to merge Agile roles into various management roles.

You might shudder to hear that, especially if you buy into the Agile community bias against managers. But if you accept Google’s model for what good managers are, which lists “Is a good coach” as the very first qualification, then you realize that a separate coach role is redundant. Coaching is just a form of leadership, and leaders are what organizations need.

Organizations need good leaders: people who are effective at creating an environment in which people flourish and do their best. That often requires making decisions, and it also requires coaching, mentoring, and supporting. It requires collaboration, inquisitiveness, and continuous learning. All these things.

Rethink the kinds of leadership that are needed for your existing Agile roles like Agile Coach, Scrum Master, and Product Owner. Make sure to include the kinds of accountability that the roles should have.

Of course not everyone is good at all of those things, but good managers know that. Effective managers recognize good leadership traits in others. It is essential that the organization’s culture – driven by the traits of the people in leadership roles – is such that those leaders recognize other leaders who have those positive traits. Effective organizations empower those who reflect a positive “Constructive” culture. A leader’s main job is to create the culture: the behavioral norms and expectations.

The Agile coach role has long been an anomaly. What kind of job carries no accountability? Agile coaches advise, but they have no power to act. They often lack domain knowledge or deep technical knowledge, although there are exceptions to that. But they usually draw a pretty high salary, and yet they are not on the hook to actually get anything done. That’s not sustainable. It is long overdue that businesses are recognizing that they don’t really need the Agile coach role – because they don’t know what it really gives them.

But they do need good leaders. People who are Agile coaches today should learn more about leadership, and become leaders who understand agility, instead of Agile-role-this and Agile-role-that. They should develop their technical and business knowledge. They should seek product and project manager jobs, and bring to those jobs their insights about how to lead people well, and how to be a transformational leader instead of a pointy-haired boss. And by the way, servant leadership, which is the primary leadership model of the Agile community, is inadequate: servant leadership is only one mode of behavior that an effective leader uses.

What About Other Agile Roles?

A supreme irony is that pivoting away from Agile requires agility.

Roles like Scrum Master and Product Owner will fall by the wayside too, and be replaced by roles like team lead and product lead or product manager. I suspect we will see the business analyst role return in some form, since it was a really important role. Instead of getting rid of that role, we should have modified it to operate in a more concurrent and agile manner.

Agile 2 was created because there is enormous dysfunction within the Agile community, in terms of the models being pushed and the narratives that are accepted. Some correct narratives are,

Phased software development does not usually work well.
Business users often do not know what they want or need.
It is almost impossible to fully design software up front.
Documents alone are not effective for communicating things.
Don’t build something entirely in one go.
Big teams usually do not work well.
Don’t micromanage how developers work.
Don’t trust anything until you see it running.
Build quality in.
More effort != better; automate to avoid effort.
Continuously reflect and improve.

But some widespread incorrect narratives are,

A team must be completely autonomous.
Multiple teams will self-organize.
Most challenges pertain to team behavior.
Teams do not need leaders, except to “remove impediments”.
Written communication is inferior to verbal communication.
Everyone should sit together.
Always trust the team.
Teams can resolve technical issues if leaders merely “get out of the way” and “resolve impediments.”
If Agile does not work at scale, it is the organization’s “fault.”
Practices such as pair programming and TDD are always “best.”
Structure prevents you from having effective collaboration across the organization.

Largely due to being stuck in the incorrect narratives listed above, like a car stuck deep in the mud, the Agile community has failed to provide a usable and scalable set of messages about what it takes to increase an organization’s agility. Agile 2 tries to provide those messages, but the riptide of articles and talks and podcasts that broadcast the incorrect narratives is so strong and relentless, and serves to benefit so many training and consulting companies and the conference and media organizations that they sponsor, that it seems that there is no way for the Agile movement to get unstuck, and so it must fail.

But Organizations Need Agility

But then what? The dilemma is that organizations still need agility – now more than ever. Indeed, a supreme irony is that pivoting away from Agile requires agility.

There is no saying “I don’t need agility”. Organizations do need agility. It is just that the Agile community has not provided good guidance on how to get it.

Agility is a result of behavior, not of process. That is one huge thing that the Agile community got wrong: by embracing process frameworks the movement committed long term suicide. Yes, I know that those who advocate for these frameworks say that they are not processes, but they most certainly are: having predefined roles and “events” make it a process, by definition. And Scrum even tells you that you cannot adjust it in any way. It’s a process that requires you to layer on additional things that it does not specify.

The Agile Manifesto is not a process, but its main flaw is that it is so ambiguous. It contains some short maxims, without explanation. That’s like providing a set of bumper stickers, and saying “That’s your guide”. Sorry, but that won’t work. It has not worked – those who understand the Manifesto’s intentions don’t actually need the Manifesto. That is why Agile 2 contains a much richer narrative that explains each of its ideas, so that people can actually have a chance of interpreting the ideas well, and have some inkling of the tradeoffs that they will need to apply to use the ideas.

So here is what people who run organizations should do:

Don’t look to the established Agile community for answers: their answers did not work.
Forget about the Agile Manifesto: it’s fundamentally broken.
Have people read the Agile 2 book. Yes, really: it is a much richer view of organizational agility. And read it yourself.
Rethink the kinds of leadership that are needed for your existing Agile roles like Agile Coach, Scrum Master, and Product Owner. Make sure to include the kinds of accountability that the roles should have, and remember that “accountable” does not mean “punishable” – accountable means that you know who to talk to about an aspect of the work. Then redefine those roles based on those kinds of leadership and accountability.
Help your people to learn about leadership, especially transformational leadership, and especially with respect to which leadership behaviors impact agility. (There is some information about this here.)
Help your people to learn about behavioral psychology, particularly about how groups of people behave.
Help your people to learn about cognitive science, particularly about how people think, communicate, and create.
Help your people to learn about operations research, which will enable them to reconsider their ideas about Lean and Flow through a much more sophisticated lens.
Find a mentor for each person, particularly people in leadership roles.
Make sure you internalize these changes yourself: lead the way. Walk the talk. Visibly demonstrate the behaviors that you want people to have. Advocate for these changes, and go the distance.

This is a major change, but the result will be that you know what your leaders – including people who formerly had titles like Agile coach – are supposed to be doing, what value they are adding, and how to help them get better at what they do.

Clifford Berg