Agile-UX: ¿Por qué el Sprint Cero es una aberración?

Extendiendo mis ideas sobre este polémico asunto


Photo by Startaê Team on Unsplash


Hace poco, en el contexto de una emocionante e iluminadora sesión de capacitación con la comunidad Ágil (yo como participante), envié a mis redes sociales un mensaje sobre la aberración que significa pensar en un Sprint Cero como una forma de insertar “UX” en un marco ágil como Scrum .


Mi post sobre el “Sprint Zero” en LinkedIn


Mi mensaje causó comentarios a favor y en contra (directos e indirectos) y creo que la única forma de aclarar el punto y contribuir al aprendizaje es crear esta nota.


Sobre Scrum — ideas de arranque Primero que nada hay que decir que cuando hablo de aberración, uso la palabra para apuntar a la definición de la Real Academia Española que establece el significado de la palabra como: “Grave error del entendimiento”. Uso la palabra para apuntar a que la idea (“Sprint Zero para UX”) tanto es grave porque nos lleva por un camino que conduce al error, y además, que tiene su raíz en no entender bien de lo que se trata el marco en cuestión: Scrum.


Scrum es quizá el marco de trabajo ágil más popular para el desarrollo de productos. En su definición se especifican roles, eventos, artefactos y reglas para operar e integrar procesos y técnicas que permiten un desarrollo incremental, iterativo e implementado a través de ciclos cortos donde se marcan los cierres y planeación con espacios para evaluación, reflexión para asimilar el aprendizaje y mejorar el producto y el proceso.


Sprints: el corazón de Scrum Una de las ideas centrales de Scrum (su corazón) es el Sprint, que se define de acuerdo a La Guía de Scrum como un “bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “terminado” utilizable y potencialmente desplegable”.

Tomando la idea de Alan Cyment, podemos decir que un Sprint es el espacio donde y durante el cual un equipo de desarrolladores hace dos cosas: (1) Crea el incremento del producto en lo que podríamos llamar un proceso de “delivery”, en el sentido de “giving birth” de la palabra y (2) Define el siguiente incremento del producto en lo que podríamos llamar un proceso de “discovery”, en el sentido de revelar, descubrir y provocar un esfuerzo de refinamiento de lo que previamente se ha incluido en el así llamado Backlog (Lista de Producto).


Lo anterior revela la posible existencia de un error en el entendimiento en cuanto a lo que es Scrum. Muchos practicantes (“agilistas” y “UXers”) entienden erróneamente que durante un Sprint de Scrum la acción está en las manos de los desarrolladores y que cualquier esfuerzo de diseño (incluido el diseño de la experiencia de usuario) y sus actividades (por ejemplo, investigar usuarios o definir una arquitectura de información) no se hace durante esos bloques de tiempo.


El rol de diseño no se limita a los espacios “fuera del Sprint” o en sus puntos extremos (planeación o evaluación), los diseñadores trabajan durante el Sprint porque son parte esencial de los esfuerzos de delivery y discovery.


En ese contexto, en las siguientes líneas explico mi perspectiva sobre el rol del diseño para el desarrollo de productos interactivos digitales.


¿Cómo el diseño de UX contribuye al Delivery que se hace en un Sprint?

Aquí entendemos el diseño de la experiencia de usuario (UX) en su sentido de aportar fundamentos para definir la interacción entre la persona y un producto digital. Estos fundamentos pueden ser elementos de psicología cognitiva, social, organizacional, o fisiología sensorial, o elementos de economía de la conducta. Todo son, sin duda, aportaciones que se dan mientras se construye el producto y que un desarrollador requiere co-definir con un diseñador UX. Muchos otros elementos como el seguimiento y revisión de lineamientos de diseño o el diseño de la información, deberían co-definirse en un esquema de justo en el momento que se requiere (just in time).


¿Cómo el diseño de UX contribuye al Discovery que se hace en un Sprint? El diseño de la experiencia de usuario (UX) también tiene aportaciones muy importantes para ayudar al proceso de refinamiento que se hace durante un Sprint (n) para anticipar lo que será el trabajo en el siguiente Sprint (n+1). Herramientas de UX para investigar a usuarios y sus reacciones, para validar prototipos de partes del producto o para hacer análisis competitivo, entre otras, son y pueden ser utilizadas durante el Sprint. Se utilizan para ayudar a mitigar el riesgo de no saber cómo un usuario reacciona ante uno de los elementos del Backlog que se están contemplando para el siguiente Sprint. Estos esfuerzos se hacen en colaboración con los desarrolladores y claramente con el dueño del producto (product owner) y otros stakeholders. Evaluaciones y pruebas se insertan entonces durante el Sprint y se programan para llevarse a cabo en varios y múltiples momentos antes de una fecha límite que, obviamente, es previa a la finalización de éste.


El Fantasma del Modelo de Cascada es el Gran Problema La pieza clave para entender el rol de UX en un marco como Scrum es entender que (1) el diseño es parte del desarrollo de un producto y (2) desarrollar implica tanto delivery como discovery. Son estos dos procesos que corren durante el Sprint, no exclusivamente en puntos extremos (al principio o al final). Como lo expresa Andy Kelk estos procesos se deben entrelazar para lograr dos metas: “Build the Right Thing” (Discovery) y “Build the Thing Right” (Delivery).


Por lo anterior decimos que, para integrarse de manera efectiva con el marco de Scrum, el diseño de la experiencia de usuario (UX) no se define exclusivamente a priori o se evalúa a posteriori. Debemos rechazar la idea de un “Sprint Zero de UX” si este se piensa como un esfuerzo donde se trata de generar toda la contribución de UX al inicio del proyecto.