<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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”.<\/p>\n\n\n\n
One of the ideas that I think is widely misunderstood is the idea of “Autonomy”.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
This is best expressed as “We can’t tell our people do that because they are autonomous”.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
How can we, as an industry, make progress if everyone has a veto on every idea?<\/p>\n\n\n\n
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<\/em> tell them to?<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Autonomy should be an act of collective responsibility.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading