So often we hear or read that Agile teams should be self-organising. Sometimes I have the impression people do not fully understand what the meaning behind it is. Let’s elaborate what self-organisation really means for an Agile team.
The origins of self-organising Agile teams
Citing the Agile Manifesto and its principles is always a bit tricky. It’s more than 20 years since its creation. Hence, in this time we hopefully learnt something while also the environment changed. Nevertheless we can still find value in its statements:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
From the Agile Principles
(…)
“The best architectures, requirements, and designs emerge from self-organizing teams.”
So, the 17 software developers coming together at Snowbird in 2001 mentioned the following:
- The best software emerges from self-organising teams
- Trust the team to get the job done
- Have motivated individuals in the teams
- Give these individuals the environment and support they need
Surely there must have existed self-organising teams also before the year 2001. But with the creation of the Agile Manifesto it was clearly specified. Next, we have a closer look at those principles and try to give an idea what it implies for our day-to-day work.
The best software emerges from self-organising teams
I put the term software for architectures, requirements, and designs. If you optimise these three parts, you are more likely to also get better software. But why do the best architectures, requirements, and designs emerge from teams that are self-organising? Before explaining that, let’s have a look what the alternatives are:
- Architecture and design is dictated from outside the team. Teams do not have that much influence on architectural decisions and are left to accept.
- Requirements likewise come from instances outside the team. The team itself doesn’t talk directly with the user.
So, let’s see what improves when the team is in charge.
Architecture and Design
The team that develops a system, knows the system best. Additionally they are nearest to the system’s development which means that they are able to take and apply decisions quickly. In their day to day work they experience what it means to extend and maintain the system. Therefore the developers should be able to judge what design and architectural directions are most promising.
Of course it does not mean that developers should ignore the outside world of architects and other teams. Actually they should take inputs from the outside seriously and evaluate them based on their good knowledge of the software under development.
Requirements
Both, the users and the developers know a software system best. The users obviously are using the system with all its features in the context the system is intended for. The developers know what is possible from a technical perspective. If we bring those two parties together conversations about the software details are very likely to happen. This is actually the point where a user story can be captured (it is not called “user story” for no reason). Besides that, the communication path between user and developer is in this case of length 1. No instances in between which could transmit informations in a distorted way (or manipulate and even bring their own view into it). Ultimately, we have short feedback loops.
In the end, self organisation also means that a team decides what they work on. Management only gives vision and strategy, no specific work assignments. The team can figure out with users and stakeholders which direction is most promising for value delivery.
People nearest to the work can make the best decisions.
Trust the team to get the job done
Every team is different since they consist of individuals with different skills, backgrounds, and experiences. At the same time every team should strive for continuous improvements within the team. Consequently every team takes different decisions on improvements, e.g. how to approach work, how to interact with stakeholders, and so on. This in turn makes every team look differently from an outside perspective.
Nevertheless, managers often try to compare teams, control them, and measure them. But what happens if a team feels they are evaluated based on externally visible KPIs? The team optimises towards those KPIs to look good from an outside perspective. Hence, their improvements take a wrong aim and not anymore try to improve value delivery. The result is a suboptimal way of working.
The only thing an Agile team has to guarantee is the ability to continuously deliver value. Stop managing the team and start trusting.
Have motivated individuals in the teams
Usually software developers are very happy about the actual work that comes with their job. They like programming and want to program. A part of us even programs in our spare time. As always there are a few exceptions. People that generally don’t like developing software should just not develop software and change their job.
Anyway, if now these motivated programers can work on their own architecture and are allowed to talk to the user, I’m convinced they are even more involved and want the software product to succeed. Developers don’t want an assembly line type of job where they just receive detailed and predefined requirements, implement and ship them. They usually want to be creative and solve problems to create great software products. And, opposite to what some people might think, programmers also like to talk to the user and build a relationship. They are humans in the end, a social species. And developing software is a highly social activity.
Finally, despite all the things mentioned above, there could still exist some obstacles in the day-to-day work of a developer. And those obstacles can decrease motivation. This is where the next part of this blog post comes into play.
It’s not only about motivated individuals though. You also need the right skills in the team. Self-organisation becomes easier if the team is cross-functional. If you are too dependent on others, it’s more difficult.
Give the environment and support they need
How can an Agile team continuously deliver value and excite users? Is it because they work hard, develop fast, and increase their velocity? No, it’s about continuous improvement and removal of obstacles. It’s about keeping a sustainable pace. If procurement takes too long, fix that. A team that needs a big screen for mob-programming doesn’t need it in 2 months, it needs it now. If you’re a manager don’t tell the team how to work. Instead, ask the team what they need for working in an ideal way.
At the same time, asking critical questions to the team is needed too. Trigger the team to reflect on their way of working with inputs from the outside. But always understand that they are self-organising.
Conclusion
Agile teams are not self-organising for no reason. There are thoughts behind this term and specific details why a team should organise themselves. If someone is claiming that his or her team(s) are self-organising, reflect on the above mentioned points.
Finally, I could imagine that self-organisation can also be pushed too far. Especially if you are working next to other teams, it might make sense to find a common ground. Because the goal is that all the teams can continuously deliver value. But if the other Agile teams (and the whole organisation) also understand self-organisation, it will not be too difficult to find a solution.