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 Scrum, 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!

De dónde venimos, dónde estamos y a dónde vamos

Una empresa cuyo modelo de negocio está absolutamente basada en Software Libre, parte de una posición privilegiada para asumir prácticas ágiles. Conceptos como el conocimiento compartido, la meritocracia, la propiedad colectiva del código, el trabajo con la comunidad, o “todos programamos”, ya los llevamos implícitos.

Si a esto le unimos que somos una empresa pequeña, que tenemos muy pocos “jefes” y carecemos de títulos nobiliarios como “Analista Orgánico” o “Programador Senior” y que se prima el talento por encima de una carrera profesional meteórica, tenemos una gran base.

Cuando Kaleidos adoptó Scrum, no nos costó tanto… bueno algo sí, pero ya tendremos oportunidad de comentarlo en futuros posts.

Los inicios

Las razones fundamentales para implantar Scrum fueron para mejorar la gestión del conocimiento del proyecto y de los hitos de entrega. Y mejoramos, pero Scrum trajo más cosas que estar sin ellas ahora sería impensable.

La gestión de los equipos es lo que más beneficio organizativo sin duda ha traído. Ahora ya no hay que pensar quién es jefe de proyecto o responsable de un proyecto, lo es todo el equipo y dentro del equipo todos hacemos lo que mejor sabemos hacer. Depende del ámbito se encargará una persona u otra.

Y de cara al cliente, reuniones con todo el equipo y decisiones consensuadas bajo los criterios de mejor solución para el cliente y para el proyecto.

Pero lo que yo destacaría sobre todo es que ahora la responsabilidad del éxito del proyecto es compartida. Cuando algo sale bien, es mérito de todos.

Y claro, si se comparte el éxito, también el fracaso. Aquí los marrones no pueden “subir” o “bajar”, aquí no hay un cliente, que a su vez echa la bronca al Jefe de Proyecto, que a su vez echa la bronca al equipo de desarrollo. Porque cuando estás en un equipo, y te sientes como tal, no hay nadie a quién echarle la culpa. Cuando te basas en metodologías ágiles, todos teníamos la misma información para verlo venir.

Todo esto hace que esté muy orgulloso de nuestros equipos, sabemos que cada uno es responsable de una parte del buen fin del proyecto y trabajamos duro para conseguirlo.

En siguientes posts iremos desarrollando cómo lo estamos haciendo, qué particularidades tenemos y las propuestas de mejora que salen de nuestros Inspect & Adapt.