Category Archives: libros

La Nevera Vacía

by

Llevo un par de semanas leyendo un librito que me regaló uno de sus autores (Diana Clarke), a la cuál conozco de mi época en Degesys, donde recibí un par de cursos de autoayuda, perdón, de gestión del tiempo y de liderazgo. :) En serio, unos talleres estupendos, donde practicamos mucho y donde aprendí a conocerme a mí mismo un poco más. Diana es una verdadera experta en conseguir eso de las personas. Bueno, al grano, el libro se titula “La Nevera Vacía” y debe su título a un comentario de una alumna de Carlos Hernández (el otro autor):

La crisis es como una nevera casi vacía, y el líder es el cocinero, o la madre de familia, que es capaz de realizar la mejor de las recetas sin apenas ingredientes.

Lógicamente, aparte de por la relación personal, me interesa mucho este tema y me lo traje como lectura veraniega y, aunque
este tipo de lectura es muy parecida a los propósitos de Año Nuevo, sí que he conseguido acabarlo. ¡Hurra por mí! :-)

Para los fans de Pilar Jericó: el prólogo es de ella. No es tan bueno como el mío en el libro de Carlos Blé, pero se deja leer. :-D

Diana y Carlos explican el estado de crisis actual, desde un punto de vista muy centrado en el papel de los departamentos de Recursos Humanos, pero también aplicable a cualquiera de nosotros, porque todos somos parte, de una manera o de otra de una organización en crisis (la sociedad misma). Así, nos hablan de la crisis económica, con efectos evidentes; una crisis de sobra estudiada y que muchos siguen tratando de paliar. Pero también nos hablan de la crisis de valores, causa raíz de la propia crisis económica. Esta crisis de valores nos ha llevado hasta una crisis de confianza, “donde nadie confía en nadie”. Y por último nos hablan de una crisis de identidad, especialmente grave en aquellas personas orientadas al logro y que necesitan un nivel de reconocimiento legítimo (y la mayoría lo somos porque nos han educado así) porque “quieran o no, vinculan aún más su identidad a la profesión que eligen”.

Crisis de Valores

Todo el capítulo sobre la Crisis de Valores me ha gustado mucho porque me ha reforzado en varias creencias muy íntimas y que me guían desde hace mucho tiempo, probablemente desde que vi la película “Momo” (versión animación, lo siento, no he leído el libro), y más recientemente, cuando leí un librito muy recomendable de Galbraith titulado “La economía del fraude inocente”. En particular, me sentí muy alineado con los autores cuando leí esta frase en “La Nevera Vacía”:

El desarrollo, tanto en sus raíces como en su direccionalidad y resultados, ha negado y vulnerado la ética. La ética ha estado ausente del desarrollo.

Nota para los despistados: cuando dicen desarrollo se refieren al desarrollo económico, no al desarrollo de software, je, je, pero (y esto lo añado yo) como en la gran mayoría de las actividades económicas, perfectamente podría aplicarse a este caso porque muchas disfunciones que todos los días comentamos en foros, conferencias, listas de correo y demás pasillos tienen que ver con la aplicación de esos “principios de enriquecimiento a toda costa”. Me encanta la frase:

La dirección sin valores es pura mediocridad.

Me parece estar oyendo a Xavi Gost. :)

Hay otras referencias a la ética, como la que hacen a la “crisis de decencia” de Leopoldo Abadía o la crítica de un decano de escuelas de negocio muy importante que dice:

Las escuelas [de negocio] se han olvidado en gran parte de las cuestiones éticas dentro de los MBA y apenas les conceden importancia.

Yo ampliaría la crítica (constructiva) a muchos más ámbitos.

Crisis de Confianza

Aunque en mi opinión, la crisis de confianza viene dada no sólo por una crisis de valores sino que también contribuye a ella una crisis de aptitudes (cierto, que también viene dada por una falta de valores). Me refiero a que muchos cambian un “enriquecimiento a toda costa” por un “crecimiento sostenible” y entonces dejan de lado la capacitación en habilidades que les permiten, entre otras cosas, no perder la confianza en sí mismos, ser capaces de criticar a los que toman decisiones por ellos y, en general, no ceder responsabilidades en exceso.

Creo que estaremos todos de acuerdo en que es muy importante, individual y colectivamente, recuperar la confianza, tal y como la describen Diana y Carlos:

La creencia en que una persona o grupo será capaz de responder de forma positiva -y en línea con nuestras expectativas- en una determinada situación. (…) Es una especie de apuesta, un sentimiento fruto de percepciones.
Por ello, cuando se pierde la confianza, ello produce agotamiento emocional.

Y una de las pistas que aportan para esta recuperación es:

