Mi primera charla en inglés

Era principios de verano cuando mi amigo Israel (@ialcazar) y yo decidimos presentar un “regular talk”, de unos 30 minutos de duración, en la ALE 2013. Como siempre tomamos la decisión en el último momento responsable, es decir, el último día por la tarde, cuando el “call for papers” estaba apunto de expirar, así que enviamos una breve descripción de nuestra charla enfocada al Bus/Truck Factor:

The agile manifesto highlights people over the process, but to what extent its good to concentrate critical information with few individuals of teams?.
A project could fail for a lot of causes, and into these causes are the unplanned circumstances (job change, boredom or any radical change in life that makes developers abandon the project suddenly and without any warning). This is called “”bus/truck factor””, a measure of the concentration of information in a team.
To manage this factor is not easy, because the best developer (the rockstar) could be the biggest obstacle. Is there a way to manage this situation?
During this talk we will discuss the elements that can interfere with software projects and organizations structure and how bus factor could affect them.
How to know what’s our bus factor? What Practices can increase or decrease the “”bus factor”” in our projects and organizations? The intended audience of this talk is everyone who is interested in the knowledge dispersion and team building.
The talk is about:
– Knowledge about how to manage this common situation in the companies
– New ideas about how to build a better communication
– How to improve the relationships into teams
– And other topics related to team building

Pasaron los días y llegó el momento de viajar a Bucarest. Llegamos el Miércoles 28 de Agosto a Otopeni (uno de los aeropuertos de Bucarest) a las 02:00 h. hora local, en el vuelo conocimos a “Antonio”, primera persona interesante que nos íbamos a encontrar en nuestra travesía, que nos permitió ir con él en su transfer hacia el hotel, aprovecho para dar las gracias de nuevo a Antonio porque si no seguramente nos hubiera resultado muy complicado conseguir un taxi a esas horas en ese aeropuerto.

Llegamos al hotel, mientras nos dieron la habitación y deshicimos las maletas nos dieron las 04:00 h. Había que levantarse a las 07:30 h, ¡¡¡Dios mio, no vamos a dormir nada y mañana presentamos!!! Nos fuimos rápidamente a dormir para poder estar lo más frescos posible.

Después de dormir menos de lo que nos hubiera gustado, nos dirigimos a hacer el check-in de la conferencia que era en nuestro propio hotel (Radisson Blue). Acto seguido nos dirigimos a tomar un café al lounge, dónde nos encontramos a nuestro gran amigo y uno de los organizadores del evento, Saket (@saketbivalkar) y a la armada española (Jaume Jornet @jaumejornet, Antonio de la Torre @adelatorrefoss, Adrian Perreau @eidrien, Ángel Diaz-Maroto @adiazmaroto, Ángel Medinilla @angel_m, Toni Tassani @atassani y Antonio Lopez @antoniolopezg), después de charlar un rato, nos dirigimos al primer keynote, en la que Jurgen Appelo iba a hablar de como intentar ser más feliz en tu trabajo.

Después del keynote de Jurgen, nos tocaba ensayar en la habitación. Los nervios estaban apareciendo, estábamos a 45 minutos de exponernos delante de mucha gente y el ensayo fue fatal….. Era la peor noticia que podíamos recibir a esas alturas, se nos había olvidado gran parte de lo que teníamos que decir. ¿Que podíamos hacer? Valientes y decididos, fuimos hacia la planta de la conferencia dónde sabíamos, inconscientemente, que íbamos a sacar lo mejor de nosotros.

Una vez abajo, en la sala donde previamente había sido el keynote, nos dispusimos a conectar el portátil de Israel con el proyector, después de una serie de problemas técnicos conseguimos tener todo perfecto y fue el momento de mirar al público y ver quien estaba en la sala, entre ellos estaban Ángel Medinilla, Saket, Yves Hounille y el mismísimo Jurgen Appelo, lo cual generaba un poco de ansiedad, pero nada que nos despistara de nuestro objetivo, hacer una buena presentación:

2013-08-28 11.31.46

En ese momento Israel dio al play de su reproductor y empezó a sonar Vertigo de U2, una gran canción para abrir una charla titulada “The rockstar developer, a blessing or a problem?”. En ese instante empezó todo, os pongo el vídeo de la charla para que podáis verla:

Después de la charla, nuestro cuerpo se relajó como cuando tienes acumulada mucha adrenalina y te deshaces de ella. El resto del día fue muy relajado, compartimos muchas conversaciones en lounge, sobre todo con la armada española, asistimos a diversas charlas hasta las 17:00 h., hora en la que finalizaron.

