5 Razones para utilizar Design thinking y Scrum y crear un producto viable de calidad

El objetivo de agile

Todos tenemos un mismo objetivo, entregar un producto de calidad a nuestros usuarios y lo más importante es que llegue pronto al mercado, seguramente si conseguimos un producto perfecto ‘llegaremos tarde’.

Para tener un producto/servicio rápido de calidad y viable tenemos que estar muy coordinados como equipo y esto lo conseguimos gracias a las filosofía agile. Para ello, existen muchos marcos de trabajo como Lean, Kanban, Scrum, etc.

En el siguiente artículo, veremos cómo encajamos como diseñadores en el marco Scrum, los principales problemas y cuáles son los pasos a seguir.

1.      La propuesta de valor

En ocasiones suele ser complejo el encaje del equipo de diseño con equipos de desarrollo y negocio o cliente. Todos velamos por lo mismo, entregar un producto o servicio que resuelva una necesidad de mercado y lo conseguiremos en base a una propuesta de valor.

La propuesta de valor es la estrategia diferenciadora en el mercado que resuelve unas necesidades concretas para unos usuarios específicos, nuestra propuesta de valor debe reflejar un producto o servicio que resuelva un problema o necesidad que el usuario esté dispuesto a pagar. De esta propuesta de valor, crearemos el deseado MVP o producto mínimo viable.

2.      Los equipos

Como equipo de diseño debemos investigar, empatizar y finalmente dar vida mediante prototipos la propuesta para poder testear en el mercado. El equipo de desarrollo deberá entregar de forma iterativa e incremental aquellas piezas que negocio y diseño le van facilitando, por ello la sincronización debe ser máxima para que todos podamos trabajar sin picos ni embudos en el proceso.

3.      MVP

El MVP o producto mínimo viable, que queremos entregar a nuestros usuarios, será iterativo e incremental. ¿Cómo dividimos esto para que todos trabajemos paralelamente? La respuesta está en la filosofía agile, en este caso pondremos ejemplos de cómo debemos realizar este proceso mediante el marco de SCRUM.

Negocio y diseño deberán empezar previamente a construir el posible prototipo que se quiere llevar a cabo al mercado. Cuando tengamos más o menos una primera aproximación a muy alto nivel, desarrollo deberá hacer el pre análisis para ver la viabilidad técnica.

Todo esto se llevará a cabo en periodos de tiempo llamados Q (trimestres) y estos divididos en sprints ( 2 o 3 semanas de trabajo). Para ello organizaremos una reunión donde trabajaremos todos los equipos juntos y crearemos la foto del trabajo que se realizará en el trimestre. Se acotará todo el trabajo en periodos de tiempo donde cada uno de los equipos se compromete a entregar partes del trabajo. Es muy importante medir los tiempos para que ninguna pieza del equipo se quede sin trabajo o sufra un pico de trabajo.

4. Implantación vs. errores en el anclaje Las dimensiones de los equipos

Jeff Bezos, fundador y director de Amazon, cita que los equipos no deberían ser mayores a los comensales de una pizza familiar.

Sí, el tamaño importa. Cuando nos sumergimos en filosofías agile debemos estar perfectamente sincronizados y las dimensiones del equipo hacen que este pueda ser más agile. 

Los tiempos

El equipo de diseño debe empezar a trabajar antes que desarrollo y tiene que ser capaz de mantener el ritmo de entrega de trabajo cuando todos los equipos estén funcionando a velocidad de crucero, para poder distribuir suficiente material facilitando que el equipo de desarrollo pueda funcionar correctamente.

¿Waterfall? 

Uno de los principios de las metodologías agile es que todos los miembros del equipo sean capaces de hacer todas las tareas, de forma que si un miembro del equipo se ausenta cualquiera de los compañeros lo pueda sustituir, las metodologías agile fueron inicialmente creadas para optimizar la producción en factorías y posteriormente pensada para equipos de desarrollo. ¿Qué pasa con el departamento de diseño?

Cierto es que el principio agile dice que todo miembro del equipo debería se capaz de sustituir a su compañero, pero cuando se trata de equipos de ámbitos muy diferentes lógicamente no se pueden sustituir, por lo tanto cuando deberían de haber más de un diseñador por equipo o en el caso de que estén separados por scrums deberían de ser capaces de reengancharse.

La documentación

Uno de los puntos marco agile Lean es eliminar toda la documentación innecesaria. Es un punto que suele encantar a todo el mundo y que suele recaer en generar 0 documentación. En mi caso, soy una gran fanática de la metodología, el orden y generar aquella documentación básica que permita a cualquier compañero retomar mi trabajo sin complejidad. Generar documentación también me sirve para hacer más fácil la incorporación de nuevos miembros.

