by Marc Kermisch
If you ask most software engineers what they want, they often will answer with “To build the best software, with the latest tools, without being bothered.” In other words, they want to build what they want and how they want, without lots of distractions or input. Couple that with the trends in Agile and the ever promoted self-organizing team’s concept and you can end up with anarchy, instead of autonomy.
Many of the software engineering teams I have worked with over the years promote the self-organizing, antonymous team concepts. They champion that it drives engagement and ultimately better (and even faster outcomes). I am all for autonomy but in at least established companies, that structure and discipline create better results. That doesn’t mean hierarchical command and control, instead, it means teamwork, collective thought, respectful debate, compromise, and results. Corporations are there to create value for their customers. In turn, that value provides jobs and profits to the corporation and its employees. That cycle of value creation, with the customer at the center, is important to keep front and center. I cringe when I hear engineers push to cut scope for the sake of delivering software on a predefined date, without the guardrails of value.
The challenge I have seen with self-organizing teams is that they struggle to come together on their own, let alone within a collection of teams in a larger enterprise. Say, one team picks a pattern for a contract between systems without collaboration with the other teams. When those other teams go to pick up that contract, they realize the pattern doesn’t match theirs. A debate ensues with tempers rising, feelings hurt and teams moving further apart vs. closer together. Autonomy can be interpreted as absolute. The concept of the people taking care of themselves and organizing turns into tribalism. Tribalism can turn into anarchy…. [
Read the rest here]
Tweet
Share