I'm agile but I don't get results

Hello everyone, today we are going to talk about a very controversial topic that generates uncertainty on the part of some people regarding the use of the scrum framework.

Why don't I get results with SCRUM?

Surely you have heard reports like this before or know someone who has been through situations where they are not getting results using SCRUM in their teams.

And the answer is not simple, there are several factors that can lead to agile teams not presenting positive results, and below I will mention the most likely:

Company culture

Team seniority

Undefined roles

Rites not being taken seriously

dedicated SM

PO not be the owner of the product

Company Culture

Companies that want to use any agile methodologies and especially SCRUM need to change their culture. These companies need to understand that although the agile framework can be adapted, it is necessary to respect its backbone, that is, it cannot be reinvented, it cannot be made a priority for everything, much less influence the team's decisions. Having an agile DNA means that everyone in the company obtains satisfactory medium to long-term results, maintaining the quality of deliveries as a pillar, and because there are constant deliveries, everyone involved is satisfied.

Team Seniority

The team needs diverse people to achieve better results. A very junior team will have more difficulty delivering frequently, and may even impact the quality and number of deliveries per release. Normally the ideal is to mix with Senior, Full and Junior professionals. It is also important to have a technical leader on the team, or if possible, technical leaders, so that the other members can evolve. A team with professionals at these levels makes it even easier for the SM to maintain an agile mindset and certainly reduces impediments. It also helps the PO to organize or even suggest changes to the product so that it can have better results.

Undefined roles

It is very common in some teams, due to the company's own organizational structure, not having well-defined roles. I've seen a little bit of everything, from:

Director being PO and UI UX

Technical leader of the team playing the role of PO or SM

Teams without SM or PO, demands being passed on directly by sales or CS.

Own team or board carrying out sprint planning

PO without product autonomy

As seen above, we have several situations where in many companies it ends up being common. It is important to highlight that all the roles described in the framework are important and even if the company, due to its structure, is still unable to have all dedicated professionals, it is necessary to have them on a part-time basis, and more than that, with autonomy to exercise their functions. In short, it is extremely important for the successful implementation of the SCRUM methodology to have all roles clearly defined.

Rites not being taken seriously

I've seen many people not agree with all the SCRUM rites. Some believe that they do not bring results or the timebox is not appropriate.

In some scenarios, the lack of an active SM or even the lack of an agile mindset in the organization can cause rites to be overlooked and this even influences the team.

It is not the aim here to discuss what the rites are, but in summary we have Planning/refinement, Review, Retrospective and Dailys. All of these meetings are important, and many teams adopt other intermediate rites such as grooming, increasingly inserting the team into the discovery process, mapping from the beginning the risks that may occur.

The rites exist to strengthen communication between the parties, whether between the team and the strategic area, with customers or even between support teams when necessary. Abdicating the rites puts the progress of deliveries at risk, potentially causing impediments or even poor quality. Furthermore, the interaction between people creates a harmonious, fluid environment, conducive to good results, and SM has a fundamental role in this context, it is the gear that makes this process happen, keeping the agile culture alive among everyone.

Nothing prevents you from creating other rites, but you also need to understand the real need so that you don't overspend the team's hours in meetings that won't be productive. It is important to highlight that each rite has its own time box, going beyond this suggested time when in fact there is no need is also not good, the SM can intervene when something goes off track. There are situations where planning can take a long time, it is up to the team and the PO to assess whether the task is in fact at an appropriate granularity, what everything indicates if something like this happens is that it is not, and the team can refuse this type of task.

The importance of the rites is indisputable, and even more so the role of SM in keeping this culture alive, continuous and healthy, teams that put these tips into practice tend to have a much higher performance and consequently higher quality deliveries.

Dedicated SM

The Scrum Master is a very important cog in leading an agile team, and this role is essential in the teams. We know that not all companies, due to their size, are able to have a dedicated SM, in some configurations it is possible to see the Technical Leader performing this role, the PO performing this role or even the QA. I'm not saying it won't work, but in practice what I see is that the role has to be dedicated.

But what to do in cases where the company is unable to play this role?

Companies that mainly want to run SCRUM and that, due to their structure, do not yet have the resources to have a full-time SM, they can have it on a part-time basis, that's right on a part-time basis, I know that many will not agree with my statement, but it is indeed a solution. But you need to have a lot of organization to do this and really make the divided resource count. What will not bring results is the parttime resource only using their "free hours" to act as SM, in fact there must be time where they will play this role and will thus maintain the agile culture within the team.

PO not be the owner of the product

Have you ever asked yourself, who owns the product I work on?

First, I would like to take the opportunity and clarify a mistake that is made today, PO is not a position, PO is a SCRUM actor, who together with the SM and the Team form the SCRUM team.

This function has gained strength in the last 5 years and the PO as a position is becoming increasingly popular. In practice, the PO can be the Director of the company, it can be the Product Manager, or the Manager of that specific product, it can be a business analyst dedicated to discovering and prioritizing the main demands.

But returning to the subtopic, currently many companies make this mistake, yes, the mistake of not having an owner for the product, or leaving the PO as just a bandit, performing the old role of requirements analyst. As a result, those Walterfall problems start to arise in teams that claim to be agile, that's right, demands that don't make sense being prioritized due to politics, or simple ignorance of the "whole", cycles being broken because someone in the hierarchy decided they needed it in the middle of the process. sprint including an "urgent" demand are just some of the situations that occur.

My grandmother used to say, "a dog that has two owners dies of hunger." You've certainly heard this, and it's the purest truth, you can't have a blind PO, where DIRECTOR A influences the cycle, DIRECTOR B gives his advice, MANAGER C sends the super demand at the last minute. urgent.

The PO must have the freedom to discover everything that is necessary in relation to the company's strategic goals, and put them into execution in sprint cycles. The PO is the only one who can break a sprint, he is the only one who can decide to increase something in the middle or do a replan, but based on data and not based on what the SO or CYCLE "thinks" it should be.

Want successful deliveries? Let the PO, the SM and the TEAM work, don't interfere, respect the decisions and you will reap the rewards. Have an agile mindset and promote this throughout the company, respect the deadlines given by everyone, listen to your entire team before making a strategic decision, have communication as a pillar, say NO when necessary and remember that everyone must row to the same side.

Do you want to understand in practice how to deliver value? If so, let's chat, I can help you a little.