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.

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.

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