Yesterday, Dean Leffingwell innocently linked to an note about an InfoQ article by Em Campbell-Pretty, in which she talks about issues with middle management and Agile. As you can see in the note, Dean talks about his Leading SAFe course, which I have not taken but suspect is pretty good.

The tweets included one from Jon Terry, saying “Yep. The pseudo-anarchist, anti-management strain within Agile had really become counterproductive by now.” I suspect he meant “has”, not “had” but am not sure. I replied:

“What if, all too often, middle management really is redundant and counter-productive?”

Jon replied:

“Firms of any scale are going to have hierarchy. If you want real change you must reckon with that.”

The chain went on: do read it. Here’s what I was thinking and talking about.

Hierarchy and management are part of the problem

As Dean points out in his note, and as Jon was apparently trying to get at, hierarchy and management are matters of great concern, especially when trying to do Agile “at scale”. The questions of importance are what one does about those matters, and, of course, how one goes about it.

Agile is about self-organization. A glance at the Agile Manifesto reminds us about individuals and interactions, collaboration, business people and developers working together daily, trust motivated individuals to get the job done, face-to-face conversation, self-organizing teams, teams reflecting, tuning, adjusting on their own.

Hierarchy is largely about authority and control. Management, often, is about telling people what to do and how to do it. These structures, often, work counter to the self-organization that is central to Agile.

Now as people in the thread pointed out, companies have management and that needs to be reckoned with. Training might help: it sometimes does. And there are many ways of trying to help.

I do not favor “scaling” Agile

Let me be up front here. I think that the present efforts at “scaling” Agile are mistaken, in the important sense that they will not result in large organizations becoming Agile in any real sense.

They may offer improvement: almost any application of sensible practice will improve a large organization. They are filled with inefficiencies; they are organized poorly for getting work done; their people are doing the wrong things with the wrong teams and the wrong tools. You can’t throw a stick without hitting something which, if improved, will make things a bit better.

Both SAFe, Dean’s offering, and Kanban, which Jon probably supports, being a LeanKit proponent and all, offer improvement. SAFe, I’d say, puts a product development structure in place that will smooth the development of products and almost certainly improve things. Kanban usually takes a more local approach to improvement, but looks at many of the same topics, and focuses on smoothing out the work. It, too, will likely result in improvement wherever it’s used at all wisely.

SAFe, Kanban, and other approaches can be useful. But if you take the view that Agile is at its core about self-organization, hierarchy and management are core issues, and neither SAFe nor Kanban address those as directly as they might.

There’s good reason for that. If you take the viewpoint that most of your management structure needs to be replaced, as some LeSS proponents seem to, you’re going to meet a lot of resistance. If your mission is to sell a lot of SAFe or Kanban, or even just to help a lot of people a little bit, you might wisely choose not to go directly up against the hierarchy.

This isn’t particularly venal or cynical. It isn’t bad business. It’s a perfectly sensible way to do business and it can help the client. Some of the people who work that way will tell you they’re playing the long game, get in there, and over time do dah do dah. I buy that it’s a sensible and honorable way to do business. I don’t buy the “over time” article, because the people doing this generally do not exhibit an understanding that hierarchical management is a big part of the problem, and generally do not do much, if anything, to replace it.

Of course, if you were taking a stealthy approach to dismantling hierarchic management you might not mention it. So maybe … but I don’t think so.

Hierarchy and management need to be replaced

Training the hierarchy, training the managers, is good stuff. It will help. But the management hierarchy was designed to control, to manage, to avoid change. The management structure of a company is there to preserve the company, and in so doing, it acts to preserve itself. And, unfortunately, the thing it’s preserving is a thing that needs to be changed, very substantially.

There is an exercise that people do in Scrum classes and similar activities, when the question of management comes up. It goes like this:

  1. Brainstorm a list of things management does, putting them on sticky notes. Hiring, firing, deciding what to do, and so on. The more finely they are broken down, the better. Break down hiring into getting names of people to look at, deciding who to hire, setting pay, authorizing the hire, and so on.

  2. Make columns for Product Owner, Whole Team, Dev Team, ScrumMaster, Other. Discuss the sticky note items and place them in the column where Scrum would put them.

The results of this are always quite interesting and enlightening. Many of the things managers do move somewhere else. The Product Owner tells the team what needs to be done, not the manager. The team decides how to do it, not the team lead or technical manager. The teams often do all the interviewing and deciding who to hire. Pay is set differently, not so much by management whim. The ScrumMaster helps coordinate with other teams, not the manager. The teams build up “Scrum of Scrum” structures for coordination. Cross-functional teams reduce the need for inter-team coordination.

There do turn out to be sticky notes that don’t fall into the PO/SM/team headings, but they are surprisingly few and quite interesting to think about. How might we do those things differently? Do we need a management hierarchy to do them?

Example: Hiring and firing

Let’s muse a bit about hiring and firing, which are pretty good examples of things that are rarely if ever delegated to teams. Hiring and firing require coordination, policy, a broad view across the organization with an eye to fairness and legal concerns. Therefore: hierarchical management?

Not necessarily. If teams are the core important element in our product development, then we want to have team makeup in the hands of the teams. And we want consistency, legality, and so on. So why can’t we have a “Scrum of Scrums” kind of team, a thing that would be called a committee in conventional thinking, made up of delegates from real teams, working up the policies and practices around hiring and firing.

Such a team has to be cross-functional: it has to have all the skills required to build its product. That means it has to have personnel expertise and legal expertise. Great, give that team a lawyer and an HR expert, to be team members, not bosses or managers. Let them work out what has to be done.

Who is the “Product owner” for such a team? I don’t know. Whoever they are, they decide what has to be done, and the team works out how.

We have to have hiring practices that are non-discriminatory: work out how we’re going to do that. We have to pay people in equivalent jobs equivalently: work out how we’re going to do that. And so on.

We can work all those things out. The problem is, it leads to …


That kind of thinking is what Agile is all about, in my somewhat experienced opinion. And that kind of thinking is very threatening to the established hierarchy. The way you make a lot of money in a company is to work your way up the hierarchy. The end result of that is that you can make ten or a hundred percent, or ten or a hundred times more money than the people who are actually doing the work, because your job is “so important”.

Thus we hear people shouting about “anarchy”, or “anti-management” or the like. These crazy ideas like Holacracy, these crazy companies like Semco or Zappos, they can’t work. Well, many of them won’t work. Some of them will.

But if you believe what we wrote in the Manifesto, all that individuals and interactions and self-organizing stuff, then you need to be working on alternatives to the conventional hierarchical approach to management.

That’s scary, and it might not be good for your business. Much SAFer to sell something that people will buy – that the existing management hierarchy will buy – and give them some good ideas and hope to do some good.

That’s OK. It really is OK. It’s good for everyone, because the ideas in things like SAFe and Kanban are good ideas, and they’re useful, and they’re going to help. These are good and honest and helpful people and organizations. More power to them.

They’re just not as Agile as they might be. Me, I’d rather they didn’t use the word if they weren’t going to support the ideals, but that ship sailed long ago.