7 Reasons to Keep Loving Scrum

Lately, I've been encountering more and more negative references to Scrum, with questions like "Why doesn't Scrum scale?" or "Why do programmers hate Scrum?" or articles alluding to the Scrum limitations, while the market has been populated with new models such as SAFE, Nexus, Less... among others, which come to provide Scrum with the ability to adapt to environments with changing needs.

I must admit that I have a special "affection" for Scrum. My career began as a developer in projects with the waterfall methodology and, since I joined agile teams, I saw the manifesto as a founding charter of freedom for the state of developers. From my point of view, advantages are still relevant and valid today so I will compile the main positive points I have found in Scrum throughout my career, comparing them with waterfall methodologies.

If you think that waterfall is a thing of the past and that software is no longer made with this model, let me tell you that for some years now I have believed that it is the most common model, even when it is not called waterfall but other names such as MVP (minimum viable product). Does this sound more familiar to you?

1. Workload

Waterfall projects have a generally calm initial phase, with the delivery date far away and time to analyze, estimate, and design functionalities that fit into a plan. Once the delivery date is approaching and the requirements are being clarified or refined, or new requirements arise and development is delayed, the rush begins chaotic periods of development at the rate of "more programmers!" leading through improvable quality. The partial and global milestones, the demos to the client, the installations followed one another and the period of chaos is extended, making conciliation a distant chimera. With Scrum, day-to-day life is much more organized, linear, and predictable. There is a known delivery date and if there is an urgency to deliver a functionality it will be in the last days or hours of the sprint and that can always be improved in the next one.

1. Value Delivery and Customer Participation

In waterfall, the game is often played for all or nothing, with a contract for the delivery of an application or an evolution with a certain budget and date, so the provider's success depends on the degree of compliance with those signed objectives. Any change management is complicated because it affects the initial contract and scope or an immovable date. In Scrum, meanwhile, there is a continuous delivery of value on a product that is continuously improved, respecting the requirements of the client, who participates in the entire life cycle of the development, being able to adapt to the changing needs and priorities throughout the life cycle.

In waterfall, the client or stakeholder participates in the requirements gathering and anxiously awaits the delivery to carry out their tests, with frustration due to delays, misunderstandings, and unmet expectations. In Scrum, that end-of-development phase -which tends to be exhausting- is alleviated. There is delivery every two or three weeks, with the scope being much more limited and the effort more concrete and manageable.

3. Labor Intrusion and Hierarchies

It doesn’t matter whether you like it or not, it is a fact that in a profession that does not require a specific degree, association, or professional qualification to practice it, there are professionals from any other discipline who work in software development.

Scrum does not avoid this but contributes to alleviating its effects. In Waterfall, it is common for professionals with other qualifications to join the development as functional analysts or project managers, all their work tools are Excel, Word, or Powerpoint, nothing that cannot be learned on the fly, right? and they contribute to many cases specific knowledge of the sector in which the project is framed. Conflicts are common because they are hierarchically above the development team, together with the ignorance of the profession lets them commit real aberrations in the requirements gathering, estimation, or management. Scrum alleviates these difficulties by defining flatter teams and clearer roles, and the "intruders" can act as a product's owner or a stakeholder with a much more limited scope of action and leave the technical and organizational decisions in the hands of the experts.

4. Stability and Learning Curve

Waterfall projects start and end, forcing developers to assume knowledge specific to a sector and functional area as long as a technology stack, which is easily not useful for the next project. On the other hand, in an agile team, the expertise of a professional in a specific area is better used in a consolidated and stable project. After each iteration, more functional, technical, and organizational details of the company are known, which results in greater speed and quality of development.

5. Productivity

Productivity and efficiency measures are taken to the team and not to the individual, making it easier to enroll a junior or newly arrived programmer. The way of working is standard and the team can focus on explaining the essentials of the work to the new addition, collectively making up for the initial learning curve. Tasks can be distributed and collaborated among the team members to smooth the landing and obtain equivalent productivity from the entire team. Once cruising speed is acquired, more story points can be delivered.

6. Estimations

Developers hate estimating, it's a fact, just as it's a fact that the management team needs estimates, so they are always a source of conflict. Why doesn't a developer like to estimate? To understand it, let's see an extrapolated example, imagine a race organizer who needs to know how long the test will last. To do this, he asks an athlete how long it will take to cover the distance. The athlete tells him that it depends on the terrain and that since he does not know it, he does not know how long it will take. The organizer insists: But suppose it is flat, how long will it take? Will you take less time when going in a group? Imagine that the terrain is mostly favorable, Could you do it in less time? Imagine now that there are many slopes, what would be the maximum time it would take? If, and if instead of the original distance 3 kilometers are cut, would the race finish by 2? It seems ridiculous but this is the exercise of estimating the unknown based on previous experiences more or less similar. And it happens that, like athletes, developers always overestimate their capabilities. The famous programmer time where 1 hour is worth 20. Scrum usually avoids time estimates, replacing them with effort estimates -which can then be translated into time anyway- collectively. With them it is guaranteed that individual factors are eliminated, issues that someone may miss are considered and it is ensured that the task will be completed within the term of a sprint or divided into smaller tasks.

? 7. .Professional Career

Companies that implement Waterfall determine a professional ladder in which programming is the base, and the successive steps are programmer analyst, functional analyst, and at some point, you have to leap to project manager because the management layer is always hierarchical and economically superior. It is comparable to other more classic professions: a bricklayer starts as an apprentice, and goes to official and foreman. With Scrum and its flatter teams, it makes perfect sense to develop a professional career as a developer, orienting the career towards mastery and excellence. The objective is no longer to perform different functions but to achieve an increasing level of quality in those performed. If the professional wants to get into management, coaching, architecture, or any other role, this is a personal decision and not guided by a predefined scale.

So why is Scrum hated?

The main reason I find in all criticism of Scrum is that in reality what is being done is a fake Scrum, taking some elements from the model, some ceremonies, and forgetting others, in such a way that the model is distorted. Everyone does daily meetings, but these have become status meetings where they report to management and are no longer from the development team to resolve their blockages and move forward.

The requirement has the form of a User Story, and the work can be divided into Sprints, but it is still waterfall development or fake Scrum, that is why MVP and Agile generate so much friction because basically, they are opposite paradigms.

We are agile, and We do Scrum but... this functionality in particular we are going to estimate and it has a certain deadline, so we leave everything we are doing for designing, and implementing a functionality that has to be ready for such a date... that is, the classic MVP. As in the song Video killed the Radio Star, MVP killed the Scrum star.

Scrum in itself does not scale well, or functionalities are developed that depend to such an extent on the development of other teams, that focusing on the work of the team is not enough and a hard and constant work of inter-team intermediation, alignment of requirements, and backlogs is needed that does not have a specific role assigned. That is, a role within the team, be it Scrum Master, Product Owner, or developer has to become a driver or facilitator, assuming inter-team responsibilities. This is not supported by any model per se, making it depend more on the person's abilities than the work model.

In conclusion, Scrum is the quintessential agile paradigm that makes a development team function, and it is the foundation of any model that aspires to enable modern organizations of any size to thrive, with the necessary adjustments and elements on the base model.