The Resilient Team, the Tech Lead Role and the Coordination Function in Scrum
TL;DR
Our genes are fantastic tiny bio-containers able to store the required data in the form of deoxyribonucleic acid (DNA), perhaps the most important molecule that developed over thousands of millions of years through an unguided chain of random events that we call evolution.
Genes are also responsible for the introduction, toggling on and off, of the features that make us who we are. Thanks to several chemical reactions, proteins and molecules form to guide the replication process that our cells depend upon in order to perform the much needed mitosis, the duplication of our genetic code into two exact (with a high degree of equivalence) copies, stored within the nucleus, within the genes of our cells.
Our genes are also co-responsible for the entire orchestration of such complexity into a well organized dance in which proteins are of great help. Proteins do the heavy lifting by serving as transporters or means of transport, they transport and process data in the form of genetic material when viruses deposit their genetic code into our cells, for instance.
But when all this pristine process is taken down by “corrupted” cells, cancer appears. Precious resources are thrown away, cells no longer know the how, what, nor when; they multiply uncontrollably, the organic tissues become unstable, causing great disruption to the entire system.
Our CD4 cells come in to organize an orchestrated attack of all our inmune cells and against such “misbehaved” cells. They attack their own kind. All of this happens every time, at every hour, minute and second within our bodies. In fact, it’s happening now.
The Resilient Software System
In software engineering, a system is resilient when it displays the qualities required to recover from a downtime caused by either internal or external factors. Such quality is deliberately put there by the designer or the engineers, or put there on the next iteration in the form of a progressive process as part of the non functional requirements.
If we saw then, a team as a system, we could come to the conclusion that such resiliency can be obtained by several means.
The Resilient Team
Just as a software system, a team behaves very similarly from the resilience standpoint. A resilient team must then present at least the following qualifications in order to continue operations even when there are “missing parts”, or when the unknowns outweigh the certainty:
- Self-organize
- Isolation, with external interfaces (communication channels)
- Proper dependencies management (internal and external)
- Transparent communication (in and out)
If we continue analysing the Resilient Team constitution, we would come to the conclusion that the aforementioned characteristics repeat themselves at the individual level (team members) in some sort of fractal-like phenomena. A set of traits that must repeat over and over again in order to gain stability and great team dynamics, which in exchange grant us the needed team resiliency that will allow us to operate even during the most uncertain situations.
The Tech Lead Role
It is rare to see such traits in every team member. And thus, when the individual units of a team configuration lack one or more of these characteristics, caos finds a fertile soil in which to emerge. Scrum allows us to self-organize up to a certain degree, because Scrum itself is a framework (a very well defined one) based heavily on science and the scientific method, we can either be very dogmatic and implement only the required roles for the framework to function properly, or perhaps we can also be very liberal and allow for roles such as the Tech Lead to be added to the configuration of the team itself. Based on my experience, it is always good to have a balanced approach.
The Tech Lead role, if not implemented well, can become a very problematic one. Common problems that arise from implementing this role in a wrongful manner, and by wrong we can mean several synonyms: unbalanced, unempathetic, asocial. Another common case for a wrongful implementation of such role is the overlapping between the Scrum Master (a lead servant) with the Tech Lead.
The Coordinator Function and the Single Responsibility Principle
As a set of best practices in software engineering, SOLID principles became the de facto guide to create resilient, robust, flexible and scalable software. Thus, there is no reason why we cannot consider the same principles for a role in Scrum that is external to the framework itself. We can then see in the figure of the Tech Lead a coordination function. A coordination function coordinates, organizes and orchestrates two or more Single Responsibility Functions.
By seeing a Scrum team member as a Single Responsibility Function, we can argue then that a very good way to allow for the inclusion of the Tech Lead role within the implementation of the Scrum framework is by allowing such a role to take the Coordination Function role. Then the Coordinator Function and the Tech Lead roles become analogous. All of this under the supervision of the Scrum Master.
But what about the Single Responsibility Functions (non Tech Lead team members) within the team? They can become Tech Leads (Coordinator Functions) as well. By encouraging self-organization and the implementation of the aforementioned traits that a resilient system must have for themselves and for other team members, we add resiliency to the team as a whole. We remove an internal virtual dependency (the Tech Lead) and enable the team to work well despite of not having all of its team members in place. This is resilience from theory to practice.
The Tech Lead role has become a very popular role to add to multiple frameworks, including Scrum. In order for the role to properly work we must pay attention to the resilience characteristics displayed by highly efficient teams and individuals, and implement them in a fractal manner.
