En la primera vez que asisto a una conferencia sobre metodologías ágiles, me encuentro una buena recepción, bien organizada, que me suelta una bolsa de tela llena de cosas según le digo mi apellido y le muestro mi ticket.

Veamos que contiene:

• tarjeta identificativa con los tickets de comida (guay!)
• 2 camisetas (gracias Paradigma Tecnológico)
• diploma acreditativo
• flyers varios de productos
• marca páginas con los shortcuts de eclipse y vi (gracias Autentia)
• 2 sets de cartas para el planning game (gracias Autentia y Microsoft)
• el libro de ponencias
• un mini boligrafo  (gracias Microsoft Azure Division)
• un pendrive de 4GB (gracias IBM)
• y una libreta estilo Moleskine (gracias Autentia)

Les pido una guía de ponencias y salas y ¡sorpresa! tienen.

Para comenzar, me meto en el workshop que dan sobre “Making feedback work in your teams” de Mark Needham (@markneedham) en equipos de trabajo (en inglés) y aunque me cuesta entender al ponente, al final termino participando exponiendo los problemas que puede tener un team leader ante la situación de que nadie quiera reconocer un error.  He hablado un poco con él y le he preguntado un par de cosas relativas a cómo abordar una ronda de reuniones con todas las personas de la organización para obtener feedback y también cómo mantener el flujo de información y la confianza una vez establecida.  Me ha recomendado el siguiente libro para que le eche un vistazo: “Discussing the undiscussable”.

El workshop termina temprano y nos vamos a tomar café.  Aquí ya coincido con un brasileño que anda tan perdido como yo, ya que se ha venido a la conferencia y  de vacaciones por España.  Ya os hablaré un poco más sobre él.

En el coffee break nos tomamos café (bueno), pastas (muchas y buenas), y zumo de naranja (regular).  Si, como veréis, voy a hablar de comida, porque es indispensable para aguantar varios días de charlas.

Después del coffee break y en vista de que el workshop había terminado, me voy a la charla de “Self-Organizing Agile Teams: Beyond the Buzzword” de Rashina Hoda y Esther Derby, pero está hasta arriba, así que miro en la de “Agile Software Development with Distributed Teams”, de Jutta Eckstein (http://www.jeckstein.com/) dado que posiblemente tengamos que implementar canales de comunicación con gente que no esté físicamente en la oficina o simplemente para facilitar el teletrabajo.  Esta conferencia me ha gustado mucho por los múltiples ejemplos que ha puesto la ponente y también por que ha tenido el apoyo de los asistentes para aportar ejemplos y opiniones.  Revisaré más adelante la ponencia para ver si hace referencia a las soluciones de las que se hablaban en equipos repartidos por distintas zonas horarias.

Puntos con los que me he quedado de esta reunión:

• La confianza está asociada a la proximidad, sin ella está casi demostrado que la confianza se mantiene entre 8-12 semanas.
• Es más difícil restablecer un vínculo de confianza que establecerlo por primera vez.
• Las diferencias culturales existen, pero hay que salvarlas centrándose en las similitudes.
• Un equipo necesita:

1. una visión común, unas reglas y unos valores compartidos, ya sea centralizado o distribuido
2. respeto mútuo y confianza

• Importancia de las retrospectivas en un equipo distribuido: redefinir las reglas y los valores comunes.  Reforzar la historia conjunta.
• División de la retrospectiva en equipos distribuidos: locales, virtuales, entre equipos y entre sedes.  Importancia del facilitador de la comunicación.

Y por último, mi favorito.  Está demostrado: las iteraciones, de dos semanas.  Resulta que es la duración ideal que hace balance entre garantizar la entrega de funcionalidades  y mantener un  bajo nivel de riesgo en el proyecto.

Sobre la comida, buffet libre para todo tipo de menus.  Nos sentamos a la mesa el brasileño, Rafael Viveiros (@rviveiros) y yo para charlar sobre la situación de los países y la complejidad de España.  También hablamos sobre metodologías ágiles y su experiencia en Brasil.  Me monté un par de primeros platos, consistentes en verduras frías y asadas, seguido de una paella y de postre unas natillas (o custard, que nos costó encontrar la traducción a inglés y eso que volvimos loca a una chica del catering, por cierto, muchas gracias).

Por la tarde comenzó la charla más larga de todas, “Getting started & leading a Kanban initiative”, de David J. Anderson (http://www.agilemanagement.net/) que nos habló de cómo afrontar un proyecto usando Kanban y cómo mejora la eficiencia y satisfacción mostrando métricas cuantificables generadas de sus proyectos y estableciendo SLA’s en base al conocimiento obtenido.  Muy revelador.  Ejemplo: un proyecto de 155 días usando metodologías más tradicionales, podía rebajarse a 25 días, garantizando la satisfacción del cliente haciéndole partícipe del proceso de creación y estimación de los requisitos.  ¿Locura?

De esta charla saqué tres páginas de apuntes, y varias fotos que publiqué en mi twitter (@jmoratilla) de distintos modelos de tableros Kanban.  Esto ayudará a la mejora de nuestro tablero y del uso que hagamos de tarjetas (la mayoría usa post-it de colores y actualizan la información en el mismo pegando otros post-it encima).  Con lo que me quedo es con lo siguiente:

Kanban ayuda a definir:

• tipos de items de trabajo (Change Requests, Requisitos o Epics o User stories) en base a: origen, destino y workflow ( a nivel de equipo de trabajo ) asociado.
• estados del workflow = columnas del tablero
• clases de servicio => ayuda a establecer contratos de nivel de servicio (SLA’s)
• cadencia en entrada (en el backlog) y salida (delivered features)
• métricas y generación de informes => ayudas al feedback.

Una idea con la que me quedo: “Definir el requisito con el cliente, delegarle la estimación al cliente”.  Afirma que las estimaciones realizadas de esta forma aciertan más de un 95% de las veces.

Se habló bastante sobre los límites del Trabajo En Progreso (WIP Limits), y las conclusiones fueron estas:

• Límites bajos son mejores, aunque el límite puede variar en base a la política de la organización y la experiencia empírica.  Valores más comunes: 2, 3, 4.  No más de 5.
• Comenzar siempre por una historia por persona.  Incrementar en base a las necesidades por proyecto y la capacidad demostrada del equipo.

Y al finalizar la charla, me quedé hablando con Miguel Miranda sobre herramientas de Análisis estático de código (parece interesante para temas de Q&A.  Un ejemplo sería KlocWork) y conociendo a gente como Roberto Canales (@rcanalesmora) que me ha dado algún consejo que otro que seguramente ponga en marcha desde ya (a ver dónde dejé el libro del “Arte de la guerra”…)

Al final del día he acabado con la cabeza llena de ideas, algunos cambios que podríamos comentar después de la reunión de cierre de iteración y ganas de tumbarme en un sofá con los pies en alto y degustar una cerveza al más puro estilo perl.