Este artículo es una guía sobre cómo estamos llevando a cabo la dirección de los equipos de ventas, aplicando el framework Scrum. No siempre es fácil desarrollar una estrategia comercial ágil, a veces incluso muy difícil, pero es una metodología interesante donde los valores de Scrum están presentes en todo momento y los resultados son francamente buenos. Hablamos de Scrum Sales.
En otro artículo en B2B Growth, en ¿Qué es Scrum? Metodología y Aplicaciones en Ventas, os habíamos contado información sobre la metodología Scrum, los roles, eventos, sprints, artefactos y reglas del Scrum. Además, profundizamos sobre dónde se puede llegar a aplicar Scrum, cuáles son sus ventajas y pudimos ver su aplicación en un equipo de ventas.
Hoy os acercamos más detalle sobre este último punto, acorde con nuestra experiencia.
Recordemos los principios de Scrum (TIA):
- Transparencia
- Inspección
- Adaptación
Y como en cualquier metodología Agile, el cliente ha de estar en el centro, no basta con creernos que conocemos al cliente, tenemos que llegar a obsesionarnos y estar seguros de que realmente lo conocemos, sabemos lo que le preocupa, sus objetivos y los compartimos con él.
Este framework, como ya muchos conoceréis, no se basa en la rigidez, sino en la adaptación, en la prueba y error. Algo que debemos tener muy claro, es que de los errores se aprende y de ello hay que sacar provecho. De nada sirve que si alguien del equipo comete un error, se le aparte, al contrario, si comete un error, lo más probable es que no vuelva a cometerlo, por lo que seremos más eficientes y productivos la próxima vez.
Scrum Sales
Pues llegados aquí, podemos definir Scrum Sales como la aplicación del framework Scrum a cualquier proyecto relacionado con el proceso de ventas (y casi por extensión a su vinculación con las actividades de Marketing). Esto permitirá una metodología Agile independientemente del tamaño de tu empresa, donde podamos aplicar sus principios a todas las etapas del proceso comercial.
Cuando se trata de vender, tenemos que entender bien los valores, cultura y objetivos de nuestra compañía, pues todo lo que desarrollemos deberá de ir con coherencia. Nos tenemos que obsesionar con nosotros mismos y con el proceso que vamos a aplicar
En los equipos de venta, debemos de entender que es muy diferente la visión de un equipo de actuación individual, generalmente orientado a comisiones de venta, donde no suelen compartir sus artimañas y best practices a la hora de vender. Esto ocurre ya que por naturaleza son roles muy individuales y para que se pueda aplicar un modelo ágil necesitarían un cambio cultural. Los bonus o incentivos en equipos Scrum deberían definirse acorde a unos objetivos del equipo y no tanto individuales. Igual que en el rubgy, en Scrum la contribución individual es necesaria para el objetivo del equipo, pero nunca a costa de los resultados de los demás.
“En el rugby la melé avanza de manera conjunta como una sola unidad. Así es la forma de actuar con nuestros equipos de marketing y ventas de forma ágil, eficiente y con un propósito de equipo”.
Bruno Méndez – CEO Sum.
Arrancamos
Lo primero que vamos a hacer es definir nuestro Backlog de Producto. Haremos una lista ordenada de todo lo que queremos hacer. Luego hablaremos de roles, pero adelantamos que este backlog es responsabilidad del Product Owner. Aquí no hablamos de planes detallados, hablamos de una lista con ordenada, que contiene una descripción, un valor y una estimación para llevarla a cabo.
Como hablamos de proyectos de alta incertidumbre, poco predecibles, no hagamos como en la gestión tradicional de proyectos, donde definimos una serie de bullets y fechas para cumplir. Esto va de ser más flexibles, no sabemos qué nos vamos a encontrar por el camino, de repente pueden aparecer nuevos actores que hagan que cambiemos la ruta, y esto no será un error, será un aprendizaje y una adaptación.
Con el backlog de producto, definimos los Sprints. Los Sprints en Scrum Sales, que por definición tienen un timebox máximo de 1 mes, son eventos de Scrum que contienen a su vez otros eventos. El objetivo de cada sprint es entregar algo que aporte valor. Por supuesto, un sprint empieza cuando acaba el anterior, y muy importante, un sprint acaba cuando acaba su timebox. Lo que dure un sprint lo definen el Product Owner y el Equipo de desarrollo.
Con una visión del equipo de ventas, una buena opción es interpretar el backlog de producto como tu Pipeline Comercial. El Product Owner puede establecer en la lista como todos los leads potenciales (o cuentas si empleamos un enfoque ABM) y, ya que se trata de una lista ordenada, podemos priorizar según nuestros intereses a partir de las variables de segmentación que consideremos oportuno usar. Otro posible orden es a partir de la temperatura del lead o scoring. Siempre debe ser el Product Owner el que ordene y defina la estrategia de ese orden.
Aceleramos un poco
Pasamos a definir la lista de tareas del Sprint. A esta lista la llamamos Sprint Backlog. Aquí ya incluimos información de cada una de las tareas (estas tareas las definimos en el Sprint Planning, reunión de planificación). En este listado incluimos cómo vamos a llevar a cabo cada tarea del backlog de producto. El responsable del sprint backlog es el equipo de desarrollo y es dinámico, es decir, lo iremos actualizando según avance el sprint.
La estructura base en los proyectos Scrum son los sprints. Esa duración, que debe ser menor a 30 días, es para poder ir aportando valor al resultado o incremento e ir iterando en cada uno de los sprints, aprendiendo siempre al menos una cosa nueva que aporte para el siguiente, de esa manera mejoraremos nuestros procesos. Cierto es que algunas operaciones dentro del backlog de producto durarán más, por lo que podemos sugerir algunos Sprints de mayor duración. Obviamente, no todos los contratos son iguales de fáciles de cerrar.
Una herramienta muy útil que nos da el framework Scrum, y que aporta esa transparencia de la que hablábamos al inicio del artículo sobre los principios Scrum, es la Daily Scrum. En Scrum Sales vamos a usar esta herramienta a diario. Para esa reunión, que debe durar menos de 15 minutos, y que, si es posible, recomendamos hacer siempre a la misma hora y mismo lugar (es la mejor manera ese interiorizarlo y facilitar agenda, puede ser en remoto), es obligatorio la participación del equipo de desarrollo, en nuestro caso, el equipo de BDRs. En esa reunión se hablará de los impedimentos y problemas que afectan a la eficiencia del equipo. Esta reunión impactará directamente en la conversión de leads a ventas, pues podremos ayudar a desatascar muchas propuestas o ideas para mejorar esas ratios. Durante los Sprints, un lead pasará de lead a venta, y es importante que el Product Owner sea consciente para mover la tarea del backlog de producto y que siempre lo tengamos actualizado.
Roles en el equipo Scrum Sales
Existen 3 roles dentro del equipo Scrum, que son el Product Owner, el equipo de desarrollo y el Scrum Master. Cada uno tiene sus funciones y todos están al mismo nivel, es decir, no tienen una jerarquía. El equipo es una máquina con estas 3 piezas en el que si una de ellas falla todos fallan.
Scrum Master
Es el responsable de velar que todos cumplen con la metodología Scrum en la organización y de que se está implementando de una manera correcta. No es un responsable de nadie, no es el jefe, pero sí es el responsable de maximizar el valor y la productividad del equipo en conjunto. Además, si existe algún problema externo que nos impide hacer bien el desarrollo de las tareas, será el encargado de buscar la solución. En resumen, es un facilitador. Es una figura muy valiosa, que asegura la calidad del Scrum Sales, que vela porque los procesos sean ágiles y se lleven a cabo los eventos necesarios, como las reuniones diarias (Daily Scrum).
Product Owner
Como hemos visto, es el responsable del backlog de producto, por lo que es el responsable de ordenar y priorizar todos los leads o cuentas, bajo su propio criterio y responsabilidad. Esto es así, ya que es el encargado de optimizar el valor que aporte el equipo de desarrollo, en este caso, el equipo de Sales y Business Reps. Es el único que podría cancelar el Sprint, pero tiene que quedar muy claro que NO dirige al equipo de desarrollo, sólo dice el “qué” hay que hacer.
Equipo de desarrollo
Estos son los que faltan, los que dicen “cómo” lo vamos a hacer. Mismo nivel que el Scrum Master y el Product Owner, pero diferente función. Es un equipo multidisciplinar, además de BDRs, pueden participar desarrolladores front, diseñadores, gente de analytics, formadores, etc., todas las disciplinas necesarias para poder realizar el Sprint sin depender de nadie de fuera. Son los responsables del seguimiento y de las estimaciones. Resuelven sus propios conflictos internos.
Scrum Sales Dashboard
“El tablero Scrum es una herramienta que nos ayuda a ser más transparentes con el trabajo que se está realizando”.
Pablo González – Martech Sum.
Por lo general, es el Scrum Master el que más lo utiliza, sobre todo para ver en qué estado se encuentran las tareas (que hablando de ventas podrían ser los leads o cuentas).
En ventas, es muy importante este tablero, ya que veremos fácilmente si está habiendo problemas para pasar a “Done”, o si tenemos mucho en “On Hold”, y si es así, tomar medidas.
Conclusiones
Implementar Scrum en maneras o gestión de proyectos de una manera no tan tradicional es relativamente nuevo. De hecho, las empresas estamos experimentando cómo nos podemos aprovechar de las ventajas de esta metodología Agile para mejorar otra serie de procesos o proyectos muy diferentes a los que venimos acostumbrados, para conseguir esa mejora continua de la que todos tramamos de alcanzar. Como consejo, cuando intentas adaptar una metodología Scrum, has de ser muy rigurosos al comienzo, el equipo ha de estar enfocado y con ganas de llevar a cabo esta transformación. Recuerda, inspecciona y adapta, prueba y error, con eso conseguiremos llegar a la mejora continua.
