Somos Product Managers y nos ha costado entender por qué lo somos. Pero, ya lo sabemos o eso creemos.
Hemos leído, mucho, y equivocado mucho también, pero lo que sobre todo hemos hecho es aprender y mejorar.
Si hay algo que casi todas las empresas repiten hoy en día como un mantra, es que son agile y que en la mayoría de ellas se utiliza Scrum.
De hecho, se repite tanto que son términos que a menudo pierden su significado y que van de camino de suceder al archifamoso nivel alto de inglés.
Como Product Managers hemos aprendido que debemos ser ágiles y que, si podemos, debemos utilizar Scrum o Kanban o ya para rizar el rizo, ¡SCRUMBAN! Sí, vale pero ¿por qué?
Lo que tienes que saber de Agile
Agile es una serie de principios que fomentan una forma de pensar y un conjunto de habilidades de negocio necesarias para tener éxito en un entorno incierto y turbulento.
Teniendo en cuenta lo imprevisible que es el mundo digital y que, como Product Managers, queremos tener éxito ofreciendo valor a nuestros usuarios, parece que nos viene como anillo al dedo.
Aunque parezca que hemos resuelto algo, se trata solo de la punta del iceberg. Ahora que estoy convencido de que quiero ser agile, vamos a investigar cómo podemos llegar a serlo.
Las responsabilidades de un Product Manager pueden llegar a variar dependiendo de la compañía y la industria en la que nos encontremos, pero en entornos digitales suelen situarse entre los pilares de estrategia, diseño, comunicación y ejecución.
Y es en este último, donde se pone un mayor énfasis hoy en día en la práctica de metodologías ágiles.
Tanto Scrum como Kanban son metodologías que agrupan un conjunto de procesos y buenas prácticas. Éstas nos van a facilitar ofrecer valor a nuestros usuarios de una manera ágil.
Por lo tanto, se tratan de un COULD, herramientas que podemos o no utilizar, nunca de un MUST. Y dependiendo del entorno donde nos encontremos vamos a tener la opción de adaptarlas más o menos. Veamos cuáles son los rasgos principales de cada una de ellas.
Lo que tienes que saber de Scrum
Scrum ejecuta y divide proyectos en pequeños entregables que un equipo multidisciplinar puede empezar y completar en iteraciones de una duración determinada.
Cada vez que un incremento del producto es completado, el equipo revisa la funcionalidad y decide qué hacer para crear el siguiente basándose en lo que han aprendido y en el feedback recibido durante la review.
A través de las inspecciones, los ciclos de desarrollo deben ajustarse con el objetivo de reducir desperdicios y minimizar riesgos, ajustándose asimismo la forma de utilizar Scrum con el fin de promover una mejora continua que garantice la satisfacción de las necesidades de los clientes.
Un incremento se desarrolla en un espacio de tiempo determinado llamado Sprint y que es representado a través del Sprint Goal. Para llegar a este objetivo, ( ojo!! 👀 Spoiler alert de la nueva guía de Scrum 2020 🙉) se selecciona un conjunto de tareas denominadas Sprint Backlog pertenecientes al conjunto del Product Backlog.
Y es por eso por lo que hablamos de incremento, porque es el Product Backlog el que marca el camino para la consecución del objetivo del producto a largo plazo, el Product Goal.
El desarrollo de un Sprint se apoya en las siguientes ceremonias:.
- Daily: repaso del progreso respecto al Sprint Goal y sus blockers.
- Planning: estimación de tareas ready que entran en Sprint y definición de Sprint Goal.
- Refinement: ajuste de las tareas para que cumplan con el Definition of Ready.
- Review: presentación a los stakeholders sobre lo conseguido en el Sprint.
- Retrospective: feedback de mejora.
En el caso de que trabajemos en un ambiente donde las prioridades no cambien de la noche a la mañana, este enfoque puede ser bastante beneficioso, ya que permite una planificación y que el equipo de trabajo encuentre una cadencia óptima.
Aquí, los equipos o squads suelen estar formados por pequeños grupos de profesionales autogestionados, centrados en conseguir el Product Goal y cuyas responsabilidades son:
- Product Owner: Gestión y comunicación del Product Backlog y el Product Goal.
- Scrum Master: Asegurar buenas prácticas de Scrum y el desarrollo de las tareas.
- Developers: Desarrollo de las tareas del Sprint.
Normalmente el Product Manager desarrolla la función del Product Owner y en ocasiones la del Scrum Master. Para profundizar más sobre este tema podéis echar un ojo a "Scrum Master y Product Owner: ¿cómo gestionar esta relación, a veces tan complicada?"
En definitiva, si el contexto lo permite, se puede establecer un proceso muy maduro que aporta resultados de gran calidad. Aplicando Scrum se suele huir de la inflación en forma de tareas no planificadas en un Sprint ya empezado, siempre que no sean críticas, claro.
Al igual que esto, no tienen que llevarse a cabo todas las ceremonias y éstas a su vez deben de ir evolucionando según el squad va madurando.
Cuanta más flexibilidad es requerida a todos los niveles de la ejecución, desde la planificación al feedback, es cuando más nos acercamos a Kanban.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Lo que tienes que saber de Kanban
Kanban es un sistema Just In Time, desarrollado en función de la demanda, que permite a las organizaciones fomentar cambios de manera muy dinámica y limitando la cantidad de Work In Progress (WIP).
El sistema se adapta al proceso existente, si lo hay, y fomenta el cambio a través del feedback generado en las sesiones de inspección que se vayan desarrollando. Las iteraciones del producto se ajustan a la demanda con el objetivo de mejorar la productividad.
El equipo de Kanban se centra en lo que está actualmente en desarrollo y una vez que terminan solo tienen que empezar con la siguiente tarea situada al comienzo del backlog.
De esta manera el Product Owner (por hacer referencia a un rol aunque en esta metodología no es necesario) es libre de priorizar el backlog en cualquier momento porque ningún cambio afecta al WIP.
Siempre y cuando mantenga los tickets más importantes al comienzo del backlog se asegura entregar el máximo valor al negocio. Sin embargo, si existen cambios de contexto muy frecuentes puede llegar a repercutir negativamente en la estrategia del producto a medio y largo plazo.
Cuándo elegir entre Agile, Scrum y Kanban (si nos dejan)
En un mundo ideal, el Product Manager tendrá total libertad para elegir la mejor forma de ejecutar su producto aunque esto no siempre sea así.
En caso de que si lo sea y teniendo en cuenta que ser agile consiste en entregar valor a tus usuarios de manera constante y flexible, podemos imaginarnos el siguiente supuesto.
Nos dedicamos al transporte de mercancías y nuestros clientes buscan trasladar bultos dentro de una misma ciudad. En este caso, Scrum y Kanban serían los vehículos que podríamos utilizar con nuestro equipo para mover las pertenencias de nuestros clientes.
Si nos piden planificar una mudanza con maletas de cierto tamaño, un vehículo amplio que nos permita transportar la carga y cierta ayuda puede ser lo ideal (Scrum).
Si por el contrario, nos solicitan transportar bultos pequeños bajo demanda, un vehículo más rápido que nos permita hacer más viajes puede ser lo ideal (Kanban).
Y finalmente, a medida que vayamos realizando viajes podremos aplicar lo aprendido hasta el momento, customizando nuestros vehículos para adaptarnos mejor a las necesidades de nuestros clientes, a la propia ciudad y al tipo de bulto que transportemos.
Foto de Kelly Sikkema en Unsplash
