Agile Marketing: cómo comenzar a aplicar la metodología

Aprovechando que la semana pasada publiqué un tutorial sobre Trello, he pensado que podría ser útil explicar cómo aplico la metodología Agile en mis proyectos.

Quizá no te suene eso de las metodologías ágiles.

O a lo mejor crees que es sólo para desarrollo de software y productos digitales.

Nada más lejos de la realidad: se puede aplicar a cualquier proceso, proyecto o departamento, realmente.

Y en este artículo tiene dos partes muy marcadas:

• En la primera te hablaré un poquito de qué esto de las metodologías ágiles y cómo comenzó todo. La teoría que hay detrás y sus conceptos.
• En la segunda parte te voy a explicar cómo aplico yo las partes que me gustan de esta metodología en equipos de marketing, para que, si te interesa, puedas empezar a aplicarlo en el tuyo desde ya. La parte práctica y operativa.

Si ya conoces la primera puedes saltar directamente aquí.

Empecemos por el principio.

Parte 1: En qué consiste la metodología Agile

Es un enfoque sobre la toma de decisiones en gestión de proyectos, que pone el foco en el desarrollo de funcionalidad incremental e iterativamente, aportando más valor al usuario / cliente en cada ciclo.

Surge primero en el desarrollo de software y rápidamente después se aplica a otros campos, como la gestión de proyectos de cualquier tipo (no solo de software), como a la creación de producto, la UX o el marketing.

Se opone a los modelos en cascada -donde para empezar una parte del proyecto hay que haber terminado la anterior- ya que se consideran demasiado burocráticos y pone mucho foco en la comunicación entre las partes, por encima de la documentación.

Suena bien, ¿verdad?, pero es posible que te preguntes cómo surge todo esto.

Pues ahora verás.

Historia de la metodología Agile

A mediados de los 90 surgió una corriente de rechazo a la gestión de proyectos estructurada, que cristalizó en una convención en 2001 en Snowbird, Utah.

Allí se acuñó por primera vez el término “Agile Methodology”, se creó la “Agile Alliance” y se publicó el “Agile Manifesto” que recoge los principios de la metodología.

El Manifiesto Agile

Puedes leer el documento original aquí:

http://agilemanifesto.org/

Los cuatro valores del Manifiesto

Como has podido ver en el enlace superior, en el documento se especifica que:

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Y estos cuatro valores se desglosan en estos doce principios.

Los doce principios del manifiesto Agile

Los tienes aquí:

http://agilemanifesto.org/principles.html

Pero te los copio:

1. “Satisfacción del cliente. Es la base de todo. Se alcanza a través de la entrega de productos de valor que cubran una necesidad.
2. Bienvenidos los nuevos requisitos. Cambiar sobre la marcha no es dar un paso atrás. Cualquier sugerencia o solución es bienvenida si se trata de mejorar el producto.
3. Entregas por semanas. La división del trabajo en fases productivas es la base de la metodología. En lo posible, ejecutar una cada semana.
4. Es posible medir el progreso. La evolución de los procesos no es un elemento subjetivo. Se puede medir con indicadores concretos.
5. Desarrollo sostenible. La forma de ejecutar los proyectos debe garantizar en sí misma su continuidad. No es una cuestión de hacer por hacer.
6. Trabajo cercano. Los líderes de los proyectos deben ejercer su labor en el mismo terreno donde tienen lugar las tareas y no desde los despachos.
7. Conversación cara a cara. El gestor responsable debe comunicar de forma eficaz sus mensajes, mejor si se hace de forma presencial. Se recomiendan reuniones periódicas tanto con el cliente como con sus colaboradores.
8. Motivación y confianza. Los procesos sólo tendrán éxito si quienes los llevan a cabo son personas motivadas y que interactúan en climas de confianza y solidaridad.
9. Excelencia técnica y buen diseño. Las formas nunca deben perderse, así como tampoco la calidad del trabajo. Todo es un conjunto.
10. Simplicidad. Las tareas han de ser lo más sencillas posible. Si alguna no puede ser ejecutada en esos términos, debe ser dividida en iteraciones hasta que se reduzca su nivel de complejidad.
11. Autogestión de los equipos. Si bien debe existir una figura que monitorice los equipos de trabajo , éstos deben ser capaces de organizarse por sí mismos. El exceso de jerarquías crea dependencia entre los colaboradores.
12. Adaptación circunstancias cambiantes. Los proyectos no suelen terminar de la misma forma en que empezaron. Es indispensable que quienes los ejecutan puedan adaptarse a las distintas circunstancias que puedan surgir.”

