Category Archives: Books

“Tribal Leadership” review

I started reading Tribal Leadership a while ago, and wrote about my first impressions here.

To being with, the books emphasizes that if you change language, you change behavior, so it will focus very much on language. Beliefs, cognition and whatever else are therefore not addressed in the book, as they are not important for practical purposes, according to the authors.

The first key concept the book introduces is that of tribe, the group of people that makes change successful or not, no matter who mandates the change: even the CEO won’t be able to accomplish some change if the tribe decides  it does not want the change.

This tribe concept is important for two reasons: first, it makes clear that we must collaborate with and involve people to get real change, it just won’t happen without them.

The second reason is that it acknowledges that organizational change affects and is affected by more people than we might think: simply put, a development team is not the unit of organizational change, so you better pay attention to the surroundings too.

While this is not very original, it is worthwhile to say it explicitly time and again. Now, using the tribe keyword is a way to avoid using organization or group, words that might lead us to old preconceptions, but I think there is not much else in the concept.

That of tribal leader is another key concept: a tribal leader listens for the cultures of the tribe and updates it to a higher level of effectiveness, doing the work for the good of the tribe -not his own.

The stage idea is the third key concept. The authors state that tribes exist at five different stages (levels) of effectiveness. Tribes and people at at a certain stage have a characteristic and very different way of speaking (language is powerful!), different behavior and different structures of relationship among them.

What’s more, what you need to do move to a higher stage differs according to the stage you are currently in, and there will be different leverage points that can be used to upgrade to the next stage. Do not try to apply the same techniques you used to move from stage 1 to stage 2  to move from stage 4 to 5. Besides, you must move from a stage to the next stage without skipping any: you just can’t move from stage 1 to stage 4 directly.

To me, this is the key idea in the book, one that is often overlooked: different levels of competency show different vocabulary and behavior, require different upgrade tools and techniques and come with different leverage points.

Most change models acknowledge the existence of several levels (stages), but not many insist on the need to use different leverage points to upgrade to a higher level. This can be a nice tool to add to your change toolkit.

A chapter is devoted to each stage: how to identify whether a tribe is at that stage as well as techniques to move to the next stage are discussed at length in them.

The five stages identified by the authors are as follows:

  • Stage 1: tribes and people at this stage speak as if “life sucks”, behavior expresses despairing hostility.
  • Stage 2: speak as if “MY life sucks” (therefore others might not suck), and behavior is that of apathetic victims.
  • Stage 3: speak like “I am great”, with an unexpressed “-and you are not”. Behavior revolves around outperforming others and dominance, relationship are two sided.
  • Stage 4: speak like “WE are great”, with an unexpressed “-and they are not”. Behavior radiates groupal pride, and relationships are three-sided.
  • Stage 5: speak like “LIFE is great”. The idea of external enemy (you in stage 3, them in stage 4) disappears.

The meat of the book revolves around stage 4 (chapters 7 to 11), which is the higher for which the authors can provide advice. They discuss at length the need to identify the tribe values so that it is possible to get the kind of alignment that will make it much more effective, or finding a noble cause to unite the tribe, as well as many other issues.

To be fair, I liked the discussion on group values in Built to Last better, but  that might be just me (see the More Than Profits chapter).

Now, let me tell you about the book’s weak points. First of all, the book is hard to read, requiring a lot of chewing. Of the last three books on change I’ve read, this was (by far!) the hardest one to read.

I feel that it contains a bit too much chaff, and that they could have done better with less pages. Half the pages would have worked.

Now, do I recommend the book? Well, I do, but be aware that it will be hard work. If you are short on time and are just curious about change, you might do better reading some other easier to read book.

“Fearless Change”: making new things work in an organization

Fearless Change is a book I must recommend to those that need to introduce new practices or change something in an organization.

Just for the sake of clarity, this means that this is not the kind of book that addresses how to overhaul the whole organization. That is the purpose of a different kind of book, such as Tribal Leadership.

Fearless change is an easy to read book (really!) with lots of practical advice, and it introduces a pattern language to help identify key techniques, practices, tools and even concepts that will be key to help introduce something new in an organization: some of those patterns are Corporate Angel, Test the Waters, Small Successes or Step by Step.

