Oppression, Revolution and the Future of Scrum — #2

Oppression: The unjustifiable placing of a burden on someone or some group, by interfering with their powers, interests, or opportunities. Oppression may be deliberate, or an unintended outcome of social arrangements; it may be recognized for what it is, or may go unremarked even by those oppressed. — The Oxford Dictionary of Philosophy © 1994, 1996, 2005

We tend to think of oppression only in its deliberate form, when used as a weapon to subdue the conquered or to quell the sense of unrest and the spirit of uprising in the lower classes, but oppression exists in many forms, and does not only affect poor, underprivileged people. We can observe many levels of oppression in large organizations today, amongst middle class, well paid professionals.

As an example, consider cubicle culture, so ingrained in our idea of how people work in the software industry — yes still, even after 10+ years of Agile.  Isolating someone in a cubicle is an act of control, a way of ensuring compliance.  Prisons throughout the world use the concept of solitary confinement as a form of punishment — some would say punishment bordering on the ‘cruel and unusual’, or even torture: it is so deeply unnatural for people to be isolated from one another.  One’s imagination does not have to be stretched far to see the similarities between a corporate cubicle and a one-man prison cell.  Without the support of their fellows an individual is more vulnerable to suggestion, and more likely to tow the line.  Is this the deliberate intention of a cube farm?  Possibly not, but it is the outcome.

But it goes far beyond office layouts.  Games of power are played out daily — often with great zest within the upper echelons, but with ever-dwindling willingness as we move down towards the grass roots of an organization. The oppression that takes place is sometimes conscious, but more often is “an unintended outcome of social arrangements”, and manifests itself in the phrase “it’s just the way we do things around here”.

Such oppression is usually hidden beneath the niceties of corporate behavior, beneath so-called socially acceptable norms.  At its most insidious it hides beneath a facade of ‘fun’, ‘teamwork’, ‘community spirit’ and other such fashionable buzzwords.  In the oppressed people it takes the form of silent compliance, the fear of making mistakes (CYA) and a general sense that it is better to make no decisions than to make the wrong one.  It is better to delay than to act.  The result of this corporate oppression is inertia: it is stagnation. If this oppression is not recognized for what it is, it cannot possibly be surfaced and dealt with. An organization groaning under the burden of such oppression can never be agile, no matter how many nice facades it puts on itself.

As well as oppression at the individual company level, there is the additional fear-based culture across companies of compliance to “standards”, e.g. SOX, ISO 9001, CMMI.  I have twice observed the effort exerted to meet such standards by those forced to comply.  It was a pathetic sight — fearful workers, terrified of making mistakes, outwardly exhausted and inwardly cowering.  I don’t exaggerate.  Others may have a different experience; this was mine.

But who is responsible for the way things are?  The oppressors?  Society?  It would be easy to apportion blame, and carry on the same way.  The reality though is that the oppressed person himself is the culprit.  In a democratic society we have choices.  If we are oppressed (and we are) it is because we choose to live that way.  “There can be no really pervasive system of oppression . . . without the consent of the oppressed.”Florynce Kennedy

This is all well and good, and a simple two-step solution would be to a) recognize it and b) act differently.  The reality though is trickier.  Too often the oppressed don’t want change; they simply want to be on the other side of the oppression.  That is the ugly reality we live in.  We have all seen individuals rise to middle-management and change behavior accordingly, fitting in to the system and emulating their superiors.  Many of us have seen teams fall apart through infighting — indeed a key part of the Scrum Master training course is focused on dealing with such situations.  Reward systems in most software corporations are based on individual superiority, and to be superior, others must be considered inferior.

Commenting on the syndrome of in-fighting between oppressed natives in colonized countries, Paulo Friere notes “Because the oppressor exists within their oppressed comrades, when they attack those comrades they are indirectly attacking their oppressor as well.”

He goes on to say “on the other hand, at a certain point in their existential experience the oppressed feel an irresistible attraction towards the oppressors and their way of life.  Sharing this way of life becomes an overpowering aspiration.  In their alienation, the oppressed want at any cost to resemble the oppressors, to imitate them, to follow them.”

