The picture is taken from this resource .
Your competitor or partner has already implemented Scrum and is showing good results, and of course you want to achieve the same. I have bad news for you: if used incorrectly, Scrum can be harmful.
Here, for example, is a list of empirically identified situations in which Scrum can interfere with your work.
1. You plan to combine roles from the classical project management and Scrum
Scrum-team must include 3 roles: Product Owner, Development Team and Scrum-Master. Within the proposed composition, the team remains “flat”, that is, we do not have direct subordination between the participants. Such a team is empowered to independently make all decisions regarding the product being developed. The roles in Scrum clearly describe who is responsible for what issues.
Now imagine that you are planning to implement Scrum in a team with classic project management. Then the Scrum team begins to work with the participation of Project Manager. What happens in this case? In fact, PM simply has nothing to occupy itself in such a project. Any areas of responsibility that we transfer to him create an imbalance in the Scrum team. Give PM a budget? Excellent, that is, PM does not regulate the value and content of the product, but in case of problems it will be he who receives it on the head. Will we also give him work with the value of the product? Then it will be possible to abolish the Product Owner. But it will not be Scrum.
How roles and tasks in a team change with the arrival of Scrum
2. You work with extremely clear requirements
Scrum was created to develop products with a high level of uncertainty. It works well in cases where we need frequent releases to get feedback from the market. In a situation where we have detailed requirements that do not leave room for creativity, or when we don’t need feedback from the customer / users, Scrum only spends team time in meetings that are not of great value for product development.
When everything is clear already, why complicate it?
3. You work with projects of short duration
The basis of Scrum is an empirical approach. Its meaning is that we turn to the existing experience of the team in order to be able to predict its future successes. If we are working on a project lasting 2 months, we simply will not have time to accumulate enough experience to apply it to improve work processes.
4. The team has no desire to change the approach to work
This is one of the key limitations in implementing Scrum. Implementing Scrum as a guideline is almost always a bad idea, first it’s important to convey values to the team, “sell the idea”. But even after that, you will not have guarantees that the ideas of Scrum will be close to all its participants. Those who have not internally accepted the idea of Scrum and agile values can begin to destroy the system from the inside, “rock the boat”.
There are several possible scenarios. First: Scrum does not take root at all. This can happen if most of the team is against change. Either the team will organize a riot from the very beginning, or will do everything to make the new approach prove ineffective.
The second option: one or more participants will not want to work in the new system. Typically, such situations result in the “problematic” participant leaving the team on their own.
Change We are waiting for changes.
The picture is taken from this resource .
5. You are not ready to use all the required practices of Scrum
For this approach, they even coined the special term ScrumBut. This is when we work on Scrum, but ... We do not hold retrospectives. But we have a Daily meeting 2 times a week. But we abandoned the role of the Scrum master. And many other similar “buts.”
Scrum framework provides a simple and clear answer to all these situations. Yes, you can add additional practices to the Scrum process of your team (for example, practices from XP). But no, you cannot refuse any elements of Scrum, since this will not be Scrum.
All the roles, events and artifacts of Scrum are tightly tied together and are aimed at achieving a common goal - to efficiently supply customers with a product of maximum value. Rejection of any parts of Scrum moves us away from this goal.
6. You are not ready to recruit employees to work on a product full time
Have you seen a graph of productive work time versus the number of projects you are working on simultaneously? If not, then watch.
This diagram itself is the best argument in favor of involving employees in work on one project at a time. But if she does not convince you, subtract from the time left on one project when working with several others, the time that will be spent on obligatory meetings (daily meetings, retro, planning, sprint review). A team member will have too little time to work on tasks. Do you need it?
There are exceptions to this rule. For example, Scrum-Master can work with several teams at once. But for other participants it is necessary to ensure maximum involvement only in this project.
7. You do not have management support
Just as we want employees to take a new approach to work, we also need the support of management. It is important to understand that the introduction of Scrum, especially on
early stages may require some investment. For example, hiring an Agile coach or a professional Scrum Master, training the Product Owner, conducting Scrum training for employees, and more. The leader should be ready to support the new venture financially.
But this is not the most important thing. It is much more important that the management of the company shares the values of Scrum and is ready to change the culture of the company. For example, the leader needs to be prepared for the fact that he will have to give new powers as part of new roles in the team. Not everyone is ready for this, so “selling an idea” may be required at this level.
This list of criteria does not pretend to be exhaustive; you can supplement it for yourself or share your cases in the comments.