Después de ver en el anterior post una pequeña introducción, dedicaremos un rato a describir más en profundidad cómo hacemos Agile y las características concretas que condicionan la implantación de toda la liturgia Scrum.
Organización y Gestión de Proyectos
Actualmente somos 3 equipos Scrum, 2 en proyectos en Python y Django y 1 en Grails. Estos equipos trabajan cada uno únicamente en un proyecto.
Cuando cambia la tecnología o el tamaño del proyecto, el mejor equipo posible para el proyecto cambia y reconfiguramos los equipos. Esto que a priori puede ser un problema, no lo es tanto, pues la estabilidad de los equipos es media-alta, de 9 meses a 1 año y el cambio de tecnología suele gustar bastante.
Lo que sí intentamos siempre equilibrar son los maestros y los principiantes en todas las disciplinas, no sólo la tecnología a usar, si no en perfiles como analistas, comunicación con el cliente o sistemas. El Scrum Master de cada equipo conoce sus funciones y las asume con responsabilidad.
Para la gestión de los proyectos y las tareas usamos Redmine con un plugin de S_crum_, que nos permite mantener y priorizar un Product Backlog, crear Sprints y gestionar luego la evolución del Sprint. La limitación más clara que tiene es que no se dispone de un gráfica para ver el Project Burndown y eso lo tenemos que llevar en un documento compartido aparte. Luego esa gráfica la exportamos en el wiki del proyecto y queda bastante bien.
Y es que teniendo dos días de teletrabajo a la semana tenemos que virtualizar los paneles, intentando facilitar tanto la visualización de la información en remoto como las comunicaciones. Esto tiene el beneficio que todo el equipo es consciente que lo que no está en la plataforma no existe, lo que ayuda a tener toda la información recogida.
Pero los beneficios de tener un panel real son muy altos, el Visual Management, así que es un punto en el que estamos trabajando activamente, porque una cosa es la gestión de las tareas y otra muy diferente el Big Picture del proyecto o las retrospectivas.
La coordinación y seguimiento de los equipos a nivel de Scrum la realiza el Agile Coach, que soy yo.
Todas los aspectos de Scrum se coordinan con el CEO de la compañía y así tener el respaldo para afrontar con garantías las acciones de mejora.
Esta denominación de Agile Coach, aunque ya la había visto, no la comprendí del todo hasta que asistí la charla de Joserra Díaz (@joserra_diaz) y Olaz Zamora (@olatzZamora ) en la CAS 2011.
Retos actuales
Por no adelantar temas de otros posts, comento rápidamente algunos retos que afrontamos actualmente.
El primero es empezar con garantías los proyectos. Detectamos una indefinición en las historias que hacía bajar nuestra velocidad, así que como reto nos proponemos tener un Sprint 0 más efectivo, que permita que el Sprint 1 sea lo más parecido posible al Sprint 9.
Otro gran reto es la cobertura de tests de nuestro código y la Intregración Contínua. Aquí tampoco me voy a extender en los beneficios que implica el “accountability” del proyecto, que comentaba Uncle Bob (http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot). ¡Vamos a por ello!
Y el más interesante. Hablar con los clientes de agilismo desde el primer minuto, desde la primera presentación. Nunca será una gestión interna del proyecto, el uso de metodologías ágiles queremos que sea vinculante.
Futuro
Y el futuro qué nos depara? Pues además de seguir creciendo internamente, está lleno de propuestas, avances, mejoras, aportaciones a la Comunidad Ágil y ¡proyectos muy muy interesantes!
