top of page

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

Extendiendo mis ideas sobre este polƩmico asunto



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.


Post: Blog2_Post
bottom of page