mi primera vez scrum

Si trabajas en la industria tecnológica (o interactúas continuamente con ingenieros), es posible que hayas escuchado los términos “metodología Scrum” y “metodología ágil”. Se trata de un sistema que los expertos en tecnología nombran con grandes reverencias y parece tener un propio y extraño lenguaje. Términos como “planning poker”, “stand-ups” y “sprints” son lanzados con frecuencia por sus promotores. Pueden resultar un tanto intimidantes para los no iniciados, que fue mi caso.

Lo sé, porque estuve en esa misma situación. Mi iniciación en la metodología Scrum fue durante mi primera semana de trabajo en Envíame, empresa de tecnología. El proceso estuvo a cargo de nuestro equipo de desarrollo de software y me volví un aficionado al instante. Era increíble la forma en que podían abordar problemas complejos, priorizarlos en tareas individuales y luego delegar esas tareas al miembro del equipo con la mejor capacidad para resolverlas.

Cuando comencé a mirar Scrum por primera vez, había algo que me asustaba un poco: toda esta concepción de completar más trabajo.

Pero la idea que soporta la metodología Scrum no es “trabajar más”, sino hacerlo de una manera más inteligente y, así, lograr más. Sutherland tiene una frase muy buena sobre esto en su libro Scrum: The Art of Doing Twice the Work in Half the Time (Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo):

“Piense sobre su trabajo. ¿Qué porcentaje de su tiempo se desperdicia mientras usted está esperando que alguien más termine su trabajo o que se entregue información o porque usted está tratando de hacer demasiadas cosas a la vez? Tal vez usted prefiera pasar todo el día en el trabajo —yo preferiría estar surfeando”.

El modelo Scrum no mide las horas que has registrado, sino las tareas que has cumplido. ¿A quién le importa cuánto tiempo tomó una tarea si el resultado es el mismo? Con esta matriz, no estás creando más trabajo para ti; estás siendo más eficiente para que puedas pasar menos de tu tiempo en la oficina y más del mismo con tus seres queridos y las cosas que te apasionan.

Una de las características principales del Scrum, y que la hace tan potencialmente poderosa, es la idea de iteración y mejora. Esto se refiere tanto al producto en el que se trabaja como a la eficiencia del equipo en sí.

Al final de cada Sprint, el trabajo liberado debería estar listo para entregarse al cliente. Esto no significa que se trata de un producto terminado y completo, más bien, significa que el trabajo debe estar lo suficientemente completo para mostrar algún tipo de Producto Viable Mínimo (Minimum Viable Product) o MVP, en la jerga de las nuevas empresas.

La importancia del MVP

Los avances te permite reunir comentarios de los usuarios desde el principio, ayudando a conducir el desarrollo del producto para asegurar un buen ajuste con el cliente.

Creo que todos hemos experimentado esos momentos en la vida en los que trabajaste horas interminables en un proyecto, solo para descubrir que la persona a la que lo estás entregando tenía una cosa completamente diferente en su mente.

El modelo Scrum está construido sobre entregas iterativas de tu producto. En lugar de esperar hasta que el proyecto esté completo al 100% para entregarlo al usuario, le entregas partes usables del mismo, a medida que las completas. Esto ayuda a evitar el desperdicio de esfuerzos por el cambio de necesidades o si algunos detalles se pierden en la comunicación.

Pero, más allá de la importancia de las iteraciones y mejoras para el producto, la metodología Scrum también se concentra en la mejora del proceso con cada nuevo ciclo.

Durante la reunión Retrospectiva, como miembros de un equipo, comentamos todo lo referente a los desarrollos que estamos ejecutando, para que la eficiencia mejore en base a un plan de acción para el siguiente sprint. En este apartado realizamos el feedback de cada uno y nos deshacemos de las frustraciones para concentrarnos en trabajar en conjunto para proponer soluciones y mejoras. Entre todos abordamos las observaciones respectivas por el retraso de una tarea en específico, tengo la libertad de dar mi opinión por falta de documentación o de permisos, o pedir aclaración de una tarea que no está entendible que pueda representar una limitación técnica que la retrase.

Por ejemplo, los integrantes del equipo al cual pertenezco, tuvimos que ayudar a un compañero del equipo en un sprint, porque tenía demasiadas tareas. Vimos la forma de resolver estos problemas, aplicamos pair programming con la finalidad de terminar el pendiente y mejorar su eficiencia para el siguiente sprint, puesto que ya estábamos casi al término del mismo. Para los siguientes -con cada nuevo ciclo- el equipo debe ser más eficiente y completar un mayor porcentaje del trabajo.

La diferencia de otras metodologías, como Cascada, es que la linealidad de los desarrollos evita que se pueda presentar feedback temprano en el desarrollo. Esto no ocurre en scrum, debido a que la filosofía de las retrospectivas debe poder abordarse en todo tipo de proyectos a través de sus tres puntos principales: qué ha ido bien, qué se puede mejorar y qué acciones vamos a implementar.

Uso de herramienta

Para el uso de Scrum en Envíame usamos Jira, que es una herramienta efectiva para implementar la metodología online, ya que se puede poner mi tablero en un monitor que sea visible para cualquier persona, compartir el acceso con todo el equipo y poner cada detalle necesario en todas y cada una de las tareas en forma de comentarios, listas de verificación, fechas de vencimiento y archivos adjuntos.