El pasado día 22 de diciembre celebramos el segundo aniversario del primer coding dojo que organizamos como AGILISMO.es. Luis Rivera, siempre disponible para echarnos una mano, nos prestó las instalaciones de Okuri, también conocidas como Tetuan Valley porque allí tiene la sede esta iniciativa de incubación y aceleración de startups en Madrid. Echamos de menos a Alejandro y Roberto, de Autentia, a los que tanto tenemos que agradecer durante estos dos años. Pero junto a los habituales también estuvo gente nueva. Eso es buena señal.

Hasta aquí no parece un artículo técnico, ¿verdad? Bueno, pues al grano. Durante el desarrollo del coding dojo, con la PomodoroKata como ejercicio, surgió un debate sobre si dejar el número 25 en los primeros pasos del desarrollo es aceptable o no. Xavi defendía la sustitución del 25 por una constante por tratarse de un número mágico mientras que @mikelodeon opinaba que era suficientemente expresivo y que el refactor era prematuro.

Como podeis comprobar en el video de la kata que grabé hace ya dos años, yo también prefiero sustituir el 25 por una constante (minuto 1:40 aprox) por las siguientes razones:

* el método minutesLeft devolviendo 25 es menos expresivo que minutesLeft devolviendo DEFAULT_DURATION
* en el test también hago este refactor aunque el título del test es incorrecto y debería decir "Un pomodoro tiene una duración por defecto", porque realmente me es indiferente cuál sea esa duración
* si realmente hubiera querido probar que la duración por defecto es 25 entonces debería haber tenido un test del tipo: assertEquals("La duración por defecto es 25", 25, Pomodoro.DEFAULT_DURATION), lo que nos habría llevado a pasar esa constante de privada a pública.

Como veis, mis argumentos están basados en la expresividad del código y en que se ajusten a lo que se quiere probar. El trabajo más difícil es siempre elegir bien los tests porque, dependiendo de ellos, nuestro diseño y posterior implementación tomarán un rumbo u otro.

No puedes conectar los puntos mirando hacia adelante; sólo puedes hacerlo mirando hacia atrás. Asi que tienes que confiar en que los puntos se conectarán de alguna forma en el futuro. Tienes que confiar en algo, tu instinto, el destino, la vida, el karma, lo que sea. Porque creer que los puntos se conectarán luego en el camino te dará la confianza de seguir tu corazón, incluso cuando te conduce fuera del camino trillado y eso hará toda la diferencia.

¡Feliz 2012 a todos!

Hace cosa de un año me preparé una charla para practicar entre amigos. Se trataba de un formato muy similar a la pechakucha y la llamamos 15en5 porque se trataba de contar una historia con 15 diapositivas en 5 minutos. Lo cierto es que fue una experiencia muy interesante porque gracias a ello me di cuenta de que se puede decir mucho en apenas 5 minutos. Pero además de las habilidades que aprendí al prepararme aquella presentación, pude aprender algo sobre mi mismo. Y pasado un año, creo que realmente ese aprendizaje caló muy profundamente en mí.

Como excusa para mi charla usé la película “El Mago de Oz”. Supongo que la mayoría la habréis visto alguna vez: Judy Garland como Dorothy, su perrito Totó, las baldosas amarillas, el espantapájaros, el león y el leñador de hojalata… Lógicamente no se trataba de hacer un resumen de la película en 15 diapositivas, aunque eso ya sería un trabajo difícil en sí mismo, sino que traté de contar algo más.

En la historia, tanto Dorothy como el resto de personajes que van acompañándola por el camino de baldosas amarillas en busca del Mago de Oz se consideran a sí mismos como personajes incompletos, a los que, de una manera u otra, les falta algo. Y hacen la ruta juntos con la ilusión de que el Mago de Oz les recompondrá mágicamente, que Él, con sus superpoderes, les hará sentirse completos, así, sin más. Pero resulta que el Mago de Oz es un farsante y no tiene realmente poderes. Es apenas un mago de feria también atrapado en el mundo mágico de Oz. Curiosamente, todos los acompañantes de Dorothy creen que el Mago les ha concedido las cualidades que ellos tanto ansiaban, sin darse cuenta de que en realidad ellos no necesitaban el don pues ya lo poseían: durante el viaje lo habían demostrado sobradamente. El espantapájaros era un líder inteligente y carismático, el león era un valiente y generoso amigo y el leñador de hojalata era cariñoso y con los mejores sentimientos. Todos, juntos, habían conseguido superar muchos obstáculos (en el libro aún más) pero todos piensan que en realidad ha sido el Mago de Oz el que les ha otorgado esos dones. No es hasta el final de la película, cuando por fin Dorothy sabe que desde su llegada al País de Oz había tenido el poder de volver con su familia.

