Management support in Agile

We all know how tight our hands can be when the 'big boys’ are not on board. Agile is not an exception. 

Do you feel that your team is not making much progress in Agile?

One of the first things you need to check is whether you are getting enough management's support. Actually, lack of such support may become a really tough blocker.

Let’s get into more details...

Usually, management expects a lot of positive changes to come with Agile and everything to be awesome. What they may not expect is that they are also part of the change.

For teams to become Agile, their managers have to be Agile as well. Self-organized teams are only possible if their members have such an opportunity. When managers don't command and control but instead listen, then there is more mutual trust between them and their teams, and employees feel safe to fail. Such a managerial approach will increase the team's confidence, freedom, and creativity.

I would like to outline some important factors regarding management's engagement on the Agile journey.

Velocity is per team, not per individual

Velocity is the metric used to predict what a TEAM can deliver by a certain point of time. "Team" is a keyword here. Individuals are shaped by their background and their experiences. For that reason, it is totally normal and expected that different team members will not commit to the equal amount of story points. Also, some members may be planning to help others, and their capacity can be limited.

Velocity should never be used as a factor for an individual's performance and comparison to others. In fact, it will only demotivate people and create unhealthy competition. There will be no teamwork and a common goal. Everyone will try to deliver the most points. People will stop helping each other as it will play against themselves.


Respect for team's commitments

If we want the team to respect and deliver their commitments, then those commitments should be recognized by management as well.

For example, management is using his/her authority to give different tasks to the team in the middle of the sprint. The team is afraid to say NO. As a result, committed items are continually being carried over. When such things happen, management should be explained that they need to go to PO first and the work should be prioritized and planned accordingly.

Of course, there may be some exceptions as things happen and we have to adapt. However, it's good when management respects the team's workflow. Otherwise, Planning and Stand-Ups are a waste of time and predicting velocity becomes impossible.

Trust between management and the team

It's essential that management respects the team’s decisions. A manager should trust the team and listen to their feedback instead of just giving orders.

For example, an application is experiencing a lot of technical debt and developing new features has significantly slowed down. The team thinks that using TDD and refactoring some of the code should help. On the other hand, the manager believes that these techniques will further slow down the new development and decides to hire more developers. What he doesn't realize is that having more people may fix the problem in the short term, but from a longer perspective, it will not do any good.

Since the team does the work, they know the best what should be done to make their job easier. So if team members say, it's TDD and refactoring, it's always better to listen to the team first and make a decision together.


Fixed scope and fixed date don't come together

I often see that teams and their Scrum Masters struggle with a lot of pressure on deliveries. They keep saying we have so much to do and so little time.

You can't have both a fixed scope and a fixed date at the same time. People are not magicians and can't do what's not realistic. Even if the team works overtime or new people are added to the project, there are still some limitations. It's crucial that management understands that. It's beneficial and less risky overall to have only one fixed constraint. When there is a set date, we can plan how much work can be delivered by that time based on their velocity. In the case of fixed scope, it's the date that can be derived.

Everyone needs feedback including a manager

Agile is all about improvement and adjusting to change. No improvements can happen if there is no feedback. It's a good practice to always ask for feedback instead of assuming things. Bad or good, feedback helps to improve. Management should seek some input as well.

People are used to asking for feedback from managers or peers, but very rarely from subordinates. When employees feel their opinion matters to their managers, they become more loyal than they could ever be.

When there is a culture where a manager asks subordinate such questions as: "what would you do if you were in my shoes?" or "what would make me a better manager?", it has a very positive influence on the team. Work environment becomes healthier and safer. The manager who asks such questions is also a good example of seeking opportunities to improve for the entire team.

Managers need Agile education too

Everyone needs education. Managers should go to the same training as their employees. They should read the same material they want employees to learn. They need to go through the same agile transition that they want for their employees.

                                                                       ...

The reason I wrote this article is that I am fortunate to work in an Agile environment supported by the management. I realize how important it is to have such support. I personally feel empowered as a Scrum Master and as an individual who wants to grow. Safety, respect and ability to freely express my opinion feel amazing, and therefore I love my job.

In summary, management's support in Agile is a big deal, and I wish everyone to have it.