Scrum Won't Help You. Let's Find out Why.

Scrum team must include three roles: Product Owner, Development Team and Scrum Master. Within the framework of the proposed composition, the team’s organisation remains flat, which means there is no direct subordination between its members. Such team is authorised to make all decisions related to the product in development independently. Scrum roles clearly dictate who is responsible for what.

Now, imagine that you are planning to implement Scrum in a team with classic project management. In this case, Scrum Team begins to operate with the participation of its Project Manager. What happens then? PM has practically nothing to do in such a project. Any responsibility that you delegate to them creates an imbalance within the Scrum Team. Shall you have PM who is responsible for the budget? Excellent. Now, while PM does not regulate the value and content of the product, they will be the one to be punished in case any problems arise. Should you have PM who is working with the product’s value as well, then? In this case, you can get rid of the role of the Product Owner. But then, it won’t be Scrum anymore.

Scrum was created to develop products with a high level of uncertainty. It works well in the cases that require frequent releases to get market feedback. In situations when you have detailed requirements that do not leave much room for creativity, or when you do not need customer/user feedback, Scrum will only waste your team’s time in meetings that are not that beneficial to the development of your product.

Why complicate things when everything is clear as it is?

The basis of Scrum is empirical approach, which means that you use the prior experience of your team to be able to predict its successfulness in the future. When you are working on a two-month project, you simply do not have time to accumulate enough experience and apply it to improve your work process.

This is one of the key obstacles to implementing Scrum. Imposing Scrum implementation is almost always a bad idea, it is important to convey its values to the team and sell them your idea first. Yet even after that, there are no guarantees that all of your team members will like Scrum’s concept. Those who do accept the ideas of Scrum and Agile Manifesto values may start rocking the boat and destroy the system from the inside.

There are several possible outcomes. The first one: Scrum does not catch on at all. This can happen if most of your team members oppose the change. The team will either protest it from the very beginning or will do anything to prove the new approach to be ineffective.

The second: one or more members do not want to work within the new system. Usually, such situations end with the ’problematic’ members leaving the team themselves.

Such approach even has its own term—ScrumBut. It means we use Scrum but... We do not hold retrospectives. But we have a daily meeting twice a week. But we gave up on a Scrum Master role. And many other such ’buts’.

The Scrum framework provides a simple and clear answer to all these situations. Yes, you can add complementary practices to your team’s Scrum process (for example, practices from XP). But no, you cannot reject any Scrum elements since this won’t be Scrum anymore.

All the Scrum roles, events and artefacts are tightly bound together and are aimed at achieving a shared goal—to successfully supply customers with a product of the highest value. Rejection of any Scrum parts moves us away from this goal.

Have you seen a diagram showing the time of efficient work versus the number of projects you work on simultaneously? If not, then have a look.

The diagram itself is the best argument for involving employees in work on one project at a time. But if it does not convince you, subtract the time that will be spent on obligatory meetings (daily meetings, retrospectives, planning, sprint review meetings) from the time left on one project when working on several more projects. A team member will have too little time to get things done. Do you really need it?

There are exceptions to this rule. For example, a Scrum Master can work with several teams at the same time. But other members must be fully engaged in this project.

Just as we want our employees to adopt a new approach to work, we also need the management support. It is important to understand that the implementation of Scrum may require some investment, especially at early stages. For example, you have to hire an Agile Coach or a professional Scrum Master, to train the Product Owner, to provide Scrum training for your employees etc. The top manager should be ready to allocate money for a new venture.

But that is not the half of the story. It is much more important that the company management share the Scrum values and be ready to change the corporate culture. For instance, the top manager should be prepared to give new authorities due to new roles on the team. Not everyone is ready for this, so ’selling an idea’ may be also required at this level.

This criteria list does not claim to be complete; you can expand it for yourself or share your cases in comments.