La moraleja de esta historia, la que yo quería transmitir, era que cada uno, por muy incompletos que nos sintamos, no deberíamos emplear nuestra energía en encontrar a un Mago de Oz para que él, mágicamente, nos complete. Es el viaje por el camino de baldosas amarillas, junto a otros mejor, el que nos ayudará a demostrarnos a nosotros mismos que realmente somos capaces de superar nuestras incapacidades.

La firme creencia en esto que acabo de afirmar es lo que me ha llevado a seguir en el camino de baldosas amarillas y a seguir buscando acompañantes con los que hacer más divertido y completo este viaje. A veces me cruzo con mucha gente, algunos de vuelta, que piensan que jamás podrán llegar a Oz y que incluso me dicen que es mejor volver (¿a dónde?) porque “por allí no se va a ningún sitio” y no sé qué pamplinas de “el mundo real”. Otros van corriendo, queriendo llegar antes. Yo, realmente, no voy a ningún sitio concreto así que tampoco sé si voy rápido o despacio… porque inocentemente busco la felicidad, pero no para quedarme allí (“Happiness is a direction, not a place”) sino por el mero placer de andar el camino.

No busco espejismos, arcoiris ni otros escenarios fantásticos como los que lee e imagina niño1 con su libro, tampoco espero que me toque la lotería (aunque reconozco haber comprado un décimo para mi madre con el oscuro deseo de que si tocara me daría parte del premio), ni tampoco creo en Papá Noel, que jamás me trajo nada cuando era pequeño, ni en Reyes Magos, igual que tampoco en el Mago de Oz, ni siquiera en el Mago More (recomiendo encarecidamente su charla en TEDxMoncloa). Simple y llanamente busco un camino que andar en buena compañía: aprendiendo cada día, compartiendo cada día y, si es posible, riendo cada día. Lo cuál no quiere decir que yo sea alguien a quien no le guste sentir a veces esa ilusión como la que seguro han vivido los niños durante este video de Spanair para estas Navidades. ¡Felices Fiestas!

Constatando, como solemos comentar, que la teoría ágil se debe adaptar a cada caso en particular, muchas veces relajando la agilidad, obteniendo la verdadera riqueza y productividad de las múltiples soluciones que ofrece la ingeniería del software.

Lo que me recuerda la keynote que JB Rainsberger dió este año en la Conferencia Agile-Spain 2011.

Rainsberger explica en la keynote cómo, en estos 10 años de Agile, muchos nos frustramos porque no nos funciona nuestra implementación de Agile y por ello comenzamos rápidamente a “innovar” y crear cosas como “post-Agile” pero sin experiencia real en practicar con éxito los fundamentos. Como colofón a su charla, Rainsberger nos aconseja leer sobre eXtreme Programming (XP) y practicar mucho hasta interiorizar los fundamentos. Sólo entonces estaremos en condiciones de adaptar con éxito los procesos a “el mundo real”. Afirmar esto en “el mundo real” parece muy radical, utópico y no sé qué otras palabras más pronunciadas con un tono poco amable, pero lo cierto es que ya era algo que hace un par de años Xavi Gost me avisaba cuando le comentaba mi intención de explorar el Agile coaching y ahora refrendado por la experiencia. Cada vez que me acerco a “el mundo real” y tratamos de hacer Agile (llámese Scrum, XP o lo que sea), el mayor obstáculo es el rechazo de las organizaciones (y las personas que las forman) a cambiar sus procesos. Esos procesos, que presuntamente funcionan, no se pueden cambiar por otros, que siendo “lo que se debería hacer” según ellos mismos, porque los nuevos son muy costosos en el plano de las responsabilidades personales, nos sacan a todos de nuestra zona de confort y nos ponen en la tesitura de atrevernos a equivocarnos (y luego reconocerlo). Y por ello comienzan a retorcer los principios ágiles (los de la parte de atrás del Manifiesto) para hacer el cambio posible y no sé cuantas cosas más, en vez de echar mano de los valores de XP, en particular del coraje y atreverse a realmente intentarlo.

