Las trampas del Agile y su relación con el UX

Creo que podemos consensuar que términos como Agile, Lean, Scrum, Kanban, entre otros, ya no son ajenos para la gran mayoría de quienes se mueven en entornos de desarrollo digital. Entre ellos los perfiles de UX. Es por esto que es común oír hablar de Agile UX, Lean UX, Dual Tracking o Design Sprints/Thinking, entre otros, pero… ¿cómo se integran estos con los equipos de desarrollo?

Partamos definiendo un poco, simple y rápidamente a:

• Agile UX como una metodología centrada en la eficiencia gracias a la colaboración en el equipo (individuos e interacciones por sobre procesos y herramientas / funcionamiento por sobre documentación extensa / respuesta al cambio por sobre seguir un plan) y la colaboración con el cliente.

• En relación a Lean UX, básicamente como apostar por la mejora (sin generar desperdicios) en base a la experimentación: idear/suponer, prototipar/construir, testear/experimentar, validar/aprender. Aunque a raja tabla se habla sólo de construir, medir y aprender.

Suena bien, ¿no? De hecho, hay un diagrama de interaction-design.org que nos muestra cómo deberíamos hacer para interactuar entre todo esto:

Esto podría ser perfecto para equipos que evolucionan un mismo producto, donde el team agile está constantemente trabajando e iterando sobre un proyecto, donde uno o más UX + Research pueden participar de manera prioritaria y dedicada, pero ¿qué pasa cuándo no es así? ¿cuándo los equipos “saltan” de proyecto en proyecto por la ansias de poner en producción más cosas? ¿cuándo tienen un backlog demasiado exigente? ¿cuándo esa exigencia viene dada por stakeholders que hacen mal uso de la agilidad? ¿Por fechas de puesta en producción impuestas por compromisos de gerentes o la (no) planificación de grandes campañas? ¿cuándo el stakeholder o el product owner prioriza la cantidad por sobre el valor o la calidad? ¿y si a todo eso le sumamos restricciones por costos o por cantidad de perfiles?

La respuesta puede darse por dos lados:

• Si tuviéramos los recursos y pudiéramos destinar varios perfiles apuntando a que puedan responder en el tiempo y la forma necesaria a todos los requerimientos en un sprint de alta complejidad, esto nos podría traer el problema, de que en este escenario, muchos sprints pueden ser menos demandantes a nivel de análisis, construcción y validación, generando ineficiencias en el equipo.
• O bien, si no destinamos o no podemos destinar más recursos, el UX podría verse sobrepasado, pasando poco a poco a perder este flujo virtuoso, para integrarse básicamente como un input para la rueda sin fin de los sprints de desarrollo. Se perdería, en gran medida, la posibilidad de testear de manera profunda y aplicar los hallazgos durante el mismo sprint. En el mejor de los casos, si se lograra aplicar un dual track, en un escenario con fechas impuestas e improvisadas, donde se puede saltar de proyectos de baja complejidad, donde ni siquiera es necesaria una investigación con usuarios, a otros de alta complejidad donde hay un mundo que descubrir, esto no es mantenible en el tiempo.

Por lo tanto, para empresas con estas características o particularidades es que realizamos junto a @dinovox, una pequeña adaptación a las propuestas que encontramos (tanto en el diagrama anterior como en otras lecturas) y llegamos a lo siguiente esquema, que aborda las etapas de discovery, delivery e improvement, y que ahora compartimos:

Para la optimización y eficiencia de los recursos de UX (menos perfiles con menos incertidumbre) y también para generar una mayor retroalimentación del equipo, es que definimos un equipo de trabajo UX + UI (+ Front en algunos casos) separado de todas las células pero con un UX responsable por cada una. Este UX participará de todas las actividades propias de las células y de los clanes a los que pertenecen.

En cuanto a las etapas y partiendo por el Discovery:

• Integramos y adaptamos las bases del design thinking pero sólo a nivel conceptual, cerrando con algún entregable / definición que sirva de base para el trabajo. Acá buscamos dejar claro que el trabajo y el resultado dependen del nivel de certidumbre de la historia de usuario / épica / proyecto. Las que pueden ir desde un simple acuerdo y un benchmark rápido, a un design sprint ampliado con la definición de un MVP + wireframes en baja.
• Esto se trabaja en acuerdo con el UX responsable principalmente con el Product Owner y el Scrum, más los integrantes que resulten valiosos en base al mismo nivel de certeza que ya hablamos. Si este fuera medio o bajo, el UX es apoyado por otro facilitador UX – Research.
• Este trabajo se realiza como el punto de partida para el equipo UX, donde aplicamos principalmente Lean pero separamos los procesos, nuevamente sólo a nivel conceptual, en idear, construir, medir y aprender.

Como puntapié de la etapa de Delivery:

• Introdujimos las Prototype Reviews, donde buscamos obtener feedback aún más temprano que los Sprints Reviews, generando menos desperdicio al llegar a los equipos de desarrollo con una definición validada (lo más cercana posible) tanto por los usuarios finales como por los usuarios internos y stakeholders. Este documento validado fue considerado como uno de los checks para establecer el DoD (Definition of Done) de la etapa de Discovery y es parte junto al UI + interacciones o documentación (de existir y ser necesario) para la creación de las historias de usuario y del DoR (Definition of Ready) del trabajo del sprint.
• En todo el proceso de delivery, el UX encargado de la célula participa de las actividades claves del sprint y será el responsable de llevar el feedback de vuelta al equipo de UX, tanto de los refinamientos con el equipo, como de los Sprints Reviews. En este punto también debe velar por la implementación o confirmación de las marcas para el seguimiento en línea del desarrollo (Analytics, Hotjar u Optimize).

Finalmente en la etapa de Improvement:

• El UX responsable, debe coordinar junto a los equipos de Analytics, Research o de Optimización para el seguimiento o mejora de la iniciativa. Llevando este aprendizaje nuevamente al equipo de UX pero también a la célula.

Con este modelo de trabajo sabemos que no estamos respetando muchos de los planteamientos propuestos por las metodologías, pero es justamente algo de lo que estamos cada vez más convencidos: adaptarse y tomar lo mejor de cada aprendizaje es crucial para optimizar recursos y potenciar el conocimiento compartido.
Como dato adicional, podría agregar que esto nos permite atender a más de 12 células con un equipo de 6 UX, los que van rotando de manera trimestral o semestral (sí, también contrario a lo que dice la literatura) para generar sinergía dentro del mismo equipo UX y con las células que van tomando. Esto nos permite planificar de mejor manera el research, distribuir las cargas de trabajo generando menos incertidumbre, aprovechar conocimientos previos del resto del equipo, apoyar en requerimientos que no vienen en metodología Agile y que el equipo pueda ir creciendo de manera más homogénea.

Finalmente y para reforzar, esta adaptación se hizo en el contexto incierto del trabajo de una gran TELCO pero que a la vez es también un contexto bastante claro: es “la certeza de la incertidumbre” tanto de la misma empresa como del mercado. Es probable que debas también adaptarlo para tu caso particular, pero si en algo te sirvió nuestra experiencia estaremos felices de leer la tuya y/o tus dudas o comentarios.

Un abrazo,
Fabbian.