Those unfamiliar with patterns need not worry, the book is highly readable even if you don’t know a thing about patterns. Let that not deter you, read the book!

The book is aptly divided into several chapters that mostly follow the way new things are introduced in a company, addressing the relevant issues as they appear and not before.

The first chapter introduces you to the  change agent (you!), the importance of culture and how people position themselves with respect to novelty, from innovators to early adopters to those resisting change.

Chapter two explains what patterns are and why the book is written using them, but I must insist: the book is so clearly written that I almost felt that this is not needed.

From then on, the book moves through the different stages something new will move through as it spreads more and more. These chapters are as follows:

  • Where do I start? So, you want to introduce a new things. Then, you’ll need to be noticed. Here’s how.
  • What do I do next? They noticed you, and you’ve got confidence that it’s worth your time. Now, you’ll need to spark influential support.
  • Meeting and more: you will need to meet people, and that means meetings. How do you survive and even thrive in them?
  • Take action! Get started. Here and now!
  • It’s all about people. You need to address people needs, more so because you are all volunteers -yet.
  • A new role: now you are dedicated! Sooner or later, you will need to make this change thing part of your official job, and get traction with management and the organization at large. How? This chapter explains this.
  • Convince the masses. Just convincing 5% of the people (the innovators) of the benefits of change will not be enough: you need to convince early adopters, to begin with.
  • More influence strategies. Now that you are addressing a different target population (early adopters) you’ll need new techniques.
  • Keep it going. You still need to convince the remaining of the organization, and keep things going to avoid losing momentum.
  • Dealing with resistance: you are going to meet some resistance, sooner rather than later. This chapter is about not only overcoming it, but about making it work for you.

These chapters are just 30% of the book but, believe me, they will be enough. I mean it: you can stop reading the book here and get 90% of the benefit. This means that you can read the real meat in four to six hours, even less if you are not taking detailed notes. That’s good.

The remaining of the book is mostly filled with a detailed description of the patterns that will help you achieve the different chapter objectives. It is a (good) detailed reference, which you will want to have at hand when you have doubts about what every patterns isreally about.

All in all, Fearless Change is a great book, with well arranged advice. A must for those interested in introducing something new in an organization -without upsetting the organization or themselves.

‘Scrum and XP from the trenches’: a good from-the-trenches book

As of lately, I’ve spent some time reading about Scrum basics for a refresher. I’ve already written about The Power of Scrum, a book that attempts to provide a high-level overview of Scrum for non-techies or techies in a hurry.

The second book I’ve been reading is  Scrum and XP from the Trenches, which you can get for free at InfoQ.

This is a practical book, focused on telling you about how a real company has implemented Scrum in a way that works for them. It is a hands-on book that does not try to be everything to everyone.

When the author tells you about something he did differently, he does not try to make it look nice. Rather, he explains the what and the why. Yes, sometimes he does things in a way that will not make it into the Scrum Hall Of Fame, so what? He always rings true, acknowledging failure when that’s what he got.

What is absolutely clear is that he’s been in the trenches, and that he has tried more than one way when he did not succeed the first time. And that, overall, he succeeded.

It is not rare to find he discusses several ways to do things. Some times, he has tried the alternatives, and sometimes he plainly says he is talking about something he might try, and why. At other times, he is candid enough to tell you not to do something (and the reasons), while acknowledging he has not tried it in practice. Refreshing.

I love the way the author has included most XP practices in the discussion. I consider that Scrum without some key XP practices in place will degenerate into fluffy or flaccid Scrum and get into real trouble real soon. Henrik Kniberg thinks the same, being very vocal on Test Driven Develoment. To me, TDD is a must for real agility in big projects, and a strong should for even small ones: ignore it and everything will crumble as internal quality takes a dive sooner or later. You might survive it, but you will get hurt.

One remarkable chapters gets deep into the problems of acceptance testing, and how real life can get in the way to tangle your beautiful sprints and make them irregular, and the product worse than you might feel safe to talk about. He goes as far as to say that delivering 1.0 to everybody might be a dream, with 1.0.1 being all you will be able to accomplish -unless the quality you need is rather low. Well, to me, talking about all of this is good, we need to know about trouble and failure rather than success to improve: kudos to Henrik Kniberg.

