Helping the team is not doing everything for the team

The Scrum Master must exercise servant leadership for his team, but beware of misunderstanding what it is to serve a team.

Our job is to get a team of people who are increasingly able to solve their problems, not to solve them all and create a group that depends on us for everything.

The point is that, especially in the early phases of the team, perhaps their perspective does not allow them to identify many of the improvements they need. To the teams at the beginning the trees do not let them see the forest or the other way around.

I believe that the good leader is in charge of providing the environment, the tools and conditions for the team to grow. Direct intervention, especially with teams with a minimum of maturity, should be only done when there is no other remedy or the consequences of not doing so can be serious. This implies not only patience and coaching with the team itself but also managing the nerves and doubts of other members of the organisation. That is clearly a space that we must win for the team.

Sometimes the solution may be one they do not dare to apply, for example, out of fear of the company’s reaction. The Scrum Master will have to assess if it is time to act for them or pave the way for them to do it alone.

Perhaps it is not clear how to solve their internal communication problems. Decide if you should tell them and explain how to solve it or it is better to provide them with tools to know how to deal with them both now and in the future.

My approach is to encourage them to grow in responsibility as they have already controlled others. But this must always be destined to take a step towards independence. He never made his dependence on you.

Always think about the team of the future. How can it become? What needs to change so that they can become it?

It is also not responsible to just ask questions and do nothing for them. You have to be able to understand the moment in which each team and each individual is and, depending on this, accompany them in the process but not do it for them.

What you have to keep in mind is that everything you can help them solve for themselves is a new focus that you can work outside the team to make their area and their confidence even bigger.

International environment: It’s not just about languages

I feel fortunate for working in such an international environment.

You would say the most challenging part is the language. It is not. Having English as common language helps with that. Of course we all have different levels, accents, not all of us are native speakers. I am not, for sure. There is also the debate about if it is equally fair then for everyone to use language which is native for some of the people but, to be honest, English is nowadays the business language all around the world, so let’s skip that debate by now.

As I say, it is not about the language. It is about culture, and culture is not just tradition but a whole net of implications, tendencies and nuances in the way we interpret the world. The work here having this in mind and think about so many different cultures that you can learn from and deepen on while becoming better with human interactions.

It is very interesting to remove that western cultural veil that we can have to get to know the nuances on how different cultures understand what is a more or less direct message, how we all perceive what is more or less “normal” in conversations or even just how we each interpret hierarchy based on our cultural background.

From my perspective is an enriching opportunity if you are interested in human interactions and communication issues. You would be surprised. Not only this. I think that experiencing this kind of environment is good not only for profiles like the Agile Coach one, but for any person.

This would, for sure if you listen carefully to other people, make you grow as an individual. But if you get to work as a Coach in any kind of really cultural diverse environment, never give for granted that the way you and others communicate and interact is equally valid for everyone in the company.

Caregivers vs gatekeepers

As Scrum Masters or Agile coaches we take care of the agility of the company, the team, the groups around us. But we should, in any case, become the Agile Gatekeepers.

Always listen to others on how they perceive agile, what do they expect from a Scrum Master or what are their ideas about the next team improvements. You don’t have to do everything others do, but listen at least.

By changing to an active listening attitude towards all agents, we can learn more than we think even about how we are doing. And for sure that we help ourselves and others understand that we are here to drive agility, not to be the gatekeepers of it.

Which is the next thing you will study as a Scrum Master?

As a Scrum Master, as defined in the Scrum Guide, you are supposed to do different things.

Of course, you must read carefully the Scrum Guide and deeply understand the framework. This is really a lot, more than many people do. But to be honest is not enough.

According to the Guide you are, for example, supposed to facilitate Scrum events. Do you understand what is the theory and techniques behind it? Have you, apart from facilitating yourself, studied and been trained for it?

You are supposed to help the Development Team to create high-value products. How much do you know about business? How about the technical aspects of what the Development Team is doing, do you know what they talk about?

When working with the organization on teaching Scrum and Agile principles. How much do you know about teaching, public speaking, negotiation, and many other aspects implied in communication?

What I insinuate here can be uncomfortable and challenging, yes.

I talk about the same level of mastery we should promote all around the teams. Don’t think you already know everything you need just because you have been doing it for some time. This can be the most painful part. It is not just about Agile but human mind. Accepting all that we really know that don’t know.

As Epictetus said:

It is impossible for a man to learn what he thinks he already knows.

Scrum haters: You can read the Scrum Guide for free

I want to talk about this trend that lately extended writing articles claiming that Scrum is evil, destroys development teams, “kills agility” (Oh, my God) or even that encourages bad development practices.

I will try to touch some of the points of several of the posts that have fallen into my hands lately. Some of which I admit that get up my nose because of the unjustified and toxic commotion that they generate.

Most of these articles that I see seem (yes, pure opinion) written by someone in any of the following circumstances:

  • They have never read the Scrum Guide
  • They have never worked with Scrum
  • Have been unlucky enough to work in a place where Scrum was poorly implemented (in which case is true that it must be terrible and I really can understand)
  • Is a fan of command and control management
  • Is a technical person trying to be in absolute control of the process, forgetting that there are business needs.

