¿Cómo se aplica Scrum en entornos no TI?

julio 21, 2022

¿Cómo se aplica Scrum en entornos no TI?

Carteles mostrando los textos Marketing, Ventas y Personas con el fondo de una ciudad

Scrum en entornos no TI (Imagen de Pixabay editado por mi)

A modo de resumen ha de aplicarse tal y como viene en la Guía Scrum, usar los eventos con el objetivo que tienen y no fijar, a priori, ningún formato concreto para los elementos de Backlog, es decir, usar Backlog Items y no Historias de Usuario.

Es posible encontrar en algún marco, como puede ser Scrum Manager, donde se definan los elmentos del Product Backlog como Temas, Épicas e Historias de Usuario. Es importante tener siempre presente que estos marcos ofrecen puntos de partida y herramientas para ayudarnos en una u otra dirección. Lo importante aquí no es la herramienta como puede ser una Historia de Usuario, lo importante es conseguir definir un requisito o una necesidad de manera que se fomente la conversación de manera que se pueda confirmar que todas las partes entienden lo mismo.

Pero veamos cómo se aplica Scrum en algunos sectores.

Marketing

Para aplicar Scrum en Marketing es muy importante romper silos, conseguir que áreas como Ventas y Marketing formen un único equipo al que además incluiremos personas con capacidades de diseño y desarrollo.

Perfiles de diseño se puede entender desde el punto de vista publicitario de la estrategia del marketing, pero ¿desarrolladores?. Es sencillo, en realidad si se incluye o no a desarrolladores en los equipos no es importante, lo importante es disponer en los equipos de todas aquellas capacidades que van a ser necesarias para poder implementar la parte de la estrategia de markenting al completo. Es decir, lo que se pretende es disponer de equipos multidisciplinares que sean capaces de conseguir un objetivo con el menor número de dependencias posible.

Estos equipos han de ser de entre 3 a 9 personas y los eventos que van a ejecutar en Scrum son los 5 descritos en la guía.

Tanto el evento de planificación como la gestión del backlog es lo que más puede llamar la atención, aunque si nos centramos en la esencia vemos que está alineado con lo descrito en la Guía Scrum.

El backlog estará compuesto por Historias de Usuario, siguiendo a priori el patrón conocido, centrandose en los Touchpoint (o puntos de contacto) del Buyer's Journey o del proceso de compra. Sin embargo, en el Backlog no incorporará Historias de Usuario exclusivamente el Product Owner, sino que los interesados también podrán incluirlas.

El proceso de la planificación del Sprint es el evento que más cambia, a este evento, con capacidad de interactuar podrá asistir: equipo de Marketing, equipo de Ventas (si no son un único equipo), Business Owners, personas de telemarketing y otros interesados internos.

A grandes rasgos durante la planificación se:

Revisar el Marketing Model Canvas para que todos compartan la misma base de asunciones
Poner un objetivo al Sprint.
Brainstorming para crear o revisar el Backlog
Crear un plan de Sprint

Otra diferencia importante es que en Marketing se utiliza los Criterios de Aceptación pero no como un medio de verificar que se ha realizado lo que se pedía antes de entregarlo al cliente, sino como medio de saber que se ha conseguido lo que se esperaba después de ponerlo en manos del cliente.

Resumen

Mantiene	Cambia
Equipos multicisplinares para no tener dependias externas	No sólo el PO tiene control sobre el Backlog, otras personas pueden introducir elementos.
Las funciones del Scrum Master	Backlog se define durante la Planning (Braindstorming)
Equipo auto-organizado	Las Historias de Usuario se escriben desde el Buyer's Journey
3-9 personas en el equipo	Los Criterios de Aceptación sirven para verificar que se cumple el objetivo pero después de ponerlo en manos del cliente.
Historias de Usuario se escriben con el mismo patrón	En la Planning participación activa de personas externas al equipo (Business Owners, Equipo de Ventas y otros intersados)
Mismos 5 eventos (Planning, Sprint, Daily, Review y Retro)

Ventas

En Ventas Ágiles con Scrum también se apuesta por tener de equipos multidisciplinares como en Marketing a fin de evitar dependencias externas.

En los equipos de ventas el elemento de trabajo no son Historias de Usuario sino cuentas o posibles clientes. Durante la planificación se ve qué cuentas se van a abordar durante el siguiente Sprint y cuál es la mejor estrategia de trabajarlas. Los Sprints han de ser suficientemente grandes para mover una oportunidad a la siguiente etapa pero lo más pequeños posible.

Los vendedores no trabajan de manera independiente como hasta ahora, trabajan en equipo de manera que, en cada oportunidad, se pueda aprovechar las fortalezas de cada uno a la par que se mejoran las capacidades del equipo expandiendo dichos conocimientos entre sus miembros. Claramente no es posible este tipo de colaboración en los equipos de ventas que generalmente existen en las organizaciones, donde cada uno se mueve por sus propias comisiones. Este tema ya lo traté en otro artículo anterior (¿Agilidad en Ventas?)

En las Reviews cada persona cuenta qué ha conseguido durante el Sprint y cómo lo ha hecho, por lo tanto, si después se conversa sobre las posibles mejoras en las estrategias empleadas, la Retrospectiva podría quedar incluida dentre de la misma reunión.

Resumen

Mantiene	Cambia
Durante la planificación se eligen los elementos del Backlog a trabajar y se define la estrategia a seguir durante el Sprint	Product Backlog Items = clientes/cuentas
El PO prioriza el Backlog	Sprints de 4 semanas con planificación semanal
Equipos multidisciplinares (formadores o desarrolladores incluidos)	Priorización por temperatura del lead o scoring
Se realizan los mismos eventos	En la reunión diaria comparten conocimiento para cada oportunidad.
	El ciclo de vida de los elementos cambia (columnas del tablero visual)

Personas

A estas alturas la agilidad aplicada a los Recursos Humanos ya es muy conocida incluyendo su propio manifiesto. De hecho y siguiendo los valores de la agilidad en muchos casos han cambiado de nombre dado que las personas no somos recursos intercambiables como puede ser un ordenador o una mesa.

Los departamento encargados de la gestión de personas posiblemente sean de los más importantes en un proceso de transformación ágil donde lo más difícil es cambiar la cultura de la empresa así como la motivación de las personas.

En este área, en realidad como en todas las demás, se puede aplicar tanto Kanban como Scrum. Habitualmente he visto que se aplica Kanban más que Scrum, pero también he encontrado donde aplican Scrum.

El área de personas abarca muchos procesos, desde contratación hasta retención a traves de difernetes medios. Para el segundo de los puntos una de las cosas que puede hacer es escuchar las necesidades que tienen los empleados y ver maneras de satisfacerlas. Para ello el equipo encargado ha empleado Scrum con Sprints de entre 1 a N semanas, utilizando Historias de Usuario para describir las necesidades de los empleados.

Construcción

¿Agilidad en la construcción?!!! Siii en la construcción también se aplica Agilidad, mil y una veces habras oido que la agilidad no se puede aplicar en todos los ambitos, que por ejemplo no se puede construir un puente o una casa con agilidad. Pero... podemos romper los moldes? podemos utilizar Scrum para el diseño de un edificio? y para la reforma de un centro comercial?

En ambos casos es SI!!!

El trabajo que realiza un arquitecto durante la concepción de una construcción se realizado con software que permite ser flexible en sus primeros pasos. A día de hoy se utilizan estandares que permite pasar un diseño de un software a otro siendo totalmente compatible quedando en un único fichero toda la información relativa al diseño de un edificio o un puente. Dado que no está soportado en papel que es más difícil de modificar su creación en Sprints o pequeñas fases es totalmente factible.

En este caso el plazo del proyecto se divide en Sprints teneiendo reuniones semanales de planificación que nos permiten cambiar de rumbo si así fuera necesario. Por tanto podemos hacer cambios hasta el último momento del diseño.

Por otro lado, durante la reforma de un centro comercial, como de cualquier otro edificio, se pueden hacer entregas por valor. En este caso se dispondrá de un backlog que nos permita priorizar por aquellas cosas que más valor aporte y gestionar las dependencias (disponibilidad de otros proveedores por ejemplo). De esta manera se puede valorar entregar primero la reforma de los baños para que los clientes se encuentren cómodos en un momento tan intimo, continuar con el sistema del aire acondicionado, después las fachadas de las zonas más concurridas, etc.

Resumen

Mantiene	Cambia
Tienen roles anáogos al Propietario de Producto, Scrum Master y Equipo de Desarrollo	Se añade el Business Owner
Mismos eventos	Paquetes de trabajo en vez de Historias de Usuario
Tablero Kanban
Se realizan entregas de valor parciales

Atención al cliente

En muchas áreas de una compañía no se puede preveer la entrada de trabajo ya que se realiza una atención a demanda del cliente, ya sea interno o externo. Sin embargo la mejora del servicio puede ser planificada y ejecutada con Scrum. Mi amigo Alex estuvo como coach ayudando a un equipo de Atención al Cliente a mejorar el servicio utilizando Scrum.

Dado que no existe un producto, tampoco existe un Propietario de Producto sino un Propietario de Proceso. La mayoría de elementos que se maneja en este equipo son de exploración y no tanto de ejecución, por ello, cambian sus elementos de requisitos:

Tema: Pain points o puntos de dolor de nuestros clientes
Epic: Causas raíz, cada una de ellas tiene un impacto y valor propio
Historias de usuario: Soluciones a las causas raíz que sean implementables en los procesos

Siendo los Criterios de Aceptación Criterios de Éxito donde se establece un porcentaje que definirá el éxito o no de la propuesta dado que se asume que llegar al 100% es imposible.

Dado que estos equipos van a revisar los distintos procesos que utilizan las personas de Atención al Cliente es necesario contar con un equipo multifuncional que de la posibilidad de ejecutar las iniciativas con el menor número de dependencias posibles.

Resumen

Mantiene	Cambia
Las Historias de Usuario usan el mismo patrón	Se cambian los elementos de trabajo habituales
Equipo multifuncional	Más Historias de Usuario de exploración que de implementación
	Hay Criterios de Éxito y no Criterios de Aceptación
	Se cambia al Propietario de Producto por Propietario de Proceso

Conclusiones

Tal y como he adelantado al inicio del artículo la esencia de Scrum se mantiene con indiferencia del área donde se aplique. Por tanto se puede afirmar que Scrum es válido para equipos que no sean de TI. Si bien es cierto que habrá que cambiar la manera en la que estas áreas vienen trabajando porque un elmeneto importante en común es disponer de equipos multidisciplinares sin los cuales no es posible llevar a buen puesto las iniciativas que se lleven a cabo en un tiempo reducido.

Un saludo,