El tercer día de la XP2011 tuvo la keynote de Brian Marick, al cual había visto en una charla sobre clojure.  Habló sobre las diferencias entre modelos económicos, hablando principalmente sobre la economía del regalo (gift economy).  Este modelo económico se basa en la aportación de presentes a otro sin establecer un intercambio específico a cambio.  Este modelo puede aplicarse fácilmente a entornos en los que el objetivo es ganar ciertos valores cívicos y sociales, fortaleciendo las relaciones grupales, sin llegar a intercambios directamente económicos.  El mejor ejemplo es ayudar al vecino a colocar la cadena de la bicicleta.  Y crear de esta forma una cadena de favores que favorezca a toda una comunidad, pongamos un equipo de trabajo.

Hubo un momento en el que Brian Marick hizo que la sala se pusiera de pie para bailar unos pasos de tango, intentando demostrar con ello que para realizar un trabajo en equipo, o en pareja, lo importante es saber reaccionar ante los cambios de tu pareja.  El liderazgo cambia, y hay que adaptarse y continuar, no pararse a razonar o discutir.

Las charlas continuaron después al ritmo del día anterior.  La primera a la que asistí fue sobre un caso práctico de teamwork: un análisis del trabajo llevado a cabo por dos grupos en una empresa noruega.  Se expusieron las características y metodologías de los dos equipos (del norte y sur de Noruega).  Poco a poco se van observando diferencias de trabajo y de comportamiento que llevan a los equipos a diferentes situaciones: mientras la zona sur funcionaba correctamente, la zona norte iba cada vez peor.  Los problemas indicados fueron:

• Los miembros escogen tareas pequeñas no prioritarias -> el trabajo de verdad no se realiza, pero el equipo se queja de estar saturado.
• El backlog se llena.
• La motivación baja en cada iteración

Puntos interesantes:

• Se observó que el equipo del norte realizaba las stand ups en tan solo dos minutos.  Las reuniones de retrospectiva trataban exclusivamente asuntos técnicos.  No había intercambio de información relativo al equipo humano.  Sin embargo en el equipo sur, las reuniones se realizaban con normalidad y se discutían asuntos sobre organización, se expresaban opiniones y las stand ups duraban un poco más.
• El equipo de desarrolladores de la zona Norte no tomaba café (!).  La explicación la encontraron al analizar el plano de la oficina.  Resulta que la zona de cafetería era colindante al área de soporte.  El equipo de desarrolladores no usaba la cafetería para así evitar entablar contacto con el equipo de soporte.  En resumen, un equipo de trabajo sin feedback.

Como conclusiones al estudio, el equipo del norte perdió la comunicación con el resto de la organización, la motivación era muy baja y al final la planificación (basada en Kanban) no tenía sentido.

Siguiendo los problemas derivados de una mala interpretación de las metodologías ágiles me metí a la siguiente charla sobre Scrum Zombies.  El scrum zombie se define como aquel miembro del equipo ágil que no “respira” sino que sólo sigue las normas.  Una persona que sólo comunica tareas hechas y por hacer, pero no expresa sus impresiones personales o sus dificultades, no está vivo, hablando en el contexto del equipo de trabajo.

Me gustó mucho este consejo para las reuniones: Hay que ir más allá de las tres preguntas en las stand ups.  Muestra tu trabajo, exprésate!

La metodología ágil consiste en obtener compromisos entre las dos partes: desarrollador y cliente.  Así que como mister de un equipo hay que conseguir el compromiso de cada uno de los miembros del equipo, si es necesario haciendo que firmen la iteración.  No es mal consejo, pero no es para todas las situaciones.

Otros consejos últiles:

1. Consigue que las tareas se discutan en abierto
2. No aceptes tareas grandes
3. Usa la última reunión de iteración para preparar la retrospectiva
4. Céntrate en lo que se ha hecho
5. Publica los resultados de la retrospectiva en la pared.  Que se vea.

Como conclusión final, me recordó mucho a la Paradoja de Zenón: Si te marcas como objetivo una meta que se mueve, nunca alcanzarás tu objetivo.  Para resolverlo, tienes que establecer un objetivo más allá de la meta actual.  Tienes que mirar más allá y mantener tu atención centrada allí.  Si no, nunca llegarás.

Las charlas siguientes trataron sobre historias de usuario. Definición de Listo y Definición de Acabado

Definición de Listo

Cómo podemos saber si una tarea está lista para empezar a trabajar en ella?  En métodos tradicionales, cuando un requisito llega a un programador, éste está “claramente” definido.  En metodologías ágiles no ocurre así y se trabaja con historias más abiertas, que hay que desgranar.  Entonces cómo saber si una tarea/historia está lista para entrar en el backlog?  Básicamente cuando el equipo sabe que se puede empezar a trabajar en ella.  Esto es curioso, porque:

• No necesita estar al 100% definida
• Sólo necesita estar definida lo suficiente como para saber que podrá ser realizada en el tiempo acordado -> estimación en equipo.

Así que, qué debe contener un backlog durante un sprint o iteración?

• Un backlog completamente priorizado
• El backlog contiene todos los bugs, historias, trabajo oculto, y tareas de mantenimiento asociadas
• Todas las user histories cumplen esta definición

Definición de Acabado

La definición de acabado está asociada a todo aquello que se entrega al product owner al finalizar la tarea.  Esto puede incluir documentación, empaquetado, limpieza, etc.  Todo aquello que hace falta para que un producto sea “distribuible”.

Si la definición no está clara, será dificil estimar, medir la velocidad, y los límites de trabajo (WIP Limits), y el cliente tendrá dudas sobre el trabajo.  El trabajo de validación debe tener una lista (más o menos estática) de cosas a auditar  para verificar si una tarea está lista.

Por último en este lote de charlas, me gustó la ponencia de Ken Power sobre una técnica llamada “Agrupación  Silenciosa de Historias”, en la que se realizó un role playing game en el que un grupo de trabajo estima el tamaño de una serie de animales sin mediar palabra entre ellos.

Partiendo del punto de escoger un primer animal y estimar su tamaño, el resto de animales se pueden categorizar fácilmente.  Cada miembro del equipo realiza una estimación, sin hablar con nadie más, y pasa el turno.  Después, todos juntos ante la primera fase de la estimación, y sin hablar, realizan cambios hasta que no se observan más cambios.  Se midió el tiempo en el que un equipo de 7 personas estimaban más de 30 animales usando esta técnica: 5 minutos en total.

A mi me gustó esta técnica.  Resuelve los problemas de discusión en equipos de trabajo, en el que la persona más carismática suele copar la mayor parte del tiempo de la reunión.

Durante la comida nos volvimos a juntar Rafael, Juan, Manuel y yo para charlar sobre las ponencias y compartir información.  Buffet de ensaladas y segundos platos.  Buena comida, buen ambiente y buena compañía.  A destacar los aguacates rellenos de gambas y el lacón que completé con piña.

¿Os acordáis que dije que hablaría más adelante sobre Rafael?  Pues bien, exponía por la tarde una ponencia muy valiente, que hablaba acerca de las bases de las metodologías ágiles, libertad, autoorganización, compromiso, velocidad.  Ver el manifiesto ágil (http://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil)

Emparejando muy acertadamente estos principios con los principios filosóficos de la naturaleza humana definida por Humbolt (“Libertad y diversidad son precondiciones para la autorealización”) y las bases de la implantación del socialismo (“los errores cometidos durante los movimientos revolucionarios son infinitamente más frutíferos que la infalibilidad del comité central más inteligente” – Rosa Luxemburg, “Socialismo no puede ser impuesto por decreto, es un proceso de adopción empírico” – Salvador Allende), estableció la revolución que están acometiendo las empresas en su seno.  No se debe consentir ser esclavo en una sociedad moderna, en una sociedad global basada en la información.  Ya digo que la charla fue valiente.  La ponencia está en esta URL:

http://es.scribd.com/doc/54369597/Lightning-ScrumEssenciaHumanaNovoSocialismo-English-XP-Conf

Antes de esta charla, Angel Medinillas habló con su estilo directo, ameno e impactante, habló sobre cómo el sistema “Command & Control” mata la auto-organización y la motivación por la falta de confianza en tu equipo de trabajo.  Para solventar el problema, establece un plan en 12 pasos para salir de la “adicción” a controlar el trabajo de otros.  Divertida: http://www.slideshare.net/proyectalis/110501-xp2011-treat-them-like-addicts

Y por último estuve merodeando un poco por el OpenSpace, un área abierta, un foro romano, o un ágora griega donde la gente anunciaba un tema y a qué hora se iba a hablar.  Al final me quedé a una ponencia sobre acceptance testing y contract testing, que se basa en establecer tests por capas de interacción, ahorrando el número de tests que hay que realizar.

Con esto terminó mi asistencia a las charlas XP2011.  Viniendo desde un entorno diferente como son la seguridad informática, el soporte y la implantación de productos, esta metodología me recuerda cada vez más a lo que en entornos de help desk y soporte basado en niveles se lleva haciendo muchos años.  Quizás me anime a dar una charla sobre ello algún día.