Mi experiencia en la AOS2011 (parte 2)

Después de una más que merecida noche de descanso toca volver a la carga, y nada mejor para retomar fuerzas como ver el ambiente tan "a la AOS" que hay en el hotel.

Con esa pegatina, este ascensor ha de tener talento :-P

Al llegar al CEIN pasamos por la cafetería para aprovechar ese desayuno tan completo que tenían y recuperar las fuerzas, porque en breve iba a empezar el evento "de verdad". Pero antes, algo de conversación con la gente, en especial con @david_bonilla, su mujer @candelamd y el gran @jerolba, nuevas noticias que no voy a contar yo aquí porque lo hará el propio protagonista en breve (ya sabes, #lodebonilla). Tras este breve tiempo de relax cada cual va a la sala que más le interesa para empezar con la primera tanda de sesiones.

Intership

La primera sesión que he elegido es la de Intership, propuesta por @hell03610, en donde comienza comentando cual ha sido su experiencia en el intercambio que ella misma realizó con @beCodeMyFriend y con Frogtek.

Emma comenta que la primera vez que lo hizo no se lo dijo a sus jefes y compañeros, sino que se cogió una semana de vacaciones y se fue a @beCodeMyFriend por su propia cuenta. A la vuelta le contó a todos su experiencia y lo que aprendió, aunque la gente se quedó un poco extrañada. ¡Has cogido vacaciones y te has ido a currar a otra empresa! es la frase más típica (existen otras como, tú estas mal de la cabeza, es la que me dicen a mi mis amigos cuando hablo de este tema).

La segunda vez que lo hizo, habló con su jefe y ya era un poco más receptivo, por lo que yo deduzco que si haces como Emma y explicas las cosas abiertamente, "cualquier" otro jefe también lo puede llegar a entender. Ten en cuenta que si le hablas de lo que ellos mismos van a ganar con este tipo de experiencias serán aún más receptivos.

Posteriormente salieron, durante un breve periodo de tiempo, algunas cuestiones del marco legal, aunque @jorgeuriarte indicaba que no era un problema y se podía solucionar de forma muy sencilla, por lo que se continuó hablando sobre la experiencia en sí misma y algunas soluciones que se podrían adoptar para fomentar este tipo de actividad en la comunidad (si te interesa, sigue el hilo en el Google Group de AgileSpain).

Otros temas tratados:

• No es realmente necesario llevar acordado el proyecto o la tecnología, puede provocar un poco de ansiedad, pero cuando comienza la experiencia y te das cuenta que con tus propias preguntas aportas valor a la otra parte, todo se lleva mejor.
• @XaV1uzz indicó algo interesante. Si colocas a la gente en los lugares donde más dudas tienes, no solo te pueden dar nuevos puntos de vista, sino que sus propias preguntas pueden hacerte replantear el problema a ti mismo (como se puede observar, está relacionado con el punto anterior).
• Para que el movimiento funcione debe ser totalmente transparente, en ese caso se reducen los problemas de confianza de algunas empresas.
• ¿Se podría crear una "marca de calidad" entorno a la red de intership? Es innegable que este tipo de actividades fomentan el compartir conocimiento, siendo esto así, también es posible que haya empresas que lo vean como un "factor de calidad".

Emma explicando su experiencia

@XaV1uzz dando su opinión

Contratos ágiles

Esta sesión facilitada por @elmendalerenda de @beCodeMyFriend fue bastante interesante, aunque es complicado sacar unas conclusiones claras. Por un lado sí quedo claro que @beCodeMyFriend no factura horas como es lo habitual en el negocio, sino que factura valor entregado al cliente, de manera similar a como lo hacía Eden en su momento (cobraba por pareja de programadores por semana). ¿Pero cómo podemos llegar a esto? fácil ... o no, con trabajo duro y ganándose la confianza del cliente.

Para empezar, algunas de las empresas presentes que facturaban de forma "ágil" a sus clientes, lo hacían dentro un contrato marco previo. Es decir que el cliente y la empresa de desarrollo firman un contrato marco en el que alcanzan ciertos compromisos, pero en dicho contrato no se especifica de forma cerrada el precio ni el tiempo del proyecto (o como máximo uno de los dos). Cada entrega (semanal, mensual, bimensual, ...) se factura por separado. Me recuerda a una idea propuesta por @chozero en una reunión de @AgileCanarias, entregar una bolsa de horas al cliente y que las vaya utilizando de acuerdo a sus necesidades. Por supuesto esto requiere de nuestra participación y dedicación porque el cliente necesitará asistencia y consejo, no podemos quedarnos sentados esperando a que las cosas ocurran por si solas.

Lo que intuyo que hace @beCodeMyFriend (y recalco lo de intuyo porque estas son mis palabras no las de ellos) es reducir los bloques de trabajo a un tamaño más fácilmente estimable, y trabajar dentro de este tamaño, cobrando por dichos bloques completados. Cuándo un bloque está completado es algo que se acuerda entre los desarrolladores y el cliente, pero como apuntaban @elmendalerenda y @XaV1uzz es necesaria la transparencia y la confianza mutua. Esto no es sencillo porque tienes que trabajar muy bien para que el cliente no pierda la confianza en ti, además @XaV1uzz apuntó algo que me gustó mucho y es que tienes que adelantarte a tu propio cliente, proponerle soluciones antes de que sepa que las necesita, que note tu preocupación por el trabajo bien hecho y por querer hacer las cosas mejor.

Por otro lado, la gran duda que me surgió a mi durante la sesión, era si alguien conocía algún caso en la administración pública de este tipo de contratos. Bueno, la respuesta general fue un poco vaga (muchas de las personas presentes no trabajaban para la administración), pero alguno empieza a existir. En estos casos es la propia administración la que ha dado dicho paso y no a partir de la propuesta de la empresa contratada.

@elmendalerenda exponiendo lo que hacen en @beCodeMyFriend

Talento

Tan solo la mención de la palabra talento sugiere muy diversas cosas para cada persona que la escucha, por lo que voy a adoptar un punto de vista distinto para el resumen de esta sesión. Iré comentando las distintas partes del contenido que quedó escrito en la pizarra al final de la misma.

@ialcazar y @rlaina orgullosos ante su propia creación :-P

Al principio de la sesión @ialcazar y @rlaina preguntaron que características se consideraban indispensables en una persona con talento, de lo que resultó:

• Responsabilidad
• Resolutivo
• Cultura corporativa
• Valor
• Aptitud
• Confiable
• Exigencia
• Ganas de aprender
• Eficaz
• Inconformista
• Creatividad
• Marcar la diferencia 
• Altruista

Como se puede apreciar son una serie de características muy amplias y muy centradas en la opinión de cada persona, pero dan una buena visión general de lo que se entiende por talento en un profesional. Cabe destacar que no salió en ningún momento por ejemplo la palabra inteligente ... creo que se debe a que se da por hecho, no una persona con un coeficiente intelectual de 140 sino una persona que sabe aprovechar sus propios recursos para sacar el máximo beneficio. No será la primera vez que veo a una persona con un alto coeficiente rendir menos que otra más "normal". En general se "dibujó" el perfil de una persona en la que puedes confiar, que sabe trabajar en equipo, capaz de hacerse cargo de su trabajo sin vigilancia externa, capaz de tomar decisiones equilibradas.

Esto llevo a la pregunta más obvia posible, ¿cómo se detecta el talento?. Pues hay dos opciones, mediante el método empírico usado por @ialcazar y @rlaina en la sesión de señalar con el dedo, o si llevas una camiseta de @beCodeMyFriend :-) Básicamente esto es lo mismo que decir que no existe una manera infalible, pero demostrado con tanto arte como solo estos dos chicos saben hacer :-D

