La importancia de ir a la raíz de las cosas: un ‘gran resultado’ que es síntoma de un gran problema

Hace un par de semanas recordé una anécdota que si no recuerdo mal (no estoy 100% seguro) contaba Steve Maguire en su libro Debugging the Development Process, un libro con muchos años pero que aún resulta refrescante y relevante.

La cosa era que un programador había conseguido cierto prestigio como una especie de crack de la depuración porque encontraba una cantidad de defectos increíble…hasta que de un modo u otro se descubrió que ello era debido a que simplemente producía muchos defectos. Y es que cuando hay muchos peces en el estanque es fácil conseguir una buena pesca.

En este caso se había asumido que el hecho de encontrar muchos defectos era un gran resultado, cuando en realidad no era más que el síntoma de un gran problema.

La lección que uno puede sacar de esta anécdota es que no hay que dar por cierto casi nada, y que uno siempre debe mirarlo todo con ojos críticos (que no criticones). Y, en particular, que uno debe buscar siempre la causa raíz de las cosas.

“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.

Cuando uno se quema con la leche…

Pues eso, que cuando uno se quema con la leche, a veces ve una vaca y llora.

En ocasiones resulta conveniente no aventurarse a hacer cambios “a ver si funcionan, en plan ensayo”. Y no por miedo al fracaso hoy (del error se aprende y el feedback es vital),  sino para evitar que si lo volvemos a intentar mañana haya heridas que se reabran y destruyan las posibilidades de éxito.

Así que si uno intenta introducir SuperAgile (el imaginario proceso que agiliza más ágil) sin las suficientes garantías y la cosa no funciona, quizá ello haga difícil o casi imposible introducir SuperAgile más adelante.

Y eso puede ser así incluso aunque el segundo intento se lleve a cabo con todas las garantías. Incluso con todo el coaching del mundo, toda la dirección de la empresa alineada y un par de monitores de 30″ para todos, hemos de tener cuidado con lo que pasará cuando los que se quemaron ayer con SuperAgile se tomen otra dosis hoy.

Así que antes de comenzar algo sin todas las garantías, asegúrate de que si no funciona hoy no vas a dejar un campo de minas que impida reintentarlo mañana. Es posible que descubras que vale la pena aplazar la cosa un tiempo, hasta que tengas (más) viento en las velas -¡o no!

La cuestión es planteárselo explícitamente y tomar una decisión informada. Si vamos adelante, que sea tras un buen análisis de riesgos.

‘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 negocio, tambié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…

Mejor que hacer algo nuevo…

Mejor que crear algo nuevo es asegurarnos que no tenemos roto algo que ya funcionaba. Aunque el juguete nuevo, que tendremos mañana  (¿seguro?), será más bonito.

O sea:

Cancela dos proyectos que no funcionan, en lugar de impulsar uno nuevo que seguro (¿seguro?) que funciona.

Deja de utilizar un par de prácticas que no funcionan, en lugar de añadir otra que funcionará (mañana).

Antes de añadir un item a la lista asegúrate de quitar otro. Mejor aún, quita dos…Puestos, ¿qué tal si no añadimos ese otro?

Simplifica antes de avanzar.

No estoy diciendo que no avancemos hacia el futuro, sino que antes de hacerlo nos aseguremos de que no nos cargamos el presente. Y distingamos entre  avanzar hacia el futuro y  huir hacia el mismo: misma parada, sí, pero diferentes destinos.

Pues eso…