The chapters on multi-team projects and remote teams are good too: if your scenario requires handling such issues, the advice will be valuable to you.

Finally, there is a chapter that provides all checklists an Scrum Master will need: short, and very useful if you don’t have your own checklist.

All in all, a very good book, full of real life considerations and advice. The author is not afraid of going against custom or being pointed that his is is not the way it should be done, always providing his rationale.

‘The Power of Scrum’: good -but still hoping for something shorter and easier

This book belongs to the let us tell an enlightening (fictitious) story that inspires the reader genre, much like Our Iceberg is Melting, with Scrum as the subject.

I praised Our Iceberg is Melting, a fable about penguins, because 1) it made very simple points very effectively, providing a shared vocabulary, 2) it was easy to read, taking very little time (little more than one hour), and 3) it was unpretentious, no attempt to be or feel realistic, only to be relevant.

Our Iceberg makes clear that if you are in charge of putting the book insight into action, you have to move to a more in-depth book. But for people just participating in the effort, it is good enough to get started. It is a short focused book, and you get what you pay for.

Well, if The Power of Scrum tries to be all those things (and it should!), it fails. The story does not feel alive, it rather looks like a miracle waiting to fall upon a great team: so good that just whispering Scrum several times will be enough for them. Yes, Our Iceberg is Melting does not pass the realism check, but the reader does not expect it: there are penguins, so it must be a fable.

The Power of Scrum is too long to be read by very casual readers, those who use commute time to read: you need far more than one hour to read it. And it does not provide you with a memorable vocabulary you can share with all those involved in the effort. I really hope they had used a short fable to put all pieces of Scrum together, rather than using a pseudo-realistic story.

To put it shortly, I don’t feel I can recommend The Power of Scrum wholeheartedly to all casual readers with an interest in Scrum. Admittedly, that’s a tall order. To be fair, I have not found a book that will appeal to that audience, so maybe I’m being too ambitious.

That said, the book will be useful to those who know nothing or very little about Scrum and are willing to invest some time in it. This will probably the case if they are going to be involved in or affected by Scrum: managers and prospective product owners come to mind. In this scenario, this book will be very useful. You’ll get an overview of Scrum without getting swamped in technicalities.

‘Tribal Leadership’ (I): primeras impresiones

Estos últimos días he empezado a leer Tribal Leadership, uno de los (muchos) libros sobre cambio organizativo.

Y la verdad es que el enfoque me ha parecido refrescante.

¿Por qué? Para responder tengo que hacer una pequeña perorata sobre SuperAgile, el (inexistente) proceso que agiliza más ágil.

La cosa es que la agilidad es una buena (muy buena) cosa: si no lo creyera o no lo hubiera experimentado una y otra vez, no estaría en ello hace más de una década. Pero SuperAgile, como casi todos los otros procesos, no contempla un par de puntos clave para que no solo tenga éxito, sino que continúe teniéndolo. Porque se trata de que SuperAgile se quede, no basta con que llegue, ¿no?

Pensemos en qué mejoras supone SuperAgile para la vida de todo el mundo: porque si vamos a ponernos a hacer cambios importantes, más vale que mejoremos la vida de todos los afectados.

Para empezar, SuperAgile es fantástico para el Team, sin duda: se les ve en la cara a poco que se empiece con buen pie, la verdad.

Para el Product Focuser de SuperAgile, que representa y defiende el valor de negociotambién es una buena cosa. Pero no tanto como queremos creer. En la vida real, que es la única que tiene, nuestro hombre tiene que coordinar unos cuantos Stakeholders que no practican la agilidad. También lleva otros dos proyectos no ágiles que le exigen un mindset diferente, con el consiguiente stress.

¿Será un 15% de mejora en su vida suficiente para que Product Focuser acepte la propuesta de matrimonio de SuperAgile? Posibilidades hay, pero más vale que le mimemos tanto como podamos.

Pero vayamos al meollo. Es decir, ¿aceptará SuperAgile aquellos que realmente aceptan y hacen posibles los cambios? Porque, atención, ese grupo no es tan solo el Team + el Product Focuser + los mandos que apoyan SuperAgile, sino La Tribu.

