Agile is Not Communism

Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I’m looking for help on this!

I have Googled “agile communism” and come up with some interesting reading:

Does Scrum/XP Violate the Agile Manifesto?
The Agile Method and Other Fairy Tales: QED

I have also done some quick research on communism to check that I understand the comparison and objection. Here is a wiktionary definition of communism:

1. A term used to refer to a number of political philosophies or ideologies which share the belief in the virtue of holding the production resources collectively.
2. A society organized in line with the communist theories, the ultimate aim of which is the abolition of the state and the creation of a classless, stateless society whose members produce according to their abilities and take what they need.

So let’s start with that definition.

Holding Production Resources Collectively
Also called: common ownership of the means of production

I suppose there are a few ways to look at this. In an agile environment which encourages (for example) collective code ownership, it might seem like holding the production resources collectively. However, the code is actually the result of production, rather than the Means of Production. This distinction is not trivial. The means of production for a team in an agile environment still include both the tools and the raw materials upon which those tools exercise. In software development (and in most creative work nowadays), the tools are computers and software and other electronic gadgets such as video cameras, telecom systems, etc. The raw materials are typically intellectual constructs such as images, sounds, ideas, processes (and of course their legal counterparts such as trademarks, copyrights, and patents). Agile methods do not require the team of workers to own these means, nor do agile methods forbid workers from owning these means. In fact, There is one important way in which agile methods are decidedly not communist: every individual owns their own creativity, experience, and knowledge and is only asked to share willingly (and usually in exchange for pay such as salary, stock options or outright corporate ownership). I believe this passage clarifies things nicely:

Marxists define economic systems in terms of how the means of production are used, and which social class controls them. Thus, in capitalism, the means of production are controlled by the bourgeoisie, (the “capitalists” – the owners of capital), while in socialism they are controlled by the people’s elected representatives and in communism they are controlled collectively by the people themselves. [Means of Production]

Agile methods, if anything, tend towards capitalism in this regard. (Although a whole other question could be asked about just how much control the owners of a corporation really have given delegated authority through the board of directors to the chief executive staff _and_ the abrogated authority through mutual funds, pension funds, holding companies, and trusts _and_ the limitations on that control through the blunt instrument of voting shares _and_ the influences on that control through the control of information by financial analysts and the media…)

Ultimate Aim of The Creation of a Classless, Stateless Society

Well, this certainly isn’t the aim of agile methods that I am aware of. The aims of agile methods as I understand them includes:

• Building stuff that stakeholders like
• Creating an environment for team members to exercise their creativity
• Doing all this in a way that responds well to pervasive frequent change

Again, I can understand why there might be some confusion here. Agile methods promote these three aims by doing something that looks just a little like a classless organizational structure. Typically, agile (and lean) environments start to have a higher manager to staff ratio (fewer managers), encourage self-organizing, cross-functional teams, and emphasize team goal setting, commitment and accountability. This might seem classless (and stateless/managementless) until one examines what is not said: Agile does not claim that every team member is exactly equal, it does not require that every team member do exactly the same thing, it does not require that every team member give up _all_ their individual preferences (although certainly it would be hard for someone who didn’t like talking to other people to be part of an agile team… so I guess some individual preferences won’t work in an agile team), it does not encourage every team member to do exactly the same amount of work regardless of if you are measuring effort or output.

Now admittedly, when I am presenting examples of self-organizing teams, I do sometimes use examples that come close to classless stateless teams… but that’s just to show that this is a possibility and allowable in an agile environment, not that it is the only way.

Those practices in agile methods that do seem like classlessness and statelessness are not aims… they are means. A self-organizing, self-managing team, is means to an end. It is not an aim in itself. Why does this matter? For the simple reason that it is always bad to confuse means and ends. The end cannot justify the means (classlessness and statelessness imposed by revolution)… and nor can the means justify the ends (classlessness and statelessness that results in apathy, boredom and low productivity). So the fact that self-organization is a means is a way for us to decide if it is worthwhile. The evidence for self-organizing teams in a business context is strong (lots of links and articles and books on this blog as well as others). Most team members enjoy being self-directed in a way that is collaborative with other professionals. So both the ends are good – productivity – and the means are good – happy people.

Members Produce According to Their Abilities and Take What They Need

To me, “produce according to their abilities” sounds a lot like a tautology. Certainly, team members can produce no more than their abilities! From an agile perspective, this isn’t even what we are interested in… we are interested in the multiplicative effect of teams of people working together effectively so that the result of the work is greater than the sum of the individual abilities. There is now substantial evidence that this is not just possible, but a likely outcome of group work (see Research on Group Effectiveness vs Individuals among many others). My favorite phrase for this is “Unity in Diversity” which describes a group of people who have united around a common goal, but with each individual having talents, experiences, knowledge, patterns of behavior, and insights that are all different from each other.

The second part of the phrase “take what they need” is another piece of this pie that has absolutely no relationship to agile methods. Again, there is evidence that this is specifically not supported. Lean methods encourage compensation that is based on a number of things including: contribution to results in one’s sphere of influence (rather than the more limited sphere of responsibility) and the number of skills you have mastered and use to contribute to the work.

Disconnecting reward from results is an obvious problem. While people do have altruistic feelings, we also are clearly motivated by praise

Some Similarities One of the attendees of the course, a woman by the name of Christina, provided me with some notes based on her understanding of Agile and Communism and she listed these similarities:

• They both rely on participation, rather than executing orders.
• One aim is less frustration.
• They use some similar phrases such as multidisciplinary / cross-functional.
• They both ask people to evaluate each other.

And What about Reality?

Well, I haven’t lived in a communist environment so I admit that my ability to talk intelligently about this is not what I would like it to be. I am interested in people out there who might be able to help me with this.

Here are some questions for people who have actually experienced communism:

• What are the actual, in-practice similarities between agile and communism?
• What are the in-practice differences between agile and communism?
• Why did communism fail and how might this affect the success of agile methods?
• How can we safeguard agile from falling into the same problems?

Can anyone out there help please?