Digital Minimalism de Cal Newport

Acabo de terminar estos días de leer “Digital Minimalism: Choosing a Focused Life in a Noisy World” de Cal Newport y no quería resistirme a compartir algunas impresiones porque me ha impactado.

Hacía tiempo que veía la necesidad de revisar mi relación con varias herramientas digitales pero el libro de Newport le ha dado una dimensión más profunda y mejor pensada. Lo más interesante es que no se limita a las ideas de un clásico post de “las ventajas de 30 días sin redes sociales”. El trabajo de este libro es profundo, estructurado y con mucha estrategia para el éxito. El plan que propone es accionable, con un enfoque sostenible y de amplio espectro; no sólo redes sociales.

El problema actual

La idea detrás de gran parte del libro es algo muy importante en todo el movimiento minimalista: intencionalidad. Algo que muchas herramientas digitales, tal como se explica en esta obra, están diseñadas por defecto para que no tengas en cuenta.

Sin ánimo de destripar el libro, trataré de limitarme a explicar que Cal Newport hace un gran trabajo al exponer las estrategias que los creadores utilizan para operar sobre nuestros mecanismos de la atención. Es impresionante el nivel de detalle y referencias que se dan para entender cómo el uso, o mejor dicho el mal uso, de estas herramientas ha llegado a ser un problema social, académico e incluso médico. Porque incluso a nivel clínico se han observado ya muchas alteraciones en grandes grupos de población.

No se habla sólo de redes, sino del propio uso que damos al smartphone y al navegador, los cambios de contexto, la continua opción de la multitarea y varios aspectos más. Y se nos propone analizar de manera consciente qué valor añaden estos usos en contraste con la inversión en tiempo y posibles detrimentos que obtenemos. Según Newman, no vale el argumento flojo de que “añaden algo” a nuestra vida. Nos llama a analizar, de nuevo, con intencionalidad, todos los puntos alrededor para ver el beneficio real y tomar decisiones conscientes tanto del qué y el porqué, como del cómo.

Y este es el comienzo del libro. En el inicio te ayuda a entender aspectos como cual es el problema que pretende resolver, cómo llego el autor a las conclusiones, el ámbito al que se refiere con “Digital minimalism” y explicarte el método que te propone seguir, paso por paso para llegar al éxito si quieres seguirlo.

El enfoque del autor

Newport, que es profesor de Ciencias de la Computación, autor de varios libros muy exitosos y miembro de la generación millenial, no utiliza redes sociales. Sin embargo, es un gran conocedor tanto de la importancia como del impacto de muchas de estas herramientas y me gusta que no me propone la vuelta a un mundo sin internet ni mucho menos.

Lo que Newman dice es que las decisiones de uso que hagamos sobre herramientas digitales, del tipo que sean, deben ser decisiones informadas. Que pongamos sobre la mesa todos los factores y obremos con intención y no simplemente dejándonos llevar. Cada herramienta digital va a tener un coste de tiempo, impacto o posibles connotaciones por la propia dinámica y diseño de su interacción y tenemos que decir para qué y cómo queremos usarla.

Organización digital

El camino empieza, eso es cierto, con una desconexión durante 30 días de tantas herramientas adicionales (más explicación de qué es adicional, en el libro) como sea posible. Aviso: si pueden ser todas, mejor.

No es una parada de descanso sino que, al tratarse de una forma de adicción, se trata de hacer una desintoxicación. Hay que verse completamente liberado del elemento adictivo, llenar esos espacios con otros quehaceres y re descubrir el mundo sin esas herramientas.

Para llevar a cabo esos 30 días, Cal Newport platea un marco para evaluar de qué tenemos que deshacernos y de qué no. El enfoque es bastante drástico, aunque a su vez expone circunstancias a evaluar. Hay herramientas de las que quizá no puedas deshacerte totalmente porque supondrían un problema real para el desarrollo de tu vida laboral o personal. Y aún así, el autor propone que, si se conservan sea bajo la estricta aplicación de una estrategia.

Vuelta al mundo

Después de la desconexión llega la vuelta. Pero para no volver igual, Cal Newport dedica una importante parte del libro a proponer estrategias, enfoques y prácticas concetas. Desde los puntos que toda vuelta debe tener en cuenta para un buen plan, hasta casos de estudio de perfiles concretos y cómo han diseñado su estratégia.

Aquí hay un par de ideas que son centrales en esta parte del proceso según el libro.

Si vas a usar una herramienta digital necesitas saber muy concretamente para qué y si es la mejor manera de conseguir tu objetivo, pero eso no es lo único. También el cómo la vas a utilizar. La configuración y modo de uso por defecto es muy probable que no cumplan con el objetivo o, si lo hacen, añadan una importante carga de lo que Newport considera un precio que seguramente puedas minimizar con una correcta planificación.

Mi estado actual

Como decía el inicio, este libro me ha impactado. Actualmente estoy en la fase de esos 30 días de desconexión pero no quiero adelantar anda aún. Eso llegará con otra entrada.

Lo que sí quiero, es recomendarte la lectura del libro. Y que si lo haces, pedirte que nos cuentes un poco de tu experiencia si te apetece.

Edición y enlaces

  • Formato: Versión Kindle
  • Editor: Penguin (5 de febrero de 2019)
  • Idioma: Inglés

Puede comprar el libro desde este enlace y me ayudas a mantener el blog.

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