Prácticas ágiles: cómo evitar errores cometidos por nuestro equipo de marketing

El secreto ha salido. La gestión ágil de proyectos cambia las reglas del juego, y los desarrolladores y la gente de TI ya no son los únicos que lo saben.

Como especialista en marketing, seguramente ha oído hablar de Agile. Su equipo puede estar usando algunas prácticas ágiles, como sprints de proyectos y reuniones de pie. Si es así, eres una minoría. Los equipos de marketing aún no han aprovechado los beneficios de Agile. Según un nuevo informe de Workfront y MarketingProfs, solo el 30% de los equipos de marketing utilizan un enfoque ágil para gestionar sus procesos. El otro 70% probablemente experimente las mismas frustraciones que experimentó mi equipo antes de comprometernos a hacer que Agile funcione.

Nuestro equipo de marketing de siete personas en Emplify ha estado practicando Agile durante casi un año. Nos tomó seis meses llegar a un punto de practicarlo bien: producir un trabajo mejor, más rápido y con más energía y compromiso.

Cuando comenzamos a practicar Agile, cometimos muchos errores. Tantos errores, de hecho, que un día encerramos a la mitad de nuestro equipo en una sala de conferencias y no nos fuimos hasta que identificamos y abordamos algunas deficiencias importantes en nuestro enfoque. Afortunadamente, había cerveza y era viernes. Aun así, fue doloroso y nos llevó tiempo salir de algunos agujeros profundos orientados al proceso.

En este artículo, comparto esos errores para que pueda evitar un encierro doloroso como el nuestro. Agile puede revolucionar la capacidad de su equipo de marketing para colaborar y entregar el trabajo más rápido, si se compromete a hacer que el proceso funcione para usted.

Antes de comenzar, cubramos algunos conceptos básicos:

¿Qué son las prácticas ágiles?

Las prácticas ágiles (a menudo denominadas “ágiles”) enfatizan la entrega continua de porciones más pequeñas de trabajo sobre proyectos con tareas interconectadas más grandes que pueden abarcar semanas o meses (lo que tradicionalmente se denomina administración en cascada).

Los conceptos básicos ágiles incluyen:

• Equipo Scrum: este equipo altamente colaborativo, organizado bajo un scrum master, resuelve problemas complejos y ofrece soluciones en iteraciones de duración fija llamadas sprints, que pueden durar desde una semana hasta 30 días. Un equipo de scrum que trabaja en contenido, por ejemplo, podría comenzar un sprint de dos semanas comprometiéndose a crear una nueva infografía o hoja de datos.
• Producto mínimo viable (MVP): al planificar un entregable, los principios ágiles enfatizan que el proyecto se desarrolle lo más rápido posible para que su equipo pueda responder temprano a problemas reales. Para lograr un modelo de entrega continua, los scrum masters alientan a los equipos a definir el MVP y descubrir las formas más creativas de terminar el producto dentro de los límites del sprint. Por ejemplo, si comienza un sprint de dos semanas para crear un libro electrónico como su MVP y su diseñador se enferma, puede decidir redefinir el MVP de ese sprint como una serie de publicaciones de blog y diseñar el libro electrónico en el próximo pique.
• Reunión diaria de pie: los miembros del equipo se paran en círculo durante 15 minutos aproximadamente todas las mañanas para discutir las tareas realizadas por el equipo de scrum, las áreas de enfoque y los bloqueadores que pueden impedirles terminar su trabajo de sprint asignado. Al final del sprint, los equipos ágiles entregan un conjunto definido de proyectos, que luego se evalúan y mejoran en el siguiente sprint. Algunos equipos de scrum también incorporan reuniones retrospectivas, donde discuten las deficiencias del proceso que se pueden abordar en el próximo sprint.

¿Por qué los especialistas en marketing deberían usar Agile?

National Public Radio utiliza metodologías ágiles para crear y probar nueva programación. Piense en eso durante su próximo "momento de entrada". Aunque las raíces de Agile están en la gestión de TI, esta forma de entrega de proyectos se puede aplicar a muchas funciones de una empresa, incluido el marketing.

La adopción de un modelo ágil de iteración continua le permite a su equipo de marketing probar rápidamente nuevos mensajes o campañas, reaccionar más rápido a las actualizaciones de productos y establecer expectativas con las partes interesadas que solicitan trabajo a su equipo.