Posteriormente aparecieron los métodos de "entrevistas" utilizados por algunas empresas, en concreto se habló de Tuenti y Autentia. Básicamente se trata de métodos en los que no se limitan a realizar una entrevista tipo RRHH, sino que se hacen pruebas "reales" de desarrollo. @XaV1uzz hizo un apunte sobre estos métodos en los que él no cree que detecten el talento sino los skills, esto por supuesto no tiene nada de malo, sobretodo porque muchas empresas lo que necesitan son skills y no tanto el talento (aunque es deseable).

Para detectar el talento requieres de más tiempo y diferentes pruebas, por lo que salió a la palestra el método GitHub, esta empresa realiza una "noche de cervezas" una vez al mes y un gran porcentaje de sus trabajadores han asistido al menos una vez a estas reuniones. Es comprensible, en estas reuniones sin ningún tipo de presión la gente suele comportarse con naturalidad dando lo mejor de si mismos. Es entonces cuando puedes hacerle a los candidatos el "test de tripas", es decir que te basas en ese cosquilleo interno que se produce cuando conoces a una persona que tiene talento, más comúnmente llamado intuición.

La cuestión que surge después es, ¿está el talento ya presente en tu empresa?, muchas veces esto es lo que ocurre y no hay que buscar, sino cambiar la propia empresa para fomentar el talento y mantenerlo. No hay que equivocarse, no hablamos de dinero, sino de retos, un entorno agradable, ese tipo de cosas que pueden marcar la diferencia. No puedes esperar que esa persona con talento sea fiel o le guste tu empresa porque sí, tienes que tratarlo bien y fomentar su espíritu de mejora continua. Es importante que si tienes a gente con talento la rodees de otra gente que tenga ganas de mejorar, que lo ponga en situaciones "comprometidas", que fomente el ambiente positivo, porque en otro caso se largará. Por otro lado cuando he dicho que no se trata de dinero, no me refiero a que con 1000 € brutos al mes sea suficiente sino que hay muchos casos en los que aumentar 3000 € la oferta de otra empresa no hace que dicha persona se vaya a quedar en la tuya, hay muchos factores que influyen, pero los más importantes tienen que ver con los retos, la motivación y permitir hacer bien las cosas a los trabajadores.