El objetivo estaba conseguido, habíamos hecho algo que unos meses antes parecía imposible, y lo mejor de todo es que nos había gustado. EL AÑO QUE VIENE HAY QUE REPETIR!!!

Por último, os dejo las transparencias de la charla por si queréis echarlas un vistazo:

Nos vemos en el ALE 2014.

¿Dónde están mis historias de usuario?

No es un título de una nueva película de Hollywood ni si quiera es una nueva obra que se vaya a estrenar en el teatro Calderón de Madrid, sin embargo si es algo que yo me pregunto, el porqué cuesta tanto tener/hacer historias de usuario, a pesar de dedicarnos a mejorar la funcionalidad de nuestro producto enfocado a un negocio claro y con especialistas de dicho negocio alrededor de nosotros.

Una historia de usuario, entre otras cosas, esta formada por una información clara que hace referencia a:
  • ¿Quién pide la funcionalidad?: Es una muy buena forma de identificar a al persona que lanzó la idea inicial y que nos puede resolver todo tipo de dudas que tengamos al respecto
  • ¿Qué funcionalidad se pide?: Se debe de especificar que funcionalidad tiene que desarrollar el equipo
  • ¿Para qué se pide esa funcionalidad?: El conocer y entender la/s razón/es por la/s que se pide dicha funcionalidad ayuda mucho para poder escoger la mejor opción a la hora de hacerla realidad
  • ¿Cómo sabemos que la funcionalidad esta bien hecha?: De alguna forma el equipo debe de saber cuando la funcionalidad va a estar acabada y se comporta de la forma que se espera, para ello podemos hacer uso de los criterios de aceptación
Las recapitulación de esta información permite al equipo empezar a plantearse una serie de preguntas al respecto de la funcionalidad, para poder acabar de entender ésta y completarla con lo que sea necesario para que sus trabajo sea excelente. Al realizar este ejercicio sobre las diferentes funcionalidades que queremos desarrollar, obtendremos innumerables beneficios que nos permitirán tener el mejor producto posible lo antes que se pueda.
Sin embargo la realidad es otra, la mayoría de las empresas viven en un entorno cambiante y acelerado en el que se suelen cuidar poco los detalles, aunque a veces se intente, como se suele decir el “día a día” no permite hacerlo. Las posibles consecuencias de todo esto pueden ser:
  • Cambios de contexto continuos, pérdida de foco
  • Bugs después de la puesta en producción
  • Frustración por parte del equipo y de la persona que pidió la funcionalidad
  • Posibles retrasos en la entrega
  • Asunciones innecesarias sobre la funcionalidad, dando lugar a funcionalidades innecesarias
  • Problemas a medio plazo con funcionalidades incompletas o distintas a las requeridas
  • Retorno de inversión incierto
  • Probable pérdida de beneficios
  • ….
Conociendo los riesgos/problemas a los que nos enfrentamos, se debería de actuar para que no sucedieran pero, ¿Qué es lo que no nos esta permitiendo hacerlo?:
  • La presión indirecta del mercado
  • El coste de oportunidad de algunas tareas
  • Fechas estrictamente marcadas
  • Querer abarcar muchas cosas, primado la cantidad por encima de la calidad
  • Costumbre de trabajar en un “servicio cafetería“: yo pido y tu me sirves
  • No trabajar como un único equipo y ver a la gente del negocio como alguien ajeno a la tecnología
  • ….
Después de ver todos estos puntos, debemos de actuar para poder cambiar este contexto en el que la mayoría de las empresas nos movemos, y digo debemos porque es un trabajo en equipo (colaborativo), porque no va  a ser posible cambiarlo si no se implica todo el mundo involucrado en el producto, y no se va a poder cambiar si no todo el mundo quiere trabajar en buscar la calidad del mismo. Tenemos que romper con las tendencias cortoplacistas y ver que la oportunidad de mercado no sólo depende de la variable tiempo.
En esta situación lo que deberíamos de aplicar es el sentido común y ver que nos falta comunicación, nos falta tener un horizonte o visión hacia el que tender, nos es necesario ver que no todo lo que hagamos para mañana va a ser mejor por sacarlo antes si no que también hay que tener en cuenta la calidad del resultado, y para ellos necesitamos que todas las personas involucradas en construir las historias de usuario empleen todo su empeño, creatividad e innovación en completar la información necesaria para que los artistas del software las hagan realidad.