El momento brillante de mi equipo llegó casi nueve meses después de que comenzamos nuestro viaje ágil, cuando actualizamos el contenido de nuestro sitio web para hacer algunos cambios en la mensajería de nuestros productos. Definimos lo que podríamos lograr en una semana y entregamos ese trabajo a tiempo. El contenido que no tuvimos tiempo de actualizar en ese sprint, lo ocultamos de la navegación. Hemos estado agregando y actualizando continuamente los mensajes en esas páginas durante nuestros sprints posteriores.

¿Qué errores se deben evitar?

Si está considerando adoptar Agile en su equipo, incluso si está buscando simplemente optimizar los procesos dentro de su equipo de marketing, querrá evitar estos cuatro errores de marketing ágil que cometió nuestro equipo:

1. Nos llamábamos ágiles sin hacer los deberes.
2. No pudimos designar a los propietarios del problema.
3. Nos enfocamos en los entregables más que en los problemas.
4. Nos abarrotamos en lugar de priorizar (y fingimos que podíamos hacerlo todo).

Error 1: nos llamábamos ágiles sin hacer nuestra tarea

Cuando comencé con mi equipo de marketing, rápidamente instituí reuniones diarias para proporcionar una forma rápida e indolora de verificar los proyectos. Pensé que había realizado stand-ups y organizado sprints en roles anteriores, así que tenía experiencia con Agile, ¿verdad? Incorrecto.

No venga al trabajo un lunes y anuncie que se está “volviendo ágil” como lo hice yo. El hecho de que esté trabajando en sprints de dos semanas y tenga reuniones diarias no significa que sea un equipo ágil. La belleza de Agile es que le da a su equipo el poder de comprometerse con proyectos juntos y definir un entregable de calidad dentro de un período de tiempo designado. Si solo está tratando de acumular tanto trabajo en dos semanas como sea posible y sacrificando la calidad para cruzar la línea de meta, esa belleza se niega.

Antes de instituir procesos ágiles en su equipo de marketing, haga su tarea. Abre uno o dos libros. Recomiendo comenzar con Scrum de Jeff Sutherland (conocido por muchos como uno de los padres de Agile) y Hacking Marketing de Scott Brinker. Además, lea algunos de los excelentes artículos de CMI sobre marketing ágil.

Una vez que haya hecho su tarea, priorice algunos cambios simples en su proceso existente para comenzar a diseñar un enfoque ágil que funcione para su equipo.

Error 2: no pudimos designar a los propietarios del problema

Si el siguiente escenario no ha ocurrido, puede omitir esta sección; ha alcanzado alguna forma de nirvana en el proceso de marketing que todavía tengo que descubrir.

El resto de ustedes, imaginen esto: están al 98% de un proyecto de equipo importante con una fecha límite clara, y una parte interesada sorpresa interviene en la última hora con docenas de revisiones. Luego, su equipo se ve obligado a prolongar el proyecto dos semanas más para abordar esos cambios porque nadie puede argumentar que esta parte interesada está equivocada.

¿Seguir leyendo? Ya me lo imaginaba.

La falta de propiedad definida de nuestro equipo fue el mayor obstáculo para nuestro progreso como departamento de marketing ágil. Estábamos abrumados por el trabajo. Nos sentimos frustrados cuando varias partes interesadas intervinieron en la calidad del proyecto. Y no estábamos obteniendo nada debido a las ediciones y correcciones de última hora.

Si su equipo de marketing es como el nuestro, tendrá dificultades para saber quién es el propietario final de un proyecto. ¿Quién es la persona directamente responsable del éxito de un entregable? ¿Quién establece resultados medibles para una tarea con la que el equipo puede alinearse? ¿Quién necesita que este proyecto tenga éxito para que, en última instancia, también pueda tener éxito?

Para evitar retrabajos de última hora, ahora asignamos a esa persona, un propietario del problema, a cada proyecto.

Cada trimestre, establecemos un objetivo de clientes potenciales calificados de ventas para cada uno de nuestros principales canales de marketing: publicidad, eventos, clientes potenciales orgánicos del sitio web, etc. Luego, a cada uno de esos canales se le asigna un propietario en nuestro equipo, y ese propietario se convierte en la persona a la que se debe acudir para cualquier entregable que pertenezca a ese canal.

La propiedad del problema ha sido particularmente exitosa para nuestro equipo por varias razones:

• Coloca la responsabilidad del éxito en una persona , que es responsable si no se cumplen las metas.
• Obliga al propietario del canal a descubrir los problemas con anticipación para que el equipo pueda abordarlos de manera proactiva.
• Permite que todo el equipo participe en la lluvia de ideas sobre una solución y la implementación de una solución.
• Le da poder a una persona para guiar la calidad de cualquier proyecto.

Si su equipo no tiene claro quién tiene la última palabra en sus proyectos de contenido, siéntese con su departamento y haga una pregunta sorprendentemente simple pero desafiante: "¿Quién es el dueño de qué?" Responder esa pregunta, y registrar sus respuestas para que todos las vean, generará una responsabilidad inconmensurable.

Error 3: nos centramos en los entregables en lugar de en los problemas

Otro momento que cambió las reglas del juego para nuestro equipo Agile fue cuando dejamos de ver nuestro trabajo como un conjunto de entregables para poner en marcha y comenzamos a pensar en nuestro trabajo como un conjunto de problemas a resolver.

Piense en los contribuyentes individuales de su equipo: desarrolladores, redactores publicitarios, diseñadores y otros roles de implementación similares. ¿Con qué frecuencia se les pide que "diseñen esta diapositiva" o "escriban este libro electrónico" con poco contexto de por qué lo están haciendo?

Simplemente asignar una tarea en una lista de tareas pendientes sin ayudar a su equipo a comprender el propósito real detrás del proyecto conduce a un trabajo mediocre sin la inversión personal de su equipo.

De hecho, tener una falta de trabajo orientado a un propósito puede tener graves implicaciones en más que solo sus tácticas de marketing. En una encuesta a miembros de LinkedIn, más del 60% de los encuestados que no tenían trabajos orientados a un propósito planearon dejar su empresa en tres años o menos.

En nuestro equipo, tenemos una regla estricta en contra de comenzar cualquier proyecto con un entregable prescrito en mente. Seamos realistas, las partes interesadas no siempre saben lo que quieren. La resolución de problemas ayuda a fomentar la colaboración para obtener mejores resultados.

En su lugar, comenzamos cada proyecto con una declaración de problema, que sigue un formato llamado habitualmente historias de usuario en el mundo del desarrollo ágil. Ese formato se parece a esto:

Cuando ocurre __________, quiero ________, para que obtengamos este resultado medible: ___________.

Aquí hay un ejemplo de este tipo de declaración de problema (o historia de usuario) de un proyecto hipotético:

El propietario del problema de cada proyecto determina qué problemas abordará el equipo para ese proyecto. Por ejemplo, el propietario podría considerar que es un problema si el sitio web no está clasificado para una determinada palabra clave o si los mensajes deben actualizarse para una próxima feria comercial. No importa el problema, el enunciado del problema nunca incluye una solución. Una vez que decidimos priorizar un problema en particular, nuestro equipo analiza el problema en conjunto y, en última instancia, busca una solución que podamos ejecutar en nuestro próximo sprint.

Resolver un problema en equipo permite que todos participen en el resultado.

Además, este enfoque obliga al equipo a descubrir puntos débiles detrás del problema a nivel de superficie para llegar a una solución que aborde las necesidades básicas en lugar de las solicitudes de vanidad.

Por ejemplo, nuestro equipo de ventas informó que algunos prospectos no asistían a las reuniones de demostración programadas y no respondían a las solicitudes de reprogramación. Nuestro vicepresidente de ventas quería que el equipo de marketing creara un video explicativo animado que pudiera ayudar a los posibles clientes a asistir a su reunión, aunque hacerlo hubiera llevado meses.

Después de hacer algunas preguntas sobre el proceso de ventas, nos dimos cuenta de que los problemas centrales del equipo de ventas podrían resolverse con mensajes de correo electrónico mejorados antes de la reunión de demostración. Establecimos una campaña de goteo de tres correos electrónicos que se activa tan pronto como se programa una reunión. Esta solución le tomó al equipo solo dos días para construir. Desde la creación de esta campaña, hemos reducido la cantidad de personas que necesitan reprogramar reuniones a más de la mitad.

Antes de asignar una tarea a un miembro del equipo, pregúntense por qué es importante ese trabajo. Al crear una declaración de problema y colaborar en una solución, pudimos identificar una solución rápida que ha pagado dividendos para nuestro equipo. Si hubiéramos creado un video animado, el equipo de ventas podría haber estado lidiando con el mismo problema durante meses mientras esperaba nuestra solución.

