What’s wrong with Scrum? / Hebrew

What’s wrong with Scrum? / Hebrew

To answer this question, let’s first answer why Scrum has become such a popular framework in Software development?

Most people will say that the key to success is its simplicity. And they are right.

The Scrum Guide is about 10 pages long (hello PMBoK) and has the most basic ceremonies and rules.

Therefore, many companies and teams implement Scrum quickly and easily.

But there is a big mistake here.

And Scrum, in fact, is much more complicated inside (try to pass PSM I just by reading the guide several times (I am completely silent about PSM II and III)) and 99% of them are not implemented by Scrum, but only by its elements.

Many mistakenly think that Scrum is an agile framework.

“Isn’t that right?” – many will ask – “It refers to Agile. And it’s about flexibility.”

Scrum is actually a rigid set of rules and strong recommendations.

Days stretch to 30 minutes – no, this is not Scrum.

They decided to skip retro because the team is exhausted at the end of the sprint – no, it’s not Scrum.

RV decided to sink the task without a team – no, this is not Scrum.

No Scrum Master – no, it’s not Scrum.

We took a step to the left of the guide – no, this is not Scrum.

It is difficult (and sometimes simply impossible) for 99% of teams to follow all the mandatory points and follow the recommendations of the Scrum guide, but without it, the Scrum guide says: “You don’t have Scrum.”

And here there is one nuance: 99% of teams do not have Scrum, but they all somehow work. They are developing. Some results are achieved.

I’ve seen teams that only had Scrum days (sometimes up to an hour) and sprints (each time varying in length). But at the same time, they said that they worked according to Scrum and managed to deliver a decent result.

Yes, Scrum is not suitable for everyone, not every company/team. But it is not found in its pure form almost anywhere.

However, its elements are everywhere. And individually, they also work well and help achieve goals.

It’s a shame that this Scrum approach is forbidden to be called Scrum.

So what is the difficulty?

One of the main factors that creates difficulties for many teams is his philosophy.

1. Difficulty for beginners and unprepared teams:

The Scrum philosophy assumes a high level of self-organization, collaboration and hands-on learning. For teams just starting their journey with Agile approaches, implementing Scrum can be difficult. It can be difficult for new participants to understand Agile values ​​and adapt their daily practices to Scrum principles.

2. Limited applicability in some situations:

While Scrum can be effective for most projects, there are certain scenarios in which it can be limited or ineffective. For example, projects with a high degree of uncertainty or constantly changing requirements may face difficulties in applying a strict Sm framework.

3. Scaling problems for large projects and in an organization with several teams:

Scrum works well for small to medium-sized projects, but scaling it to larger projects or organizations with multiple teams can be difficult. Managing dependencies between teams and aligning common goals can be a challenge.

4. Limitations of flexibility, especially regarding quick response to changes:

Scrum provides structure and predictability through iterative sprints, ensuring stability in the development process. However, due to tight timelines and only making changes at the end of the sprint, it can be difficult for teams to quickly respond to unexpected changes.

5. Problems with communication and coordination within the team and between teams:

Scrum implies close interaction between team members and active communication. In large teams or organizations with multiple teams, it can be difficult to maintain effective communication and coordination among all participants.

6. Lack of formal documentation can lead to problems in knowledge transfer and knowledge management:

Scrum emphasizes work products over complete documentation, which can make it difficult to transfer knowledge and experience between team members. This is especially relevant in situations with transitions of team members or in projects with a high level of complexity.

7. Insufficient attention to product quality due to emphasis on fast delivery of working products:

Because of the focus on delivering a working product at the end of each sprint, some teams may not spend enough time on testing and quality assurance. This may affect the stability and reliability of the final product.

8. Not always suitable for projects with tight time frames or a high degree of uncertainty:

Scrum allows for flexibility, but in projects with tight time constraints or when requirements change daily, using Scrum can be difficult or inappropriate.

9. Difficulties in assessment and planning, especially when working with uncertain or new tasks:

Scrum involves evaluating and planning based on the team’s experience, which can be difficult if the team is faced with new technologies or uncertain tasks.

10. Difficulties in changing the work culture and habits of the team to comply with the principles of Scrum:

The implementation of Scrum requires a change in the working culture and habits of the team. This can be a challenge, especially if team members are used to other development methodologies.

In conclusion, the Scrum framework has a number of drawbacks related to its complex philosophy. Difficulty for beginners, limited applicability in some situations, and scaling difficulties are the main problems that can arise when using Scrum. Despite its popularity, teams should carefully consider their needs and real-world capabilities before deciding to implement this framework.

Related posts