DirectJNgine & the JEE-DJN connector 2.3 beta 1 are publicly available

The DirectJNgine 2.3 beta 1 as well as the JEE-DJN connector are now publicly available!

The main feature in DJN 2.3 will be support for pluggable adapters that will allow users to support integration with Spring, CDI/JEE, Guice, etc.

That means that it will be possible to define action classes as beans and inject Spring beans, CDI/JEE beans, etc. in them, making it very easy to work with Spring, CDI, etc.

Beta 1 is providing support just for the JEE-DJN connector, and can be downloaded from the DirectJNgine site.


Spring-DJN: integrating Spring into DirectJNgine

I have created an Spring connector for DirectJNgine, spring-djn which is currently in alpha!

This connector will integrate Spring into DirectJNgine, making it possible to use Spring beans as Ext Direct actions. This means that you will be able to get the benefits of Spring built-in lifecycle support. Besides, you will be able to inject Spring beans into your own action classes, greatly simplifying Spring usage with ExtJs.

The beta version of spring-djn should be made public in two to three weeks.

“Estamos en la última fase de desarrollo y encontrando muchos defectos, así que podremos entregar el producto en breve”…

Más de una vez he oído algo así como “todo el mundo está trabajando duro, encontrando defectos a porrillo, así que podremos entregar el producto en breve”. Esto suele decirse bajo la asunción implícita de que “los encontramos tan rápido que acabaremos con la mayoría en un plis plas”.

Pues no, la práctica demuestra todo lo contrario, si estás encontrando muchos defectos es casi seguro que quedan muchos más.

Si uno pesca muchos peces, puede asumir que probablemente quedan muchos: que vayamos a acabar con ellos en breve es una asunción bastante arriesgada -a menos que tengamos información adicional que apunte a ello.

De hecho, solo si uno encuentra cada vez menos peces debe empezar a preguntarse si acaso no está pescando los últimos. Vamos, que encontrar muchos peces solo prueba que hay o había muchos, ¡no que quedan pocos!

Pues con los defectos pasa lo mismo: si uno sigue encontrando muchos defectos lo más probable es que queden muchos más.

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

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.