No sé qué te parecen, pero si alguna vez has estado involucrado en el desarrollo de productos digitales, es difícil no estar de acuerdo con absolutamente todos los puntos.

Muy difícil.

Tanto que, en la actualidad, vista su utilidad en el ámbito original se ha trasvasado esta metodología como digo a la gestión de todo tipo de proyectos e incluso a sectores.

Se habla de “Diseño de producto Agile” o de “Agile Marketing” y “Agile Management”, en los que siempre se intenta poner foco en:

• Comunicación cara a cara.
• Transparencia.
• Satisfacción de cliente.
• Simplicidad.
• Desarrollo incremental y mejora continua.

¿Le vas viendo color a la metodología?

Vamos con los elementos imprescindibles.

Elementos y conceptos básicos de la metodología Agile

Bien. Todo lo explicado hasta ahora es muy bonito, pero para empezar con ello hace falta bajar la teoría y explicar los distintos elementos que harán posible su planteamiento y ejecución.

El framework

Dentro de que todas las metodologías ágiles recogen los mismos principios y valores, cada una los aplica de forma diferente.

Y esta forma diferente de hacer las cosas son los diferentes frameworks o marcos de referencia.

Hay varios, cada uno con sus reglas, sus ventajas, recomendaciones e inconvenientes. Los más habituales y conocidos son dos: Kanban y Scrum.

Kanban

Surge en Japón tras la II Guerra Mundial, que dejó al país sumido en un desastre económico y tecnológico.

Toyota en los 50 diseñó un sistema de producción “just in time” (JIT) en el que cada pieza se hacía en el momento justo, ni antes ni después y que definió como “altamente efectivo y eficiente”.

Para llevarlo a cabo se basaban en tarjetas que identificaban las necesidades de material en la cadena de producción.

Entonces, esta metodología recoge la idea de las tarjetas y las equipara a una tarea.

Se crea un tablero con una columna por cada estado por el que tenga que pasar una tarea, por ejemplo:

• Definida.
• En ejecución.
• Finalizada.
• Revisada.

Éste es un ejemplo de tablero sencillo, pero se puede hace tan complejo como requiera el proyecto. Un ejemplo de tablero más complejo podría ser:

• Definición.
• Análisis.
• Desarrollo
• Pruebas.
• Puesta en producción.
• Documentación.

El tablero será diferente para cada empresa o equipo según sus necesidades y es aplicable tanto a proyectos de desarrollo nuevo («lanzar el blog», «abrir canal de Tik-Tok») como a tareas de mantenimiento («revisión de los banners de la web») o de recurrentes («revisión de comisiones de afialidos», «reporting semanal ecommerce»).

El tablero puede ser físico (es lo que se recomienda para que sea visible y transparente para todo el equipo) o informatizado, que es donde entra Trello en juego.

Scrum

Es parecida a la anterior, ya que como te decía, los principios en los que se basan y filosofía es la misma.

El naming se podría traducir como “melé” y viene del rugby, cuando todo el equipo se une.

Se distinguen en pequeños matices, quizá porque se considera que Scrum es más restrictivo y en mi experiencia está más orientado a desarrollo de producto digital:

• Recomienda equipos interdisciplinarios. En Kanban se permiten los especializados.
• Roles concretos: Scrum Master, Product Owner y equipo de desarrollo en scrum son obligatorios, en Kanban puedes tenerlo o no
• Iteraciones de duración determinada (entre 1 y 4 semanas): los sprints (se pone mucho énfasis en esto).
• Los cambios: lo que entra en un sprint es inamovible y los cambios deseados se pospondrán hasta el próximo sprint para poder medir el proceso de quemado o Burntdown (no es así del todo). En Kanban los cambios son más sencillos de ejecutar, ya que se puede sustituir alguna de las funcionalidades con prioridad más baja por la nueva deseada.
• Ceremonias concretas de tiempo fijo.
• Tablero nuevo en cada sprint vs el tablero persistente de Kanban.

