Aunque sigo al grupo Agile & Lean Baleares desde hace algún tiempo, las horas a las que se celebran sus eventos coinciden con baños y cenas de los peques por lo que me resulta bastante difícil asistir. Sin embargo, hace un par de semanas aproveché que una de las superabuelas estaba de visita para apuntarme al meetup “UX y Agile en Habitissimo”.

El evento, organizado en las oficinas de Habitissimo del Parc Bit y facilitado por Josep Riudavets (¡gracias Josep!) tenía como principal objetivo tratar de ayudar a los miembros de esta empresa en su proceso de integración de las tareas de UX en los diferentes equipos de desarrollo que utilizan metodologías Agile.

El meetup se desarrolló bajo un formato abierto y con técnicas basadas en Design Thinking. Tras formar varios grupos, la primera de las fases fue escuchar como los integrantes de Habitissimo nos contaron la situación actual y los retos a los que se enfrentan. Seguimos con una ronda de preguntas para tratar de recopilar más información para tener una visión lo más completa posible. A partir de ahí, definimos visualmente cómo creíamos que era la situación actual a todos niveles (organización del trabajo, relaciones entre miembros del equipo y resto de la empresa, dónde existían las principales barreras, etc.) y continuamos con una fase de elaboración de soluciones a nivel grupal, que posteriormente compartimos entre los diferentes equipos que se habían formado. Por último, cerramos el proceso con el diseño de una posible solución que intentará ayudar al equipo de Habitissimo a mejorar en sus procesos de trabajo. La sesión estuvo muy bien en todos los sentidos (contenidos, organización, ambiente…) e intentaré repetir en futuras ocasiones.

Intentando plantear la situación de forma visual

Algunas ideas sobre la combinación de UX y Agile

Sin entrar en los detalles específicos de los problemas del equipo de Habitissimo (que por otra parte creo que son los habituales cuándo se intenta integrar las tareas de UX dentro del mundo agile) el evento me ha servido como excusa para reflexionar un poco como veo este tema.

Antes de contarte mi perspectiva, sirva como advertencia que no soy un experto en metodologías agiles. Aunque llevo trabajando con Scrum varios años y estoy certificado como Product Owner, no considero ni mucho menos que pueda dar consejos a otras personas o equipos. Si además esperabas encontrar «LA SOLUCIÓN» a todos los problemas que plantea la integración de UX y Agile, creo que puedes dejar de leer ahora mismo :-P. Dicho esto, en el meetup encontré una situación bastante habitual. No ha sido la primera vez que he oído este tipo de situaciones ya que las he vivido anteriormente e incluso estamos intentando ajustarlas dentro del equipo del formo parte actualmente.

Mi opinión sobre el problema es que, para empezar, muchos enfoques excluyen por defecto parte de las tareas de UX,  y quedan enmarcadas en una fase previa al sprint. Dentro de los mismos, no hay investigación, no hay entrevistas, no hay test de usuarios… y el trabajo de UX queda reducido a la parte de diseño visual y/o maquetación (si es que se puede considerar como una tarea UX).

El equipo de Habitissimo

En el fondo, esta aproximación viene condicionada por la necesidad de trabajar en la definición de los elementos del product backlog previamente. Básicamente, antes de crear la historia de usuario necesitamos conocer el problema (investigar) y plantear su posible solución. En caso contrario, podemos caer en el error de tratar de solucionar el problema equivocado. Por ejemplo, desarrollar un formulario de consultas para evitar llamadas al Centro de Atención al Cliente cuando el problema puede ser que los usuarios no conocen que existe una sección de ayuda en la web o que, una vez en la misma, no encuentran lo que necesitan ya que no existe un buscador usable y que funcione en condiciones.

Una vez explicado este factor, creo que uno de los aspectos la clave del proceso es la inclusión del responsable del diseño dentro del equipo de Scrum a tiempo completo. Por un lado, creo que es imprescindible para que se sienta un miembro más y se comprometa a la alcanzar los objetivos, siguiendo la filosofía de valores que promueve el manifiesto de Scrum.  Por otro, significa evitar dependencias, pérdida de foco y problemas de gestión de prioridades, un elemento muy habituales cuando debes realizar tareas de distintos equipos. Ya sabemos qué cuando marketing pida cambios en la landing que había que lanzar “ayer” será difícil argumentar que es fundamental trabajar en las tareas del sprint.

No obstante, el hecho de que la persona encargada de UX forme parte del equipo no debería significar (o al menos no siempre) que estén terminados los diseños visuales para empezar a programar.  En ese caso, lo que consigues es un proceso en cascada… como el que se sigue cuando, por defecto, se espera a que el desarrollo de backend esté terminado para empezar con el de frontend. Precisamente, el ser miembro del equipo debe permitir realizar tareas de diseño en paralelo a otras así como realizar cambios durante el sprint según las circunstancias lo requieran.

Pero es esta integración donde, desde mi punto de vista, surgen los dos mayores problemas. El primero es que Scrum intenta minimizar el papel de los especialistas (todos son desarrolladores «a secas») para evitar esas dependencias. Sin embargo, a la mayoría de desarrolladores les cuesta mucho afrontar tareas de diseño, así que al final tienen que pasar por el diseñador por lo que el proceso acaba ralentizado.

El segundo de los inconvenientes es que si el/la UXer está 100% enfocada en el sprint… ¿quién hace el trabajo previo de investigación? Una posible solución es que haya personas o equipos distintos: uno más enfocada a las tareas previas (investigación, conceptualización, test de usuarios…) y otro centrada en el trabajo de “producción” (que generalmente se trata de los diseños visuales).  Sin ser una solución fácil, puesto que no todas las empresas pueden permitirse esta contar con tantos perfiles (ejem… el debate sobre si una única persona debe ser capaz de realizar todo el proceso UX lo dejamos para otro día), tiene como desventaja la perdida de información a lo largo del proceso y entre los diferentes miembros del equipo. No obstante, creo que puede ser una buena forma de anticipar ese trabajo de definición previa a la entrada de elementos al backlog.

Siguiendo este modelo y para intentar una gestión adecuada de esa carga de trabajo, surgen conceptos como los dual-track (discovery & delivery) o los design sprints que, aunque con una perspectiva interesante sobre cómo enfocar el trabajo con el usuario, desde mi punto de vista, añaden una cierta capa de “cascadismo” al proceso y retrasan la entrega de valor.

Dual Track para combinar UX y Agile

“Vale… ¿y cuál es la solución?” estarás pensando. Pues, como ya avisé, no lo sé. El desarrollo de producto es muy diferente según la cultura y objetivos de la empresa, y no creo que que exista un método que funcione en todos los casos. Por ejemplo, en Type Form trabajan con dual-track y parece que les va bien. En el otro lado de la balanza, expertos en metodologías agiles como Jerónimo Palacios consideran que hacer dual-track no es hacer Scrum.

Al final, creo que es trabajo de cada equipo buscar cuál es la mejor forma de trabajar y obtener los resultados deseados, intentando eso sí, maximizar el valor para el usuario (y no «hacer la misma basura, pero más rápido”)  Para ello, nada como ser transparente, inspeccionando y adaptando, algo que defiende el manifiesto de Scrum y que es, precisamente, lo que hace el equipo de Habitissimo. Mi reconocimiento para ellos 🙂.