Scrum recipe confusion

Scrum dates back to the mid-eighties, but why does it work beautifully in some companies while others are so chaotic that they are reverting to old ways? Perhaps the companies that float or fail are doing it because they are moving away from the Scrum recipe.

Companies prefer to put their fingerprints on classic Scrum. Initially, it does not differ from modern, healthy Scrum, but then the company begins to replace all the ingredients in Granny’s proven recipes. They replace butter with applesauce, cheese with cottage cheese, and sour cream with yogurt.

While substitutions make sense, sometimes they don’t work and you are left with a plate of cookies that you better just throw away. The same can be said for ingredient substitution in Scrum.

Like a cookie that is left uneaten on a plate, there may be too many rash substitutions in Scrum that affect the success of the venture.

Let’s take a look at some of the spoofs that can affect your successful Scrum environment.

IT Product managers or business Product managers

Some companies believe that IT Product managers and business Product managers are one and the same. They are wrong.

The whole point of a Business Product Manager is to bring an understanding of the customer’s needs into the development process. These two roles are measured by different things. The Business Product Manager is driven by expanding product reach in the marketplace, where IT management is measured by metrics such as uptime, responsiveness, speed and stability.

If the product has users and a business Product manager who is responsible for the strategy and direction of the product’s development, then the Scrum Product Manager should not get involved in this.

The culinary equivalent of this substitution is tantamount to replacing a professional chef with a fast food chef. Do they know how to cook food? Yes. Can a fast food chef make a meal like a chef? Usually not.

Make sure Product Managers are part of the team that sets the direction for the product. In the case where multiple Business Product Managers determine the vector of development, one Product Manager can deal with technology to satisfy multiple requests and guide other Business Product Managers in setting priorities. One way or another, the direction of development should still be determined from a business point of view. Why do you need a product that quickly does what users don’t need?

Allowing changes to a sprint

In a rush to deliver change faster, many companies ignore the Scrum recipe guidelines, which say that once a sprint has been planned, there should be no change. For some reason, companies believe that this will go without consequences, despite the fact that there are already many bad examples on the market.

This practice is equivalent to starting making chocolate chip cookies and then making a cake out of them. You may not have enough resources, you may have to give up the work done, and worst of all, it can negatively affect the team.

There is a rhythm in a sprint, as well as a certainty that the planning agreement will be followed and everyone will move in the same direction. Making changes to the sprint, especially when it becomes a habit, undermines trust and affects the rhythm of the sprint, never allowing the team to succeed despite its capabilities.

Building too large Scrum teams

Guidelines for the size of Scrum teams vary greatly, with most of them having between seven and nine people.

Some companies, based on previous experience or reporting structure, decide to assemble large teams. At first, the new order of things seems innocent, but over time, problems become apparent. Stand-ups no longer last 15 minutes, team collaboration becomes more difficult, and more humble team members lose their voices and, in general, many other complications arise.

It is recommended to stick to the standard of seven to nine people so that the team has sufficient experience, but at the same time works quickly. If too many people are trying to solve a problem, then even the smallest problem becomes more difficult.

Stick to the basics

The first time you try a recipe, it’s best to just stick with it. The same is true for Scrum. Following a recipe does not mean that you cannot change it in the future and make it fit for you, but it is best to get the result before you start changing it.

When it comes to Scrum, it’s better to start with its principles. As your teams master them, they will have the opportunity to suggest improvements through channels such as retrospectives. As a result, the changes made will have a positive impact.

Very soon, the Scrum environment will start working smoothly, and it will take into account the nuances of the company, but they will not affect the efficiency of work.

Translation of the article prepared as part of the course “Agile Project Manager”… If you are interested in learning more about the course, we invite you to Open Day online.


Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *