Ahora que ha salido la nueva certificación sobre Scrum with UX, quería escribir sobre el papel de los UX en Scrum. Vamos a repasar el sitio de las diferentes áreas funcionales en los Scrum Teams.
Últimamente, no paro de leer artículos en favor de los UX, incluso hace poco, se han creado dos grupos de Meetups sobre UX y la certificación PSU. Bien, uno de los últimos mensajes que he leído es “buscamos UX que aporten soluciones a los clientes, vas a trabajar en un departamento con más UX”. Lo curioso de esta afirmación es que una organización, definida como Agile que tiene departamentos, busca UX que aporten soluciones. Recordemos lo que dice Agile: “las mejores arquitecturas nacen de equipos autoorganizados”. Esto es importante, no podemos pretender que la figura del UX defina toda la solución. Esto ocurre en organizaciones que no entienden bien Agile, y que, por tanto, defienden mucho el Design Thinking, Sprint 0 o Diseño de Productos Digitales. Todas estas técnicas no son malas per se, sin embargo, si son utilizadas para definir la “solución definitiva” ¿para qué hacemos Scrum? Scrum aporta inspección & adaptación para descubrir tu solución, si todo está ya definido Scrum apenas aporta.
El design thinking como nuevo waterfall
El ejemplo más extremo de esto es lo que he vivido en un cliente hace unos meses. El personal del cliente estaba asombrado porque les vendían fases de “design thinking” de tres meses de duración y a un coste desorbitado. Lo peor, más de un 80% de lo que se definía en esa fase se tiraba a la basura. Los motivos eran varios, pero uno de los principales es no contar con un arquitecto técnico en ese momento. Si los diseñadores tratan de definir todas las soluciones sin alguien técnico que diga que no se puede hacer, mucho trabajo se tirará.
Un ejemplo que pude vivir como Scrum Master hace tiempo. El equipo de diseño propuso eliminar el campo “sexo” a la hora de pedir un seguro, se consideraba anacrónico. Cuando apareció una persona técnica experta, explicó las consecuencias de esa decisión: “si eliminamos ese campo, necesitamos un desarrollo de seis meses”. Los diseñadores, marketing y negocio no se lo podían creer. El técnico lo explicó: “ese campo se usa en muchos sistemas de la compañía, si no se rellena, entonces todos esos sistemas fallarán, habrá que cambiarlos y probarlos”. Después de este debate, estuvimos valorando poner siempre “masculino”, tampoco nos convenció. Finalmente, cambiamos el campo “sexo” por “¿Qué trato quiere que le demos?” De esta manera, conseguimos una solución a base de iteraciones y de descubrimiento.
¿Y la arquitectura?
Venimos del paradigma de definir la “arquitectura perfecta” antes de empezar el desarrollo. Una vez más, las mejores arquitecturas emergen porque los requisitos y las necesidades emergen y, por tanto, no podemos hacer la arquitectura definitiva. Muchas de las decisiones arquitectónicas requieren saber lo que quiere mi usuario y es algo que se va descubriendo a medida que hacemos entregas. El ciclo es: entrega, feedback, nuevas opciones en forma de PBI y nueva entrega. La arquitectura tiene que adaptarse a lo que nos vamos encontrando continuamente.
Estamos en un mundo complejo, lo que supone, que no existen buenas prácticas, existen prácticas. Cada práctica tiene su sitio, pero no podemos diseñar la solución final. Esto aplica tanto a UX como a Arquitectura, ser prescriptivos en un mundo complejo, no funciona.
¿QA o Sistemas?
Hemos hablado de las disciplinas que suelen actuar antes, ¿qué ocurre con las que suelen actuar después? Precisamente, si algo enseñamos a los equipos Scrum, es que la calidad es parte del proceso. En Scrum, se define lo que significa que algo esté terminado, incluyendo el proceso que definamos como “calidad”: pruebas unitarias, integradas, seguridad etc. Perfecto, todo esto se tiene que hacer a la vez que se desarrolla, una vez más no esperamos a que la subida final.
Para Sistemas, la cultura DevOps, automatización y Continuos Delivery, nos ayuda a que las cosas “terminadas” incluyan las operaciones. Esto no significa que todo tenga que subir en el acto, eso dependerá de nuestra estrategia de producto, pero el recorrer el camino de la subida aunque no vayamos a subir nos elimina muchísima incertidumbre sobre ese camino.
¿Mantenimiento o Explotación?
Una vez más, estas disciplinas deberían ser parte del proceso. Mantenimiento o explotación existen porque trabajamos bajo la mentalidad de proyecto de entrega big bang y, después, mantenimiento. Pero, en Scrum hablamos de producto, precisamente de entrega contínua, el mantenimiento no es que no exista, es que es parte del proceso de trabajo con el producto.
Equipo Multidisciplinar
La conclusión a la que llegamos es: un equipo multidisciplinar. La gracia es que todas las disciplinas que hagan falta trabajen juntas ¡sin etiquetas! Por eso, no existen UXs, Diseñadores, QAs, Sistemas, Fronts o Backs. En vez de eso, hay “skills” en el equipo. Tareas que hay que hacer y que se hacen en equipo, sin atribuirnos etiquetas ni méritos, somos un equipo y tenemos que trabajar juntos para alcanzar los retos del mismo.
Es curioso cómo las empresas “agile” siguen teniendo departamentos para mejorar su “eficiencia”. Precisamente, la agilidad no se basa en que hagamos muy rápido el trabajo de Sistemas o el UX, la agilidad es la capacidad de entregar a mercado y eso es un trabajo de muchas disciplinas en colaboración, no en formato departamental.
Y tú ¿Qué departamentos tiene tu organización?
Estoy bastante de acuerdo con lo que comentas Javier. Pero tengo una pregunta relacionada con este tipo de equipos. Esta sería si el rol de Business Analyst sin que sea el PO y en el caso de que haga únicamente trabajo de definición, puede entrar en la categoría de miembro del equipo técnico. O por lo menos cuál sería el encaje más correcto en un equipo de Scrum. En entornos de seguros, bancos, etc, este rol es bastante común y no es raro que haya dos o tres por equipo.
Al final, Scrum y todas las disciplinas nuevas que están apareciendo tratan de fomentar que no haya etiquetas. Si piensas que los productos son “cosas que hay que hacer” y las personas “profesionales que saben hacer cosas” no tendremos etiquetas como Business Analyst. Dicho esto, los BA pertenecen al Dev. Team y trabajan como uno más. Seguramente, en los refinamientos tengan un papel más predomindante que otras personas del equipo. Si hay varios, es porque es necesario, eso en principio no importa. ¿Cómo lo plantearías?
Tengo una duda, des de hace tiempo, que leyendo este artículo me ha vuelto a la cabeza.
He trabajado con equipos muy potentes donde todo el Dev Team eran true fullstack, y era una delicia! Todos sabían de React,PHP, Android, IOS, testing etc y compartían experiencias y enseñanzas para crecer juntos.
Nunca he conseguido sentirme cómodo en como integrar aquí la figura de UX. Había una persona dedicada al diseño en el equipo, que participaba de la misma forma que lo hacía el resto del Dev Team, pero era la única que tenia el conocimiento de diseño. Para mí esto es razonable, ya que tiene una formación distinta, y a la vez, me chirría porque solo hay una persona que se pueda ocupar de diseñar los cambios.
Cómo lo solventaríais?
Buenas Genís, recuerda que en un equipo Scrum no buscamos que todos hagan de todo. Podemos tener miembros con diferentes skills y es positivo. Lo importante, que el Scrum Team sea capaz de sacar adelante el producto por sí mismo. Si tienes una persona especialista en UX, pues durante la Sprint Planning nos organizaremos para entregar la mayor cantidad de valor posible. La respuesta está en el propio equipo y en cómo quieran organizarse ell@s.