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, telecomm 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 SimilaritiesOne 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?

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

14 thoughts on “Agile is Not Communism”

  1. Even if you would consider that Communism and Agile share similar values, failure of one doesn’t necessarily imply failure of the other…
    I would actually start with debating that communism as a philosophy hasn’t failed, but large scale implementations have. The failures I immediately think of – not through experience though – suffered from continuously decreasing quality as a result of competitive capitalist behaviour (not sharing fundamental communist values). Similarly, agile adoption will not likely be successful for teams not sharing fundamental agile values, such as delivering high quality products and services.
    So does that imply that large scale agile adoption cannot be successful? I don’t think so. Citizenship leaves you with few choices on which political system to live in. Companies however might provide you with a few options, maybe even mixing both agile and other approaches. So instead of forcing a single process onto all employees, individual ‘preferences’ can be taken into account in the team, department, even in the company. After all… we value people and interactions over processes and tools…

  2. I come from Poland and thus have had first hand experience of communism, I also work in an Agile environment now. I may sound a little bit cynical here, but I don’t think there is any way in which you can even attempt to compare agile and communism – that is – the true and real communism as people experienced it behind the Iron Curtain not the idealistic concept. Communism undignified people, undermined trust and had no respect for individual. Agile is based on trust, value the individual, teamwork and commitment.
    I can however see how people can think of agile to be communism like – but they mistake collective ownership (i.e. no-one owns it) to collaborative ownership (i.e. we all have responsibility).

  3. I do agree with Floryan from Poland. I think it is very important to distinguish between ideal marxism and communism practiced in Eastern Europe and elsewhere. I am a son of a previous leader of the communist party in my country, been part marxist youth movements, hold a mastersdegree from a leading elite business school and now consult large corporations in lean transformations.
    I believe the key here is the definition of communism and marxism which is difficult to do because this is filled with lots of stereotypes and political gaming. (remember Marx himself said he was no communist, and rejected the whole idea of revolutions in Russia)
    The key question here in my view here is ownership of capital (means of production). Usually in a communist state that is the state (and without democracy) To many that the state owns all means of production is a perversion, and they call it state capitalism. Some do agree in the state as the owner but see the lack of democracy as the perversion. In Marx terms it was the workers that should be the owners and the state is not in the equation. (the central planning is not in there at all)
    In your link to the “means of production”, it discusses this briefly at the end. Here is a the quote:
    “Thus, in capitalism, the means of production are controlled by the bourgeoisie, (the “capitalists” – the owners of capital). In the pure ideal of socialism, such as that “communism” was/is supposed to be, the MoP are controlled by the workers production collectives directly. In fact this situation has only been historically realized temporarily such as in the Israeli kibbutz or the early Soviets before the entrenchment of the communist party as a “New Class”, or in isolated or preliminary form such as in the final phase of the Second Spanish Republic, or various experimental utopian communities.”

    In the end of the quote the author quckly brushes of the whole idea about worker ownership as something that belongs in utopian communities. Well, then I work in one of those utopian communities. In our consultancy company we all own a part of the company, like many thousands of others in this field of work. That goes for many in the software industry as well. There are also others very successful companies like mondragon of Spain and Semco in Brazil. Many of them are high performing companies. In fact, when I facilitated a leadership workshop for a large international metals comapny, the CEO said that he wanted his workers to behave and think like they owned the comapny. His assumptions was that as owners they would make better decision and perform better. (I think that when the other brushes it off like he or she does, reflects either bias or lack of reflection/ knowledge.)
    I do know if a workers ownership principles would work on a national or mulitnational scale. I know however, that it works in many companies. If that is communism, really depends on how you define it. That is why I think you need to carefully define communism/ marxism (without bias) before you can answer your questions.
    Your question about why communism failed, is matter of controversy, and to most people, it could not ever succeed. Here is what I believe:
    communism failed because it removed all sense of responsibility. When the state owns it, nobody does and you get something called “the tragedy of the commons” It became a dehumanising ideology. In addition to becoming a state owned system, they also got stuck with central planning. Central planning was the fad of the early 20th century all over Europe and that became a central tenet of the Soviet system. Many believed central planning to be more efficient and we see the reminiscient of that in many large mulitnational companies of today(Many of them even operate with 5 year plans.) and are probably equally bureaucratic. Central planning, state (no) ownership, complete corruption and dictatorship sounds like a complete disaster to me. If these are the root causes, I am not sure. Some people just argue that a) marxism is an evil ideology or b) marxism is utopian because people are inherently selfish. (I leave this for a later discussion while currently reading a book about the evolution of the moral mind)
    How we can make sure that this does not happen to the agile community?
    First of all, the means of production in software development lays in the the creative ability of the people. It will be difficult to centralise the ownership of the minds. However, it could happen by some strange patent or copyright laws. (example: we have taught you how to program in this environment and you are not allowed to practice those skills outside the company – or something similar)
    Second, we need to make sure that a system do not evolve into a dictatorship and that there are true feedback mechanisms in place to correct that. (If a product manager stops listening to the programmers or the customers)
    Thirdly, I am not sure if agile constitute a system of central planning. It is certainly much more flexible. However, the product manager decides what to do, which in a sense could constitute central planning. However, in our society, the product has to stand the test of the market, and if they do not make the right decisions they will be out of a job. And if they do not trust the programmers, they will deliver poorly and inefficient. Hopefully, the company will see this and take action. However, in both cases you rely on well functioning feedback mechanisms.
    In all, agile needs to make sure that it does not evolve into the perverted form of marxism (which I do not think it will) If agile is the ideal form of marxism depends on the definition of both terms. However, at any rate that would be a hard sell, and would probably alienate a lot of people to agile.

  4. Please note that, by this logic, a party is impossible.

    At a party, we bring food or drink according to our ability, and eat and drink according to our needs… JUST LIKE COMMUNISM.

    The activities of the party are determined collectively by the partygoers… JUST LIKE COMMUNISM.

    To prevent parties from failing… JUST LIKE COMMUNISM, we must reorganize them along more capitalistic lines. I recommend that, from now on, all parties should forgo free food and drink in favor of vending machines and several competing cash bars. Only the highest bidders will have the right to offer people fun things to do. Partygoers who fail to meet the two-drink minimum will be deemed loiterers, troublemakers, and impediments to commerce, and will be thrown out immediately by a private security service.

  5. I could be communism because, you can have a junior programmer working back to back with a senior one, and they’re the same for SCRUM, for example. But, the payroll is so much different.
    That’s the “feeling” about communism. Another example, could be when someone has been working for years in a project, and a new developer is entering, and he has the same rights. This could be unconfortable for people who has been working for a lot of time, if the new one, starts talking, giving opinions or critics and doing things that are reserved for the old-ones, who had already demostrated their abilities.
    Maybe, it could be avoided with a rank. That rank, could led to have a distinction, like they were stocks of a company.

  6. It is communistic in it’s spirit. At least Scrum is. In the old methodologies (spiral, iterative, etc) developers would have a manager, and that manager would ensure that every developer was producing. It was clear, who did what on the project, and people were accountable for their actions. With Agile Scrum the team gets a pile of work in a sprint. Some people can do more work, and some can do less work. Nobody can really get promoted anymore though, because designations don’t matter, we are all team members. So why would anyone work harder than anyone else? Why not just do the bare minimum possible? That’s what happens, the people who start out working hard see others who are just doing the minimum and get essentially the same reward, so they taper off and stop working hard. Productivity grinds to a halt and the whole organization starts to fail, as ours is.

    What makes it even worse is that in our organization, dissenters are thrown out of the company, because management is drinking the coolaid that agile will solve all problems. They have also hired people who have staked their entire careers on Agile. Because of that, they would never question the methodology itself. They are looking for a reason to explain lost efficiency, but wouldn’t you know it, they can’t seem to find it.

    As someone above stated a young team member with 3 years experience who has a loud mouth can sway the decision of the team as much as a 10 year veteran. (And this is BAD for the company, because they don’t know what they are talking about.) A good example for this is story sizing. Stories are routinely sized at 1/3 of the time it actually takes to complete them. Yet nothing changes.

    Don’t question. Just do. It is agile.

    1. Hi “someguy”.

      I’m sorry to hear about your bad experience. This is not unusual. Actually, as an Agile Coach and consultant, this is one of the things that I warn people about and see in many organizations that have tried to do Agile without proper support… which is hard to find. One of the fundamental principles of working with people is Truthfulness. Anything that blocks this is going to be bad in the long term. Agile and Scrum should never become a prejudice or a barrier to seeing the truth and trying to learn from it and get better. I certainly have seen companies, even some that I have consulted with in the past, who have gone down this negative path. Like with anything, becoming fanatical is dangerous.

      In Scrum, there are supposed to be things that protect against this a little bit, but frankly, one of the reasons that Scrum works is _because_ it doesn’t have lots of checks and balances and almost no individual accountability (except the Product Owner). This lightness is meant to empower people, but there are many things in an organization’s culture or in people’s behaviour that can subvert that lack of checks and balances.

      I’m not sure if I can help, but feel free to contact me directly if you want to chat. I may be able to give some practical advice to change things for the better. My email address is

      Thanks for your candour.


    2. > … the people who start out working hard see others who are
      > just doing the minimum and get essentially the same reward…

      This is overwhelmingly my experience with a traditional command-and control environment since managers don’t really know what is happening. Scrum makes this all visible and things like peer pressure get everyone working well together. Scrum often doesn’t work but I have experienced it and the rewards are much better (sense of achievement, team spirit, team bonus).

    3. Indeed. The fundamental challenge that we even perceive that some people work “harder” than others is a pretty big challenge. The transparency of Scrum can help, but ultimately Agile methods depend on people’s positive intent and willingness to recognize that positive intent in others. If you work with a team or in a corporate culture where people just aren’t willing to perceive positive intent in others, then it’s going to be extremely difficult to may Scrum work. Much as I don’t like it, command and control sometimes has to come in to help correct extreme misbehaviour. As one philosopher put it, we must demonstrate justice towards lying, thieving, and tyranny, but all other types of problems should be approached with mercy and compassion.

  7. You missed the whole point of the comparation between communism and agile. The point was that just as in communism it was more important to look like you were doing hard work instead of actually doing it, in a similar way Agile encourages looking busy. Because of its tendency to atomize everything it encourages work but not necessary meaningful one. And the point system makes things more about the points than the final product.Basically it does not matter if your code will need fixing, patching or even removing in the next sprints as long as you commit it. The main problem is the idea of sprint. Agile and especially Scrum Agile has the false belief that there is something called “sustainable sprint” . But if they took the time to see one discovery or nature tv show beginning to end they will see this simply is not true. A cheetah may be the fastest mammal but he cannot maintain it more than 5-10 minutes, it consumes a lot more resources than most mammals and spent most of the day/night cycle sleeping or resting. Agile is against common sense even in its extremely vague manifesto. What brings people together in a project is less common beliefs and ideas and more a common goal. You may have hindu , christians , “christians”, jews and many other categories who definitely do not share a lot of common beliefs working together for a common goal.

  8. This is fascinating. And I thank everyone deeply for their contribution to the debate. I am fortunate enough to work in a multinational corporation that embraces principles that align with my own relative to social justice, contribution to community and outreach. Agile and lean are intrinsic to our development culture in that we embrace the notion of an anti-fragile culture. One that encourages innovation and contribution by the individual and recognizes that value in the spirit of contribution to the whole. A Marxist tenet when viewed in light of the intent to be of service, which in the context of the company reflects the intention of the ideology of the corporation as a whole. We too practice a generous ESPP enabling ownership and also vesting employees. We also offer generous benefits. PTOn give developers the chance to innovate on the clock, VTO to volunteer on to clock. The company mandates equal pay for all job bands regardless of race, ages and genders, not common in the US, surprisingly. And as head of IT methods and practices I can tell you that with 15 years of product management experience specifically in agile…you can scale it to global IT organizations. But only if you have a compassionate, open and relatively, yes, classless, culture. But…there remains this issue of centralized top down planning. And therein lies the issue. Capitalist or communist. Centralized top down planning denies the collective value of operational insight during the execution of complex interconnected programs delivered with substantial interdependencies globally by self organizing teams. And that is why. Even though I manage planning tools and processes for 150m budgets and 750 staff. for a 10bn Silicon Valley success story…What was and is, so alluring about Marxist ideologies, is praxis. The common and shared goal achieved through concensus. Although I find more of value in the ideas of syndicalism relative to agile than of communism, I do think that there is a wellspring of theory and practice from European Marxist thinking that Is inspirational when related to agile lean practice at scale . I just finished reading “rythmanalysis” by Henri Lefebvre, the French philosopher. His thoughts on how dialectical thinking fails us when we consider temporality, is a critique of Marxist thinking, and informs my thinking about how cycles of governance, management, operations, engagement, development percuss. What I love about agile in this context is how we can take those values and through this optic of time, expand and scale them. We align around estimations through consensus of approximate and relative values. We do so iteratively and we communicate and engage through our artifacts, which include knowledge and working software. Well, our value, is that we align around values – we establish and adapt and continually improve (arguably) controlling the ‘modality’ of production and we can granuarly shift and adapt those values should the work change or the work should the values change. Isn’t that the ideal way of planning at scale…now I’m off to build something wonderful. Because there is at the heart of Marxism one truth that Agile shares – there is no theory without practice and there is no practice without theory!

Leave a Reply

Your email address will not be published. Required fields are marked *