Lecturas recomendadas

Además del seminal de Beck, XP Explained, yo recomendaría también la lectura del de Jeffries, XP Installed, también citado por Rainsberger en esa keynote.

Me gustaría hacer hincapié en el hecho de que el objetivo final de la incepción es llegar a un punto de acuerdo sobre las expectativas del producto que hay que construir. El producto puede ser desde software hasta una silla de madera, eso es lo de menos, lo realmente importante es que todos los que están en la reunión son los que van a construir esa silla de madera, además de los que se van a sentar en ella, los que la van a vender, los que la van a comprar y cualquier otro intermediario. (En un escenario ideal, claro).

Esta semana he hecho una para arrancar un proyecto para el que ya se había hecho una consultoría previa y en la cuál no estaba el cliente ni el usuario final. Eso nos obligó a imaginar mucho sobre los personajes relacionados con el producto. Pero también me obligó a trabajar mucho, como facilitador de la incepción, en tratar de evitar que esa consultoría nos influyera demasiado en la averiguación conjunta de cuál debe ser el plan iterativo e incremental que el equipo debe seguir.

En la otra incepción, el escenario era diferente, aunque quizás no tanto. Se trataba de un producto cuya construcción se ha atascado y no son capaces de poner en producción. Como detectamos que había una discrepancia fuerte entre lo que se entendía que era el producto, planteé esta incepción. Pero durante la sesión fueron saliendo que las discrepancias son muy de fondo. Trabajamos mucho, mucho, mucho en qué no hace el producto y nos centramos sólo en un personaje para tratar de construir el plan para el MVP (Minimum Viable Product) y permitir que construyan sobre él. Wow! Eso costó. Creo, sin embargo, que mereció la pena, aunque sólo el tiempo lo dirá.

Como resumen:

La incepción es una poderosa herramienta si se usa con sabiduría.

Perdón por la pedantería, pero en la práctica he comprobado que no es una receta “for dummies” porque requiere de mucha mano derecha para avanzar y mucha mano izquierda para ayudar a que salgan las discrepancias que permiten avanzar con seguridad. Es una herramienta que puede crear la falsa sensación de tener un buen plan pero, si no se ha sido honesto, puede haber dejado riesgos latentes; o si no se ha contado con todas las personas necesarias (porque es una reunión muy cara) haber construido una imagen falsa del producto.

Esto me recuerda eso de:

Individuos e interacciones sobre procesos y herramientas

P.S.
Si hubiera querido ser psicólogo habría estudiado psicología.

Pero conocer a otra gente que está cambiando el mundo me está pareciendo una experiencia excepcional. Yo les cuento cómo lo hacemos nosotros (los raros del agilismo) y ellos me cuentan cómo lo hacen ellos (los raros del emprendimiento). Y todos aprendemos. Yo les hablo de autoexigencia, autodisciplina y ritmo sostenible y ellos me hablan de flujo de caja, levantarse después de cada fracaso, imaginación, legislación… Y todos compartimos experiencias, ideas, gente que conocemos… generosamente, sin pedir nada a cambio y en un ambiente de optimismo pragmático. (Tranquilos, ya estoy preparando un artículo sobre esto).

Veo en esta iniciativa que apenas está empezando una actitud que ya me es familiar: @picoj, @rosapoo y @javimonsalupe están poniendo mucho cariño. Me recuerda mucho al cariño que he visto en organizar la #CAS_2011 o del #TEDxZgz, o en las cosas que hemos hecho como AGILISMO.ES. E igual que los ponentes y asistentes en estos eventos ponen mucho de su parte para que todo funcione bien, también lo ponen “los profes” de este #iniciador_kids. @FMorenoNieto (del que podría escribir un artículo sólamente dedicado a él) y @fabianaco (@contoplanet) ponen mucho cariño para que los niños puedan jugar a ser emprendedores. Fernando se los explicaba muy bien el primer día:

Os voy a explicar cómo jugar a un juego y luego, si os gusta, vosotros podéis seguir jugando incluso de mayores.

Estas coincidencias no pueden ser casuales. Hay algo que nos empuja a todos de la misma manera. Yo creo que son las ganas de cambiar el mundo. Unas ganas que no caben dentro de los esquemas habituales y que, poco a poco se van encauzando gracias a las redes sociales o a padres y madres como los que han traído a sus hijos a este #iniciador_kids. Cada uno a nuestra manera, con más o menos implicación, con más o menos habilidad, vamos dando pequeños pasos, sin grandes ambiciones en el corto plazo pero con una gran ambición en el largo plazo.

Y mientras, los niños se empapan de una actitud activa frente a los retos que les presentan varios dueños de varias empresas cada uno. Y algunos, como @alexperezpaya (amiguete de @licuende o @izqui9) y que ya había oído hablar del video de Thomas Suarez, hablan de WebViews, de Python o le oigo pasear explicando a un amigo cómo se comenta el código para que quede más claro. (Bueno, para los más exigentes, vaya en su descargo que apenas tiene 15 años y que ya me preguntó por mi pulsera de Clean Code, así que no todo está perdido)

Y otros serán diseñadores de balones de fútbol, venderán pelos de famosos o buscarán actividades menos novedosas, como una tienda de Legos. Eso sí, y habrán pensado en la promoción con sus propias páginas web, claro. ¿Se puede pedir más? Bueno, si es por pedir, que los mayores sigan el ejemplo de los pequeños. ¡Ah! Perdona, que esto no es “el mundo real”.

El caso es que David Calavera por fin ha conseguido su “green card” y se puede mudar establemente a San Francisco (California, USA) y tuvo el detallazo de compartir con nosotros cómo trabajan en su actual empresa: Engine Yard. Para poneros en contexto antes de empezar, Engine Yard es uno de los mayores proveedores de PaaS del mundo y tienen una facturación anual de varios millones de dólares. El trabajo de David, tal y como él lo describió consiste en desarrollar aplicaciones y servicios para sus clientes (considerando a ellos mismos como los primeros clientes).

Pues bien, David nos explicó cómo trabajan en Engine Yard y nos dijo que ellos no hacen Agile. De hecho, y creo reproducir literalmente sus palabras:

Si alguien dice Agile yo dejo de escuchar.

La manera de trabajar en Engine Yard es simplemente razonable y adaptada a sus necesidades y cultura. Son un equipo muy unido, maduro y cualificado. No necesariamente en ese orden.

Agile slaves

David nos estuvo hablando del proceso de desarrollo. Cómo planifican un mes de trabajo pillando funcionalidades nuevas entre todos, sin un dueño de producto ni nada por el estilo. Es una reunión donde todos tienen voz y voto pero donde se demuestra que todos (dirección y programadores) están muy alineados alrededor de la visión y la misión de la compañía y de los productos que tienen que construir. Claro, eso no encaja mucho con otros modelos de negocio ni, sobre todo, con otras culturas empresariales. Ésa era justamente la clave de la charla de David. Nos estaba tratando de decir que ellos no siguen un proceso según ningún libro porque ha sido un proceso de maduración al que han ido llegando entre todos y a lo largo de mucho tiempo.

Me llamó mucho la atención el nivel de madurez de la compañía porque el departamento de marketing espera a anunciar los productos cuando estos están listos y no antes, lo cuál, entre otras cosas, evita la necesidad de gestionar las expectativas.

Bomberos, mecánicos y programadores

Todas las semanas hacen cambio de pareja (SIEMPRE, SIEMPRE, SIEMPRE trabajan en pareja) y cambian también en el foco de su actividad porque una pareja se dedica a “apagar los posibles fuegos” que puedan surgir durante esa semana, otra se dedica a “reparar defectos” y el resto está enfocada en trabajar. Se reunen lo menos posible pero no por ello no saben lo que se cuece ni dejan de ayudar a otros cuando es necesario.