In Scrum we don´t care about quality

It is not true. At no time is that said in Scrum, but rather the opposite.

No one (not even the Scrum Master) tells a development team how to do their job. The only people responsible for the quality level of the code are the members of the development team. Quality is not negotiated in Scrum. It is a habit.

No one tells the team how much work they put into the Sprint Backlog, so no one is forcing them to run to close things with a poor quality because there is too much work.

In fact, the teams have a definition of the fact that, among other things, protects them from having to deliver garbage only to meet deadlines.

Literally from the Scrum Guide:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Product Owners don´t care about quality

False again. Or a very bad generalisation at least.

A Product Owner watches over the quality of the product and understands that this quality happens, among many other factors apart than the number of bugs, due to the quality of the code.

Obviously, that is not their focus. But using this “is not their focus” to support the argument that Scrum does not take care of quality is, at least, forgetting that the Scrum team works through collaboration. In my opinion, it is also to treat the Development Team as young children who are not supposed to be able to assert their technical criteria.

By the way, Scrum does not enter into how the technical team executes its work. Nothing prevents a team (in fact it is desirable) to incorporate into their work practices of other Extreme Programming or other methodologies. Whether it’s TDD, Pair programming, Code Reviews … what the team thinks works for them and makes sense to them.

The lack of hierarchy in the Development Team does not work

Where doesn’t it work? In what team? When and why?

Another soft argument.

Having a team with equal responsibilities favors emerging leadership. And yes, this happens and it works and I have seen it many times. The thing is that requires not believing that one is smarter than the others and letting each make one step forward when the time is right.

There will be a developer who takes the leadership in some case because something is undertaken for him is within his area of ​​expertise. In other cases another person because he has more experience in that code base, in others that one who has a moment of greater professional growth …

Having the obligation to include a “code chief” in each small group of developers, can produce situations in which the criteria of that person is the one that has to be imposed only by title. Authority should always be earned, not imposed. It can cause the dependence of that person and a lower degree of involvement of the rest since they only have to be attentive to what the person in charge says they will already execute.

But also… if something goes wrong, is it going to be only that person’s responsibility? Or, then, will it be good for us to have the development responsibility of the entire Development Team?

Of course this is not always the case. I also see Scrum Teams where the leadership is not executed in this way and leaders take care of promoting emergent leadership. In any case is something very important to take into account and be very careful with it.

This is talking about accountability towards development. Scrum doesn’t care about the companies hierarchy but about the responsability of the develpment  on a daily basis. A team lead, if it exists and no matter how you call it is not more reaponsible towards the outcome of the Sprint or how they create the product in Scrum.

That the development team share responsibility also makes it possible for everyone to be free to join a task for the common good, to ensure the delivery of the product and that there is no ownership over the elements of the backlog when someone starts working on implementing something.

You can´t deploy so often with Scrum

First of all, I would like to know what period of time is “so often”, because the romantic ideas of the past sometimes distort the reality of what has been lived.

The issue is that that is completely false. Scrum speaks of having at the end of the sprint a product increment potentially deployable in production. Never, at any point, says that you can not go to multiple deliveries.

What a team should not admit to itself is to take it as good that a Sprint ends and there is not a finished product delivery.

If your deployment system allows it and makes sense in your company, why not do five deployments per day? You minimize the risk due to the accumulation of developments, you collect feedback much more frequently and you contribute value continuously.

The concept of a Sprint puts pressure on a team

This argument seems to me naive.

Working with a time-box is a way to get among other things:

Minimize the risk. Working with a maximum time, it is assured that in case of error, if there is a change of intentions, if the development does not go where it was expected … the risk of losing too much time and money is much lower. And yes, I wrote “money”, because we are developing a product and everyone’s salary is not paid with good intentions and desire to do it very well, but with the product that is delivered continuously.

Responsibility towards delivery. What a Sprint does produce is the responsibility to deliver the product. The teams get used to limiting their work in controlled iterations that they know they must deliver. And it is that you have to deliver. I insist It may seem like a truism but a development that lasts for infinite reasons is a black hole of time and money and you have to take responsibility for that.

I’m going to write this again: No one forces the development team to take on a certain amount of work. For what they must manage (which is part of becoming more professional) the amount of work they estimate they can carry out in a given time. It is their responsibility not to assume unmanageable amounts of duties and then not closing them.

It’s funny because people would get very upset if they go to a restaurant and because they admit more customers they can attend take forty minutes to bring each dish, but it’s hard for us to understand the customers to whom you deliver software (yes, also if your client is your own company) you must also deliver what you have agreed that you will deliver at the end of the Sprint.

The development team learns this on their own path, getting to know which is their real capacity. Is not something that will just happen overnight. Just be careful if after some time you find a Development Team that oversees this point and just have not finishing things as something normal and acceptable.

I leave for another article in depth the fact that this type of arguments and articles seems, deliberately or not, to obviate not only that the teams work on their own improvement Sprint after Sprint, but that Scrum is based on five values ​​that are fundamental for the Scrum team and that ensure the functioning of everything else in a healthy and professional environment.

  • Focus
  • Courage
  • Openness
  • Commitment
  • Respect