¿Que no sabéis qué es La Tribu? ¡Leed Tribal Leadership para enteraros! Lo único que os puedo adelantar es que son de 20 a 150 personas.

Así que La Tribu, que es multidisciplinar, inter-departamental, etc., será quien realmente determinará la adopción de SuperAgile. Y muy probablemente lo hará si está alineada con el nivel de madurez al que está SuperAgile (que es grande)…pero si no, más te vale ponerte a conseguir la alineación de la tribu. Ese es, al menos, mi punto de vista.

He aquí un gran agujero en la línea de flotación de los distintos procesos ágiles: no actúan sobre quienes aceptan el cambio, solo sobre aquellos que lo llevan a cabo. Nadie se preocupa por cómo SuperAgile afecta a y es visto por aquellos que son los que realmente darán su sí o su no: y si ellos dicen que no, lo que diga el mismísimo CEO no será más que papel mojado.

Así que Tribal Leadership es importante para los agilistas porque proporciona un vocabulario que permite poner el foco sobre la unidad de aceptación del cambio. Porque lo ágil hay que conseguir que se quede. Si apuntamos tan solo a SuperAgile y los que lo practican, nuestros tiros se quedarán demasiado cortos.

No sé si compraré las conclusiones del libro, apenas lo he comenzado: pero lo que sí es seguro es que el de Tribu me parece un concepto valioso, que incorporaré a mi vocabulario.

¡Leed Tribal Leadership y temblad…o no!

PD: Por cierto, antes mencioné que la mayor parte de los procesos ágiles adolecen de dos fisuras clave, y solo he hablado de una. Estoy en ello…

‘Our Iceberg is Melting’: a nice book about change

En el Agile in in the air del 13 de julio pasado Marc Florit me mencionó un libro sobre el cambio que le pareció muy interesante, “Our Iceberg is Melting”, que además se podía leer en un rato: un libro de tren de cercanías, vamos.

Desde luego, el libro es fácil de leer, y de hecho me lo leí de cabo a rabo en una ida y venida en el tren de Barcelona a Vilanova i la Geltrú, a un encuentro de la gente de workOS. Va offtopic: muy buena su presentación sobre temas lean en el Lean a la fresca, concisa, dinámica y bien hecha, kudos a Sylvain y Miquel!

Volviendo al tema, no muchos libros de gestión o técnicos se pueden leer ‘casualmente’, sin exigir mucha concentración, lápiz y papel para tomar notas, y en una hora u hora y media: un plus.

¿Me gustó el libro? Sí, y mucho, y también no.

Lo que me gustó (y mucho)

El libro es una fábula, y como tal enfatiza solo unos puntos y no se enreda argumentando. Eso es lo que lo hace fácil de leer, y hace que sea realmente factible que todos los miembros de un equipo lo lean, se queden con las claves y lleguen a una visión realmente compartida. No hay nada o casi nada sobre lo que argumentar y con ello casi desaparece la posibilidad de conflicto, desacuerdo y conversaciones interminables.

Y es que es básico crear un vocabulario compartido sobre los principios y actitudes clave en los procesos de cambio, vocabulario que puedes usar con una sonrisa cuando hables del señor “NoNo” (un personaje clave de la fábula, que obviamente representa el inmovilismo), o llames a alguien “Buddy” (otro personaje memorable) para que le quede claro que es un gran comunicador y amigo de sus amigos, pero que quizá esa tarea de implementar un driver de base de datos le quede grande -y ello con una sonrisa en los labios.

El cambio es duro: construir un vocabulario común sobre las actitudes y puntos clave es básico. Y que se pueda hablar con un cierto aire de buen humor es, simplemente, una necesidad.

Lo que no me gustó (aunque no importa, la verdad)

Pues que es simplista, o sea, su punto fuerte. Los principios que preconiza el libro son sólidos y fáciles de entender, pero si uno quiere profundizar y es el que lidera o cataliza el cambio, seguramente debería irse a otro libro del autor, Leading Change. Cosa que pienso hacer.

Los puntos clave resaltados por el libro

