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.

Debemos rechazar la idea de una “Evaluación UX al final del Sprint”, si esta se piensa como el único espacio en donde este esfuerzo puede integrarse a la práctica de Scrum. En resumen rechazamos pensar en UX como un componente no integrado a Scrum y marcado por el paradigma del modelo de cascada (Waterfall), donde la separación y la especialización son la base.

Para aclarar, debo enfatizar que esfuerzos de descubrimiento inicial (al arrancar un proyecto complejo), o bien evaluaciones formativas en cada evaluación al final del Sprint (ej. pruebas de usabilidad) o pruebas sumativas al final del release, son todas excelentes aportaciones que el profesional UX da al marco de Scrum, pero no son las únicas y las más fundamentales.

La idea central que identifica la relevancia de UX para Scrum está en entender que los procesos de planeación y evaluación no deben hacerse sólo en los puntos extremos de un Sprint, sino dosificarse a lo largo de este.

Para madurar la integración de UX a Scrum seguramente deberemos de transicionar por varias etapas en las que primero introducimos algunos métodos y componentes de UX en el marco. Quizás nuestros esfuerzos iniciarán con un marcado acento Waterfall (separado y especializado), pero no deben permanecer ahí. UX deberá integrarse orgánicamente en el núcleo de las prácticas si se aporta fundamentos y métodos para el diseño de la experiencia de usuario.

Conclusión Siempre soy optimista. Creo que aunque en muchos escenarios existe renuencia a la integración de UX con Scrum, la realidad es que los más talentosos miembros de las comunidades Agile y de UCD (User Centered Design) están plenamente conscientes de lo absurdo de las divisiones y son proponentes de la integración inteligente.

Creo que aunque UCD es un marco de métodos robustos, lógicos y valiosos, marcos de desarrollo de producto como Scrum aportan un esquema válido y práctico de articulación que tiene mejores oportunidades de ser adoptado por algunas organizaciones.

Un UX con énfasis Waterfall no es tampoco malo y para muchas situaciones es la única forma en cómo el valor del diseño (fundamentos+métodos+estrategia) podrá impactar al desarrollo de un producto digital. Busquemos entonces, integración plena donde se puede y esfuerzos puntuales donde no.

UX y Scrum tienen mucho que lograr juntos y esto se logrará si propiciamos entre ellos, como lo indica el Manifiesto Ágil: una colaboración, no una negociación contractual.

---

¿En qué te ayudaron las ideas de esta nota? ¿En qué te puedo ayudar?

Aprecio tus opiniones y comentarios.

Escríbeme e-mail: victor.gonzalez@sperientia.com / twitter: @vmgyg

¿Deseas platicar sobre cómo mejorar la experiencia de tus productos o servicios? Contáctanos: Sperientia [studio+lab]® www.sperientia.com

---

Nota: Esta nota se públicó originalmente en Medium el 27 de mayo de 2017 y luego en mi libro "Ensayos de Sperientia" (2018). La versión que se incluye aquí tiene ligeros cambios con respecto a esas otras.

All rights reserved Copyright © 2017-2020 Víctor M. González Todos los derechos reservados por Víctor Manuel González y González. Sperientia, Sperientia [studio+lab] son marcas registradas. Todas las opiniones expresadas aquí son a título personal y no representan la opinión de mis actuales o anteriores empleadores, clientes o socios.