Agile Open Spain en Madrid

Desde Agile Spain estamos organizando el primer Agile Open en España. Se celebrará los días 23 y 24 de Octubre en las instalaciones de la Universidad Politécnica de Madrid. Apuntáos porque, aunque es gratis, es posible que nos quedemos sin sitio para todos. Llevamos apenas una semana anunciando el evento y ya hay ochenta y tantos inscritos. ¡Vamos a tener que poner lista de espera y todo!

El Agile Open es un openspace al que asistiremos mucha gente de muy diversos perfiles, experiencias, intereses profesionales, procedencias geográficas... algunos sabemos algo de esto del agilismo, otros no, pero todos tenemos en común que tenemos ganas de mejorar nuestro entorno profesional. Y si eso implica tener que desplazarse a Madrid y conocer gente extraña, que utiliza términos como "iteración", "retrospectiva" o incluso "dueño de producto", pues se hace y ya está. :-)

En Argentina ya llevan dos años haciendo este tipo de eventos. ¿Vamos a ser nosotros menos? :-) Por cierto, no quisiera dejar pasar la oportunidad de invitar a todos los argentinos y demás hispanohablantes para que, si podéis, asistáis también. El único límite es el aforo y que las sesiones son de sólo 1 hora. Je, je...

Bueno, bromas aparte, si consigo algunos videos de los Agile Open anteriores celebrados en Argentina, los iré colgando porque así tendréis una idea más acertada de lo que se trata este tipo de reuniones.

Memoria histórica en Internet

Como miembro de la diáspora onubense, me he alegrado mucho al ver un pequeño reportaje en CNN+ sobre la iniciativa de la Diputación de Huelva gracias a la que se han digitalizado miles de documentos relacionados con los muchísimos consejos de guerra ...

Colateralmente estoy muy de acuerdo con uno de los entrevistados que decía:

"El futuro de los archivos no está ni en Salamanca ni en Cataluña, sino en Internet".

Por cierto, ¿es exportable esta innovación? Sospecho que puede haber otros países que, desgraciadamente, han sufrido atropellos similares y que pudieran estar interesados en hacer llegar toda esta información a los familiares de los fallecidos.

Playas de silicio

Esta reflexión me vino a la cabeza cuando estuve en Tenerife hace un par de semanas dando una charla. Allí coincidí entre otros muchos con un holandés que había decidido mudar su residencia y su trabajo a Tenerife simplemente porque el clima era estupendo. (Al menos eso me dijo).

Podéis decir que estoy equivocado, pero creo firmemente que en España no sabemos desarrollar software (¡ojo! ¡me incluyo!). Lógicamente es una generalización y, por tanto, injusta con algunos, pero no estoy hablando de casos particulares sino de "los grandes números". Pero el mundo es muy grande y estoy seguro de que hay muchos buenos y expertos profesionales que preferirían trabajar en Canarias antes que en Groenlandia :) si la infraestructura tecnológica fuera similar. El caso de este holandés que os comentaba antes es un buen ejemplo. Y creo que es interesante esta fórmula de invertir en crear condiciones para atraer talento, experiencia, inversores a las zonas que tradicionalmente exportan "sol y playa". Estas zonas turísticas ya tienen mucha infraestructura que se podría adaptar fácilmente a dar servicio a pequeñas empresas tecnológicas y además tienen una imagen de marca muy atractiva y cultivada a lo largo de años: sólo tendrían que "matizar" su mensaje e, insisto, crear las condiciones necesarias para que los programadores, consultores, diseñadores, etc del norte de Europa y otras zonas del mundo donde tienen mucho menos sol que en España.

Muchos hablan de un cambio del modelo productivo, pues quizás deberíamos ir pensando en fórmulas algo más elaboradas que la mano de obra barata. ¿Alguien se anima?

Sin miedo a cambiar

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. ;-)

Control de proyectos

Dice Tom de Marco en su diatriba sobre la ingeniería del software "Software Engineering: An Idea Whose Time Has Come and Gone?" ("Ingeniería del Software: ¿Una idea cuyo momento ha venido y se ha ido?"):

Así que, ¿cómo puedes gestionar un proyecto sin controlarlo? Bueno, puedes gestionar la gente y controlar el tiempo y el dinero. Le dices a tus jefes de equipo, por ejemplo, "Tengo una fecha de finalización en mente, pero no la voy a compartir contigo. Cuando llegue un día y te diga que tu proyecto terminará en una semana, debes estar listo para empaquetar y entregar lo que tengas como un producto final. Tu trabajo consiste en desarrollar el proyecto incrementalmente, añadiendo piezas al conjunto según el orden de su valor relativo y haciendo integración, documentación y pruebas de aceptación incrementalmente a medida que se va haciendo." Esto puede sonar como una prescripción de métodos ágiles, pero estoy demasiado lejos actualmente de la construcción real de software como para hacer recomendaciones al nivel de metodologías. En cambio, estoy llamando a un enfoque de gestión, uno que bien podría orientar al equipo hacia métodos ágiles, al menos hacia los aspectos incrementales de la escuela agilista.

Y más adelante dice:

Consistencia y predictibilidad aún son deseables, pero nunca deberían haber sido las cosas más importantes. Durante los últimos 40 años, por ejemplo, nos hemos torturado a nosotros mismos con nuestra incapacidad para terminar un proyecto de software en tiempo y presupuesto. Pero como indicaba anteriormente, esto nunca debería haber sido el objetivo supremo. El objetivo más importante es la transformación, crear software que cambie el mundo o que transforme una compañía o cómo ésta hace sus negocios. En cambio hemos tenido éxito al transformar, frecuentemente mientras actuábamos fuera de nuestro ámbito de control. El desarrollo de software es y siempre será algo experimental. La verdadera construcción de software no es necesariamente experimental, pero la concepción sí lo es. Y hacia esto es hacia donde nos deberíamos enfocar. Es hacia donde siempre deberíamos haber estado enfocados.

Espero que la traducción de estos dos pequeños fragmentos sean suficientemente fieles. El objetivo no era hacer un resumen ni tampoco una traducción, sino colaborar en la difusión del mensaje.

Por cierto, si aún no habéis leído nada de Tom de Marco, os recomiendo encarecidamente dos libritos excelentes. Se leen muy rápido y se releen mucho más despacio (como los buenos libros). Se trata de "Peopleware" (Xavi, no se te olvide devolvermelo que está descatalogado en Amazon) y "Slack". Ambos retratan nuestro mundo de personas obsesionadas por conseguir objetivos medibles y dan muchas pistas para tener éxito en quitarnos esas pesadas cargas de encima. :-) Vale, lo pondré en mi lista de resumenes de libros a bloguear.