Archivo por meses: octubre 2010

12 meses haciendo Scrum

Buenas a todos!

La verdad es que no sé muy bien como empezar… y este siempre ha sido un buen comienzo jejeje.

Hace más o menos un año, conseguí que aceptaran mi propuesta de cambiar la forma de gestionar el proyecto “Estrella” de la división donde trabajo. Este cambio vino ocasionado por el semi-caos en el que nos encontrábamos a causa de problemas internos. En realidad, tuve suerte en este aspecto, fue recibido con buenos ojos, aunque con escepticismo, por parte de la dirección. Los cuales me dijeron “Adelante, necesitamos cambiar esta forma de llevar las cosas, y que todo el mundo vuelva a estar ilusionado con su trabajo”.

Realmente este era uno de los principales problemas, gente desmotivada y quemada por siempre hacer lo mismo año tras año. El otro gran problema, fue el ir dando trabajo a cada miembro del equipo, según iba llegando, asignando tareas según carga, especialidad de cada persona, y urgencia. Es decir, saliendo adelante como bien se podía. La gestión del caos dirían algunos.

Pues bien, Lo primero fue concienciar e informar a todo el mundo, de qué era eso de Scrum y la Agilidad. Tarea muy agradable y fácil para alguien que se había empapado bien de cómo funcionan estos temas, además de estar totalmente de acuerdo con los principios que ello conlleva (Manifiesto Ágil). Después de que todo el mundo diera su aprobado, nos pusimos manos a la obra.

Lo siguiente que hicimos, fue repartir papeles.

  1. Propietario del producto (Product Owner). Esto fue fácil de elegir, cliente interno, mi responsable técnica de división.
  2. Equipo. También fue fácil, las 7 personas de mi equipo a las que gestionaba en el proyecto.
  3. Scrum Manager. Yo mismo, al menos por el principio, ya que era el que me había implicado más en este cambio y el que más conocía estos temas.

Yo como “Scrum Manager” junto con el “Product Owner” definimos como tenía que ser la estructura del “Product Backlog” en un principio, y junto con el equipo, definimos el documento “Sprint Backlog”. Estos dos documentos han ido evolucionando en progresión junto con nosotros y nuestras necesidades.

Teniendo todos los papeles asignados, decidimos una fecha que encajase, para que todas las tareas pendientes de terminar en ese momento, se finiquitaran y pudiésemos empezar el 1º Sprint, lo más limpio que se pudiera. Yo por mi lado, acaparé una pizarra de la sala de reuniones y la acondicioné, para eso que me llamaba tanto la atención “Gestión de tareas por Posit” con un tablero Kamban. Y después de tener todo organizado para empezar, dimos el primer gran paso, la reunión de inicio del 1º Sprint!!!

El 1º Sprint fue el más complicado, pero también el más motivador, tanto para mí, como para el equipo. Creo que lo que más agradable fue ver como los miembros del equipo se divertían “jugando” a estimar con la técnica de “Planning Poker” y como se abalanzaban sobre las tareas para autoasignarselas.

Los principales problemas que detecté en este Sprint, fue la difícil adaptación de los miembros del equipo hacia la auto-gestión y auto-organización. Desde el 1º día esperaban a que yo, como su antiguo jefe de proyecto, les diese las pautas de como implementar y realizar sus tareas, además de esperar igualmente a que les dijese que tarea tenían que asignarse después de terminar otra. Poco a poco esta “manía” se les fue quitando y al tercer o cuarto Sprint ya había desaparecido.
Impresionante-mente al finalizar este 1º Sprint, todas las tareas estaban terminas y funcionando para pasar a producción.

La demo también fue bastante motivadora, enseñando orgullosamente todas las funcionalidades implementadas. Más motivación al canto!

A medida que fuimos metiéndonos en un Sprint tras otro, algunos problemas fueron aflorando. Principalmente la dificultad al estimar la duración de las tareas. Esta ha sido recurrente hasta ahora, y creo que siempre estará ahí. Ya que, aunque las estimaciones cada vez se han ido afinando mas, y la mayoría de veces son acertadas, muchas veces nos encontramos con problemas imprevistos que no supimos ver al discutir sobre la estimación de determinada funcionalidad.
Después de discutir mucho sobre este tema en las retrospectivas, hemos llegado a la conclusión, de que la mejor forma para evitar estos problemas es, dividir al máximo las tareas complejas, para así evaluar más acertadamente las tareas resultantes mas simples.

