¿Por qué este artículo?
Tanto el desarrollo de software Agile como el diseño de experiencia de usuario (UX) tienen como objetivos comunes entregar antes sistemas más usados y valiosos para el cliente. Sin embargo en muchas ocasiones ambas no consiguen estos objetivos porque trabajan por separado. En una serie de dos artículos vamos a proponer medidas para facilitar el trabajo conjunto de diseño y de desarrollo, y así mejorar el valor obtenido.
- En este primer artículo veremos porqué es importante añadir UX a Scrum, la resistencias que podemos encontrar, y dos enfoques para integrar Scrum y UX.
- En el segundo artículo, más centrado en Scrum, veremos como adaptar el uso del Backlog de Producto y de los PBI a UX, y como tratar Done.
Problemas habituales
Hay contextos donde el diseño de experiencia de usuario es más necesario que en otros.
- En los desarrollos internos para usuarios de una organización (B2B), podemos tratar directamente con estos para conocer y validar sus necesidades. Aún así, es muy importante hacer sistemas útiles y usables, y por ello la participación de especialistas en UX puede ser necesaria.
- Sin embargo, en proyectos para clientes externos (B2C) trabajar en la experiencia de usuarios (UX) es vital. En estos contextos, conocemos menos a los usuarios (y sus necesidades), es más difícil interaccionar con ellos y además pueden tener una gran facilidad para escoger otros proveedores si los productos que les ofrecemos no són suficientemente útiles o usables.
Riesgos de desarrollos Waterfall o Scrum sin UX
En los proyectos basados en el ciclo de vida de cascada (o Waterfall) existe un riesgo evidente de no acertar en la experiencia de usuario. Se pueden desarrollar análisis funcionales detallados y diseños en papel (wireframes o mockups) para entender las necesidades del usuario. Aún así, hechos como que el diseño funcional, la programación y las pruebas suelen ser realizadas por personas diferentes y en momentos potencialmente alejados, hacen que el riesgo de invertir mucho esfuerzo y tiempo en diseños no validados pueda producir sistemas con funcionalidades e interfaces que no solucionen los problemas del usuario y que tengan baja usabilidad, siendo muy difícil de arreglar en caso que se hayan hecho mal.
En los desarrollos de producto con Scrum el riesgo de no desarrollar un sistema útil y usable es mucho menor: trabajamos en iteraciones cortas, teniendo en cuenta y validando frecuentemente las necesidades y expectativas del usuario. Aunque el impacto será menor, porque en caso de equivocarnos lo podremos detectar y corregir antes, el riesgo no desaparece, p.e.:
- Podemos intentar cubrir necesidades que el usuario no tiene realmente (p.e. prefiere seguir trabajando como antes de tener el sistema porque no percibe el valor de usar el producto).
- Podemos aportar soluciones funcionales a necesidades reales pero poco usables.
Así pues, que el desarrollo adopte un enfoque UX (con o sin especialistas en diseño) puede ser necesario, en contextos donde haya más complejidad en entender al usuario, para evitar el riesgo de producir sistemas no usables (o usados) y el sobrecoste realizar cambios evitables.
Esto ya ha pasado antes (p.e. QA)
Introducir Scrum en las organizaciones tradicionales siempre levanta un problema: necesitamos crear equipos autosuficientes, con la capacidad de tomar decisiones y realizar el trabajo asociado. Esto requiere que sean polivalentes o "cross-functional", usualmente trayendo personas de equipos o departamentos separados. Este rediseño organizativo suele provocar un nivel de rechazo por almenos tres motivos:
- Los managers de los grupos o departamentos pierden capacidad de trabajo (y poder)cuando dejan ir a las personas a los equipos Scrum.
- A los miembros del equipo Scrum no se les libera de su dedicación al departamento, induciéndoles una sobrecarga del trabajo y tensiones por las prioridades de su trabajo.
- Hay personas en la organización (a veces fundadamente) que piensan sin los departamentos se pierde la calidad, el control y el criterio común para un tipo de trabajo.
Un ejemplo conocido en las adopciones Agile es el rol de QA. Tradicionalmente el control de calidad (en producto y proceso) ha sido planificado y realizado por un grupo separado, mientras que en las organizaciones ágiles esta función se ha integrado dentro de los equipos, aunque a veces se mantenga parcialmente separada en contextos donde la calidad es crítica. En general esto no ha producido una reducción de la calidad sino al contrario, un aumento, debido a factores como:
- Adaptación más fácil de los procesos a las necesidades reales del equipo. No hacen falta auditorías porque los procesos se mantienen útiles y actualizados.
- Mayor educación en calidad al resto de miembros del equipo, que son más independientes y están más sensibilizados para realizar bien el trabajo de calidad. El especialista de QA se convierte más en un mentor y coach que un controlador.
- Más integración en la definición de requisitos, programación y pruebas técnicas y funcionalides (p.e. TDD y BDD). Los errores se descubren antes y por tanto se solucionan en mayor proporción.
Así pues, aunque las organizaciones (y los grupos de UX) puedan tener una resistencia al cambio, saber que los equipos Scrum ya han incorporado otros roles en el pasado con éxitopuede ser un argumento poderoso para convencerles.
Integrando Scrum y UX: Opción 1) Dual-track
Cuando queremos integrar el trabajo de UX y de desarrollo, una opción intuitiva para organizaciones tradicionales (con grupos de trabajo UX y DEV especializados) suele ser crear Sprints alternos para cada tipo de trabajo. Esto es:
- Sprint N: los diseñadores definen la interfaz.
- Sprint N+1: los desarrolladores la convierten en software.
- Sprint N+2: los diseñadores testean y recogen el feedback.
Este enfoque, llamado comunmente "dual track Scrum" tiene varios problemas:
- No es Scrum, al final del Sprint no hay producto potencialmente entregable.
- Se alarga la entrega hasta ciclos de 3 Sprints, y por tanto la validación con el usuario y la entrega de valor.
- Se pierde casi toda la posibilidad de interacción entre el usuario, el diseñador y el desarrollador. Eso puede generar incomprensión y desperdicio de trabajo (p.e. como dice Jeff Gothelf [5], un mínimo del 50% del trabajo de diseño no implementados).
El origen de este enfoque está en el artículo de 2007 Adapting Usability Investigations for Agile User-centered Design de Desirée Sy donde explicaba el modelo de colaboración frecuente (diaria) entre los diseñadores y desarrolladores. Cuando habla de 2 lineas de trabajo se refiere a diseñadores y desarrolladores trabajando juntos y no en equipos ni Sprints separados.
Integrando Scrum y UX: Opción 2) Diseñadores en equipos Scrum
Otra opción para integrar el trabajo de diseño y desarrollo es tener Sprints únicos donde trabajen concurrentemente diseñadores y desarrolladores. Este enfoque puede generar dudas, especialmente a los diseñadores, respecto aspectos como:
- ¿Cómo planificar el trabajo de diseño en Sprints cortos?
- ¿Cómo alinear los ritmos del diseño y del desarrollo?
- ¿Debemos tener un único Backlog de producto o podemos mantener un Backlog para cada tipo de trabajo, uno de diseño y otro de desarrollo?
- ¿En qué momentos del Sprint interactuar?
Las respuestas a estas y otras preguntas no son triviales, pero tampoco difíciles. Esto ha funcionado en muchos equipos donde se hace Scrum con UX de manera habitual. El curso Professional Scrum with UX profundiza, de manera altamente interactiva, en como integrar Scrum y UX.
En el siguiente artículo...
El segundo artículo de esta serie, adaptando el framework Scrum a UX, trata de responder a las anteriores preguntas revisando el uso del Product Backlog, PBI, refinamiento y eventos.