Lean Code

Por fin había llegado la sesión a la que tanto deseaba asistir, por su naturaleza más técnica. @plagelao utilizó el guión de Chris Parsons para enseñarnos a todos la importancia de un proceso lean y de evitar recargar nuestros procesos de desarrollo con artefactos innecesarios.

Lo que más me gustó es que nos hizo cuestionarnos a todos porque hacemos lo que hacemos al desarrollar código, y porque a veces tendemos a hacer las cosas mal cuando estamos bajo presión. Las iteraciones eran tremendamente cortas y a veces los requisitos cambiaban en medio de una iteración, pero nunca se nos ocurrió hablar con el cliente y explicarle la situación. Siempre estábamos centrados en resolver el problema, esta fue la lección que más me gustó porque en la vida real a mi me pasa muy a menudo.

Me agradó que junto a mi compañero, un chico muy simpático y eficiente llamado Pablo (@pvcarrera) completamos los requisitos solicitados, aunque algunas veces tuvimos que usar parte de la siguiente iteración para completar cosas de la anterior. Pero en ningún momento dejamos de hacer TDD!!! esto es indudablemente WIN!!! Además me reí mucho con @amaliahern, @jacegu, @chozero y @yurenaghm :-D

Dandole a la tecla tan rápido como podíamos

Aprendizaje continuo

Tras una comida que solo puedo catalogar de simple, eficiente, abundante, sabrosa y bien pensada volvimos a la carga. Si digo que me enamoré del CEIN me quedo corto :-) Esta sesión era curiosa, @plagelao simplemente estaba preocupado por la mejora y aprendizaje continuo, por lo que hizo una serie de preguntas que le preocupaban, y cuando tuvo las respuestas ... se acabo la sesión.

