mayo 25, 2011

Eventos en zona norte:

Este mes y poco que resta hasta finales de Junio se presenta muy intenso, te invito a que te unas a cualquiera de estos eventos que tenemos por esta zona del norte, donde podremos coincidir!

  • 28/Mayo: Katayuno y Merendojo, donde estaré haciendo un pequeño taller de historias de usuario (esa es la presentación en que me basaré), cortito pero intenso, ya que Luis me lo propuso. Te puedes apuntar!
  • 1/Junio: Reunión habitual de la zona norte de agile-spain. Más info en el blog apuntado.
  • 3/Junio: Reunión del grupo The Mêlée, al que tenía demasiado abandonado lamentablemente, y resulta que ahora vuelvo con charlita incluida :) , acompañando a Guillermo que nos hablará de control de versiones.
  • 17-18 Junio: El Agile Open Spain vuelve con fuerza, tras vender en 4 horas (¡4!) las 150 entradas disponibles. Este año he vuelto a colaborar con la organización de tan magno evento, así que... ¡¡Allá nos veremos!! Quizás esteis a tiempo de apuntaros en la lista de espera si no lo habeis hecho ya.
Creo que me toca sudar la camiseta antes de las merecidas vacaciones.

mayo 12, 2011

Peligro, las herramientas te cambian de objetivo

Generalmente buscamos en las herramientas que empezamos a utilizar la respuesta a un problema. Tenemos una necesidad que queremos cubrir, y creemos que una determinada herramienta la cubre: necesidad de llevar el control de incidencias, necesidad de orden en el desarrollo, necesidad de comunicarnos,...

Generalmente estas herramientas acaban fagocitándonos y cambiandonos el objetivo que queríamos alcanzar con ellas. Nos olvidamos de nuestra necesidad inicial, y alimentamos al monstruo en que se convierten.
En vez de minimizar las incidencias, nos quedamos satisfechos con que estas estén en la herramienta de control. En vez de procurar aprender a desarrollar software, nos quedamos tranquilos sabiendo que seguimos los pasos de una metodología -herramienta- que nos dicen que es buena. En vez de hablar, nos comunicamos por messenger o por correo electrónico.

¿cuando ha sido la última vez que pensaste que las herramientas te dominaban?

mayo 09, 2011

Retrospectivas: Busca necesidades y no problemas

Cuando planteamos problemas en una retrospectiva, generalmente tenemos una idea ya prefijada de las causas que los pueden estar produciendo. Esto nos lleva a plantear muchas veces la lo que creemos que es la solución como el propio problema o impedimento a solucionar que tenemos.

Sin embargo, creo que hay que llevar a las retrospectivas la verdadera necesidad que tenemos, aquello que si lo conseguimos, podremos hacer mejor nuestro trabajo. Esa necesidad es la que debe ser compartida con el equipo, para entre todos, buscar sus causas posibles de que no suceda.
En un sistema complejo como un desarrollo de software (Management 3.0), la causa-efecto no es linear. Las cosas que suceden pueden tener más de una causa, y por tanto no siempre las mismas causas desencadenan los mismos efectos. Esta complejidad añade más valor a analizar los problemas por el equipo, con más visión que sólo la de una persona. Si planteas tu necesidad al equipo que no puedes conseguir, es más facil averiguar las causas de manera colaborativa.
En resumen, podrías plantear situaciones ideales en vez de problemas. Y averiguar cómo llegar a esa situación, eliminando las causas que te lo impiden. ¿no favorecería esto el aprendizaje y la visión compartida, al establecer la meta antes que el camino?

Me gustaría compartir además algunas ideas que he ido obteniendo a lo largo de unas cuantas retrospectivas (algo más de dos años, al menos una cada 15 días,...):
  • Piensa siempre lo primero que el problema es sistémico, no de las personas. Soluciona primero el sistema, generalmente éste limita a las personas.
  • No evites los conflictos, genera un ambiente donde sea sano que florezcan.
  • Plantea las necesidades a resolver, no lo que pensamos que son las causas. Esto también ayuda a la eliminación de la figura del "culpable"
  • Aprende técnicas de retrospectivas y conoce cuando se debe aplicar cada una. Ayudan, y mucho.
  • El brainstorming es la técnica más conocida y peor implementada. Pon reglas claras desde el principio para hacerlo bien: elimina las críticas que impiden una verdadera libertad de ideas.
  • Siempre obtén acciones de las retrospectivas, o no serán retrospectivas, solo "reunión de desahogo". Que no vienen mal de vez en cuando, pero esas, con una cerveza en la mano mucho mejor.