Por todo esto yo personalmente para Agile marketing prefiero Kanban y es la que te voy a explicar en este artículo.

De hecho, no es lo más habitual pero yo he visto y trabajado en modelos híbridos:

• Uso de Scrum para nuevos desarrollos y Kanban para tareas recurrentes dentro del mismo equipo. Es el que teníamos en Lowi.
• Metodología “Scrumban” que toma prestado partes de uno y de otro.

Historias de usuario

Quizá el núcleo de la metodología.

Se trata de una manera sencilla de describir una tarea concisa que aporta valor al usuario o cliente.

Se suelen redactar en tarjetas (a mano en post-it o digitalmente) y cuentan con:

1. Título: breve, para hacer referencia a ella.
2. Descripción: Como [rol del usuario] Quiero [funcionalidad] Para [Objetivo de la historia]. Ejemplo: «Como usuario del blog quiero ver artículos relacionados al final del artículo para seguir leyendo temas de mi interés«.

Además, tienen que poseer estas características:

1. Independientes: unas de otras. Se tienen que poder encarar de forma aislada, aunque estén relacionadas. Por ejemplo, en una campaña publicitaria se separará la tarea de diseño de la de copywritting, pero obviamente ambas tienen que estar relacionadas.
2. Negociables: se acuerda entre ambas partes el alcance y los detalles y se renegocia si es necesario, dividiéndose por ejemplo en dos partes.
3. Valoradas: tienen que aportar valor real al cliente, tiene que ser tangible.
4. Estimables: esto es que se puede analizar el esfuerzo requerido para su ejecución. En tiempo o en puntos de desarrollo.
5. Pequeñas: si son muy grandes y no se pueden estimar se tienen que subdividir.
6. Verificables: testables, con criterios de aceptación binarios (lo pasa o no lo pasa).

Una vez redactada, se coloca la tarea en el tablero en la columna inicial y conforme cambia su estado, se irá moviendo entre columnas.

El Backlog

Se trata del conjunto de tareas del proyecto redactadas y pendientes de encarar.

El Equipo

Dependiendo de la metodología, es imprescindible o no contar con ciertos roles en el equipo.

Por ejemplo, en Scrum, lo habitual es contar con:

• Product Owner: responsable de negocio del producto.
• Scrum Master: solucionador y facilitador del desarrollo. Puede ser el líder del equipo o no.
• Equipo de desarrollo / especialistas (UX, diseñadores, SEO…): realmente, las personas que ejecutarán la mayoría de las tareas.
• Tech-lead: responsable técnico del equipo. Puede ser la misma persona que ejerza el rol de Scrum Master.
• QA: testeo.

En Kanban no es necesario contar con estos roles, aunque es cierto que cuanto mejor esté definido el rol de cada miembro del equipo, más fácil le será valorar la tarea y desarrollarla posteriormente.

Sprints

Duración de una iteración, ciclo o entrega, en la que se sacará una o varias nuevas funcionalidades priorizadas o mejoras (features) de un producto digital o se desarrollarán las tareas pertinentes de ese ciclo («elaborar los contenidos de Instagram»).

Lo normal es que duren entre una y cuatro semanas. En desarrollo de producto digital suelen ser dos o tres, mientras que en marketing pueden ser perfectamente de una.

El objetivo del Sprint

En desarrollo de producto, cuentan con un objetivo del Sprint, que aglutina la mayor parte de las funcionalidades que se pretenden acometer.

En otro tipo de proyectos no siempre es necesario ese objetivo.

Ceremonias

Así es como se denominan las reuniones de equipo propias de la metodología.

Éstas son las más habituales y cada una tiene su duración, frecuencia y objetivos:

Sirven para analizar, e y mejorar el desarrollo y procesos iterativamente