A todos nos gusta en mayor o menor grado: prevalecer, ganar, tener la última palabra, demostrar que somos listos y/o guapos y/o simpáticos, lograr que nos admiren, respeten y quieran. Lo que nos compensará por renunciar a esta necesidad de reconocimiento será la confianza de que pertenecer al grupo trae consigo ventajas.

Crisis de Identidad

Cerrando esta primera parte del libro, Diana y Carlos se centran en otra crisis de la que casi nadie habla: la crisis de identidad.

Las personas orientadas al logro, y que necesitan un nivel de reconocimiento legítimo, quieran o no, vinculan aún más su identidad a la profesión que eligen.

¿Qué pasa si te quedas sin trabajo? ¿Qué pasa si el tipo de trabajo que venías haciendo desaparece? ¿Desapareces tú también con él? Claro que no. Pero muchos no se dan cuenta de que, llegados a ese punto, no les queda más remedio que hacer algo diferente a lo que habían estado haciendo hasta entonces. Yo creo que, en muchos casos, la incapacidad para ver esto tiene que ver con una falta de confianza en uno mismo y, también, por una falta de capacitación que les impide reinventarse o incluso, siquiera adaptarse a los cambios.

Recetas

Si el libro se quedara ahí, francamente, lo habría tirado a la basura. (De buen rollo) :-) En serio, no me gusta nada que me digan lo mal que está todo, aunque sea de un modo tan certero. Es algo que me pone de mal rollo. :)

En la nevera falta confianza, valores, ilusión, pero aun así es posible cocinar un buen plato, y ésa es precisamente la función del líder. Hay pocos ingredientes, pero bien mezclados crearemos magníficos platos.

O como decía la abuela de un viejo amigo: Si todo lo que le echas a la comida está bueno, entonces seguro que está muy rico.. :-)

La Crisis como Oportunidad

Toda crisis genera oportunidades y supone, estimula y proporciona cambio. Pero para aprovechar esas oportunidades hay dos alternativas: ser capaces de reconocerlas y aprovecharlas o, más difícil aún, crearlas y aprovecharlas. En ambos casos, el factor común es ser capaces (estar-dispuestos-a) aprovechar las oportunidades.

No voy a destripar este capítulo porque me parece muy interesante, pero sí resaltaré lo que más me ha gustado de este libro CON DIFERENCIA:

Ser generoso genera más oportunidades de las que nos podemos imaginar. Sí, sí, hablamos de dar y no de pedir. Las personas que constantemente son generosas y ofrecen su ayuda a los demás incrementan notablemente su red de contactos, y ésta les devuelve dicha generosidad en forma de oportunidades.

Más claro, el agua. Pero además es que soy un firme creyente en algo que me enseñó Roberto Canales (al que, de paso, dedico este resumen del libro, si es que este tipo de cosas se pueden dedicar) y es que si das, con el paso del tiempo recibes mucho más de lo que has dado.

La Crisis como Cambio

Me ha gustado mucho cómo han tratado esta parte porque me he dado cuenta de lo mucho que tenemos en común. Yo hablo mucho de autoexigencia y ellos, por ejemplo, hablan de “disconformidad permanente” y que, además, es una actitud que hay que cultivar.

Es evidente que los cambios que provoca una crisis nos obligan a salir de nuestra zona de confort, lo que implica asumir riesgos, entre ellos asumir que nos podemos equivocar. Pero lejos de ser algo malo, deberíamos aceptar las equivocaciones como oportunidades para aprender y, por tanto, ponernos por delante de nuestra competencia. Esta combinación de humildad (para aceptar que somos falibles) y de arrogancia (para aventurarnos como si fueramos inmortales) es muy poderosa y creo firmemente en ella.

También proponen la necesidad de tener una visión y un plan específico, con el objetivo de aprovechar los cambios. Hay, sin embargo, una duda aquí que me surge: ¿no es algo contradictorio el tener una visión más un plan específico con darnos la oportunidad de explorar? No sé, yo soy más de los seguidores de la idea del Homo Ludens, y en este sentido me viene muy bien el post de hoy de David Bonilla: L’equip petit.

Motivación

El resto del libro ya se me vuelve un poco denso :-( , quizás porque cuando leo palabras como motivación siempre me sale un “pues te vienes motivado de casa, chaval”. Pero claro, es que soy poco empático. Sé que ambos son defectos que debo trabajar y lo explican muy bien en el libro, pero bufff…

Comunicación

Sin embargo, hay una sección dedicada a la comunicación que me ha gustado mucho, quizás porque ahora que tengo que cuidar mucho mi marca personal, me fijo mucho más en eso y en cómo es posible que la gente pierda la confianza en tí con mucha facilidad simplemente porque has comunicado mal. Seguro que todos tenéis en mente muchos ejemplos, y muy probablemente alguno tenga que ver conmigo. :-)

