Tanto si ya estás comprometido con uno de los dos marcos ágiles más populares, como si estás buscando el que mejor se adapte a tus necesidades, explora las diferencias clave entre Scrum y Kanban y haz el test para descubrir cuál es el más adecuado para ti.
En mi vida como Product Manager (PM), he enfrentado diferentes situaciones y utilizado tanto Scrum como Kanban. A veces, el equipo estaba en marcha y completamente cómodo con sus procesos y rituales. Otras veces, ante retrasos o contratiempos, se cuestionaban su organización. Entonces, ¿cómo decidir si una metodología es adecuada para su equipo? ¿Existe un momento adecuado para pasar de Scrum a Kanban (o viceversa)?
🎡 Scrum, el consenso para todo tipo de empresas
He encontrado Scrum en la mayoría de los contextos que he experimentado, ya sea dentro de grandes corporaciones, startups o scale-ups. Trabajar en un entorno Scrum implica días llenos de reuniones recurrentes: daily meetings, sprint plannings, retrospectivas, u otros refinamientos. Por lo tanto, no puedo trabajar de manera just-in-time y siempre necesito estar adelantado en mis User Stories (US) para informar a mi equipo durante el próximo sprint.
Entonces, tengo una visión muy clara del trabajo que tenemos por delante y puedo estimar de manera bastante precisa las fechas de lanzamiento de mis nuevas funcionalidades. La estructura ofrecida por Scrum me permite aclarar los objetivos de mi sprint con mi equipo. Por otro lado, esto significa que debo estar suficientemente preparado para anticipar las necesidades de mi equipo. Si surge una user story urgente, generalmente solo se puede abordar en el próximo sprint, a menos que afecte al actual. Sin embargo, es preferible evitar esto tanto como sea posible para respetar los objetivos establecidos al principio del sprint.
🌈 Kanban, ¿hacia una mayor libertad?
Recientemente experimenté con Kanban durante un proyecto para una startup. En comparación con Scrum, mi vida diaria es mucho más liviana y flexible. El número de reuniones disminuye: ya no hay daily meetings, sprint planning, o retrospectivas, etc. Con Kanban, ya no tengo ceremonias obligatorias que "impongan" un ritmo al equipo. De hecho, no tengo que preparar todas las US de la siguiente quincena para una fecha concreta: también puedo optar por alimentar el backlog continuamente, si me falta tiempo para anticiparlo todo, por ejemplo. Incluso, tengo la opción de agregar una US urgente como la próxima tarea para los desarrolladores, lo cual resulta bastante útil en caso de cambios de prioridad repentinos, estoy seguro de que estarás de acuerdo conmigo...
¿La desventaja? Como PM, no tengo tanta visibilidad sobre el progreso del equipo. Es difícil para mí determinar una posible fecha de lanzamiento. Mi visibilidad depende principalmente del progreso de los tickets en el tablero Kanban, de ahí lo importante que es para mí trabajar con un equipo de desarrolladores que sean lo suficientemente conscientes y rigurosos como para mover sus tickets de columna en tiempo real. También tengo que asumir la responsabilidad de identificar (aunque mi Tech lead pueda ayudarme) los tickets que que llevan varios días sin salir de la columna "en progreso", para hablarlos con el desarrollador a cargo.
Así que, como puedes ver, ambos frameworks tienen sus ventajas y desventajas para un PM.
✅ ¡Haz el test!
¿Te preguntas si estás operando dentro del marco de producto más adecuado para tu contexto? Para ayudarte, te propongo un cuestionario rápido para obtener la respuesta a esta pregunta en solo 3 minutos. Recuerda, ¡aquí no hay una verdad absoluta!
Parte 1: El Contexto
Q1: ¿Cuánta visibilidad necesita de mí la dirección?
💧 Necesito proporcionar mucha visibilidad a la dirección, que regularmente pregunta sobre el progreso de los desarrollos.
⭐️ Necesito dar visibilidad a la dirección de forma ocasional.
🔥 No necesito especialmente dar visibilidad a la dirección.
Q2: ¿En qué etapa de desarrollo/crecimiento está mi producto?
💧 El desarrollo del producto se está acelerando (post-MVP).
⭐️ El crecimiento del producto se está desacelerando: hemos entrado en una fase más tranquila después de un fuerte desarrollo.
🔥 El producto se está construyendo (pre-MVP).
Q3: Las prioridades de los productos, ¿son cambiantes?
💧 No, una vez que se establece el plan, no se cambia bajo ninguna circunstancia.
⭐️ Sí, las prioridades cambian pero se pueden anticipar.
🔥 Sí, las prioridades cambian incesantemente.
Q4: ¿Cuál es el nivel de madurez del Producto/Ágil en mi organización?
💧 Mi empresa no es ágil en absoluto.
⭐️ Mi empresa está en transición hacia la agilidad: parte de una metodología de ciclo en V o de un área inicialmente alejada de la tecnología (ningún producto digital al principio, por ejemplo).
🔥 Mi empresa es ágil, domina la mentalidad ágil y sabe aplicarla sin ser necesariamente "de libro".
Parte 2: Necesidades del equipo
Q5: ¿Cuál es la necesidad de supervisión hay dentro del equipo (nivel de proceso)?
💧 Los procesos son vitales. Están en todas partes en mi organización y eso me parece bien.
⭐️ Tenemos una base de procesos, a veces agregamos algunos, a veces quitamos algunos.
🔥 ¡Es "freestyle"!
Q6: ¿Hasta qué punto estamos seguros de lo que hay que construir?
💧 Muy claro.
⭐️ En general, claro.
🔥 Aún no está claro.
Parte 3: Dinámica del equipo
Q7: ¿Cómo reacciona el equipo ante obstáculos y problemas imprevistos?
💧 El equipo intenta resolver los problemas de manera estructurada utilizando métodos predefinidos.
⭐️ El equipo evita los obstáculos en la medida de lo posible siguiendo rigurosamente los procesos establecidos.
🔥 El equipo está acostumbrado a resolver problemas rápidamente sin necesidad de formalizar procedimientos.
Q8: ¿Cuál es el nivel de autonomía y responsabilidad de los miembros del equipo?
💧 Se anima a los miembros del equipo a tomar decisiones y gestionar su propio trabajo de manera autónoma.
⭐️ Los miembros del equipo tienen roles y responsabilidades definidos, pero siguen necesitando validación para ciertas acciones.
🔥 Los miembros del equipo tienen una libertad de acción considerable y pocas limitaciones en cuanto a responsabilidades definidas.
🔍 Las Respuestas
Cuenta tus emojis y compáralos con la siguiente tabla:
¿Mayoría de 💧?
Operas en un entorno que requiere alta visibilidad para la dirección, un marco estructurado y procesos bien establecidos (posiblemente incluso una etapa de crecimiento post-MVP para tu producto). En este contexto, Scrum ofrece el marco estructurado y los procesos necesarios para satisfacer estas necesidades.
¿Mayoría de 🔥?
Tu entorno de trabajo favorece la flexibilidad y la capacidad de respuesta a los cambios constantes, con necesidades menos pronunciadas de visibilidad estricta y estructuras rígidas impuestas por procesos formales. Kanban, con su enfoque más fluido y adaptable, puede ser la herramienta perfecta para gestionar tus proyectos bajo estas condiciones.
¿Mayoría de ⭐️?
Tu situación probablemente se encuentre en algún lugar entre Scrum y Kanban, beneficiándote de una estructura moderada mientras requieres cierta flexibilidad. Puedes alternar entre los dos según tu contexto. Por lo tanto, es importante considerar los aspectos únicos de tu equipo, tu producto y tu entorno de trabajo para determinar qué marco o combinación de marcos podría funcionar mejor para ti. Si no te convencen Scrum o Kanban, ¡que no cunda el pánico! A continuación te sugerimos otros marcos de trabajo.
En conclusión, estoy convencido de que no existe una metodología perfecta, sino más bien metodologías beneficiosas para un equipo en un contexto dado, durante cierto tiempo. A medida que evoluciona el contexto del equipo, un cambio en la metodología puede ser relevante para adaptarse a nuevas realidades.
4 Puntos Clave para concluir:
- La metodología elegida debe adaptarse a mi equipo y a mis necesidades.
- Debo permanecer abierto a los cambios si el enfoque actual ya no parece funcionar eficazmente, y tener en cuenta que la elección de la metodología no es inamovible.
- Explorar diferentes metodologías puede ayudarme a encontrar la que mejor se adapte a mis necesidades (sin ser un veleta).
- Y si ni Scrum ni Kanban parecen ideales, también hay otras alternativas como Scrumban, Shape Up, ...
Gracias a Julie Crépet y Naban Tuo por sus valiosos consejos durante la redacción de este artículo.
Para obtener más información: descarga Product Management Toolkit