• Daily: diariamente, los miembros del equipo comentan muy resumidamente lo que van a hacer ese día y si hay algo que les esté bloqueando una tarea anterior, de forma que se comenten los pasos a seguir para eliminar el bloqueo. Debería durar unos cinco minutos.
• Sprint plan: Al finalizar el sprint en curso, el equipo se reúne para comentar cómo se va a encarar el sprint siguiente y estimar las tareas.
• Refinamiento: es el paso previo a la anterior ceremonia. En el refinamiento se trata de que cada historia esté lo suficientemente clara y comprensible para el equipo y el alcance esté definido para que sea valorable en el Sprint plan.
• Retrospectiva: tras el cierre del sprint se analiza cómo ha ido la cosa. Qué problemas nos hemos encontrado y los puntos de mejora se pueden considerar para futuros sprints.

Si hablamos de marketing, ¿son imprescindibles todas estas ceremonias?

Más adelante te doy mi respuesta, porque hasta aquí llega la teoría.

Ahora te explico cómo lo he aplicado yo en distintos equipos y proyectos desde cero.

Además, verás que el enfoque es muy sencillo y no hacen falta cambios radicales ni nuevas herramientas para comenzar a aplicar principios de agilismo.

Parte 2: El proceso de implementación de la metodología Agile en Marketing

Si nunca has tenido experiencia con metodologías ágiles, lo primero que quiero que hagas es leerte varias veces el manifiesto y sus principios, porque, realmente, con eso es suficiente para entender y aplicar algunos conceptos.

Se trata de un cambio de mentalidad en el que te diría que lo principal es hablar y llegar a acuerdos entre las partes (jefes, propio equipo, equipos externos…) sabiendo que todos buscáis el bien común.

Lo segundo, ser flexibles. Entender que los cambios van a llegar y hay que asumirlos. Aunque nos fastidie. Eso no significa «ceder» siempre, sino llegar al punto anterior: hablar y acordar.

Lo tercero y último, medir. Porque midiendo es la única forma que tenemos de saber cómo de óptimo es nuestro rendimiento, el de nuestro equipo y si realmente todas las acciones que ejecutamos realmente merecen la pena.

Vale, pues una vez que tengas grabado eso en la cabeza pasemos a hablar del sistema.

El sistema del Agile Marketing

La idea que hay detrás es que tu equipo es capaz de ejecutar una serie limitada de tareas en un tiempo dado.

A este tiempo dado lo vamos a llamar sprint y, para empezar, lo más sencillo es que su duración sea de una semana.

Entonces, tendrás que organizar un sistema para que cada semana (sprint) se realicen el número de tareas adecuadas.

¿Cuántas son esas tareas? Pues al principio no lo sabes, porque no tienes un histórico. Así que, en los primeros sprints, lo máximo a lo que aspiras es a estimar con un cierto grado de error, menor conforme más experiencia tengáis tú y tu equipo.

Además, tampoco tenéis experiencia redactando tareas, por lo que se añadirá una capa de dificultad a la estimación.

Pero tranquilo, que esta carencia de certeza durará poco: una vez que lleves varios sprints, hayas medido y sepas redactar las tareas correctamente ya tendrás datos para poder estimar cada tarea mucho mejor.

Entonces, sabiendo cuál va a ser la evolución, lo primero es encontrar una herramienta donde crear el backlog y anotar todas las tareas del sprint.

Las herramientas del Agile Marketing

Tienes varias, según prefieras que sean online u offline.

¿Ventajas de cada tipo?

Pues te diré que las online son más inmediatas y pueden tener coste mínimo, mientras que las offline, que básicamente consiste en un tablero y unos post-it, dejan muy claro a todo el equipo y ponen en valor de cara al negocio en lo que se está trabajando.

¿Mi recomendación?

Salvo casos en los que sea imprescindible dejar a las claras todo lo que se está haciendo, comienza con una herramienta online.

Yo te recomiendo dos, en función de tu convencimiento sobre el sistema: Excel si quieres probar y Trello si estás convencido de que esto es para ti.

Agile Marketing con Excel

Digo Excel porque es es la más extendida, pero cualquier hoja de cálculo (Google Sheets, LibreOffice…) te vale.

La idea aquí no es tanto hablar de Kanban y tableros sino empezar a aplicar principios ágiles desde ya.

Para ello, te crearás un documento en el que irás añadiendo todas las tareas a acometer una debajo de otra. Será tu Backlog.