Con el tiempo (y mucha constancia) han llegado al famoso “despliegue continuo” entre otras cosas porque se han dado cuenta de que es mucho mejor poner las cosas en producción en cuanto están hechas para evitar luego el dolor de los “merges”. Claro, todas las funcionalidades están parametrizadas para evitar que las vean los usuarios que no deben verlas.

¡Ah! Y que no se me olvide. No tienen herramientas para medir la cobertura de tests porque todo lo que está en producción tiene sus tests (automatizados, claro). Y están seguros porque SIEMPRE, SIEMPRE, SIEMPRE trabajan en pareja, con lo que además del “code review” continuo, sumas la “autoexigencia redundante”

En resumen

Suscribo 100% las palabras de David:

El fin no es ser ágil porque eso no hará que funcionen nuestros productos. El fin último es tener un producto genial y las metodologías son simplemente el medio.

Y agradezco mucho que haya compartido esto que, siendo una realidad, para muchos nos resulta una utopía y para otros un imposible. Pero creo que es mucho más sencillo: es simple pragmatismo. Otro día hablaré de pragmatismo, optimismo, el mundo real y de cómo las utopías se hacen realidad.

Voy a tratar de explicarlo un poco más porque quedaría demasiado simple. En el TEDx Zaragoza pude comprobar que hay gente genuinamente feliz, algunos extremadamente felices e incluso hasta incómodamente felices. El envidioso que todos llevamos dentro me ha dicho más de una vez eso de “no se puede ser tan feliz: eso sólo puede ser una pose”. Sin embargo, creo que lo que he descubierto tras este “congreso” es que cada cuál vive la felicidad a su manera. No hay una definición universal de felicidad, pero sí hay gente más o menos proclive a ser feliz. Por ejemplo, Bob Esponja es MUY proclive a ser feliz.

Echando mano de mis notas leo el comentario de Jorge acerca de la estupenda charla de Barbara Ehrenreich:

La felicidad no puede ser impuesta.

Efectivamente, cada uno de los que allí estuvimos estaba interesado en un aspecto de la vida diferente, porque cada uno es diferente, y tenemos nuestras propias necesidades, miedos, pasiones… y seguro que podremos acordar que es algo simplista pretender que haya una única definición universal de cómo gobernar nuestras vidas para alcanzar la felicidad. Así, recuerdo cómo Allison Massari hablaba de que además de mucho amor y amigos, en ocasiones necesitamos también muchas agallas para ser felices. Idea muy relacionada con la charla de Enrique Comba donde casi daba forma corpórea a la resistencia que representa nuestro sistema límbico (el cerebro reptiliano) a la hora de tomar decisiones. Y también recuerdo cómo Pablo Herreros nos explicaba que hemos olvidado, como primates, el valor de cooperar entre nosotros para sobrevivir, hasta el punto de poner en peligro nuestra existencia como especie. Recuerdo a Juan Gasca hablando con pasión sobre cómo había ayudado a los chavales del catering para presentarnos uno de los desayunos más originales en los que he estado y del que seguro que se pueden sentir muy orgullosos. Y por supuesto recuerdo a Paco Salvador (@quesitosgiver) hablando de la generosidad como un activo incalculable en términos de felicidad. O a Maica, una antropóloga que quiere cambiar el mundo que me decía en el viaje de vuelta que había vuelto a creer en la Humanidad. O a Lucas (@CalvoConBarba), Teresa y su marido Alberto, Pablo, Rubén y todo el equipo en general… que nos decían exhaustos, con una sonrisa de oreja a oreja y con el corazón en un puño… TODO A LA VEZ… que su sueño se había hecho realidad.

Efectivamente, Nigel Marsh lo explica estupendamente en uno de los videos que vimos de un TEDx en Sydney:

Small things matter.

Por eso, para mi, estar sentado tranquilamente junto a “niño2″ puede ser un momento de felicidad.

