Fernando Botella, CEO de Think&Action
Si algo caracteriza a las empresas de hoy es su agilidad. Los sistemas ágiles definen una operativa organizativa que reduce drásticamente los tiempos de desarrollo de un producto desde su concepción inicial hasta su versión entregable. De hecho, agile, lo que hace es comprimir ese proceso, solapando sus fases de tal manera que deja de estar claro dónde esté el comienzo y dónde el final. Si bien “agile” no es una metodología en sí misma, su aplicación se sustenta en diversos métodos desarrollados a su rebufo como design thinking, lean startup o custumer development. De todas ellas hay una en particular que explota como ninguna las capacidades exponenciales del trabajo colaborativo entre los miembros de un equipo y el resto de agentes implicados. Esta metodología se llama Scrum.
Scrum (marcos de desarrollo ágiles) es un modelo que fue definido por primera vez por los japoneses Nonaka y Takeuchi a principios de los 80 tras analizar los sistemas de trabajo de algunas de las compañías tecnológicas más punteras del momento. Hoy este sistema ha tenido un enorme calado en las organizaciones de todo el mundo, y trascendiendo el ámbito informático en el que surgió para extenderse por todo tipo de sectores y proyectos, especialmente en aquellos que requieren altas dosis de rapidez y flexibilidad. Además. su aplicación no es solo útil para la realización de productos y servicios de cara al cliente sino que también tiene interesantísimas aplicaciones a nivel interno, por ejemplo para agilizar los procesos propios de las políticas de Recursos Humanos.
Scrum parte de una serie de roles como son Scrum Máster, quien desempeña las funciones de manager y coordinador; Product Owner, cuya misión principal es hacer de nexo con los distintos grupos de interés o stakeholders (clientes, proveedores, vendedores, etc.) implicados y, por último, el equipo de trabajo encargado del desarrollo.
El funcionamiento de Scrum es el siguiente: durante un periodo de tiempo que, por lo general, puede durar entre una y cuatro semanas, el equipo crea una versión beta del trabajo que ya está en disposición de ser entregada al cliente. Esa versión es compartida con el Product Owner quien la conecta con el resto de personas implicadas en el proyecto para su estudio y mejora. El proceso se caracteriza por su alto nivel de comunicación y colaboración entre todos los miembros del equipo, con reuniones diarias para actualizar los progresos, descartar errores e introducir mejoras.
Entre las ventajas de esta metodología destaca su agilidad para gestionar las expectativas del cliente, ya que las interacciones con él son tan frecuentes que prácticamente se ajustan sobre la marcha, evitando así sorpresas y mejorando significativamente el alineamiento. La integración de los distintos participantes en equipos autónomos y autogestionados y es también una fuente de motivación para sus miembros. Todo ello redunda en una reducción significativa de los tiempos de trabajo.
De alguna manera, Scrum pliega el tiempo, difuminando las fases y convirtiendo a los distintos participantes en el proyecto, en agentes no pasivos sino activos y protagonistas a lo largo y ancho del proceso.
Pero, ¿cómo se aterriza todo esto al trabajo real. Hay una serie de puntos que pueden ayudarnos a aplicar Scrum a nuestros proyectos.
- Nombrar al Product Owner.
Es una figura fundamental, así que hay que poner los cinco sentidos en su elección. Ya sabemos que esta es la persona que tiene claro cuál es el objetivo final del proyecto. El producto o servicio que se quiere crear para cubrir una determinada necesidad. El Product Owner tiene la visión y también ha de manejar conceptos clave como riesgos, costes y una estimación realista de lo que es posible o no conseguir.
- Montar el equipo.
Llega otro momento fundamental. Montar el equipo que va a realizar el trabajo sobre el terreno. Necesitamos que sea un equipo no demasiado grande (entre 3 y 9 miembros) pero la suficiente complementariedad y nivel de expertise para poder encargarse del trabajo de manera autónoma. A la hora de su concepción será importante que sus miembros posean las habilidades que previamente hayamos identificado como claves para el éxito del proyecto.
- Nombrar al Scrum Master.
El Scrum Máster es otra figura fundamental. Por un lado es quien coordina al equipo con el resto de agentes implicados. También es quien monitoriza la buena marcha de los trabajos y regula los flujos de trabajo. Es al mismo tiempo un impulsor, un motivador y un solucionador de problemas.
- Crear un backlog.
Un backlog es una hoja de ruta, una lista de objetivos que incluye todo aquello que debe hacerse para convertir la visión en realidad. Se trata además de una lista viva, que crece y cambia a lo largo del proceso. Como toda buena lista, establece prioridades y va “tachando” los hitos conseguidos dejando en tipografía destacada las tareas pendientes.
- Hacer estimaciones.
Es importante que las personas implicadas en el proyecto realicen estimaciones realistas sobre el tiempos, recursos y esfuerzos que les llevará completar cada tarea, y que todos los implicados las conozcan y las tengan en cuenta para sus propias estimaciones.
- Planificar los sprints.
Llega el momento de que equipo, Scrum Máster y Product Owner se reúnan para empezar a planificar los distintos sprints. El factor tiempo es muy importante y tiene que estar claro desde el comienzo cuánto va a durar cada uno de los sprints. Una o dos semanas suele ser lo normal, aunque también es posible acortarlos o estirarlos una semana más o menos. La reunión debe acabar en acuerdo total y con todos los implicados alineados.
- Visibilizar el trabajo.
Como buena metodología agile, si queremos extraer el máximo provecho de Scrum, debemos hacerlo visible en formatos gráficos, mapas conceptuales y otros recursos que permitan al equipo tener aproximaciones al estado del proyecto en cualquier momento y de un solo vistazo. Una de las formas más efectivas es mediante una pizarra con tres columnas que dividan las tareas en “Pendiente”, “En proceso” y “Hecho”.
- Reunión diaria.
Scrum es un ente vivo y la mejor manera de tomarle el pulso es con monitorizaciones continuas y sistemáticas. Coger el hábito de celebrar una pequeña reunión diaria de no más de 15 minutos con los implicados para analizar avances, posibles incidencias y próximos pasos permite que el proyecto progrese sin demasiados sobresaltos.
- Revisión.
La revisión es una demostración del sprint. Una reunión en la que el equipo muestra lo realizado durante el sprint. Quizá no se a un producto terminado, pero sí debería contener la base para empezar a funcionar en poco tiempo. En esta reunión es útil que estén presentes el resto de stakeholders implicados como directivos, otros equipos o los clientes.
Una vez realizada la revisión, toca reflexionar acerca de logros, posibles fallos y mejoras a introducir. El feedback del resto de stakeholders resultará vital en esta fase. Al final de esta reunión, deben quedar claras los objetivos y mejoras que se van a incorporar de cara al siguiente sprint.
- Siguiente Sprint.
Sin dilación y sobre la base de los puntos anteriores, el ciclo comienza de nuevo.