Otros problemas con los que hemos tenido que lidiar han sido los siguientes:

  • Cambios de tareas a mitad de sprint. Este problema fue de fácil solución. Solo dejamos añadir tareas, si hay alguna/as que el “Product Owner” esté dispuesto a retrasar a siguientes Sprints, que sumen lo mismo que esa nueva en su estimación, que no afecte a ninguna otra y si realmente es necesario para el cliente.
Supongo que habrá gente que no esté de acuerdo con esto, y que diga que Scrum no permite estos cambios, pero yo pienso que así es la agilidad, adaptarse a las necesidades en cada momento :P

  • Mala comunicación con la parte comercial al no poder estar presentes en las demos. Nuestro centro está en Valladolid (Boecillo) y nuestros comerciales en Tres Cantos (Madrid). Con lo que no les suele ser fácil desplazarse cada dos semanas a la demo. Para solucionar este problema, junto con el “Product Owner” hacemos un documento de resumen de la demo, explicando cada nueva funcionalidad del producto, además de otro tipo de demos especiales para ellos, en las que digamos juntamos varias de las nuestras. Ahora estoy mirando para poner un streaming de vídeo de las mismas y que puedan verlas desde donde quieran, aunque ya sé que no es lo mismo, es mejor que perdérselas ;D
  • Implementación de una tarea, haciéndola algo diferente a lo que el “Producto Owner” había pensado. Por ejemplo exportar informes a formatos Office, el equipo hacerlo a formatos de OpenOffice en vez de Microsoft Office como se quería. Esto al principio solía ser habitual, pero lo hemos corregido (casi del todo) actualizando diariamente un servidor de desarrollo interno, en el que se pueden ver las funcionalidades que se van implementando. También me encargo de tener un documento explicativo de cada funcionalidad, antes de la reunión de inicio de Sprint, escrito entre el “Producto Owner” y yo. Así queda todo mucho más claro y los miembros del equipo, pueden pensar en cada tarea antes de esta reunión y tener las dudas preparadas.
  • Aparición de errores en las implementaciones después de la demo. Este problema es uno de los peores. Aquí hemos puesto varios frentes. El 1º, empezamos a meter poco a poco técnicas de TDDExtreme Programing, intentando plagar todo con test para que exploten al mínimo fallo (aún nos queda mucho). Y 2º metimos una 4º columna en el tablero Kamban, en la cual otra persona de la que ha hecho la implementación, tiene que probar la historia de usuario, para que este terminada-terminada, incluyendo revisión de código.

Ha habido muchas cosas que destacar sobre cómo empezamos al principio y cómo vamos evolucionando con la opinión y experiencia de todos. Pero para no alargar esta entrada demasiado, os pongo solo unas pocas:

  • Al empezar a meter técnicas de Extreme Programing, la que más suele chocar es la programación en pareja. Normalmente se suele pensar, que se tira el tiempo de una persona, al ponerse dos a trabajar en el mismo ordenador.
    Pero como yo me convencí de que esto es erróneo, fue al poner a dos personas con unas habilidades, destacadamente distintas a programar juntas. Una sabe programar, estructurar el código y utilizar el lenguaje de programación bastante mejor que la otra. Y por su parte la otra, sabe abstraerse de la solución, pensar más globalmente y contener en su mente problemas más complejos. Esta combinación de mentes, a la hora de resolver un problema y plasmarlo en código es la mejor que me he encontrado, haciendo que los resultados sean impresionantes. Sin hablar ya, de todos los beneficios que conlleva, como el aprendizaje mutuo, la doble revisión, rápida entrada en estado de flow, mejora de moral, propiedad colectiva del código, etc. Si tenéis la suerte de poder probarlo, no dudéis en hacerlo, veréis los beneficios.
  • Como decía antes, el ajuste de las estimaciones suele ser bastante conflictivo. Pero con tan solo un año de ellas a nuestras espaldas, hemos podido comprobar la mejora evolutiva muy a detalle. Un ejemplo que suelo poner, es la estimación de un nuevo informe dentro de nuestro producto. Nuevos informes nos surgen continuamente, todos muy parecidos, pero con necesidades diferentes. Pues bien, en los primeros Sprint, el equipo solía coincidir muy poco en su estimación, unos decían 5 días, otros 1, etc. Con lo que nos salía una media de 3 normalmente. Después de todo un año estimando y todo el equipo repartiéndose los cíclicamente, ahora cada vez que sale uno a estimar, hasta el Product Owner se ríe y murmura 2, antes de que el equipo estime.
    Con esto quiero decir, que no solo ahora todo el equipo sabe de sobra que un informe medio se haga en 2 días, sino que, una tarea que hace un año tardábamos 3, ahora la hacemos en 2. Beneficios de la autoasignación de tareas y repartición del conocimiento al autoasignárselas. Posdata hemos conseguido recortar una media de un 33% una tarea que suele aparecer con frecuencia en nuestro trabajo.
  • La motivación ha sido otro de los puntos fuertes dentro del cambio. Antes de empezar con él, creo que casi ningún miembro del equipo, estaba contento día a día con su trabajo. Ahora puedo afirmar con seguridad, que todos y cada uno de ellos, no solo se sienten bien y trabajan mucho más y mejor que antes Sino que están tan convencidos de ello, que cada vez que me preguntan algo sobre Scrum delante de alguno, saltan antes de mi respuesta y les explican todo el funcionamiento de principio a fin entusiasmados. Esto es mi mayor motivación diaria.
