Por Mauro Strione, @maurostrione
kanban, Scrum, innovación
El equipo de integración y ensayos (En adelante IE) de una empresa de desarrollo de satélites de telecomunicaciones se encontraba trabajando en tres satélites(Proyectos) al mismo tiempo dentro de una única sala limpia (Dónde se ensamblan y se integran las distintas partes y se hacen pruebas del mismo), compitiendo por herramientas de manipulación, espacios de trabajo y el personal del equipo de IE en ciertos momentos concretos para cumplir con plazos estipulados muy estrictos. No existía en ese momento una herramienta que permitiera a cada equipo de proyecto conocer las necesidades de los otros proyectos, ni los compromisos adquiridos por el equipo de IE. Realizaban reuniones periódicas de sincronización para poder conocer las necesidades de los otros equipos y negociar y coordinar las peticiones de trabajo, las cuales se realizaban inicialmente desde múltiples canales (Emails, llamadas telefónicas, charlas de pasillo) y se gestionaban de manera independiente por cada jefe de proyecto.
El equipo de IE, utilizó con cierto éxito y para gestionar las tareas de un proyecto ya finalizado, un software desarrollado por un miembro del equipo que ya no se encontraba más trabajando en la empresa. Dicho software era muy simple, registraba tareas y las mostraba en un formato de lista.
Con el software antes mencionado bajo el brazo, lo mostraron al equipo de desarrollo de sistemas de información (SI en adelante) a cargo del desarrollo de las aplicaciones de gestión de la empresa y solicitaron generar una solución similar para poder gestionar las tareas de los proyectos en curso.
El equipo de SI, en plena adopción o "adolescencia ágil" con las hormonas alteradas y muchas ganas de llevar el agilismo fuera del equipo, no quiso simplemente hacer un desarrollo más, sino que hizo una contra propuesta que no incluía solamente software, sino también agregaba una sugerencia metodológica para intentar ayudar a que la solución fuera más efectiva. Dicha propuesta consistía en crear un gestor de tareas que se incluyera un tablero Kanban. Al principio, se escuchó la propuesta con bastante escepticismo, la pregunta imaginamos que era... ¿Por qué estos muchachos del mundo del software vienen con propuestas sobre como mejorar la forma de trabajar de un equipo de integración satelital, qué pueden saber ellos de nuestra industria? Luego de contar los beneficios de visualizar el trabajo en curso, limitarlo, y trabajar en mejorarlo, nos dieron su voto de confianza y nos su apoyo para encarar el proyecto. Inicialmente la herramienta la utilizó el equipo de IE internamente, seguía recibiendo las solicitudes de trabajo desde múltiples canales pero las registraban dentro de la herramienta y la utilizaban para hacer un seguimiento y planificación de las mismas. También los convencimos de la necesidad de generar dentro de su equipo la figura de un Product Owner.
Luego de un tiempo de utilizarlo y adaptarlo a sus necesidades y cuando estuvieron conformes con el resultado, incluyeron a los proyectos y actualmente solo reciben peticiones a través de esta herramienta. Otras áreas de la empresa cuando fueron escuchando conversaciones de pasillo sobre esta herramienta, pidieron acceso para utilizarlo, luego de adaptar la herramienta para facilitar la visualización por parte de los distintos equipos solamente de las tareas que les interesaban, paulatinamente se fue incluyendo más y más equipos.
Las prácticas ágiles no solo nos ayudan a los equipos de desarrollo de software a mejorar la forma de trabajar, sino que pueden generar importantes cambios en procesos y equipos de otras áreas.