Como mencioné en mi anterior columna, me interesé en agilidad porque vi muchas ofertas laborales relacionadas con estos tópicos. Por lo tanto, lo primero que hice fue buscar un curso en Udemy para partir. Mi error fue elegir un curso de Scrum y no agilidad. Sin embargo, el curso partía explicando conceptos de agilidad, lo cual me permitió entender la relación entre ambos conceptos.
El segundo curso que hice fue uno de Sence, llamado “Gestión de proyectos con metodologías ágiles” (Debí haber partido éste). En esta asignatura hacen una introducción completa de la agilidad y además hablan del triángulo de hierro de un proyecto: La calidad de uno está definido por su alcance, tiempo y coste, donde hay variables constantes y otras flexibles. En el caso de la agilidad, las variables fijas son coste y tiempo (equipo y sprint). Sin embargo, en la gestión tradicional de proyectos, tratan de dejar fijas todas las variables. ¿Cuál es el efecto? Termina impactando la calidad del producto y/o proyecto y por eso, se ve una alta tasa de fracaso con este tipo de gestión.
La agilidad nace en respuesta al eterno dolor de la gestión de proyectos: cualquier plan raramente termina siendo ejecutado dentro de los plazos, con los alcances definidos y con los recursos acordados. En propuestas complejas como el desarrollo de software, esto era aún peor (¿quién no ha escuchado o participado de una implementación de ERP fallida?)
Por esto, líderes en el desarrollo de software crearon el Manifiesto Ágil donde se definen 4 valores y 12 principios. Los 4 valores son:
Los 12 principios se definen a partir de los valores y son mucho más explícitos.
A partir de estos valores y principios, J.J. Sutherland desarrolló la metodología que hoy conocemos como Scrum. En su libro “Scrum” cuenta cómo fue el proceso para desarrollar esta metodología y los diferentes ámbitos de aplicación. El libro me encantó. Dejé muchas notas a lo largo él que luego resumí en la última página. También lo recomiendo como punto de partida.
La agilidad desde la óptica del Scrum
Como indiqué, Scrum es una metodología que aplica los valores y principios del manifiesto ágil, dando una estructura para proyectos de desarrollo de software.
¿Qué encontraremos en un curso o libro de scrum? Aquí es donde me asusté la primera vez que leí de scrum, pero ahora verán que no es tan complejo.
Scrum contiene:
- Pilares del scrum: Transparencia, Inspección, Adaptación.
- Equipo Scrum: Scrum Master, Product Owner y Equipo de Desarrollo.
- Artefactos (Entregables): Product Backlog, Sprint backlog, Incremento del Producto.
- Eventos: Sprint, Sprint Planning, Daily scrum, Sprint Retrospective, Sprint Review. Todos los eventos tienen un tiempo máximo para ejecutarse. Para el Sprint es de 30 días.
Al detalle
Scrum establece una estructura para realizar el trabajo. De hecho, si buscan scrum en Google, se darán cuenta que siempre aparece una gráfica que muestra un ciclo como este:
Para entrar al detalle de este ciclo, primero es necesario definir las funciones dentro del Equipo. En mi cabeza, las definí así:
Scrum Master: el gurú, se asegura que todos entiendan scrum y facilita para que las cosas sucedan/fluyan acorde a los principios de agilidad.
Product Owner: Responsable de la satisfacción del cliente. Es de su responsabilidad el producto final. Por lo tanto, es el encargado de entender las necesidades del cliente y “traducirlas” en productos funcionales o en un listado de trabajo para que sea desarrollado por el Development Team (Dev Team).
Equipo de Desarrollo (Dev team): Son un equipo multifuncional con capacidad de autoorganización. Algo que suena obvio, pero es vital dentro del desarrollo de un proyecto tecnológico. Dentro del equipo no hay cargos. Son todos parte del equipo, por lo tanto, son todos responsables del trabajo. Dentro del equipo puede haber desarrolladores full stack, diseñadores, QA, etc. Pero para efectos de Scrum, eso es irrelevante.
En definitiva, el Equipo de desarrollo es la productividad. Son ellos los que hacen el trabajo. El Product Owner asegura que esa productividad se traduzca en valor. Por último, el Scrum Master asegura que la velocidad de este proceso, sea la adecuada.
El ciclo de Scrum es una repetición constante, llamada Sprint, unidad fundamental dentro de scrum y con un tiempo definido (1 a 4 semanas). Un sprint comienza con la planificación (Sprint Planning). En ésta se define cuál será el producto funcional entregable al finalizar el sprint, el orden de magnitud de cada tarea (cuánto trabajo involucra cada tarea) y orden de prioridad en el cual se realizarán.
El ciclo comienza. Todos los días, el equipo de desarrollo tiene una reunión diaria (Daily Scrum) donde se aseguran de ver qué hizo cada integrante el día anterior, que hará el día presente y si tuvo alguna dificultad. El trabajo se visualiza en un tablero (Aquí entra Kanban por ejemplo). Es un tablero que busca visibilizar el estado de avance del sprint.
Por último, al final del Sprint, ocurren 2 eventos. La revisión (Sprint review) donde se reúnen con los stakeholders del proyecto y presentan el producto funcional e incremental del sprint o ciclo de iteración. La última reunión es la Retro (Sprint retrospective) donde el equipo analiza qué funcionó en el sprint y qué mejora se podría aplicar al siguiente sprint.
En conclusión
En Scrum lo más importante, son los pilares. Sobre ello se sustenta toda la metodología. La transparencia, inspección y adaptación son lo que define el éxito de Scrum. Todo lo demás, son los elementos o herramientas de trabajo donde veremos el reflejo de estos pilares. Por eso cuando se habla de “implementación de agilidad” se entiende como un concepto equivocado. La agilidad no se implementa, se habilita, ya que es una capacidad organizacional que se sustenta sobre los valores de la organización. Si los valores de la organización están alineados con los valores de la agilidad y/o de scrum, esto se puede lograr. De lo contrario, será un fracaso.
Hasta la próxima.