Ahí van:

  1. Establecer un sentido de urgencia: el cambio solo es si es aquí y ahora.
  2. Formar una coalición para liderar el esfuerzo del cambio: solo no se puede.
  3. Desarrollar una visión para ayudar a dirigir el cambio: hay que remar, pero en la misma dirección.
  4. Comunicar la visión y las estrategias corporativas: el resto debe saber por qué remas, y hacia donde.
  5. Facultar a los demás para actuar sobre la visión de la organización: no monopolicemos, abramonos a los demás.
  6. Asegurar los resultados a corto plazo: de nuevo, aquí y ahora.
  7. Consolidar las mejoras y seguir profundizando los cambios: buenos cimientos, o se cae la casa.
  8. Institucionalizar los nuevos métodos, asegurando el desarrollo del liderazgo: convierte lo bueno en rutinario.

Imposible estar en desacuerdo, ¿no?

AGRADECIMIENTOS: Giving credit where credit is due

¡Gracias a Marc Florit por darnos a conocer un libro recomendable!

Introducción al control de versiones, usando Git: Pragmatic version control with Git

Ahora mismo, si alguien me pidiera opinión sobre qué control de versiones usar, y qué libro utilizar para iniciarse en el uso de un sistema de control de versiones, la respuesta sería “usa Git, y echale un vistazo a Pragmatic version control using Git“.

El libro va al grano, sin perderse por vericuetos, y sobre todo sin perder de vista que un sistema de control de versiones es un medio para un fin: primero, pues, viene la necesidad concreta, y después lo que un sisteam como git nos ofrece para satisfacer esa necesidad.

Demasiado a menudo nos cuentan el cómo sin que se vislumbre el por qué:  no es el caso de ese libro, que nunca pierde de vista el por qué de las cosas.

Por otro lado, si ya tienes experiencia con el uso de un sistema de control de versiones, tampoco te irá mal un libro que une muy rapidamente la necesidad concreta (¿cómo creo una rama aparte para “trastear”?) con lo que git proporciona para satisfacerla.

Finalmente, si eres un super experto…busca en otro lado. Estamos ante un libro de poco más de 150 páginas, simplemente no puede serlo para todo el mundo.

Una introducción excelente tanto a los sistemas de control de versiones como a git, ideal para programadores que tengan ninguna o poca experiencia con ambas cosas.

De ‘Rework: Change The Way You Work Forever’

Entre ayer y hoy me he dedicado a leer “Rework: Change The Way You Work Forever“, un libro de 37 signals.

Aunque no estoy de acuerdo al 100% con todo lo que dicen los autores, creo que el libro está lleno de buenos consejos y tiene una gran capacidad de impacto, algo esencial.

Porque con frecuencia no hacemos cosas en función de lo mucho que un tercero nos haya “convencido” de ello, sino de cuánto nos consiga impactar.

Y este es un libro con opiniones fuertes.

Como muestra, un trocito del capítulo Say no by default:

If I’d listened to customers,
I’d have given them a faster horse.
– Henry Ford

It’s so easy to say yes. Yes to another feature, yes to an overly optimistic deadline, yes to a mediocre design.

Soon, the stack of things you’ve said yes to grows so tall you can’t even see the things you should really be doing.

Start getting into the habit of saying no -even to many of your best ideas. Use the power of no to get your piorities straight. You rarely regret saying no. But you often wind up regretting saying yes.


Uno puede estar de acuerdo o no (yo lo estoy al 90% 99%), pero no se puede negar que los autores saben cómo hacer reaccionar al lector.

Además de movilizar, el libro está repleto de sentido común (!) y se lee muy fácilmente (!!).

Un gran libro, pues.

‘Debugging the Development Process’ & Timeless Principles

These days I’m re-reading Steve Maguire’s Debugging the Development Process, which is one of the first “realistic development process” books I read, almost two decades ago!

By “realistic” I mean that it takes into account that it is human beings who make software, and that how we communicate and what we feel about ourselves, the team and the process itself is crucial. Processes do not create software: people do. People comes first, processes second; it follows that it is processes that must fit people, not the other way around.

But, back to the book…This book is at least 16 years old, and it shows: no agile-speak here, for example. Yet, this must be the third or fourth time I read it, and the book still feels fresh.

