Autonomy != Anarchy

I am a long-standing believer in the principles of Agile development. I have been working this way for several decades, before it was referred to as “Agile”. I am friends with several signatories to the original “Agile Manifesto” and with them I share a degree of disappointment about how those important ideas are often misinterpreted and ignored.

I have been fortunate to have been close to the birth of several ideas that have been widely adopted. My observation is that it is always the case that so much is lost in translation as the idea gains wider “acceptance”.

One of the ideas that I think is widely misunderstood is the idea of “Autonomy”.

These days I work as an independent consultant. I work with lots of teams in lots of different organizations and I perceive a common anti-pattern in those organizations that claim to have embraced the principles of an Agile approach.

This is best expressed as “We can’t tell our people do that because they are autonomous”.

This is tricky, because it is kind of true that you want autonomous teams and also kind of a disaster if every individual on every team has complete freedom of choice.

I think it is important to treat everyone with respect and to recognize the fact, and encourage the culture, that good ideas can come from anywhere. It is also an important characteristic of successful teams that they are organized in a way that means that they don’t need to ask for “permission” from people outside the team to change the design, the architecture, the tools or the way that they work.

However, there are some ideas that are wrong. There are more wrong ideas than right ideas, and reinventing the whole of computer science and software development practice from scratch for every individual on every team is a patently a ridiculous idea.

How can we, as an industry, make progress if everyone has a veto on every idea?

For me the answer is one of scope. What is the correct scope for Autonomy? Is it the individual, the team the organization, or should everyone just do what I tell them to?

Much as the last answer would stroke my ego, I think that the real answer is that the correct boundary for Autonomy is the team.

There is some flex in what that means, but the team is the scope. If the team agrees that they are going to practice pair programming, and one person doesn’t want to, they can’t veto the decision or decide not to take part. It is a team decision.

If the team decides to change the tools that they use for their build, one person can’t decide to decline and continue with the old. Even if they really dislike the new direction.

Autonomy should be an act of collective responsibility.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

11 Responses to Autonomy != Anarchy

  1. José Miguel Ovando Jeria says:

    Sometimes autonomy is the result of absence of team, then the scope tends to be me.

  2. Miguel says:

    Based my experience I would like to say that the problem with empowering individuals and teams is that most of software engineers lack the knowledge to gather properly project requirements (and to realize when they have bad requirements), to perform object oriented analysis and design rightly, etc… I have saw most organizations doing agile give autonomy to the teams and individuals before maiking sure the are doing an effective software development process, this is lack of management.

    • davef says:

      I agree and think that this is part of a deeper problem, something I am working on exploring at the moment in a new book.

      I think that we, as software developers, focus on, and learn the wrong things. Our education is not sufficiently focused on the importance and techniques of problem-solving – How many “Computer Science” courses explore the importance of “Scientific/Engineering” thinking? How many have modules on the Scientific Method and its applicability to software development?

      Understanding the problems that we work on is not, or at least should not be, optional. It is, surely, what we are employed to do?

      I agree that management, technical and more broadly, is often poor. So is education in our discipline.

    • Emiliano says:

      Agree.
      Also, notice that skills and competences is never a variable taken into consideration in the current understanding of agile.
      Sometimes myself and a few other seasoned devs were a minority in a large team of baby engineers having no clue on the basics of software engineering. It was not pleasant.
      I believe the original authors of the agile manifesto had the idea of a “dev team” which is very different from the actual implementations that one happens to encounter in many companies nowadays.

  3. Eamonn Moloney says:

    I see this as a function of the product you are building and the freedom granted. Autonomy to me is freedom to change the product as required to meet the needs of the customer and also freedom to change engineering norms as needed by the product requirements. In short, remove the gatekeepers (architects, managers, principal engineers, etc.)

    It is rare a product is simple enough to be able to divide it up and assign a piece to an individual. So, we form teams with devs, PO, SM, etc.

    That unit works well when the product boundaries are clean.

    Now step up a level (or back?! :)) into a brown field project. 10+ years. It’s not so easy to grant the autonomy. Upgrading tools, libraries, infra, etc. is hard. Crazy customization is usually part of such a setup with “sneaky” bugs hidden over time.

    It should be a goal to clean up the boundaries of the brown field but before doing so, it would be a mistake to ignore the brown mess and grant autonomy at the team lead as defined above.

    Cleaning up those boundaries should be where the gatekeepers focus their efforts so we get to a place that allows the autonomous teams to flourish.

  4. Wagner says:

    What I’ve seen is that what we call a “team” decision is normally the decision of the loudest voice. In that sense, the said “team autonomy”, only obscures accountability.
    It is also a way for managers to hide and pretend they follow modern practices by not putting weight and strategic (or even tactical) thinking behind decisions.

  5. Rodolfo says:

    The tools aspect is also tricky. Large organizations don’t want every team to chose their own tools, as many of them cost money to buy and operate. How would you see this?

    • davef says:

      Tool choice is a cultural thing, there are trade-offs with either choice. I think that traditionally big orgs have assumed that “production-line economics” works for software. They assume that there economies of scale by buying tools for everyone. I think that this is mostly a mistake, but not entirely. There are times and circumstances, and industries or architectural choices that can make homogeneity a good thing.

      One way to organise for this is to create a kind of federated team structure approach. Each team is largely independent, but there is a group of people who form a kind of “coordination team” representing the different roles in the individual dev teams. This is a kind of managed-matrix approach. I have worked that way on a few large projects. Sometimes this coordination team is called a “Scrum of Scrums”.

      The idea is that you have the lead tech-lead, the lead-product-owner the lead-qa person (and so on) form a team to help guide strategy. This works best when the idea is not that these individuals direct things or impose their will, but rather act as a communication channel for the real teams to coordinate through. I played that role as a tech principle. This approach provides a forum to have debates about tools, and importantly a channel to change the agreed tools when they are wrong.

      This approach doesn’t scale as well as genuinely independent, microservice-style, teams, but it does scale into the low hundreds of people quite well.

      The cultural trick to not providing free tool-choice to teams, IMO, is to ensure that each team-member, in the small development teams also feels that they are part of the larger team, has a voice, and can object to dumb decisions and will be heard. It doesn’t mean that they will always get their way, but that is how collective responsibility works.

  6. Simon Shepard says:

    I totally agree with the content of the blog post. I think the title is a shame, for me it would have been autonomy != chaos/cowboy culture. Actually when you look into anarchy, it doesn’t mean a lack of organization, it actually just means a preference for decentralized organizations that are members of larger organizations on a voluntary basis rather than through force. Unfortunately the word ‘anarchy’ get’s abused a lot as a catchall for chaos or disorganization when you look at it historically it didn’t mean that at all.

  7. Dexter Sy says:

    Agree, it’s a very tricky situation. In a lean or agile environment, even a hint of bureaucracy can feel “icky”. But empowerment and autonomy is not just allowing people to do what they will, it’s also giving them the resources to do it right. The team, as you mentioned, is one of those resources. It’s a way for them to get consensus and some shared accountability.
    I’ve always thought of this as a scale where you ideally want to end somewhere in the middle of anarchy and bureacracy. Wrote about it here, if you’re interested: https://techmanagement.life/2019/10/02/the-anarchy-bureaucracy-spectrum/

Leave a Reply to Wagner Cancel reply

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