Conclusiones obtenidas:

• Involucrar a más gente para fomentar la motivación y la auto-motivación.
• Marcarse metas medibles para saber el desempeño realizado (por ejemplo número de páginas leídas por semana), pero ojo sin que eso suponga estrés o ansiedad porque sino no tiene sentido ninguno. @programania indicaba aquí que él se marcaba unas horas estrictas para aprovechar mejor el tiempo, muy en la línea de la técnica pomodoro.
• Tomando como partida el punto anterior, debe ser una actividad sostenible, es decir que no nos quememos y terminemos por odiar el proceso de aprendizaje continuo.
• Hay que gestionar el problema de lo que no sabes que no sabes, es decir todos esos nuevos temas que desconoces leyendo de un tema que ya de por si desconoces :-P Simplemente aceptarlo y no estresarse, es un camino largo y que no tiene fin (recomiendo leer Apprenticeship Patterns).
• Enseñar y coger aprendices te obliga a aprender a ti también, puede ser una buena manera de forzarte a mejorar.

Para acabar me quedo con la frase de @mgryszko con una copa de vino en la sesión, "lo que no esta prohibido está permitido", este "polaco loco" me cae muy bien :-)

Comunidades locales

Con diferencia el tema más abstracto y que más de lleno me toca, como ya he escrito mucho y este ladrillo podría volverse infumable lo que haré es dejar la foto con las conclusiones que obtuvimos en forma de Starfish Retrospective, igualmente hay un hilo en el Google Group de AgileSpain.

Lo que si cabe destacar es que los problemas de las comunidades locales independientemente de su situación geográfica o su tamaño son compartidos, por lo que cualquier idea venga de donde venga puede ser buena. 

No termino de ver la forma de Canarias :-P

Retrospectiva

Para acabar el evento se realizó una retrospectiva, de la que igualmente solo voy a colgar la foto, porque cualquier cosa que diga solo será repetir lo que indica la imagen.

Tras la retrospectiva se resolvió cuales pueden ser las sedes del AOS2012 ... y serán ... Zaragoza o Canarias :-D

Pues bien, todos los que crean que esto es así, nueva sorpresa, aquí y ahora en nombre de @AgileCanarias y después de haber hablado con mi archienemiga @tolivern :-) hemos decidido crear una alianza y apoyar totalmente a Zaragoza en la AOS2012!!! pero no os preocupéis, es solo porque ellos nos apoyarán a nosotros en la AOS2013, ¿es posible que estén "decididas" las sedes para los próximos dos AOS? espero que sí. Y además así colaboramos con otra comunidad local más, al igual que ya hemos tenido relaciones con @AgileCyL :-D

Foto de familia

Pintxos ágiles

Aunque estaba algo cansado, tras la AOS fuimos a tomar unos pintxos y no me arrepiento, aquí se crearon algunas nuevas ideas y tras la lucha encarnizada con @tolivern por el futuro AOS surgió la idea de asociarnos. En realidad es que yo ya tenía algunos planes para 2012 y organizar AOS2012 también, podía ser un poco casi que imposible.

¿Cuáles son esos planes para el futuro? ... el tiempo lo dirá ... ¿verdad @jmbeas? :-D

Conclusiones

Este AOS ha sido distinto, pero tan fantástico como el anterior en Barcelona, una inyección de energía y moral para volver a seguir trabajando lo mejor posible y mejorando día a día. He echado de menos a mucha gente que no ha venido esta vez, pero me ha alegrado desvirtualizar a otra mucha, conocer gente nueva y tener nuevos propósitos ... por ejemplo aprovechar la CAS2011 para pasar unos días con la gente de @beCodeMyFriend, me hace mucha ilusión :-) aunque me llevaré el casco listo por si @XaV1uzz intenta tirarme algo a la cabeza.

Espero que todos lo hayáis pasado y vivido tan bien como yo.