The last link in the nerves chain

If you are in a group or environment where, for whatever reason, the nerves spread, the best thing you can do is to become the last link in that chain.

Transmit security or calm is not easy but, if you somehow lead teams, it is your best option. In my opinion, it should be the only acceptable one.

Never continue the spiral. Do not transmit your nervousness to someone to force others to solve what presses you.

Better transmit the importance of the facts and facilitate the resolution or search for solutions. Help others, if they can really help you to get over it, to work on ways to improve things instead of putting a backpack of pressure on them. That would make it harder for them to move clearly. If it is not something that is in their hand to resolve, you should directly manage that anxiety by yourself.

If in one way or another you lead or manage a team make your best effort to be the one who breaks the chain. “They put pressure on me” or “they hurry me up” is a childish response; As they beat me in the yard, I beat you.

Do not get carried away, stop a moment, breathe, be objective and seek collaboration. Is not the simplest at all but differentiates who leads who simply rule.

It is not about the Scrum Master’s success

The Scrum Master doesn’t have teams in the path through the ones he will succeed. The teams find a Scrum Master in the path that will be able to provide value that will help them succeed.

Sure we need to do it well and be the best Scrum Master we can be. But not for the sake of our own success, but for the sake of doing the teams succeed. Don’t focus on what you are doing good and communicating it to the world so loudly that you forget that you are there to serve.

As was said by Albert Einstein:

Try not to become a man of success, but rather try to become a man of value.

More people should understand the tech side of everything

When you tell someone how a creative, unpredictable and intricate thing it is to create software, do they usually get it? I’d guess that usually no.

Sometimes maybe you get some “OKs”, a few “Ahas” and other times maybe a few “I don’t think so”. But at the end, most of the people who haven’t been in direct contact with this process at deep level, not necessarily coding, don’t have a clue of how a complex topic it is and the amount of variants that it has.

As Carl Sagan said:

We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology.

Could be that a good idea, before talking to non believers on Agile methodologies about why Agile is a better approach, make them understand how complex the process it is and why. Then, when they have understood the whole real problem, you could be able to talk about what we try to do to deal with all this complexity.

Be an action Scrum Master

Great thoughts speak only to the thoughtful mind, but great actions speak to all mankind.
— Theodore Roosevelt

Theodore Roosevelt gave a scheduled speech for 90 minutes after being shot in the chest during a political campaign. He carried the bullet in his chest for the rest of his life. But no, my idea is not to talk about politics but about action.

We probably don’t need to go as far as Roosevelt had to go, but there is something we can learn from that: be an action person. Probably nobody would remember that speech if he wouldn’t have done this.

As Scrum Masters, we need to be also action people.

Don’t let me be misunderstood. I know that I write about letting the team solve some problems, about philosophy and getting to know people but don’t think that then, for me, being a Scrum Master is just talking and walking around making people feel well. That is very naive.

Let your actions and not just your words talk about your job.

Actively work on the things, be involved. Get you hands dirty. Work on the trenches. Call it however you want but please don’t think that you don’t need to actually go and actually do stuff.

Never understand that having real uncomfortable conversations inside the organisation is not your job when it is being an impediment for your team.  Sit with the team and work with them on whatever you can automate to make all their work smoother – This doesn’t mean that you have to be coding- . Investigate and come back with solutions. Have action plans and execute them. Don’t just navigate from one retro to the next one and expect that people will trust you and whatever you say that should be done.

Work hard on what you have to do. The concept itself is easy to explain: Do your job. And your actions and the impact in the teams will talk about you. Then don’t fight to get the credit, you shouldn’t and you will probably won’t even need it. Even if some people don’t understand it.

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

Who assigns the tasks in the Development Team?

No one. End of the article.

It is not a joke. I will explain a little more about why.

It is common to hear that there are people doing Scrum in teams where it turns out that, after the Development Team estimates, the Scrum Master makes an assignment of the tasks. I did it when I started working with Scrum and did not understand what the matter was about.

When I started studying as a Scrum Master it was one of the first things that I changed. It was not easy. There was a lot of reluctance to stop doing it. But, as I always say, I think it was normal. It was an old habit that came before we really started to do Scrum. Management was afraid the teams could not organize the work and agree. The developers did not see it clearly at the beginning either. We started with a team and then we exported it to the others. At the end, of course, no one doubted it and it would be unthinkable to return to that.

The Scrum Guide, when talking about the Development Team, says it clearly in a single paragraph.

They are self-organizing. No one, not even the Scrum Master, tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.

The “not even the Scrum Master” is key. The development team is autonomous, no one tells you how to turn the Product Backlog into an increase.

Well, what happens to be more intrusive in someone’s work than telling them how to organize it and who will do each thing? The Development Team has all the members that it needs to carry out the development of the product. It depends on a thousand factors, sometimes even on daily conditions, to select who is more suitable or which is the best time to undertake each task.

If you are thinking about the issue of assigning Fronted tickets to Fronted people and Backend tickets to Backend people … it is not about that either. It is not a matter of “I finish mine and I pass it to you and then I continue with something else and you take care of yourself”. The team must work as a team and not just as a group.

“It would be good if today you would look at this with me because tomorrow we can divide this other. I will investigate how to hook what you have done with mine and thus save time for the other. I have touched it and so next time I can start it alone. If we divide this, you can start what you had earlier and we can integrate this part as soon as possible … “

All this is much more like what should happen within the team and be heard in the Daily Scrum that phrases that would squeak a lot and that before I heard a lot like “I’m with my ticket and then I’ll put on the other one I have”.

Trying to make a quadrant with tickets for each person believe me that not only goes totally against getting a team to self-manage, but also is to shoot yourself in the foot. You are not going to leave the accounts for hours to square it. It is a system with a zero capacity for modification in the appearance of unforeseen events, steals responsibility to the team about something they have to answer, attaches responsibility to the Scrum Master about something that does not have to answer … it’s crazy.

If you are doing it, stop doing it now. In the next Sprint. It may take some time for the team to get used to it and give them a bit of vertigo, but it is an essential step to self-management.

You can start by being a bit conservative, without a crazy amount of work in the Sprint Backlog and slowly you can help them discover ways of seeing when they are needed and do not see it because they are locked in their task. In the daily, you can see when someone is getting hooked and you can try to establish a dynamic so they can see that it is super healthy for that task to be divided again or learn to share it. And it will even happen that over time some will be firm with helping another because he sees that there is something that if not, they will not get out of the sprint.

It is a matter of taking steps towards taking responsibility. They are the responsible ones that have to face delivering or not the product increment and they will not be responsible for doing it executing a plan that is imposed right? The Sprint Backlog is owned by them, right? Well, the plan to carry it out, too.