Cuando abrí mi caja con el kit para difundir la felicidad (que he de reconocer que está sin usar a fecha de hoy) #FAIL me encontré con la chapa que ilustra este artículo. Me pareció tan increiblemente acertada la frase que no acepté intercambiarla con nadie. Efectivamente, la felicidad no es un lugar al que ir sino un camino que recorrer porque (permitidme que cite el título de mi blog) “Se hace camino al andar…”. Y por eso mismo no creo que haya un futuro de la felicidad sino un presente, el que hacemos en cada instante de nuestras vidas, con nuestros pequeños detalles.

No quiero terminar sin agradecer a TODOS los que me hicieron pasar un extraordinario fin de semana con todos esos pequeños detalles. Un abrazo de varios segundos para todos.

En nuestra sociedad, nuestro estilo de vida premia los mensajes cortos, rápidos, originales, sorprendentes… brillantes. Todo lo que no se pueda consumir como un anuncio de televisión nos acaba resultando pesado, aburrido, casi indigesto. Esta regla la aplicamos a los telediarios, a los mensajes de los políticos, a la comida, a los libros o el cine, a las charlas más sesudas e incluso a las conferencias profesionales.

Los telediarios tienen un formato parecido a la lectura rápida “en diagonal” de un periódico: un pastiche de telegramas deslavazados que no dan la oportunidad al telespectador para reflexionar sobre la avalancha de mensajes que está recibiendo. En este espacio, muchos agentes tratan de incorporar su mensaje porque saben que, con un solo disparo, llegan a muchísima gente. Como ejemplo de actualidad están los mensajes electorales. Los partidos, especialmente los mayoritarios, que tienen más medios y mayor capacidad de influencia, tratan de colar sus mensajes en un formato aún más breve. El telediario conecta con el mitin de turno, se enciende una luz en el atril y el político suelta el anuncio de que va a subir las pensiones o que va a bajar los impuestos. Desgraciadamente, la letra pequeña no es relevante en estos casos. Al menos en los anuncios de coches te explican las condiciones de financiación, aunque sea a la velocidad de un neutrino.

Nuestra alimentación también se ha resentido. Vamos a restaurantes “de menú” para comer en menos de una hora y llevamos a casa “platos” precocinados, a los que tenemos la desfachatez de adjetivar como “caseros”; en el colmo del paroxismo gastronómico somos capaces de hablar de “las croquetas de la abuela” para referirnos a unas croquetas ultracongeladas. Se ha convertido en normal consumir conservantes y colorantes capaces de transformar un insípido líquido espeso de color indeterminado en una sabrosa y atractiva crema de zanahorias que servimos sin pudor a nuestros hijos.

La lectura no se ha librado tampoco de este efecto “colapsador”. La mayoría de los libros o películas de gran consumo son de una estructura tal que no representan un gran reto intelectual. Las editoriales piden a los autores que no usen formatos complicados para el lector medio y que las historias sean lo suficientemente sencillas de entender para que no se pierdan y sigan leyendo… y consumiendo la segunda, tercera, cuarta parte…

El formato TED, del que he de confesar que estoy enamorado, o el formato Pecha Kucha, son otros ejemplos de condensación de ideas. Pensamientos muy elaborados, pero presentados en apenas unos pocos minutos. En la radio oigo concursos de microrrelatos y soy un asiduo de Twitter. A veces tengo la sensación de que toda la sabiduría y las emociones del mundo se podrían condensar en un haiku.

Y finalmente llegamos a las conferencias profesionales, a las que les pedimos también que tengan esa capacidad de iluminación, de ilustración, de sorpresa incluso.

Por otro lado, cuando somos capaces de detener por un momento nuestra vida acelerada, por ejemplo cuando salimos de vacaciones a algún pueblo del interior o a un país “sin civilizar” o simplemente haciendo una barbacoa con nuestros amigos, entonces nos damos cuenta de que somos capaces de charlar tranquilamente con otros y poner en jaque nuestras creencias basadas en los mensajes recibidos por twitter, radio, televisión… también somos capaces de cocinar tranquilamente nuestra propia comida, a fuego lento; a veces incluso somos capaces de percibir los sabores de los productos cultivados tranquilamente, durante meses. Incluso cuando conseguimos encontrar ese tiempo mágico de leer tranquilamente un cuento a nuestros hijos nos damos cuenta de matices que no percibimos en nuestras relaciones del día a día. Esa capacidad a veces perdida de “tener tiempo” es un bálsamo maravilloso que nos aclara la vista, despeja el olfato, afina el oído, amplifica el gusto y, sobre todo, sensibiliza el tacto. ¿A cuánta gente habéis abrazado últimamente durante más de 3 segundos?