If large monolithic bodies such as IEEE and PMI are the oppressors in the software industry, then it follows from Friere’s observations that the smaller process innovators, the ones who once kicked back against the style of management represented by these bodies, will now wish to emulate them, to essentially become them. The Scrum Alliance events, for example, are moving from intimate gatherings of passionate people to corporate sponsored events with big-name keynote speakers, in essence becoming identical to all the other mainstream software conferences.  The PMI, champions of the oft-scorned waterfall process, are now being looked to for advice and support.  This isn’t progress, it is regression, or at best circularity.  The spirit of revolution so apparent in the beginning of this movement has all but disintegrated, as we march to the corporate drum.

Where does Scrum fit into a landscape of compliance and corporate emulation?  Quite possibly it will be absorbed back into that culture, watered down, commoditized.  It will be made nice.  And in 20-30 years time a new generation of dissatisfied, disempowered workers will start the revolution all over again.

We all desire change, but evidence indicates we don’t know how to go about getting it in any deep and lasting way.  By recognizing the reality of the oppression we live in, by facing it, acknowledging its truth, perhaps we can shake off the shackles of ingrained behaviors and begin to think and behave in new ways.  And in doing so perhaps we can reinvent the world — or for now, at least the software industry.

8 Responses to “Oppression, Revolution and the Future of Scrum — #2”

  1. Mike Sutton Says:

    Great article.

    I have found that Scrum is all things to all people. The revolutionary mind (like yours and mine) see in Scrum a real chance to change the world. Not of just work, but of everything.

    Government’s run by Scrum would be far more effective, fairer and infinitely more accountable.

    It all depends on what the business is, and what value matters.

    On the subject of oppression – it may seem a little harsh, but I personally feel that anyone who does not realise they are oppressed deserves what they get (I mean this in the context of western working culture). There is so much more information available now that empowers the individual, to ignore it is careless.

    We all owe it to ourselves to seek to know ourselves and seek to be at peace with that which we discover – or change it.

    keep on keeping on
    Mike

  2. Anon Says:

    IMHO the beauty of the Agile Manifesto lies more in its generative than its reactive quality.

    The opposite pole of rigidity is chaos, not principled adaptability. It might be less important to choose one approach over another than it is to choose one and apply it steadily. Both excessive rigidity and absence of any guiding principle can make good people frightened and ineffective.

    I spent the last 18 months “fearful …, terrified of making mistakes, outwardly exhausted and inwardly cowering” as you describe. It wasn’t due to hidebound process orthodoxy but to the lack of any effective process. The organization prided itself on not doing BDUF, minimizing PMI-style practices, not producing IEEE-style deliverables, and being utterly disinterested in objective benchmarks like the CMM – as if their rejection alone were a badge of merit.

    The professed desire to work “in an agile/Agile way” unaccompanied by constancy of purpose became a general-purpose cudgel that could be used in any circumstance. In the resulting chaos the only rational response was to take as little initiative as possible and try to remain unremarkable.

    Given that both rigidity and chaos can create similar behaviors, it seems like the IEEE and PMI might not be the real villains, and flight to their polar opposite not the solution. Form valued over substance under any banner causes problems, but an organization needs some agreed way of working, whether tacit or explicit, to function effectively.

    Response: Thanks for the comment, and for sharing your experience.  “Being Agile” is not an excuse to do things badly; it is to be regretted that some people will use it that way.  I have seen similar things you describe.  There is nothing agile about this approach though; it is simply bad craftsmanship.  Agile is a very disciplined way of working, but the discipline is established by the team and the business for what makes sense in their context; it is not an imposed, one-size-fits-all discipline.  I hope I made it clear in my post, but if not I’ll reiterate here: the PMI, IEE, whoever, are not the villains.  Those that blindly comply to work practices that make their lives unhappy and don’t produce value are the villians.  That applies as much in a chaos culture as it does in a control culture.  I’d like to ask you this: what did you do to change the situation you were in?

  3. Arnaud Bailly Says:

    Tobias: Thanks for this great post (and the first part too).

    Mike: The ways of domination are far more subtle than one may think at first, and the oppressed, even the best informed one, may not always be aware of the oppression. A french sociologist named pierre Bourdieu uncovered a form of domination called ’symbolic violence’ that is at the root of most societies. Dominated groups (women, aliens, lower clas, homosexuals, you name it) tend to conform to the domination by incorporating (in what is called an habitus), even in the physical sense, the domination. It is a characteristic of society to perpetuate various symbolic dominations through discourse, ideologies (think of the representation of women in advertising).

    This is different still, with the desire for crossing the domination barrier, and in my opinion a much more common form of stagnation.

    Unfortunately, I see more and more Scrum as an new form of the domination, even more so here in France where it is relatively new and.

    regards,
    Arnaud

  4. zeptimius Says:

    Reality check.
    ARTHUR: Hey, .NET programmer!
    DENNIS: Software developer!
    ARTHUR: Software developer. Sorry. Who sits at that desk over there?
    DENNIS: I develop Java.
    ARTHUR: I– what?
    DENNIS: I develop in Java, not .NET.
    ARTHUR: Well, I can’t say ‘Hey, Java software developer’.
    DENNIS: Well, you could say ‘Dennis’.
    ARTHUR: Well, I didn’t know you were called ‘Dennis’.
    DENNIS: Well, you didn’t bother to find out, did you?
    ARTHUR: I did say ’sorry’ about the ‘coder’, but from behind you looked–
    DENNIS: What I object to is that you automatically treat me like an inferior!
    ARTHUR: Well, I am Manager!
    DENNIS: Oh, Manager, eh, very nice. And how d’you get that, eh? By exploiting the workers! By ‘anging on to outdated imperialist dogma which perpetuates the economic and social differences in our society. If there’s ever going to be any progress with the–
    WOMAN: Dennis, there’s some lovely bugs down here. Oh! How d’you do?
    ARTHUR: How do you do, good lady? I am Arthur, Manager of R&D. Whose desk is that?
    WOMAN: Manager of the who?
    ARTHUR: R&D.
    WOMAN: Who’s R&D?
    ARTHUR: Well, we all are. We are all R&D, and I am your manager.
    WOMAN: I didn’t know we had a Manager. I thought we were an autonomous collective.
    DENNIS: You’re fooling yourself. We’re living in a dictatorship: a self-perpetuating autocracy in which the working classes–
    WOMAN: Oh, there you go bringing class into it again.
    DENNIS: That’s what it’s all about. If only people would hear of–
    ARTHUR: Please! Please, good people. I am in haste. Who sits at that desk?
    WOMAN: No one sits there.
    ARTHUR: Then who is your boss?
    WOMAN: We don’t have a boss.
    ARTHUR: What?
    DENNIS: I told you. We’re an anarcho-syndicalist commune. We take it in turns to act as a sort of Scrum Master for the week,…
    ARTHUR: Yes.
    DENNIS: …but all the decisions of that Scrum Master have to be ratified at a special daily standup meeting…
    ARTHUR: Yes, I see.
    DENNIS: …by a simple majority in the case of purely internal affairs,…
    ARTHUR: Be quiet!
    DENNIS: …but by a two-thirds majority in the case of more major–
    ARTHUR: Be quiet! I order you to be quiet!
    WOMAN: Order, eh? Who does he think he is? Heh.
    ARTHUR: I am your Manager!
    WOMAN: Well, I didn’t vote for you.
    ARTHUR: You don’t vote for Managers.
    WOMAN: Well, how did you become Manager, then?
    ARTHUR: The CEO of the Company,… [angels sing] …his arm clad in the purest shimmering Armani, held aloft my contract signifying by Divine Providence that I, Arthur, was to sign it. [singing stops] That is why I am your Manager!
    DENNIS: Listen. Strange men in Armani suits distributing contracts is no basis for a system of management. Supreme executive power derives from a mandate from the masses, not from some farcical bureaucratic ceremony.
    ARTHUR: Be quiet!
    DENNIS: Well, but you can’t expect to wield supreme executive power just ’cause some guy in a suit threw a piece of paper at you!
    ARTHUR: Shut up!
    DENNIS: I mean, if I went ’round saying I was a CTO just because some nut in a costume had lobbed a document at me, they’d put me away!
    ARTHUR: Shut up, will you? Shut up!
    DENNIS: Ah, now we see the violence inherent in the system.
    ARTHUR: Shut up!
    DENNIS: Oh! Come and see the violence inherent in the system! Help! Help! I’m being repressed!
    ARTHUR: Bloody coder!
    DENNIS: Oh, what a give-away. Did you hear that? Did you hear that, eh? That’s what I’m on about. Did you see him repressing me? You saw it, didn’t you?

  5. Alex Says:

    Great post — well thought out and well researched! You put agile and the software industry in a very interesting context.

    It seems to me, though, that you’re presenting an inevitable path which ‘agile’ must take. Look at any enterprise started with honourable goals in mind — religions, the US Government (well, that’s arguable), PMI — eventually organizations grow to the point where their primary goal is one of self-preservation and growth for the sake of the sake growth. The original intentions fail to keep hold. Will the Agile Manifesto stand the test?

    Also, can you think of a society or point in history where the oppressed didn’t want to just become the oppressors? It seems to me this is human nature.

  6. Huet Landry Says:

    Great post!
    A fresh look at the forming-storming-norming-performing life cycle. (There is truly nothing new under the sun, other than new ways of looking at the world.)

    I tend to see the PMI as being more in the norming-performing part of the cycle, with groups like the Agile Alliance being in the storming part. What many people fail to see, is that frameworks for understanding life (and project management) are only useful as long as they are useful – and not a second longer. We can’t expect to reach the “performing” stage and stay there forever. That’s the big lie that oppressors always promote.

    The thing I like most about the Agile Manifesto is that it encourages us to continue to work through the forming and storming stages with every project and task.

    I became a PMP because my employer and primary customer valued the PMBOK. I became a CSM so that I could show them how to realistically tailor the appropriate parts of the PMBOK to get real, valuable work done with less overhead.

  7. David Koontz Says:

    Tobias, wonderful article, very interesting view point.

    Love the re-framing of the Arthurian legend in Scrum terms.

    As I read this, I was reminded of another compelling story. I have just re-watched (multiple times now) the Matrix trilogy last week. The movies works on some many levels – one is the control system that is used by the machines to control a human mind, to subjugate the body to the power generation system. An interesting parallel can be made to most oppression systems. However what struck me is that in the Matrix movie the machines had devised a “perfect world” which the human mind rejected, therefore the next best solutions was the matrix of control of an imperfect world at the height of human civilization (circa 1999).

    However we the audience find out that it is not a perfect control system – Zion has formed, rebellion is happening. In the 2nd, movie we find out that the machines have a Architect program that has accounted for the imbalance in the equations of control and has designed a mechanism of death/birth that leaves the machines in control with acceptable losses. This happens to be an iterative process.

    I’ll now pop out of the story to refer to Bridges Transitions model: Ending, Neutral Zone, New Beginning. This Neutral Zone in Bridges model is a chaotic time where the person generates new ideas. “Chaos is the primal state of pure energy for every true new beginning” – William Bridges

    Now back in the Matrix – Reloaded. Neo must make a choice: 1) save Trinity or 2) save Zion (the free-humans). There are cost to each decision. Save Trinity and the machines crush the city of Zion and all free-humans; Save Zion (the concept) and Trinity (his love) dies. To chose Zion he will be allowed to choose X number of people to start again.

    We find out the the machines have accounted for the imbalance in the equations, that lead to the creation of A Neo, that it has happened before and will happen again. The choice is predetermined to create a reset – reboot of Zion and the continuation of control. What the Architect doesn’t account for is that in the neutral zone (his office outside of the simulated world Neo, makes a new choice – to save the girl (come-on, the hero always saves the girl! – stupid machine).

    Neo chooses love over another iteration of oppression.

    The questions I have are these.

    Can someone else free me of oppression or is it a choice only I can make?

    If someone else frees me from oppression – is this another from of control?

  8. Bob Davis Says:

    Interesting discussions and great comments. Some of the arguments/comments are difficult to respond to when they seem to be framed so tightly as to only be able to allo only the answer that a person is looking for. Perhaps I need to dust off my philosophy hat and wear it more but for now I’m content to think and absorb.

    I’m a PMP and have to manage different projects using different ’styles’ based upon the need, complexity, and product to be delivered. To assume that, as a PMP, I have all the tools necessary to ‘develop/build everything’ would be proof that I wasn’t paying attention when I was learning about PM. As someone said in an earlier post, PMI does not deal with how the work is to be done, but in how to manage the process to ensure a greater possibility of success. How the work is to be done is really dependent upon the nature of the project and the team. Just as I wouldn’t use every tool in my toolbox to drive a wood screw, every tool/process in the PMBOX is not appropriate for all projects.

    In our development efforts we’re attempting to use more ‘agile’ methodologies while working in an environment (government) that wants to see everything planned out prior to releasing funding and before work can begin. Since we’re spending other peoples money there’s wisdom in the approach but only to a point. My current view is that agile methodologies can be applied most effectively in the execution and control portions of a project where the actual work is accomplished while the appropriate PMI methodologies for the project can be effectively applied in the initiating, planning, and closeout portions of the project.

    This approach may be overly simplistic to many but I’m open to learn. Thanks for the time.

Leave a Reply