Initial argument
SCRUM forces daily follow-up meetings because no one really trusts the team to manage itself. Programmers tend to take the simplest stories just to show progress in volume as administrators do not understand, or are not interested in going into the detail of the difficulty of stories. On the other hand, estimates are often blatantly inflated and even if estimates are met, what is really being done is wasting company money and degrading productivity because most stories can be solved in half the time or less. . The upshot of all this is that all team members fall into a whirlwind of mediocrity that drags them to be worse, not better. We owe all of this to SCRUM.
SCRUM is a framework, not a formal methodology. Each company, project and team has its own peculiarities that make it necessary to adapt SCRUM to the reality of the projects, not the other way around.
Some examples of adaptations:
Track by number of finished stories, not by deviation between estimates and execution times (#NoEstimates).
Hold meetings on business issues and technical issues separately, with different team members.
Balance new development stories, improvement stories, and production incidents.
Adapt to remote work, geographical and even cultural differences of the different team members.
In that sense, although there are guidelines for the different roles of the team, the degree and characteristics of team supervision depends on many factors. For example, senior members likely require less supervision than junior members, who need constant guidance and deeper quality reviews. SCRUM’s daily meetings are not really designed for an individual follow-up of people but of the team in general. The success of this monitoring, the cohesion of the team, the achievement of goals, increased productivity and improvements in quality, among other aspects, depend on the team itself and the culture imposed by the SCRUM Master (more focused on technical issues) and the Product Owner (more focused on business issues and how technology can support them).
Skip the bend with the easy stories
Individuals should not decide which stories work. There are other factors such as complexity, experience and workloads, among other aspects. The assignment should be given by the SCRUM Master based on their judgment. It is not SCRUM’s fault that an individual continually receives the easy job.
Inflating estimates
First, estimates are not strictly necessary (#NoEstimates). Although even today, after talking about not making estimates for many years, Project Managers and executives in general will continue to ask about estimates and delivery dates. If estimates are used, an individual cannot be blindly believed. The team itself, and moreover the SCRUM Master, must have sufficient judgment to dispute very high or very low estimates. If people inflate their estimates and the team and managers accept it, they are creating a culture of cheating and mediocrity. SCRUM is not to blame for it.
Low productivity
Again, if the productivity of the team is low, and a good programmer could do what they commit in half the time or less, but they still double down and the managers or the team say nothing, they are the managers, especially the SCRUM Master who must have the visibility of what is happening inside the team, who are the culprits. This creates a culture of mediocrity that is difficult to stop. SCRUM is not to blame.
Conclution
SCRUM is neither the best agile approach nor the only one, although it is perhaps the most popular today. As a frame of reference, it is not a straitjacket nor does it have all the answers, I would say few in reality, in front of the projects. This is why SCRUM cannot be blamed for the failure of the teams. What’s more, I don’t think about success either. It all depends on the people.