Aún nos faltan muchos pasos por andar y aún nos faltan muchas cosas por afinar y aprender. Pero sin duda, el producto ha mejorado muchísimo y tanto el equipo, el Product Owner, los superiores y yo mismo, estamos muy contentos con la dirección que todo va tomando poco a poco. Me gustaría hacer más a menudo retrospectivas y unificar en la rueda, la integración continua, la gestión de bugs, testing y despliegues, pero todo se va viendo más cerca y vamos poco a poco.

En resumen, cada día que pasa haciendo Scrum, me convence más, de que para este tipo de proyectos, es la mejor gestión que existe, o que al menos yo conozco.

Salu2!

Reunion 25/10/2010

Día: 25/10/2010
Hora: 19:30 – 21:30
Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid
Posteriormente en cafetería (cerveza en mano, como mandan los cánones).

AGENDA

1. Frecuencia quedada
2. Calendario de trabajo
3. Brainstorming de temas
4. Desarrollo de Temas

ASISTENTES

1. Javier Santana
2. Ignacio Cruzado
3. Olivier Salmon
4. Alfonso Bernal
5. Isidro Merayo
6. Alvaro García
7. Jose Da Rocha

RESUMEN

1. Frecuencia quedada y Orden del día
Se confirmó por parte de todos la utilidad de conocer a priori las citas y quedó aprobado la regla de quedar todos los martes de cada mes.
Se espera reservar el Centro Cívico. En principio queda encargado el pobre Jorge, por no poder asistir ;-) .
Se plantea la posibilidad de tocar dos temas en cada reunión: uno de Gestión y uno más Técnico, dando cobertura a las dos vertientes principales.
En los Temas se desarrollarán PUNTOS (topics) sean teóricos, prácticos o herramientas.
Se podría realizar algún otro SEMINARIO intensivo en algún sábado, en probable colaboración con ExeCyL.

