For the development process to be carried out, there is necessarily an analysis practice to convert the client’s need into a “requirement” and a “architecture” job to define how that requirement will be implemented.
These two tasks are always present, it would not be possible to move forward without doing this.
I have noticed in many cases that agencies do not do this analysis / architecture process or do so very limited.
In most cases they are “tasks” that enter into the orbit of developers, of those who have more experience generally, but they expect all developers, somehow, to do some analysis work.
Normally this unification of roles (analyst / architect / programmer / tester) in the developer is justified by invoking some kind of “agile” development theory.
(Strangely, when companies look for developers, they don’t usually request “requirements analysis” and “application architecture” skills. In the best case they mention “capacity for analysis”, this term is so vague that it means nothing in itself or means everything according to how you want to interpret)
It is very likely that a developer with many years of experience has all or part of the ability to fulfill all these roles. But how does this affect the dynamics and performance of development teams?
The policy of unifying roles, from my point of view, is a waste of resources and considerably lowers the team’s performance and its ability to acquire knowledge.
Not having some kind of centralization of the analysis and architecture tasks implies that the unification of criteria on how to do things is “theoretical” and therefore is subject to “interpretation”. The result, almost inevitably, is that each developer will use their own criteria and experience.
The results may be better or worse depending on the quality of the developers but something is certain, there will be no homogeneous criteria within the company. The software will not have identity, low capacity to recycle code and optimize processes, in addition to making verification and debugging procedures difficult.
This way of working (bad practice from my point of view) leads to an accumulation of technical debt that will be paid in the short / medium term and the cost of growing the team increases instead of decreasing. The rotation of developers not only complicates things further, it is stimulated by this way of working. Developers with little experience often feel inferior to conditions and those with more experience assert their experience as a way of personal positioning. Many times the “agile” teams are a battlefield of egos.
Usually the PM chooses which developer to assign a task based on the “supposed” estimated complexity of the task, but it is not possible to know the true complexity of the task until the analysis process is performed!!!. Therefore there is no guarantee that the assignments are correct. When the criterion is wrong, the team loses efficiency and in most cases the tasks end up being assigned by an availability criterion instead of a suitability criterion.
This is one of the reasons why companies often require that all their resources be “highly qualified” and therefore always have an unsatisfied demand.
In other cases, the task is really complex but code has already been developed for another client, in this case it would only be necessary to make a re-implementation / adaptation that most likely does not require an experienced developer.
In any case the unification of roles leads to under-utilization or over-utilization of resources.
The other aspect of the problem is related to training. Usually many developers are overwhelmed by the complexity of the requirement and must make a major effort to solve it, which implies a high degree of stress.
When a requirement was well analyzed, it is clear and well documented, it serves as a guide to more easily find a solution for implementation and if it is necessary to ask other team members for help, it makes it easy to ask the right questions. Both things contribute to the training of less experienced developers in a less stressful way and make the implementations meet the company’s standards with less code revisions.
Many companies solve their lack of resources by looking for developers in other regions that do not share the language and time.
When the team has members who work 100% remotely, as I usually do, it greatly facilitates communication by helping to overcome language barriers and those imposed by different times.
I think that in its origin many agencies required a criterion of “we all do everything” as an engine of growth but to persevere with this, once established, limits development and runs the risk of becoming bonsai agencies.
I think that a collaborative project management that includes all the members of different areas (accounts, design, development, etc.) is positive, agile and allows to improve the perspective of all members. But pretending to supplant the analysis by this collaborative management or dilute it in development tasks is highly damaging.
An adequate organization and composition of the Magento development team (PM, Analyst, Architect, Developers of different seniority) is what allows to create balanced, sustainable and solid teams allowing the growth of both the team members and the agency for which they work for.