Actualmente, una de cada cuatro medianas empresas registran caídas de 50% en ventas por mala gestión (Gestión, 2016). Para hacer frente a esta situación, han surgido nuevas alternativas en la planificación de trabajo y en la implementación de nuevas técnicas de gestión, en las que el pensamiento ágil es clave. Una de las que más populares son las llamadas “metodologías ágiles”.
La principal ventaja de ellas es que se utilizan equipos pequeños, interdisciplinarios y auto-organizados. Según Amaro Calderón & Valverde Rebaza (2007) “las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. (…). Dividir el trabajo en módulos abordables minimiza los fallos y el coste” (p,11).
De esta manera, en lugar de tener un número grande de personas dedicando mucho tiempo en un proyecto complejo, se tienen equipos pequeños pasando menos tiempo y desarrollando algo menor (Skarin & Kniberg, 2010).
Por ello, para fines del presente artículo, se desarrolla específicamente el marco de trabajo Scrum, el cual se presenta como una opción de gestión ideal para tratar el desarrollo de proyectos en entornos complejos que exigen rapidez en los resultados sin dejar de lado la generación de valor y flexibilidad ante los posibles cambios que puede solicitar el cliente.
Surge en 1986, con una fuerte influencia del artículo de Harvard Business Review (HBR): “The New New Product Development Game” de Hirotaka Takeuchi e Ikujiro Nonaka[1]. En él se desarrollan las mejores prácticas en las 10 compañías japonesas más innovadoras. Luego, en el año 1995, se formaliza el nombre Scrum, haciendo referencia al juego de rugby, por una formación en donde el equipo está abrazado empujando hacia un mismo lado mientras el rival hace lo mismo en el sentido contrario (Amaro Calderón & Valverde Rebaza, 2007).
Finalmente, en los años 2001 y 2010, el enfoque tomó fuerza por la generación de elementos como “Manifiesto ágil de desarrollo de Software” y “Guía de Scrum” ellos con el objetivo de globalizar y convertirla en lo que es hoy en día: uno de los marcos de trabajo más usados, no solo en el área desarrollo de software, sino en campos como administración, educación, innovación, entre otros (Rodríguez & Dorado, 2015).
Según Rodríguez & Dorado (2015) los perfiles dentro de Scrum están compuestos por cuatro actores principales: En primer lugar, se tiene al Product Owner quien es la voz del cliente y del resto de los interesados que no están implicados directamente en el proyecto. Se encarga de definir los objetivos y de garantizar que el equipo se desempeñe de tal forma que los alcance. Asimismo, es responsable de que los ítems correctos formen parte del proyecto.
En segundo lugar, está el Scrum Master, encargado de asegurar que el proyecto tenga un proceso suave y que no existan problemas en el resto del equipo para que aborden sus funciones y tareas. En otras palabras, es como el facilitador del proyecto, pues fomenta que sus compañeros se mantengan activos y productivos en el desarrollo de sus tareas (Rodríguez & Dorado, 2015).
En tercer lugar, se encuentra al Scrum Team, compuesto por el equipo encargado de desarrollar y entregar el producto. Se puede afirmar que su trabajo es insustituible, ya que se trata de una formación horizontal estructurada, capaz de autogestionarse (Rodríguez & Dorado, 2015).
Finalmente, cabe mencionar a los Stakeholders, ya que son parte de los procesos del proyecto. Están conformados por los diferentes interesados: directores, dueños, gestores, entre otros (Rodríguez & Dorado, 2015).
Ciclo de Vida
Gracias al vídeo de Shojaee (2013), a continuación se menciona el ciclo de vida del enfoque, la cual se puede dividir en cuatro etapas. En primer lugar, se realiza el análisis de los atributos según la perspectiva del usuario final. Ellos son conocidas como: historias de usuario, Product Backlog o Wish List, las cuales están conformadas por las características que harán del producto único.
En segundo lugar, se debe iniciar la planeación de las historias que se van a utilizar en la liberación o Release Backlog. Para planearla, el equipo identifica las historias de usuario que se utilizarán. Lo ideal es que el equipo priorice las historias clave, entregue valor de forma ágil y estimen tiempos para cada una de ellas.
En ese sentido, cuando se presenten historias muy grandes, se debe realizar una subdivisión de tiempo para hacerlas manejables. Con la colección de las estimaciones se permite promediar el tiempo que tomará el desarrollo de la liberación. Para lograrlo, lo mejor es realizar una estimación en horas.
Una vez que las historias estén priorizadas y los tiempos estimados, se procede a la tercera etapa: el planeamiento de los Sprints. Ellos son la vía corta para hacer de los hitos un preparado para la entrega. Van de 2 hasta 30 días dependiendo del ciclo de liberación del producto. Entre más corto sea el ciclo de liberación, más corta debe ser la longitud del Sprint.
Como los Sprints son pequeñas representaciones reales del producto, la terminación tardía de cada uno de ellos es un indicador de que el proyecto no cumple con lo agendado y algo no será terminado. Por ello, es importante realizar un monitoreo constante de cada Sprint con el Burndown Chart, una de las mejores herramientas de visibilidad de proyectos, ya que provee una medición diaria de la cantidad de trabajo restante para la liberación. Con él el equipo puede calcular la tasa de productividad rápidamente, porque se entregan pruebas empíricas de que el proyecto está bien encaminado o si existen retrasos.
Como se mencionó anteriormente, parte del proceso de liberación es crear las estimaciones para cada historia de usuario y del Release Backlog. La colección de estas estimaciones nos da el Sprint, que representa el tiempo importante de trabajo que se debe realizar para completarlo.
Con ello, se procede a la etapa final en donde cada miembro del equipo es responsable de actualizar el tiempo empleado en cada ítem, ello debido a que realizan el trabajo de las historias de usuario. Por ejemplo, en vez de 8 horas, la historia se realiza en 4 horas. Esto hace que el tiempo restante del Sprint cambie día a día. Con optimismo se espera que llegue a cero antes que el Sprint finalice. Por ello, el Burndown Chart es sumamente útil, ya que promedia los tiempos restantes de trabajo y los muestra visualmente; del mismo modo, comunica una gran cantidad de información en poco tiempo. Lo anterior se realiza en las características reuniones diarias: Daily Scrum.
El Daily Scrum es una herramienta esencial para que la comunicación fluya libre entre los miembros del equipo. La idea es hacer reuniones rápidas donde los miembros del equipo listan las tareas terminadas de la reunión anterior y los obstáculos que se le hayan presentado. Es en esta reunión en donde los miembros del equipo comentan los inconvenientes y buscan la manera de solucionarlos. Finalmente, previo a que cada Sprint finalice, es importante tener la retrospectiva de la reunión donde el equipo puede visualizar qué estuvo bien y qué estuvo mal según lo programado.
Después de todo, Scrum es un marco de trabajo flexible de desarrollo ágil que genera múltiples beneficios en diferentes aspectos dentro de una organización. Deemer, Benefield, Larman, & Vodde (2009) afirman:
Es un marco de trabajo iterativo e incremental para el desarrollo de proyectos, productos y aplicaciones (…). Un tema importante en Scrum es “inspeccionar y adaptar”. El desarrollo inevitablemente implica aprender, innovación y sorpresas. Por eso Scrum hace hincapié en dar un pequeño paso de desarrollo; inspeccionar el producto resultante y la eficacia de las prácticas actuales; y entonces adaptar el objetivo del producto y las prácticas del proceso. Y volver a repetir. (p,5)
Además, fomenta el trabajo en equipo, ya que focaliza los esfuerzos de todo el Scrum Team en alcanzar un objetivo común e influye en la responsabilidad y comunicación, ya que se trata de un modelo de autogestión y autodisciplina frente al entorno cambiante y competitivo en donde el valor agregado es el diferenciador frente a la competencia (Rodríguez & Dorado, 2015).
Bibliografía
Amaro Calderón, S. D., & Valverde Rebaza, J. C. (2007). Metodologías Ágiles. Escuela de Informatica., 1–37. Retrieved from https://uvirtual.unet.edu.ve/pluginfile.php/268695/mod_resource/content/1/Metodologias Agiles.pdf
Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2009). INFORMACIÓN BÁSICA DE SCRUM (THE SCRUM PRIMER). Retrieved from www.ScrumTI.com
Gestión. (2016). Una de cada cuatro medianas empresas registran caídas de 50% en ventas por su mala gestión | Economía | Empresas | Gestion. Retrieved August 21, 2018, from https://gestion.pe/economia/empresas/cuatro-medianas-empresas-registran-caidas-50-ventas-mala-gestion-115183
Rodríguez, C., & Dorado, R. (2015). ¿Por qué implementar Scrum? Revista Ontare, 3(1), 125–144. https://doi.org/10.21158/23823399.v3.n1.2015.1253
Shojaee, H. (2013). Scrum en 10 minutos – YouTube. Retrieved from https://www.youtube.com/watch?v=PlLHc60egiQ
Skarin, M., & Kniberg, H. (2010). Kanban y Scrum – obteniendo lo mejor de ambos. Retrieved from https://s3.amazonaws.com/academia.edu.documents/38825031/KanbanVsScrum_Castellano_FINAL-printed.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1534830663&Signature=lKPIZID4140bq5KcYX7f0V00G88%3D&response-content-disposition=inline%3B filename%3DKanban_
[1] Artículo rescatado de HBR en el siguiente enlace: https://hbr.org/1986/01/the-new-new-product-development-game
