Cross-functional team
It all starts with the team. 2+2=10 is a well-known term describing good teamwork or in other words “the whole is greater than the sum of its parts.”
Have you ever thought about how to improve the effectiveness of your development teams? How to be more productive? We have heard people wondering about it a lot and there seems to be millions of books about it.
One solution we see is having cross-functional development teams, who have all the knowledge they need to build this specific product (or part of the product or business stream etc.). This includes backend, frontend, mobile development, DevOps, UX, data analysis, business understanding, and so on.
That doesn’t mean everyone is an expert in all of them, but a shared goal and vision are essential parts of the concept. It means that everyone is aware of what is going on in different areas and what challenges there are. Like the ball that never drops and always stays somewhere in between, each team member needs to have a feeling of ownership. You do not need to wait behind other teams so there is major growth in effectiveness and productivity.
Of course, it means that the size of the team matters. Just like Scrum and several other sources state, we also believe that 3 - 6 dedicated full time employees is the perfect size for a self-organizing team. If it grows bigger, being aware of everything that is going on becomes too time consuming.
Another important aspect is that there should be no knowledge or skill that only one person can master. Then the stress and risks are too high. How can one go on vacation? How does one not become a blocker inside of the team? Sharing goals and knowledge grows productivity and makes prioritization much more effortless. Once the priority changes, the whole team is aware of it and there is no need to coordinate it between several teams (as would be the case if backend and frontend developing occurred separately).
A case study from our own experience - we used to have an infrastructure team taking care of the production environment. Now we have a platform team that builds the environment where all of the development teams can handle production activities with Kubernetes themselves. In 1:1s, we have received great feedback from developers that this has been a remarkable change because:
- it gives a strong feeling of ownership;
- it makes the process quicker;
- it is fun to learn new things.
Of course, you cannot always have all of the knowledge in the team. If necessary, the team can ask for support from the outside, but getting it and implementing it stays within the team’s responsibilities. That’s ownership. And that makes everything else described in this book possible.