A Twitter thread asked whether and why “Agile” often seems anti-management. Here, lightly edited, are my thoughts on that. Agile Software Development, as contemplated by the Agile Manifesto, isn’t anti-management. It’s much more radical than that: it’s a quite different approach to management.

Agile Software Development remains a much more radical proposal than is even recognized today, including, rather unfortunately, by most of the branded approaches and, in my somewhat old man shouting at cloud viewpoint, by most of the smaller “Agile” purveyors as well.

Agile Software Development, as we defined it, calls for daily collaboration between “business” and “developers” in the frequent, sustainable creation of working software. It calls for those teams to be self-organizing, and specifically says:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

This principle makes it clear that everything, software, architecture, design … AND REQUIREMENTS … comes from within the team. EMERGES from within the team.

For example, requirements DO NOT come from some business entity, get passed up to a central committee, and then passed down some conventional management or project management hierarchy until it lands on some programmer’s desk.

This is not “anti” management. It doesn’t at all address topics like budgeting efforts, compensating people, assessing performance, or many other “management” concerns.

Rather, it proposes a new and different form of management of the production of software products.

It specifically addresses a new way that software development should be managed, with self-organization and incremental, evolutionary techniques based on the sustainable production of working software.

Is Agile anti-management? I don’t think so. It is definitely anti-tayloristic management, and rather pro-deming management.

And, like all good people, we’re in favor of good productive management and strongly opposed to poor, ineffective, harmful management.

But I want to suggest that the bottom line is this:

If an organization is trying to “manage” Agile Software Development by providing any form of conventional management control over the team’s choice of what do to and how to do it, odds are they’re doing it wrong.

And if you’re an Agile proponent and you’re trying to reach some kind of middle ground or rapprochement with conventional management, odds are that you, too, don’t really understand how radical Agile Software Development is intended to be.

Scrum in this light

Consider the formulation of Scrum, the most popular “Agile” approach if not the most effective. <cough>XP</cough>

Scrum calls for a “self-organizing” team that includes a “Product Owner”, an empowered individual with full authority and responsibility for the return on the larger organization’s investment in the team. And that Scrum Team includes a “Dev Team” of “Scrum Developers”, which must include “all the skills necessary” to deliver the Product Increment, an integrated, tested, working, software element containing all the value produced by the team to date.

Scrum acknowledges that the Scrum Team is embedded, somehow, in an organization that is providing funding (“investment”), and that there are people who care about what the Scrum Team does, “stakeholders”, with whom the Scrum Team meets Every Single Sprint, showing them what is done and inviting and listening to their input. And the next Monday, the Scrum Team, with its fully empowered Product Owner, decides what to do next and how to do it.

The Sprint Review is Scrum’s complete interface between the Scrum Team and the organization it is embedded within.

There are questions left unanswered by Scrum, the same unanswered questions referred to in the Twitter thread above. It doesn’t answer how you budget, how you decide compensation, how you assess performance, and so on.

In Scrum classes, people often ask about various management functions. There’s a classic exercise in response to that, where the class groups write down all the management functions they can think of, on post-it notes. Then they put the notes down in four locations: Dev Team, Product Owner, ScrumMaster, and Other.

Two things happen. First, many conventional management functions go to one or another of the Scrum Team elements. Assigning tasks goes to Dev Team, deciding what to build goes to Product Owner, support and coaching functions go to ScrumMaster, and so on. The interesting bit is that there are always functions left over in the Other pile. Scrum does not even suggest how those might be done: they are outside its concern.

What is clear, however, is that Scrum intends that whatever those outside functions are, their interface with the team is primarily, perhaps only via Sprint review. Specifically, no one other than the Product Owner can ask the team to do anything, which is a pretty specific limit on what “managers” can do while the Scrum Team is in effect.

Is Agile Software Development anti-management?

Agile Software Development calls for a new kind of management, at the scale of teams, with all the authority and responsibility for the product being inside the team, and the primary interface being inspection of the actual evolving product.

That’s not necessarily “anti-management”, but it’s certainly in opposition to certain kinds of management, notably the more invasive forms deriving from Taylorism and probably Fordism, which treat work as more mechanistic and workers as having little authority or agency. It’s far less in opposition to notions like those of Deming and Statistical Process Control, though Agile Software Development surely calls for the application of those notions from inside the team, not from the outside.

But the main notion, I suggest, is quite clear: Agile Software Development calls for a very different approach to management, pushing as much power and authority down to the team as possible. It sets no upper limit on how far that might go, and it sets a rather stringent lower limit, with all the “What” and all the “how” of a product embedded in the team.

What are the limits of these ideas?

That’s hard to say. We see Agile teams with growing ability to decide who is on the team and who is not, and with great influence over compensation and evaluation. We’re beginning to hear of teams who work directly with customers who fund the product, based sometimes on fixed price arrangements, or more commonly on a running rate.

Most of the limits today are imposed by the organizations trying to do “Agile”, and many of those limits seem to me to be rather clearly mistaken. Sometimes the organization doesn’t yet understand strategically how best to manage. I think more commonly, individual management structures are left in place on top of Agile: the various team members “belong” to one manager or another, and that manager continues to try to exercise control over what the team members do.

Frankly, that’s right out, from the viewpoint of empowered self-organizing teams, and it leads to conflict, confusion, and quite often is the primary source of would-be Agile organizations moving toward Dark Agile™

The bottom line, though, is that Agile Software Development calls for a different kind of management, and that it is likely incompatible with some outdated management notions that are, unfortunately, still fairly prevalent today.

Anti? No. Quite different? Yes.