Fundamentos de Scrum desde la mirada Garage (1/2)
Como Garage Labs hemos vivido múltiples iteraciones metodológicas para ir adaptando nuestro equipo y operación a nuestras necesidades y de nuestros clientes. Una de las más importantes fue implantar Scrum, que es un framework de trabajo ampliamente usado y aceptado por la industria de desarrollo de software. En esta serie de artículos me gustaría contarte un poco sobre Scrum y cómo hemos cambiado nuestro paradigma de trabajo, además de darte algunos tips y consejos si aún no te haz unido al mundo ágil!
Scrum, ¿qué es?
Scrum es un marco de trabajo que surge en los años 90 para venir a revolucionar las distintas industrias, en un comienzo la automotriz, y luego da el salto a todos los ámbitos y rubros que puedas imaginar. El término scrum viene del mundo del rugby, en que todos los participantes del equipo cooperan para mover el balón de un lugar a otro de la cancha. La filosofía scrum nace desde la idea de la mejora continua y podría resumirlo en estas 3 frases:
- Las personas son más valiosas que los procesos
- Crear valor es el objetivo de todo lo que hacemos
- Debemos aceptar el cambio como algo bueno
Tal y como lo explica Jeff Sutherland en su libro Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo, si somos capaces de entender y aplicar estas premisas, conseguiremos equipos de trabajo de alto rendimiento que entregarán productos de calidad y en poco tiempo (!!!).
A continuación entraré en detalle en estas ideas, para que sepas como poder aplicarlo en tu propio equipo.
Las personas son más valiosas que los procesos
Dentro de un equipo Scrum, cobra mucha más importancia el rol que juega cada uno de los integrante y sus propias capacidades por sobre los procesos que llevan adelante. Como regla general de los mutan de Scrum se dice que los equipos deben ser lo más pequeños posibles, entre 3 a 9 integrantes. Esto se debe a que incluir más personas aumenta los canales de comunicación dentro del equipo, hasta el punto de volverse insostenible (Jeff Sutherland nos plantea que con 10 miembros en un equipo tenemos 45 canales de comunicación !!)
Los equipos Scrum deben ser autónomos y autorganizados, sin relaciones jerárquicas, es decir, que puedan tomar sus propias decisiones en pos de lograr un producto de calidad, ya sea en cuanto a su forma de trabajo, directrices de negocio para el producto, entre otras. Un equipo sin autonomía nunca logrará un desempeño óptimo y nunca estará seguro de lo que hace. Mientras las decisiones se tomen como equipo se volverá absurdo buscar culpas en los tiempos malos, ya que todo el equipo es responsable del producto final.
Finalmente, hay que tener en cuenta que los equipos Scrum deben tener los integrantes correctos para que todas las habilidades necesarias estén cubiertas. Esto nos dará dos resultados: El primero, todo el equipo deberá remar hacia la misma meta para lograr un producto de calidad y segundo; el desempeño en conjunto será mucho mejor que el individual. Algo de esto nos habla Natalia Rodríguez Mariani en su artículo sobre el trabajo individual en equipo por si quieres echarle un vistazo!. Por esto último, no necesitamos héroes dentro de nuestros equipos, sino que todos tengan compromiso por lo que hacen.
Crear valor es el objetivo de todo lo que hacemos
En cualquier rubro que imagines sabemos que el tiempo es finito, por tanto debemos saber utilizarlo correctamente para aportar valor real a nuestros clientes. Scrum nos propone dividir nuestro trabajo en periodos cortos de tiempo, más conocidos como sprints, que nos permita obtener una pieza de software o producto funcional al final de cada iteración. Con esto en mente, podremos obtener feedback rápidamente para corregir el rumbo de nuestro producto, ya sea a través de pruebas con usuarios, pruebas de estrés o de concepto. Lo fundamental de todo esto, es que en cada sprint el aporte de valor a tu cliente que le entregue el software o producto sea el máximo, de tal forma que pueda ser aprovechado de inmediato, incluso en etapas tempranas de desarrollo.
Para lograr llegar al punto máximo de rendimiento y de entrega de valor, debemos ser conscientes de que el camino no será fácil, y necesitaremos ir eliminando el desperdicio, como podrían ser las reuniones innecesarias, la documentación innecesaria, ser un “multitarea” o lo que tu creas que impida avanzar rápidamente en la entrega de tu producto y a tu equipo.
Debemos aceptar el cambio como algo bueno
Hacer planes completos de desarrollo, con complejos roadmaps e hitos de entrega nos ha demostrado ser poco eficiente en el desarrollo de software y uno de los puntos importantes de fracaso de proyectos gigantes. Podríamos dar muchísimos ejemplos, pero la causa principal de esto es que no toleran el cambio, al contrario, lo penalizan. Scrum por otra parte nos propone planificar sólo lo necesario, sin hacer grandes planificaciones ni cartas Gantt.
Anteriormente mi compañero Alejandro Soto Cisterna nos ha contado sobre la importancia de convivir con el error en nuestro día a día. Esto cobra aún más importante cuando trabajamos con Scrum, ya que los errores nos mostrarán en qué hemos fallado y qué debemos cambiar en la siguiente iteración. La mejora continua y el cambio a lo largo del desarrollo de software son los pilares que debemos abrazar para alcanzar ese producto que imaginamos como equipo en nuestras mentes.
Cuando decidimos aceptar el cambio y el error como un motor para mejorar continuamente debemos saber priorizar aquella nueva funcionalidad que nos entregará más valor que lo que teníamos en mente, y cuál es el timing perfecto para lanzarlo. Para esto necesitamos por sobre jefes, líderes en nuestros equipos que tengan una visión avanzada sobre el producto que está en nuestras mentes y que nos cuesta definir. A su vez, se vuelve necesario tener visibilidad de lo que hacemos y lo que no, para ser honestos y evaluar objetivamente los tiempos y esfuerzos que necesitamos llevar a cabo.
Para ir cerrando, uno de los motores de tus equipos Scrum debe estar en la felicidad del trabajo que llevan a cabo, en el deseo de llegar a la maestría en lo que haces en el proceso y no quedarse en el área de confort y finalmente en estar contento con nuestro desempeño. Para llegar a este punto de alta satisfacción solo puede ser alcanzado luego de un largo camino recorrido y de mucho esfuerzo por ir eliminando el desperdicio de nuestros procesos.
Como uno de nuestros objetivos trabajando con agilidad es perseguir la maestría en lo que hacemos, Jeff Sutherland hace la comparación de Scrum con el Shu Ha Ri, un concepto enseñado en las artes marciales japonesas que persigue exactamente lo mismo, pero planteado como un estilo de vida en esa cultura. El primer paso para llegar a nuestro objetivo es seguir las normas predefinidas (Shu), para luego innovar en lo que haces (Ha). Cuando ya domines lo que sabes de Scrum y agilidad, solo deshecha lo que sabes y actúa en base a lo que sabes! (Hi).
En el siguiente artículo de esta saga les contaré cómo hemos aplicado todo lo que te describo aquí en nuestros equipos Garage y cuáles han sido nuestras grandes dificultades para implementar Scrum y llegar a ese punto de felicidad que te describí antes. #StayInHome!