Error 4: abarrotamos en lugar de priorizar (y fingimos que podíamos hacerlo todo)

Si intenta encajar todo lo posible en cada sprint de marketing ágil, como hicimos nosotros, lo está haciendo mal.

Sin un sentido compartido de prioridad, no tiene idea de dónde concentrar su tiempo. Y sin foco, recurres a decir que sí a todo. Y cuando dice que sí a todo y no tiene propietarios de problemas para sus proyectos, se encuentra en medio de un trimestre estresante con muchos entregables a medio terminar.

Muchos equipos ágiles utilizan la estimación para priorizar el trabajo y aumentar la velocidad como equipo. Ellos aproximan la cantidad de esfuerzo que requerirá un proyecto o discuten cuántas horas pueden tomar las personas para completar sus tareas. Con el tiempo, muchos equipos ágiles llegan a una sensación de rendimiento promedio por sprint, lo que les ayuda a planificar nuevas tareas.

En nuestros primeros meses como equipo Agile, nos propusimos hacer este tipo de estimación. Desafortunadamente, terminamos manipulando nuestras estimaciones para que pareciera que podíamos hacer todo. Adivinamos cuánto trabajo tomaría un proyecto, y luego regateamos los requisitos para dar cabida a otras tres solicitudes. Al final, negamos el valor de estimar el trabajo, perpetuando un ambiente de estrés implacable.

Probamos dos o tres métodos de seguimiento de la velocidad (incluida la planificación del póquer, una forma común de estimar el trabajo). Nos enfocamos en utilizar la estimación como una forma de demostrar que podíamos hacer mucho trabajo, no como una forma de convertirnos en un equipo más eficiente. Ese fue nuestro error.

Recientemente, conversé con el director de ingeniería de nuestra empresa, quien administra el proceso Agile para nuestro equipo de productos. Cuando mencioné que nuestro equipo nunca había dominado la estimación, dijo esto:

Si sus partes interesadas solicitan constantemente informes de velocidad o estimaciones mejoradas de su equipo, es probable que esté experimentando problemas de proceso más importantes que están afectando la capacidad de su equipo para entregarles el trabajo a tiempo.

Cuando su equipo Agile, que funciona bien, realiza iteraciones rápidas de un proyecto con regularidad y comunica las inquietudes a las partes interesadas cuando una fecha límite no es razonable, naturalmente evita las preguntas sobre los resultados o la productividad de su equipo. El gerente de proyecto o scrum master tiene la responsabilidad de corregir el rumbo y comunicar esos cambios cuando el trabajo se está quedando atrás.

No tema priorizar solo uno o dos nuevos proyectos (o problemas o historias) en su próximo sprint porque tiene algunos proyectos sobrantes en su sprint actual. Solo asegúrese de comunicar el trabajo sobrante de manera oportuna a las partes interesadas y comparta sus planes para terminar el proyecto lo más rápido posible.

Y no tema designar a un líder para que haga la última llamada sobre lo que debe priorizarse. Nuestro equipo, por ejemplo, prohibió a todas las personas mover tarjetas de Trello a la columna de "prioridad", excepto a nuestro vicepresidente de marketing. Eso colocó la responsabilidad de priorizar a la persona con la mejor visión de todo el negocio.

Conclusión

Nuestro equipo, como todos los equipos de Agile, está adaptando los principios de Agile de manera que nos funcione. Cualquiera que sea el enfoque ágil que pueda adoptar su equipo, solo funcionará si brinda oportunidades de comentarios abiertos sobre el proceso y si es lo suficientemente flexible como para cambiar su flujo de trabajo con regularidad. Si tuviera un registro de cada ajuste que hemos hecho a nuestro enfoque ágil hasta ahora, sería más largo que esta publicación.

¿Qué errores han cometido sus equipos al implementar procesos ágiles? ¿Cómo ha abordado esos errores? Háznoslo saber en un comentario.

¿Quiere mejorar su estructura para la efectividad del marketing de contenidos? Suscríbase a nuestro boletín semanal Content Strategy for Marketers, que incluye información exclusiva de Robert Rose, asesor principal de contenido. Si usted es como muchos otros especialistas en marketing que conocemos, esperará con ansias sus pensamientos todos los sábados.

Imagen de portada de Joseph Kalinowski / Content Marketing Institute