Me gusta cómo explican que la comunicación debe ser veraz y puntual (cubriendo esos aspectos éticos tan olvidados), debe transmitir calma y esperanza (¿tú seguirías a alguien completamente histérico?). Llegados a este punto me di cuenta de que encajaba bastante bien con lo que los autores denominan los cuatro pilares de la confianza:

  • Competencia (o Resultados)
  • Visión positiva (o Calma)
  • Integridad (o Ética)
  • Interés por los demás (o Empatía)

Sólo habría que complementar esta comunicación con aspectos centrados en la empatía y los resultados y tendríamos una estrategia de comunicación bastante potente.

Hay algunas partes densas del libro que, aun así, hay que leerlas con detenimiento porque hay algunas partes donde he visto muchos puntos en común con libros que me son muy cercanos como “Apprenticeship Patterns” o con detalles como:

A menudo, la máquina de café es el lugar ideal para comprender lo que se cuece en nuestra organización.

Creatividad

No sólo he aprendido detalles de cómo pensamos los seres humanos, sino que he entendido por qué hay que salirse de los cauces establecidos para innovar. Para innovar de verdad.

La clave está en atreverse y no censurarse.

Si esto es así (que lo es), yo también me pregunto por qué en las empresas se habla constantemente de la innovación pero no se entrena a las personas para romper esquemas. Esto (y es un aviso para navegantes) lo vamos a cambiar muy pronto. De hecho, ya lo estamos cambiando, ¿verdad? ¿O acaso iniciativas como el desksurfing no lo demuestran?

Hay muchos consejos más para facilitar la innovación que no voy a enumerar aquí para que os compréis el libro o para que contratéis a Carlos o Diana para que os ayuden. ;-)

Talento

Claro, tenía que ocurrir. Un libro de RRHH y que no hablen de talento… :-P ¡Qué rabia que no hubieran estado en el AOS 2011 en aquella sesión sobre el talento! Seguro que Arturo Herrero, por ejemplo, les habría enseñado alguna cosilla después de su larga lista de experiencias buscando su empresa ideal. Aunque también es seguro que habríamos estado de acuerdo en muchísimas cosas.

Hay muchos detalles en este capítulo que me reafirman en la necesidad de organizar algún tipo de evento donde asistan profesionales de los RRHH a los que podamos inocular el virus del agilismo, la artesanía, el aprendizaje, la creatividad… y nos ayuden a romper las reglas. :-)

Conclusiones

Voy a copipegar parte del último párrafo del libro, que a su vez es transcripción de las palabras de un ejecutivo asistente a alguno de sus cursos:

Seamos:

  • Serios, pero no tristes. (…)
  • ¡Sabios y audaces! (…)

Me parece estar, una vez más, escuchando a Xavi Gost. No puede ser casualidad. :-)

 

P.S.

¿A vosotros también os choca decir “Diana y Carlos“?

Érase una vez… el diseño ágil con TDD

by

Después de varias semanas de retiro en las lejanas tierras de Huelva, obligado por razones familiares, y después del fenomenal éxito del libro “Diseño Ágil con TDD” que mi buen amigo Carlos Blé me ha dejado prologar, debo reconocer que ahora mismo no tengo mucho que aportar en este blog salvo extraer ese prólogo. Me siento bastante orgulloso de él, no sólo porque es original, sino porque creo que resume bastante bien cómo enfocar un desarrollo de software guiado por las pruebas además de reflejar el espíritu del cambio (aunque tardío) que se está produciendo en nuestro sector y que desde iniciativas como Agile Spain o agilismo.es trato de apoyar en primera persona. Espero que os guste:

Érase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián, que además eran hermanos. Ambos eran los cerditos más listos de la granja y por eso el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de ordenador para controlar el almacén de piensos. Les explicó que quería saber en todo momento cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes, pero les advirtió de que en una semana quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.

Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir lineas y lineas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera, pero bueno, esto del software va de reutilizar lo que ya funciona, ¿no?

Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabrían que efectivamente estaba terminada cada cosa. Iván quería poder conocer cuanto antes cuántos sacos de grano había en cada parte del almacén porque sospechaba que en algunas partes del almacén se estaban acumulando sacos sin control y se estaban estropeando. Como constantemente tenían que entrar y salir sacos del almacén, no podía saber cuántos había ahora mismo, así que acordaron ir contabilizando cuántos había en cada zona del almacén y que cada vez que entrara o saliera un saco apuntarían a qué zona iba o de qué zona venía. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.

Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván!

Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó además las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa, pero salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en ningún momento. Claro, todo lo que enseñó lo había probado muchísimas veces antes de hacer la demostración gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una linea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván. El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serían necesarias para lo que había pedido Iván, pero tenía un aspecto “muy profesional”.

Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un 50% más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré nada.”. Era una oferta complicada porque por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis. Mmmmm.

Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.

Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un webservice que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.

Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso aprovechó para anotar algunos criterios que luego les servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo. Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dió por concluida la reunión y se dispuso a trabajar. Antes que nada resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara. A continuación se marchó a casa a descansar. Al día siguiente, cogió la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había venido desde América a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y éste hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este Hudson era realmente veloz e incansable!

