When we ask a developer if they are full stack, their answer is usually “Yes! But… rather specialized in… such part”. As part of an Agile IT project, we are often looking for a full stack development service. But, what does this term mean and what can it bring to the project?
We will first see what stack means and the reasons put forward for the composition of a team of full stack people. Then, we will see its implementation in the context of an IT project through an example.
What is a “Stack”?
A “stack” is a stack comprising all the layers necessary to carry out an IT project. Each of these elements or layers therefore constitutes the “stack”. For example, we can talk about a technical stack, if we only refer to the technical layers of a project.
Very often, when we speak of a full stack developer, we are tempted to favor only the technical layers and in particular the “front” and “back” layers. But it would be a shame to limit ourselves to the technical aspects alone. Indeed, so-called “soft skills” are also important, particularly in an agile environment.
A (non-exhaustive) list of elements making up a “stack” could be:
The idea of a full stack team is therefore that each member of the development team can intervene on each layer of the “stack” within an IT project. Consequently, in the case of an Agile project (where the developers are self-organized and have a broader responsibility than on a V-cycle project), a developer can therefore:
– process a User Story from start to finish during the sprint (functional understanding, development of the different technical parts, etc.);
– proofread and validate the work of another developer.
– intervene on functional subjects
Supposed advantages of a full stack team
Now that we have defined the elements, let’s try to understand the reasons for this choice.
On paper, this method offers many advantages, the main ones being:
– the simplification of the organization, because each developer can intervene on each of the subjects;
– the possibility of simply increasing the development load by increasing the number of developers;
– better involvement of developers who will be in charge of complete User Stories, thus allowing better functional visibility thanks to the performance of technical tasks in different areas (and not just one).
But is it all so simple? What about in practice?
To answer these questions, it is necessary to address what is meant by “intervening on each layer”.
A full stack developer must be able to intervene on each of the layers of a “stack”?
What do we mean by this assertion? Does a developer have to work on every topic? If so, should they have an equivalent skill level on each layer? The answer is no. It is very complicated for a developer to be competent and autonomous on each layer.
When we talk about full stack profile, it means that the developer is specialized in certain areas, while having knowledge on other subjects. In general, we consider a full stack developer to have mastered at least 3-4 topics. But this does not cover all the needs. After analyzing these points, we understand the reluctance of developers to consider themselves full stack because everyone has their preferences, their favorite areas and can hardly master all the layers of an IT project.
If we project ourselves on a larger team, what would be the expected result?
We can sum it up with this sentence: “For each layer of the stack, have at least two people who master it” Why two developers? Quite simply so that the team is not blocked when one of the two is absent (holidays, sick leave, etc.).
However, a digression remains possible. Indeed, the existing needs in each IT project do not involve the same level of complexity on each layer.
After all, the composition of a full stack team is more complex than associating only so-called full stack developers. It is necessary to analyze the specialties of each developer who makes up the team in order to have consistency in the face of the challenges of the project. The risk of not having a team with sufficiently varied skills is that the technical response will potentially be the result of the experience of the members rather than the best possible response. For example, if a UX expert is missing, developers could be tempted to find technical solutions to an ergonomics problem.
Another important remark: it is difficult to have an ideal organization from the first iterations of the project. Having only one person mastering a subject at the beginning can be an accepted risk if skills development is planned within the team.