La comunicación

Si me dieran un euro por cada equipo que su mayor problema es la comunicación, seguramente estaría escribiendo este artículo en mi propio yate. 

La base de que un equipo funcione bien es que todas las piezas se sientan realizadas y motivadas y uno de los elementos principales es la comunicación. Con los marcos agile, tenemos una serie de ‘ceremonias’ o reuniones periódicas que ayudan a esta comunicación. Estas ceremonias se deben realizar con todos los integrantes de los equipos ‘negocio, desarrollo y diseño’. Si con las reuniones establecidas no es suficiente para que la comunicación sea fluida, recordad que somos diseñadores y que resolvemos problemas investigando y empatizando, no dudéis en aplicar nuestros conocimientos para hacernos más fuertes como equipo.

 5. Diferenciación de tareas

Imaginemos que vamos a crear un ecommerce revolucionario en el mercado y hemos medido el alcance que queremos desarrollar en el primer trimestre. Lo dividiremos en épicas que estarán compuestas de historias que a su vez estarán compuestas por tareas.

Ejemplo

Hemos hecho entrevistas exploratorias para ver la aceptación en el mercado de nuestro producto / servicio. Las respuestas de los usuarios han sido excelentes!. Tenemos nuestra propuesta de valor y MVP o minimum viable product definido y hemos creado conjuntamente nuestro backlog.

Las épicas que hemos definido para nuestro MVP son: Landing page promocional, Definición de la página de producto, Proceso de compra, Simulador de recomendaciones básico, Sistema de devoluciones y atención al cliente, KPIs de nuestro MVP…

Para el primer Q, Sprint 1 vamos a trabajar las siguientes épicas e historias de usuario. Epica 1: Landing page promocional. Historias de la épica 1: Arquitectura del menú, Diseño home con espacios comerciales en la home, Espacio del simulador, Research, Maquetación, Desarrollo…

El tablero

En nuestro tablero colocaremos las historias y tareas asignadas en el sprint.

Las Historias se escribirán 1 por cada post y las colocaremos en orden de prioridad en el primer cuadrante del tablero de forma vertical.

A continuación, se escribirán las tareas asociadas a cada tarea y se colocarán de forma horizontal seguido de la historia en el cuadrante ‘TO DO’. Cuando empecemos una tarea la moveremos en el cuadrante de ‘DOING’ y solo cuando esté finalmente terminada la colocaremos en el cuadrante de ‘DONE’.

 Los actores

El scrum master se encargará de que todo esté en orden y que todas las piezas del equipo hagan posible llevar el backlog del MVP en marcha. Esta figura tiene un rol de árbitro neutral, no está a favor de ninguna de las partes. 

Las ceremonias

• Planning del Q (4 – 5h)

Ceremonia trimestral donde se planifican la historias que se van hacer en cada uno de los sprints. Es una estimación, puede que algún sprint no podamos terminar las tareas o bien podemos coger las del siguiente. 

• Sprint planning (1 -1:30h)

Un sprint puede ser de 2 o 3 semanas. En mi caso, hacemos sprints de 2 semanas, aunque me encantaría que fueran de 3 semanas, evitando tanta ceremonia y sin tener que arrastrar historias grandes a varios sprints. En la sprint planning colocaremos las historias asignadas en ese sprint y cada uno de los miembros pondrá las tareas asociadas a la historia. 

• Daily (15 min)

Es una reunión que se hace diariamente, como su nombre indica, lo recomendable es que se haga a primera hora de la mañana. Cada uno de los miembros dice lo que hizo ayer y lo que va hacer en el día en curso apoyados en el tablero. Si hemos terminado alguna tarea la pondremos en ‘done’ y pasaremos a la siguiente. Si hay alguna duda se puede comentar en el momento para que entre todos le podamos ayudar. 

• Refinamiento (1 -1:30h)

En el refinamiento dedicaremos a resolver posibles dudas, detectar posibles dependencias. 

• Demo (1 -1:30h)

Se organiza un día antes de la planificación y se proyectan los avances de cada uno del sprint para ver en qué hemos estado trabajando.

• Retrospective (1h) Prohibido llevar portátil

Es una reunión que se hace de forma muy ocasional, debemos hacer al menos una vez al Q, debemos hablar de aquellas cosas que hemos hecho bien y en qué podemos mejorar.

Artículo de Irene Ferrer, UX/UI Designer at BBVA for Everis – Madrid. Docente Curso de UX. Diseño de experiencia de usuario y usabilidad de IEM Business School.