This question has been killing me for a long time. Should I be a Superman with extensive knowledge in one particular area or should I be able to do everything? Or, maybe I am asking the wrong question?
I have been working in the Scrum Team as a member of the Development Team for almost 3 years and I have been thinking about it all the time. I thought the answer would come easily after receiving the PSM I certificate, but it did not. So I started looking for it intensively. I decided to gain an insight into this topic and answer it to the best of my ability with the first, non-technical post on this blog. Because, well… What would teach us better than finding the answers ourselves and then trying to explain it to others, right?
Is being a specialist inadvisable?
No. In fact, it is perfectly fine. But striving to be so-called “unicorn” (having broad knowledge in everything) does not always go hand in hand with being productive and delivering the greatest possible value for the team and product. What is more, as this strange name of such phenomena suggests, it is ultrarare to achieve this formidable level of expertise.
If someone is a “database wizard”, then no one is expecting this person to be an expert in the front-end or testing. However, an undoubted asset is knowing the basics of other areas of the Development Team and willing to widen the knowledge of those fields to support your colleagues at any time.
Why then there is so much talk about the importance of being “more cross-functional” and not a specialist?
Answering this question, we have to remember that epithet “cross-functional” usually refers to the whole Development Team and not individuals. It means that the Development Team, as a whole, has all the skills necessary to create a product Increment. It is highly desirable that they have all the ability to take items from the Product Backlog and, without relying on people outside the team, turn them into an Increment of potentially releasable functionality. In practice, it is not a problem for us to have different specialists in our Development Team, as long as we are able to build an Increment without relying on the external help.
What is more, cross-functionality helps improving efficiency of the team and fighting against unexpected events. Imagine a situation in which we have one tester and several developers in the Development Team. During the Sprint, developers merge their changes into the main branch, deploy them on the test environment and ping tester after everything is ready for testing. In such situation, the tester will most likely be extremely bored at the beginning of the Sprint and, at the very end (pronounced: right before the Sprint Review), a tremendous amount of work will fall on him. For now, let’s ignore the fact that such situation leads to a deterioration of the quality, because the tester very often wants to close the test phase as soon as possible and mark things as “Done”. Otherwise, the Scrum Team will show almost nothing on the Sprint Review, which of course is considered to be the biggest failure of all time and unfortunately, it will feel as it was because of him. Obviously, that is not true and the Development Team has a bottleneck that they can solve by being “more” cross-functional as individuals.
Cross-functional individualities in such case are e.g. developers who could relieve the tester by helping him in testing even to a minimal extent. Thanks to this, the bottleneck in the team can be removed. Not to mention the fact that the Development Team can avoid possible panic when the tester takes a sudden time off for the entire Sprint or, worse, quits his job.
The Development Team member does not need to be a specialist in all areas. Actually, that is very unlikely. Of course, it is right to strive for it, but achieving it is so rare that people have even given it a very fitting name mentioned earlier – unicorn.
The Development Team member should have a level of knowledge which allows him to help his team in all of the competence area even in the slightest degree. Then, when someone goes on a long vacation or even leaves the team, you will not say “Guys.. We are in soooo deep sh..” but “Fortunately, we have some fundamental knowledge about it, so we can survive the search for a replacement”.
Do I really need to learn all of these other areas?
The short answer is: yes, you should. Because you are part of the team. As you probably know, you do not take responsibility for the Sprint Backlog items as an individual by “being assigned to it”. The whole team owns the Sprint Backlog and shares the accountability for it. The same with making things done. You should not just focus on your job and be an individual, but have the courage to learn new things, cooperate and act as a team member. At Navy Seals, where ‘life and death’ is at the stake, they are more likely to pick someone who has a high level of trust, but not necessarily has a high level of performance than someone who has significant performance, but lower trust. What is more, someone who is considered to be the best performing soldier in the world, but has no trust from the team is also considered as toxic. So if you want to be a reliable part of the team, you really need to start thinking and acting as a collective – not as an individual.
It would be great to be an expert in two or three different areas, but the team will never require it. What they need is you being able to help them, when they are overwhelmed by tasks of their area of specialization, and not saying “it is not my area of expertise, my part of work there is finished”. That is why you have a common Sprint Goal – it should always cause you to work together rather than on separate initiatives.