Además, te crearás una serie de columnas que te ayuden a definir cada tarea, planificar y medir el rendimiento del equipo y el esfuerzo que requiere cada tipo de tarea:

En este caso, las columnas que tenemos son:

• Prioridad: ya que aunque se podrían colocar las más prioritarias del sprint arriba, eso nos impediría filtrar, así que añadimos una columna.
• Marca: si trabajas con varios clientes o marcas, esto te permitirá segmentar por cada uno de ellos.
• Tareas: en este caso añadimos sólo el título, ya que, en general, son tareas que ya conocemos y no hacen falta descripciones más amplias.
• Comentario: en cualquier caso, si necesitáramos más detalle, lo añadiríamos aquí.
• Tipo de tarea: lo que nos va a permitir saber cuánto tiempo dedicamos a cada una de las labores diferentes y poder analizar:
  • Si merece la pena el tiempo invertido.
  • Si el tiempo de ejecución se reduce conforme más experiencia coge la persona ejecutando el mismo tipo de tarea.
• Persona: pues eso, quién la va a realizar.
• Estado de la tarea: Sin empezar, Empezado o Finalizado.
• Fecha de entrada: la fecha de inicio del sprint, lo que nos permitirá filtrar lo que se hace en cada sprint.
• Inicio: fecha de cambio de estado de la tarea, de Sin empezar a Empezada.
• Hora inicio: la hora en la que se empieza una tarea.
• Hora final: la hora en la que se acaba una tarea.
• Esfuerzo en horas: la diferencia entre la Horia inicio y la Hora final.
• Semana: para saber la semana del año y poder comparar a futuro o hacer gráficas.

Cada sprint se añadirían las tareas nuevas añadiéndoles la Fecha de entrada y filtrando por esa fecha, con lo que ya tendríamos establecido el nuevo sprint.

Eso sí, si han quedado tareas pendientes de otros sprints, añadimos al filtro la fecha del sprint anterior para que nos aparezcan las tareas de ambas.

Este método es válido siempre que no tengamos tareas de más de 2 sprints, sino se agregarían demasiado y tendríamos que buscar otro sistema como crear una nueva tarea del sprint nuevo que reemplace a la que se quedó sin hacer del sprint anterior.

Bien, pues con una plantilla como ésta es más que suficiente para empezar a planificar y aplicar los tres pilares del agilismo: acordar, ser flexibles y medir.

Ahora, que cuando lleves un tiempo -y veas que esto funciona- lo mismo quieres dar un paso más allá. Será el momento de cambiar de herramienta…

Agile Marketing con Trello

Lo primero es que aquí tienes un tutorial para iniciarte con la herramienta.

Una vez que lo hayas leído y te hayas creado la cuenta, que sepas que tengo publicado este artículo acerca de cómo utilizar Trello para aplicar la metodología Kanban en marketing, en el que entro en más en detalle, pero aquí te dejo de todas formas algunas pinceladas:

1. Créate un solo tablero para empezar. Es mucho más fácil de gestionar cuando empiezas.
2. En ese tablero, créate 3 o 4 columnas, no más, que podrían ser:
   • Backlog: el backlog con todas las tareas, las de el sprint en curso y todas las demás que se vayan añadiendo para futuros sprints.
   • To do: mueve de Ready a esta columna las tareas que se van a ejecutar en ese sprint. Las tareas de mayor prioridad serán las colocadas más arriba.
   • Doing: una vez empezado el sprint, la persona encargada de cada tarea, cuando empiece una nueva, la moverá de la columna To do a esta otra.
   • Done: una vez que una tarea se haya finalizado se moverá de la columna Doing a ésta.
3. Si la tarea tuviera que validarse por una persona diferente a la que la ejecutó, añadiríamos una quinta columna «Validated».
4. Una vez cerrado el sprint, se archivarían todas las tareas acabadas y comenzaríamos a colocar en To do las tareas del nuevo sprint.

¿Fácil verdad?

Ahora sólo faltaría añadir la capa de análisis, ver qué ha pasado si no se ha terminado alguna, si el problema ha sido de análisis de capacidad del equipo, de redacción de la tarea, de estimación de la tarea…

Y una forma de encarar el asunto es en las ceremonias.

Ceremonias del Agile Marketing

