1. 20

  2. 12

    I’m the original author, and would suggest removing the satire tag on the basis that this isn’t satire. Supposedly agile software teams aren’t self-organising, this article is a checklist of self-organisation indicators on a hypothetical team.

    1. 4

      Once again I think people are confusing chaos for anarchy. As a social anarchist I always find it irksome that whenever discussing politics with anyone, the first hour of the conversation is spent doing an undergrad political science course.

      For this post, I think the philosophy tag would be much more apt.

      1. 2

        As every nerdy middle-schooler used to know, the Chaotic/Orderly and Good/Neutral/Evil axes are orthogonal.

      2. 1

        Management pay performance-related benefits like bonuses to the gang for the gang’s collective output, not to individuals.

        Does the team then divide them evenly or based on contribution as measured somehow by the team itself? If the former, what do you do if there is a large and obvious difference in value/output among the members?

        1. 3

          Let the team chose?

          Another way I could see it is that if you are someone who look to contribute a lot and more in return, then you are free, and perhaps you should associate with people with similar expectation. If you contribute more than another member and you are fine with that, then what’s the matter?

          One of the common point of view from anarchism / self-organization is:

          From each according to their ability, to each according to their need.

          1. 3

            Would it be a self-organising team if we told them what rules to follow?

            1. 1

              Your whole article is a list of rules to follow.

              1. 1

                No it isn’t. Feel welcome not to follow them and not to treat them as rules: I didn’t when writing them (which is why “rules” and “follow” and their synonyms aren’t in the original post).

        2. 7

          A rather silent truth about the industry is that there are many teams that are self-organizing in the way that the OP reports and many that have leads. If you visit teams in both camps, each will swear that their way is the right way but, in my experience, both work. This is very much like the dynamic vs. static typing debate.

          A big reason for this bifurcation is culture. If decision-makers in management have Agile lineage, the flat, leaderless team is more prevalent. Trad organizations tend to have leads. Especially, in my experience, teams that use MS languages. It really seems to be a culture thing. Teams and orgs tend to do what other teams and orgs within their line of sight do.

          1. 3

            hell yah, anarcho-syndicalist software teams, a two points I want to touch on:


            #5 seems like a really good idea, but effectively limits the type of people who can work in this environment. Now, to work on this team, you need to be able to be a good union rep, a good people manager, and a crack software dev. People like to say that anyone can be a manager, but it is a set of skills that one must hone, just like being a dev. Asking people to hone both sets will lead to them being less sharp in each.

            (I’m ignoring union rep because I have no experience with that, but there’s a similar issue I’d imagine.)


            If I could make an addition to these rules, I would say that the gang has to setup and sign a contract when they are hired by management. Note, this is not their contract with the management, but a contract with each other. The contract would need to dictate a bunch of the “fill-in-the-gaps” questions that get asked of this stuff. For a couple examples:

            • What do we define as wide enough consensus on an issue?
            • How do we enforce #4 while maintaining autonomy?
            • What is the recourse for violations of these rules?
            • etc…

            These contracts would have to be re-drafted and signed between each project, though some reuse could obviously occur.

            1. 1

              These contracts would have to be re-drafted and signed between each project

              I would be very glad to form a new workers’ co-op for each project I start. Much sunk cost fallacy comes from still being in the company that sank the cost.

              1. 1

                I would be very glad to form a new workers’ co-op for each project I start.

                But going back to my first point, are we requiring our programmers to now have contract negotiation skills just to make sure their needs are met?

                1. 2

                  Wait, don’t employees negotiate their contracts, or end up with unknown and arbitrary terms, already?

                  1. 2

                    If you lack the ability to negotiate over consensus, community norm enforcement etc - you are only really able to have your needs met by lucking into a community that happens to match what you want.

                  2. 0

                    Add lawyers too.

                    There should be electroshock collars on the new hires too

                2. 3

                  Any time you read of a new methodology that includes a new buzzword in place of “team”, you know somebody’s trying to sell you some snake oil.

                  1. 4

                    This “new buzzword” came from existing literature on self-organising workforces. The methodology is not “new”, it’s written in the manifesto for agile software development. And no “selling” is implied, though I’ll definitely take your money if you want.

                  2. 1

                    In this scenario, there’s nothing wrong with individual productivity, imho. It’s okay to receive feedback or get information about your individual productivity as long as that information is used only by the individual and his sole benefit.

                    Maybe his/her productivity is decreasing and needs some vacations, maybe is super productive and could work less hours.

                    1. 1

                      Hire outsiders, more teams more meetings and less progress!


                      I keep trying to quit professional work but they keep guilting me to stay.