Esta semana, pensando en este artículo y leyendo la resaca de tweets y blogs acerca de la CAS2011 he sentido mucho de estas dos sensaciones. Por un lado he visto cómo esta necesidad de ir siempre más allá ha concentrado muchos esfuerzos de organizadores, ponentes, patrocinadores y asistentes en hacer La Mejor Conferencia Jamás Vista. Por otro lado, he visto muchos mensajes profundos y elaborados que requieren más reflexión por mi parte para aprender de ellos. Ambas visiones son, en mi opinión, dos caras de una misma moneda: una comunidad que está aún muy en pañales, ni siquiera me atrevería a decir que estamos en la niñez y mucho menos en la adolescencia. Personalmente ya he dicho en muchas ocasiones que no creo que la gente que hoy nos congregamos en torno a las metodologías ágiles seamos exactamente la comunidad agilista; creo más bien que somos profesionales del desarrollo de software que buscamos maneras de mejorar y que estamos encontrando una manera de rodearnos de gente con intereses similares. En este sentido creo que aún somos un bebé que apenas empieza a dar pistas sobre cuál será su personalidad en el futuro. Nos queda muchísimo camino aún por recorrer y muchos errores que cometer. ¡Y ya veréis cuando lleguemos a la edad del pavo! Por eso creo que no se puede ser tan exigente con la CAS2011 como con la Devoxx 2011, por ejemplo, ni tampoco caer en la autoindulgencia.

Para ilustrar mejor lo que digo y abandonar el a veces pedregoso terreno de las metáforas, voy a dar un par de ejemplos. Empezaré por hacer autocrítica. Yo, por ejemplo, puse a mis propuestas de sesión títulos y descripciones llamativos con la intención de que fueran atractivas y las aceptaran: “El jardinero fiel (y ágil)” y “Show me the money”. Desgraciadamente, la que tenía más ganas de hacer porque la estaba trabajando con Enrique Amodeo fue la que descartaron. La otra fue una especie de impulso de última hora que no había reflexionado demasiado y a la que, a pesar de trabajarla muchísimo, no conseguía encontrar la manera de contar lo que había comprometido en la descripción de la charla. Finalmente, gracias a conversaciones que tuve con mucha gente, especialmente en el coche con Germán del Zotto y en el hotel con Israel Alcázar, el jueves decidí no asistir a la charla de Jorge Baez contando la experiencia de despliegue ágil en Idealista, pero fui capaz de poner en orden mis ideas y darle forma a mi discurso final. Tuve que pagar el alto precio de perderme una de las mejores charlas de la CAS2011 según me han contado, y por ello debo buscar una manera de evitarlo en el futuro. Se me ocurre que no debo proponer ninguna sesión que no tenga suficientemente preparada, para ello voy a meter en mi backlog el estar constantemente preparando charlas. Así, si me aceptan una, sólo tendré que trabajar “la puesta en escena”.

Como ejemplo de las charlas que requieren una mayor reflexión podría hablar de ambas keynotes, la de Xavier Quesada o la de J.B. Rainsberger, o incluso de la, para algunos, insulsa charla de Enrique Comba. Como están grabadas, el tiempo, vuestro criterio y la reflexión que todos haremos de ellas las pondrán en su lugar. Sin embargo, sí me gustaría poner como ejemplo la sesión de Javier Acero. Javier, al que conozco personalmente y por el que tengo un gran afecto, creo que representa muy bien el perfil de alguien a quien me gustaría poner en valor especialmente. Ésta era la primera charla de Javi en una Conferencia de este calibre, y estoy segurísimo de que no será la última. Su sesión sobre legibilidad del código estaba muy cuidada: se notaba. Pero lo mejor de la sesión fue cuando terminó. Preguntó si alguien tenía alguna pregunta y todos-todos nos quedamos en silencio. Aún estábamos noqueados por el mensaje:

Escribid el código para que os entiendan otras personas, no sólo para que os entienda la máquina.

Había sido devastador. Mi sensación era: tengo que pensar sobre esto y actuar, tengo que buscar maneras de ayudar a escribir mejor código. Javier había conseguido sacarme de mi circuito de estímulo-recompensa facilón y me había creado la necesidad de reflexionar. Gracias, Javier, eso es justamente para lo que creo que sirven las Conferencias. Javier hizo un esfuerzo muy generoso, igual que todos los que se expusieron frente a todos y dieron una parte importante de su tiempo para preparar esos discursos que nos hagan pensar por un par de días y darme la oportunidad de contrastar esas reflexiones con los que allí asisten. En general, eso no lo hicimos. Y eso forma parte de nuestra deuda como asistentes. Yo asistí a pocos debates, la verdad, y creo que eso es justamente lo que más eché de menos, sobre todo si comparo con la experiencia en los Agile Open que ha organizado Agile-Spain o en los pequeños openspaces que han organizado en 2011 gente como Raquel Laina en Decide o Jesús Jiménez a título individual.

Tampoco he visto que hayamos compensado a los organizadores, todos ellos voluntarios, con un ejercicio de generosidad comparable al suyo, y eso también se debe añadir a nuestra deuda como asistentes. Mi sensación general es que muchos hemos ido (me incluyo) a una Conferencia “a mesa puesta” y nos hemos permitido el lujo de criticar sin aportar nada más que nuestra asistencia, el desplazamiento y quizás el coste de una entrada (muy barata, por cierto). Lógicamente, no incluyo a los patrocinadores ahí porque ni he estado en la organización ni he patrocinado nada. Los organizadores han cometido errores, han intentado fórmulas nuevas, algunas han funcionado y otras no, y han acertado en muchas cosas. Organizar una conferencia para unas 250 personas en un sitio donde pudiéramos tener todo lo necesario, conseguirlo en tan poco tiempo y además sacando tiempo de su vida personal no es nada fácil además de muy generoso. Lo mínimo sería ofrecer nuestra ayuda para lo que sea necesario y ayudar a resolver cualquier inconveniente antes, durante y después de la Conferencia. Quizás deberíamos pensar que la camiseta que nos entregan al registrarnos no es un regalo sino una obligación para el que la lleva, la obligación de colaborar con la organización para hacer La Mejor Conferencia Posible. Autoorganización: ¡eso sí sería ágil!

En mi opinión, la Conferencia Agile-Spain 2011 ha sido buena, pero podría haber sido mejor si nuestra actitud hubiera estado más dispuesta a aprender, compartir y ofrecer lo que sabemos. Tengo la sensación de que nos gusta llamarnos Comunidad pero no siempre estamos en ese estado de ánimo generoso y orientado a la colaboración desinteresada. Han faltado voluntarios y, en mi opinión, muchos de los tweets y blogs que he leído estos días están escritos como si esperaran algo de los demás en vez de explicar lo que ellos han aportado a esta Conferencia o lo que van a aportar a la próxima. Creo que estamos, como comunidad-aún-por-hacer que somos, en un estadío en el que nuestro comportamiento es muy egoísta y nos miramos demasiado al ombligo y ni tan siquiera somos conscientes de que tenemos que aprender a andar antes que a correr.

Dicho esto, creo que tenemos una nueva oportunidad de mejorar participando activamente en la organización de la Conferencia Agile-Spain 2012. ¡Yo me apunto!

Hasta aquí tenemos en nuestro espacio de trabajo un repositorio sincronizado con el remoto “origin”. A partir de ahí ya podemos tener a más compañeros trabajando con nuestro repositorio haciendo:

$ git clone "url hasta miproyecto.git en servidor"


Si con ssh accedemos al sistema de archivos en el servidor remoto veremos que hay una carpeta llamada “repos/miproyecto.git”, pero si queremos replicar el contenido podemos hacer:

$ git clone "trayectoria hasta repos/miproyecto.git"
$ git pull


Tengo que ver cómo simplificar muchas de estas tareas y cómo usar ramas, en este sentido tengo aún pendiente leerme este artículo.