A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Le terminaron echando la culpa a todo el mundo. A Iván porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices porque no tenían ni idea de cómo funciona una granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y a partir de ahí generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco tiempo, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aun renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.

Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado. Les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez: “¿Qué estará haciendo Adrián? ¿Cómo lo llevará?”.

Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando, que cada vez que arreglaba una cosa le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde funcionaba a duras penas) y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados… y lo peor de todo: el programa no hacía lo que habían acordado con Iván.

Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.

Moraleja:

Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar “criterios de aceptación”, Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente.

En este libro que ahora tienes entre tus manos, y después de este inusual prólogo, te invito a leer cómo Carlos explica bien clarito cómo guiar el desarrollo de software mediante la técnica de escribir antes las pruebas (más conocido como TDD).

Un cordial saludo,
Jose Manuel Beas

Espero que después de leer esto, los que no hayáis comprado el libro de Carlos sintáis un impulso irrefrenable y lo hagáis rápidamente, y los que ya los hayáis comprado, o al menos leído, dejéis un comentario aquí sobre qué os ha parecido. ¿Cómo mejoraríais la historia? ¿Qué le quitaríais? ¿Le daríais otro enfoque?

Sin miedo a cambiar

by


Tengo pendientes otras revisiones de libros, pero acabo de terminar de leer (en primera lectura) “Fearless Change. Patterns for Introducing New Ideas” y me ha parecido tan, tan recomendable, que no puedo evitar bloguear un poco sobre él.

Este libro explica un conjunto de patrones que podemos usar si queremos introducir un cambio (las autoras hablan de una innovación, que suena mejor). Se lee muy rápido porque está dividido en tres partes bien diferenciadas: una primera donde explica cómo emplear mejor estos patrones, una segunda y muy breve con algunos ejemplos (casos de éxito) y una tercera con cada uno de los patrones explicado bien en detalle. La primera sería el Manual de Usuario y la tercera el Manual de Referencia. ;-)

Las autoras recomiendan comenzar haciéndose Evangelista dentro de la organización donde queremos introducir la innovación. Como Evangelista emplearemos patrones como Test the Waters, Time for Reflection, Small Successes y/o Step by Step, con el objetivo de contagiar la pasión, sin llegar al fanatismo, entre los Innovators (que son los más fáciles de ganar para la causa). Una vez conseguido el primer paso es necesario obtener la complicidad de más gente. Para ello podremos usar patrones como Connector, Guru on Your Side, Innovator, Ask for Help y/o Just Say Thanks. Hay un capítulo muy bueno sobre reuniones, con patrones como Piggybak, Brown Bag, Do Food, The Right Time, Plant the Seeds, External Validation, Next Steps, Stay in Touch, e-Forum y/o Group Identity.

Llegados a este punto ya podemos hablar de comunidad y entonces recomiendan el uso de Just Do It, Study Group, Mentor y especial cuidado con las relaciones personales (Personal Touch, Tailor Made, Shoulder to Cry On).

Y si finalmente todo esto funciona y estáis dentro de una organización capaz de valorar los beneficios que pueda aportar la innovación que defendéis, entonces estaréis en condiciones de convencerlos (probablemente con la ayuda de vuestro jefe, Local Sponsor o Corporate Angel) de que os convirtáis en un Dedicated Champion. Así podréis abordar el siguiente escalón: llegar a las masas (Early Adopters e incluso Early Majority). Hay varios patrones para usar en esta situación, pero seguro que los leeréis pronto. :-)

Para mi gusto personal, el mejor capítulo de todos es el último de la primera parte: “Dealing with Resistance”. Los patrones en este capítulo tienen nombres verdaderamente deliciosos: Fear Less (Sin miedo), Bridge-Builder (Constructor de Puentes), Champion Skeptic (Campeón Escéptico), Corridor Politics (Políticas de Pasillo) y Whisper in the General’s Ear (Susurrando al Oído del General). Suenan un poco a manipulación, pero no sé quién me dijo en cierta ocasión que gestionar y liderar gente consiste en parte en manipularlos.

Es curioso porque algunos de estos patrones los he ido usando a lo largo de mi carrera aun sin saberlo. De hecho, el renacimiento de Agile Spain en parte es debido a que algunos de estos patrones se han ido aplicando (insisto, aun desde el desconocimiento de los mismos). ¡Ay si me hubiera leído este libro antes!

Aún tengo que interiorizar muchos de estos patrones, pero probablemente sólo podré hacerlo cuando tenga la posibilidad de ponerlos en práctica. Espero que no sea dentro de mucho tiempo. ;-)

http://jmbeas.blogspot.com