2. Calendario de trabajo
Se va a intentar tener ya pre-configurados los TEMAS de las REUNIONES (tanto el técnico como el de gestión) a ser posible al menos 3 semanas antes de la reunión.
En esta reunión (y posteriormente en el foro se completará una lista de 2 Temas al mes para que todo el mundo sepa cuándo se va a tratar qué y pueda organizarse personalmente para asistir a aquellas que le sean más afines.

La idea sería:
Asignar 2 Temas por mes. Esta tarea de planificación a M/P la haríamos ahora, y una única vez en la primera semana (este año de Noviembre; años posteriores podemos comenzar, al menos, un mes antes).

Luego se entraría en un ciclo durante los meses hasta junio (incluido):

    1ª semana del mes: publicar el acta de la reunión y acabar de concretar quién desarrollará qué Punto en cada Tema (Plan).
    2ª y 3ª semanas: los voluntarios generarán algún post en el blog sobre sus topics a desarrollar (Sprint). Al final de la 3ª semana (Sábado); publicación.
    4ª semana del mes: lectura del grupo de los post: asistencia a la reunión (Demo). Repaso y discusión de los post en la reunión; la reflexión de mejora ya en la cafetería (se debería publicar con el acta de reunión las conclusiones o propuestas de mejora más interesantes)

El verano (julio-agosto) podría convenir no considerarlo ‘hábil’ (la gente coge vacaciones y el que no tenga irá generando gusanillo para el otoño).

El Orden del día de una reunión sería (comenzando a las 19:30 -alguien propuso adelantarlo, pero dado que no empezamos hasta las 19:50…):
1. Breve presentación asistentes (1′ por persona).
2. Discusión Tema técnico (40′).
3. Discusión Tema de gestión (40′).
4. Retrospectiva y lanzamiento de ideas de mejora a postear (5′).

Sería importante aplicar más puntualidad a la hora de llegada, para poder aprovechar el poco tiempo disponible del CC. Para ello hay una vieja técnica consistente en pensar que tienes la reunión a las 19:15 :-P

3. Brainstorming de Temas.
Se plantaron los siguientes Temas, a repartir por el calendario anual

Temas de Gestión (escritos por orden de aparición):

  • Gestión de proyectos (general; PMBok)
  • Gestión comercial
  • Dirección
  • Liderazgo
  • Gestión de equipos humanos

Los problemas de la interfaz comercial-técnicos:

  • Gestión del tiempo
  • Gestión de calidad
  • Gestión de imprevistos
  • Gestión del conocimiento

Temas Técnicos (en orden según se aplican en un ciclo de vida de cascada):

  • Administración de sistemas (instalación de software, seguridad, …)
  • Análisis y especificación de requisitos
  • Arquitecturas y Diseño software
  • Implementación y Codificación del software
  • Gestión de configuración (branching, merge…)
  • Pruebas

En ambas pilas de producto se hizo una votación entre los asistentes y se seleccionaron como más deseados (en orden de votación):
Temas de Gestión

  • Gestión de imprevistos
  • Gestión comercial
  • Gestión de equipos humanos

Temas Técnicos:

  • Pruebas
  • Gestión de configuración

Y se decidió dejar para el foro el debate final de cuáles en concreto encajarían en cada mes y cuales, de estos 5 son los dos seleccionados para su desarrollo y reunión en noviembre.
Aquí no encontramos la técnica y herramienta adecuada (¿doodle?) así que salvo que alguien aporte alguna idea mejor (espero!) lo haremos por discusión en un hilo del foro.

4. Desarrollo de Temas
Aquí comenzamos a desarrollar los Puntos de los temas de este mes.
Uso T=Teoría, P=Práctica, H=Herramienta

Pruebas

  • T. Factores a tener en cuenta en la Estimación del trabajo de pruebas
  • T. Debate sobre cuándo se pueden evitar las pruebas
  • P. ATDD y BDD
  • H. Hudson
  • H. Cruise Control

Gestión configuración

  • T. Patrones de ramas (intentar contar con Pablo Santos)
  • P. Gestión de Dependencias en Ruby y Python
  • H. PlasticSCM
  • H. Mercurial
  • Git

Gestión de imprevistos

  • T. Cómo gestionar el conocimiento extraído de los imprevistos sucedidos
  • T. Qué hacer con tareas imprevistas y con las no-terminadas en una planificación agile-time-boxed
  • P. Revisión de historias

Gestión de equipos:

  • T. Motivación
  • T. ¡Reunion-itis!
  • P. Resolución de conflictos
  • P. Equipos distribuidos

Gestión comercial:

  • T. Contratos comerciales y agilismo
  • T. Validación del cliente: ¿el rol del Client-ficticio es operativo?
  • T. ROI (Return Of Inversion) de organizaciones que adopten agilismo
  • P. Mercadotecnia: métricas y argumentos que soporten el agilismo comercialmente
  • P. Comercial interno: cómo evangelizar tu propia organización.

CONCLUSIONES

El nombre de los temas espero que no de lugar a mucha confusión: de ser así los re-nombramos.
Desde luego el nombre de los Puntos se puede mejorar y se pueden meter o sacar, en función de los voluntarios a desarrollarlos.

Ahora nos queda las siguientes tareas:
A. Asignar Temas a los meses (al menos votar las 2 de noviembre).
B. Coger un Punto cada uno de los voluntarios y redactar un Post al respecto.
C. Leer el trabajo de los demás.
D. Afinar nuestro modo de trabajo.