En la parte de teoría hemos hablado de cuatro ceremonias:

• Daily.
• Sprint plan.
• Refinamiento.
• Retrospectiva.

Cada una se lleva a cabo con unos objetivos muy claros, pero creo que están muy enfocadas en el desarrollo de producto digital y en marketing no son imprescindibles todas.

En realidad dependerá también del tamaño del equipo, porque, cuanto más grande sea, más necesario será poner orden y escuchar.

Aclarado esto, te doy mi opinión de cada una:

La daily es imprescindible. Y lo es porque ayuda mucho al buen funcionamiento del equipo y desbloquea cosas, además de que todos tenemos claro en qué punto estamos.

El sprint plan es útil, aunque no imprescindible si el equipo es pequeño (hasta 3-4 personas).

Y el refinamiento, es incluso más prescindible, ya que, si el equipo lleva tiempo junto no es necesario una sesión para aclarar cosas que se resuelven en un mensaje de Slack o en una llamada de 30 segundos entre las dos partes.

Las retrospectivas son útiles sobre todo si ha habido algún problema importante en el sprint. Escuchar la opinión de cada miembro nos ayudará a tomar buenas decisiones de mejora.

Eso sí, no creo que sea imprescindibles hacerlas tras cada sprint (sobre todo si son sprints semanales), pero sí periódicamente y también, como digo, siempre que haya habido algún inconveniente de cierta consideración.

Para concluir, digamos que considero que las ceremonias tienen que ser un medio para alcanzar un fin, no un fin en sí mismo, como algunas veces me he encontrado.

Tamaño del equipo

Aunque he utilizado el sistema explicado hasta ahora en equipos de 10 personas, creo que para este tamaño habría que hacer algunos ajustes.

Sin embargo, creo que es perfecto para equipos más modestos de entre 3 y 6 personas.

Si tu equipo es más pequeño, ni siquiera creo que Trello sea necesario. Quizá con Excel y slack (o Telegram) sea más que suficiente.

Ventajas del Agile Marketing

La principal para mí es poder tener una vista de todas las tareas a acometer en el cada sprint, de forma que podamos tener claro a cuáles llegamos y cuáles hay que posponer. Es muy fácil de priorizar y asignar tareas a personas.

Esto a la hora de organización es gloria, sobre todo porque el equipo sabe lo que tiene que hacer y puede focalizarse en ello.

La siguiente ventaja es que, una vez implementado el sistema, seremos capaces de medir y analizar cada tipo de tarea. Si comparas el esfuerzo con el aporte a negocio, lo mismo te sorprendes dejando de ejecutar tareas que llevas años haciendo («publicaciones en Facebook»).

O de descubrir a qué persona del equipo es mejor asignarle cada tarea.

Otra ventaja es que, en el caso de que uses Trello más que en el de Excel, todo queda documentado, teniendo a nuestro alcance un auténtico repositorio.

Por último, en el caso de que sea necesario, como he comentado antes, tener un tablero o un backlog bien relleno pone en valor el trabajo realizado por el equipo.

Por último, el coste de todo esto es pequeño:

• En dinero, porque las herramientas son gratuitas o de bajo coste.
• En tiempo, ya que, aunque hay un ligero aumento de la carga de trabajo, espero haberte dejado claro que compensa sobradamente.

Conclusiones

Pese a que el artículo es de cierta longitud, apenas he raspado la superficie de la metodología Agile.

Es una introducción para que consideres si esto puede ser para ti o tu sistema actual te cuadra más.

De todas formas, más allá de sistemas, me gustaría que te quedaras con los que son para mí sus tres valores principales:

• Hablar y acordar entre las partes.
• Flexibilidad.
• Medición.

Dando por hecho que tenemos claro que, de lo que se trata esto es que sacar el trabajo / proyecto adelante.

Dicho esto, espero haberte podido explicar el valor que tiene aplicar la metodología Agile en equipos de Marketing, ya que bien ejecutada, realmente aporta mucho valor. Te lo digo por experiencia propia.

Así que, hazme el favor y dale una oportunidad.

De todas formas, aunque no soy Scrum Master ni muchísimo menos, si crees que necesitas ayuda con la organización de tu equipo en proyectos digitales, no tienes más que escribirme.