Why is this so? I think that Maguire just keeps pounding on some underlying principles that will always hold, timeless principles that will never change:

  • You must be focused and have a clear purpose.
  • You must be concrete and explicit.
  • You must do things, instead of letting them happen.
  • You must be courageous.
  • You must believe that good enough never is: there’s always a better way.
  • The declared problem tends not to be the real problem: difficult problems tend to be difficult because they are not what they look like, what you are seeing is not what is there.
  • You must care about people: care that is shown via actions, not PR speeches -people almost always resent just-talk-the-talk PR campaigns aimed at them.
  • You must choose the right people/company: you must know your culture and choose the people and companies that are closer to it, because bypassing what’s deeply important to us is very straining, and you just can’t be the best at doing something you don’t believe in.

If you read the book paying attention to this, you will find Maguire provides a thousand concrete policies that work in the right direction to fulfill one or more of these timeless principles. Here are some examples…

Be focused

From chapter 1, Laying the Groundwork:

“Focus on improving the product… any work that does not result in an improved product is potentially wasted or misguided effort”

“The project lead should ruthlessly eliminate any obstacles that keep the developers from the truly important work: improving the product”

“Always determine what you are trying to accomplish, and then find the most efficient and pleasurable way to have your team do it”

“…one way to keep (housekeeping work) to a minimum is to regularly ask the questions ‘what am I ultimately trying to accomplish?’ and ‘How can I keep the benefits of the task yet eliminate the drawbacks?’”

From chapter 3, Of Strategic Importance:

“Don’t waste time on questionable improvement work. Weigh the potential value returned against the time you would have to invest”

From chapter 4, Unbridled Enthusiasm:

“If you hold a meeting that doesn’t end in a decision, that meeting has probably been a waste of time…Try to eliminate unnecessary follow-up work. I think you’ll be surprised at how many follow-up tasks don’t seem nearly as important by the end of the meeting as they did earlier, in the middle of an intense discussion”

From chapter 6, Constant, Unceasing Improvement:

“People often ask for something other than what they really need. Always determine what they are trying to accomplish before dealing with any request”

Be concrete and explicit

From chapter 1:

“At the very least, you should establish a ranking order for these priorities: size, speed, robustness, safety, testability, maintainability, simplicity, reusability, portability…in addition to ranking coding priorities, you should also establish a quality bar for each priority…otherwise, the team will have to waste time rewriting misconceived or substandard code”.

From chapter 2, The Systematic Approach:

“As you put systems in place, explain the purposes behind them so that the development team can understand what aspect of the product the systems are meant to improve”

From chapter 6, Constant, Unceasing Improvement:

“If you want your team members to make great leaps as well as take incremental daily steps to improvement, you must see that they actively pursue the greater goals…let them choose the skills they want to pursue…and merely verify that each goal is worth going after [by making sure] the skill would benefit the programmer, the project, and the company…the goal is achievable within a reasonable time frame…the goal has measurable results…[ideally] the skill will have immediate usefulness to the project”

Be courageous

From chapter 3, Of Strategic Importance:

“Sometimes there are questionable requests…a large corporate client had requested the LAYOFF macro so that they could lay people off without anybody being able to claim that the selections were biased [!]. The company would be in a position to simply point to Excel to prove their innocence…The task fell to me and I refused to implement the request…for months we beat the marketing team’s persistent requests for the feature. Marketing felt they needed the macro to close the sale…”

Care about people

From chapter 6, Constant, Unceasing Improvement:

“If you constantly expose a team member to new tasks that call for new skills, he or she will eventually reach a point at which your project no longer offers room to grow…for the benefit of the company, you should kick such an expert off your team…You have a duty to the programmers and the company to find the programmers positions in which they can grow”

From chapter 8, That Sinking Feeling:

“If your project is slipping, something is wrong. Don’t ignore the causes and demand long hours of the team members. Find and fix the problems”

On and on…

Maguire keeps on adding lots of foolproof advice throughout the book; most of it solidly rooted on the belief that it is people that makes software great -or a mess. I can’t agree more with him!

Yes, Debugging the Development Process is old…so, what? Some principles are timeless, and Maguire knows how to materialize them with concrete policies.

Highly recommended if you care about preserving what’s essential!