Six Sigma, Lean, PMBOK, Scrum vs. Kanban — hay una gran cantidad de debates de jerga y metodología de gestión de proyectos lanzados alrededor que puede encontrar confuso o poco claro. Sin embargo, hay algunas metodologías que vienen a la mente cuando usted está buscando para crear un plan de proyecto eficaz.
Las metodologías de gestión de proyectos están destinadas a proporcionar a los equipos un marco o una teoría para basar su planificación de proyectos. Todos ellos tienen sus ventajas y desventajas, pero un par de metodologías proporcionan una manera ventajosa de visualizar su plan de proyecto.
Tanto Scrum como Kanban están bajo el paraguas de la metodología Agile, lo que los convierte en buenos marcos para dividir proyectos más grandes y complejos en fragmentos manejables. Echemos un vistazo a las diferencias entre los dos y lleguemos al fondo del debate Scrum vs kamban.
¿Qué es Scrum?
Scrum es un marco de proyecto para implementar la metodología de gestión de proyectos Agile. Es un método popular para administrar proyectos que requieren un rápido desarrollo, pruebas y lanzamiento de productos.
El marco de trabajo de Scrum divide un proyecto en iteraciones cortas de una a cuatro semanas, denominadas sprints. Un equipo de Scrum, generalmente dirigido por un maestro de Scrum, trabaja para entregar una iteración o versión del proyecto final al final de cada sprint. Los equipos de Scrum también tienen reuniones diarias de standup para discutir el progreso y aumentar la colaboración en equipo.
Para obtener más información sobre Scrum, echa un vistazo a nuestra guía en Scrum para novatos: Cómo usar Scrum para domar el caos.
¿Qué es un Board Scrum?
Un Scrum Board es una herramienta que le ayuda a administrar y supervisar su proyecto Scrum. Le ayuda a realizar un seguimiento visual de qué trabajo queda en el trabajo pendiente de su producto, qué elementos se asignan a su trabajo pendiente de sprint y cómo progresa el trabajo dentro de su sprint activo.
Mientras que un Scrum Board puede ser un tablero físico con notas o tarjetas adjuntas, tienden a ser tableros digitales en línea incluidos en muchas plataformas de gestión de proyectos.
Procurify, una startup de software de compra en Canadá, encontró que ahorraban el 70% de su tiempo al planificar sus sprints utilizando una herramienta de colaboración. Ahora tienen visibilidad del trabajo de los demás y pueden colaborar en diferentes equipos.
Estos son algunos pros y contras del uso de Scrum y Scrum Boards para gestionar sus proyectos:
Pros:
- Los errores pueden ser corregidos y los problemas potenciales evitados
- Los cambios se adaptan fácilmente debido a los sprints cortos con retroalimentación constante
- Puede cambiar el desarrollo en cualquier etapa a medida que el proceso aumenta en flexibilidad
- Los clientes tienen acceso a un proceso transparente, que les permite rastrear todo el procedimiento y medir la productividad individual
- La metodología Scrum es a menudo amigable con el presupuesto debido a su simplicidad
Contras:
- Es de naturaleza iterativa, por lo que requiere retroalimentación continua del equipo para mejorar el proceso
- Este proceso requiere mucha confianza dentro del equipo. Si la gobernanza es demasiado estricta, todo el proyecto puede fallar
- No es fácil para un miembro del equipo salir durante el proceso
- La fluencia del alcance puede ocurrir si no se proporciona una fecha límite
- No viene con ningún límite de tiempo previsto y valoraciones de costos, lo que puede resultar en varios sprints
- Hay una mayor presión sobre los miembros del equipo, y tienen que dedicar una gran cantidad de tiempo al desarrollo de proyectos
¿Qué es Kanban?
Kanban es otro framework Agile popular. Pero, a diferencia de Scrum, Kanban está menos basado en el tiempo y más centrado en la gestión del volumen de trabajo en proceso (WIP).
El marco Kanban fue diseñado para ayudar a mantener un flujo continuo de productividad mientras se asegura de que nadie en el equipo esté sobrecargado de trabajo o abrumado. Ayuda a los equipos de proyecto a reducir los cuellos de botella, mejorar la eficiencia, aumentar la calidad y aumentar la producción general.
Para obtener más información sobre Kanban, consulte La guía definitiva de la metodología Kanban.
¿Qué es un tablero kanban?
Tradicionalmente, Kanban implica una pizarra de planificación o pizarra, donde se enumeran todos los estados como “Planificado”, “En curso”, “En revisión”, etc..
Cada entrega se escribe en un Post-It y se coloca bajo el estado adecuado. A medida que la entrega se mueve a través de las etapas, el Post-It se mueve en la pizarra de estado del proyecto.
Estos son algunos pros y contras del uso de tableros Kanban y Kanban para gestionar sus proyectos:
Pros:
- Ayuda a empujar el trabajo que a menudo se “atasca” hasta su finalización
- Es ideal para separar el trabajo basado en el cesionario
- Es ideal para entregables altamente dependientes de su estatus
- Es fácil de configurar e implementar en cualquier lugar
- Las cargas de trabajo son visibles y fácilmente maleables
- Puede comprobar y evaluar rápidamente la productividad en todo su equipo
Contras:
- Dado que no hay limitaciones de tiempo, los entregables pueden
- Las tablas Kanban obsoletas pueden descarrilar la productividad
- Si está utilizando el sistema de organización de pizarra tradicional, es difícil asociar el trabajo real con la propia junta.
Kanban vs Scrum: ¿Cuáles son las diferencias?
Kanban y Scrum son marcos de proyectos creados para ayudar a los equipos a adoptar la metodología, los valoresy los principios de Agile. Como tal, tienen una serie de similitudes. Ambos marcos fomentan la mejora de los procesos, la colaboración en equipo y la descomposición de los proyectos en fragmentos más pequeños y manejables.
Sin embargo, Kanban y Scrum tienen enfoques significativamente diferentes en la forma en que eligen implementar estos principios. Aquí hay cinco áreas esenciales donde Kanban y Scrum varían:
Funciones y responsabilidades
Scrum tiene tres funciones específicas, cada una con sus propias responsabilidades predefinidas:
- Maestro Scrum: Actúa como facilitador y entrenador. Su trabajo es ayudar a eliminar los cuellos de botella y mantener al equipo avanzando en la dirección correcta.
- Propietario del producto: Crea la hoja de ruta del producto y se encarga de garantizar que las necesidades y deseos del cliente se traduzcan correctamente en características de productos de trabajo.
- Miembro del equipo: Los miembros del equipo de Scrum realizan la mayor parte del trabajo del proyecto. Son un equipo autogestionado que participa en la planificación, ejecución y revisión de los sprints de proyectos y sus resultados.
Kanban no prescribe roles como Scrum. De hecho, uno de los cuatro principios de Kanban establece que los equipos deben mantener sus funciones y responsabilidades actuales. La creencia detrás de este principio es que los equipos adoptarán el marco más fácilmente si no tienen que preocuparse por cambiar los títulos de trabajo y las descripciones.
Delegación y priorización
Scrum se basa en la idea de equipos autogestiones que trabajan juntos para completar un proyecto. En última instancia, el propietario del producto puede tener la última palabra sobre qué características o tareas tienen prioridad en el trabajo pendiente del producto (una lista de todas las características, tareas y trabajo que se deben completar en el proyecto), ya que están actuando como representantes de las necesidades del cliente. Sin embargo, todo el equipo proporciona información sobre qué tareas se abordarán en un sprint.
Los miembros del equipo de Scrum también suelen tener plena autonomía a la hora de completar el trabajo dentro del sprint. Pueden seleccionar en qué elementos trabajan cuando, siempre y cuando todo se logre al final del sprint.
Kanban fomenta la colaboración y el liderazgo a todos los niveles, pero no acepta al equipo autogestionado de la misma manera que Scrum. Dado que Kanban promueve que los equipos mantengan sus funciones antiguas, las estructuras de equipo anteriores tienden a dictar cómo se maneja la delegación.
Comúnmente, el gerente se encargará de priorizar el trabajo y administrar activamente el flujo de trabajo. Pueden delegar tareas específicas a ciertas personas o permitir que se aborden como “primero en llegar, primero en servir”.
Modificaciones y cambios
Scrum y Kanban manejan modificaciones y cambios de maneras muy diferentes.
En Scrum, se planea un sprint antes de su inicio, el equipo ejecuta su trabajo, y el sprint termina con la entrega y revisión del producto. Los comentarios, problemas, errores o cambios solicitados por los clientes se agregan al trabajo pendiente general del producto y se trabajan en futuros sprints en función de la prioridad.
Los cambios que se identifican a mitad del sprint no se abordarán hasta futuros sprints a menos que un problema sea lo suficientemente significativo como para que deba abordarse de inmediato. Este enfoque significa que las escalas de tiempo de sprint no cambian, pero es posible que sea necesario agregar sprints adicionales al proyecto general si se producen suficientes solicitudes de cambio.
En Kanban, los cambios se pueden realizar en cualquier momento y se recomiendan activamente las modificaciones inmediatas. Esto puede afectar a la escala de tiempo del proyecto, dependiendo de la gravedad del cambio.
Kanban fue creado originalmente por Toyota para la fabricación de automóviles, y a menudo se utiliza para hacer frente a una gran cantidad de las mismas tareas o piezas de trabajo. En este tipo de escenario, donde los productos son intercambiables, el énfasis está en entregar un cierto volumen en lugar de una pieza determinada. Por lo tanto, cuando se descubre que un producto está dañado, defectuoso o necesita una revisión, por lo general se extrae del flujo de trabajo para que se desecha o modifique.
Medición de la productividad
Scrum se basa en métricas como la velocidad y las tasas de agotamiento para medir la productividad.
- Velocity realiza un seguimiento de la cantidad de trabajo que un equipo está completando durante un sprint.
- Los gráficos de burndown muestran cuánto trabajo queda por completar.
Juntos, estas herramientas ayudan a ilustrar lo productivo que ha sido el equipo hasta ahora y lo productivos que deben seguir siendo para completar el proyecto a tiempo.
Kanban tiende a monitorear el tiempo de ciclo, el tiempo de entrega y el trabajo en curso para evaluar la productividad.
- El tiempo de ciclo mide el tiempo que tarda una tarea en completarse. Esta medición suele tardar un promedio de cuánto tiempo está en curso el trabajo.
- El tiempo de entrega es una métrica más amplia que mide durante cuánto tiempo se identificó o agregó una tarea a la placa kanban hasta que se completó.
Imagine que se le asignó una tarea el lunes por la mañana, comenzó a trabajar en ella el miércoles por la mañana, y la completó al final del día el viernes. En este escenario, el plazo de entrega fue de cinco días (de lunes a viernes) y el tiempo de ciclo fue de tres días (de miércoles a viernes).
- El trabajo en curso mide el volumen medio de tareas en la etapa “en curso” de su tablero kanban.
Fechas de vencimiento y plazos de entrega
En Scrum, los sprints suelen tener una duración de una a cuatro semanas, y un incremento del producto, o una versión del producto, se entrega al final de cada sprint. Cualquier documentación justificativa, como materiales de capacitación, también se entregaría en este momento. Rara vez hay fechas de vencimiento o entregas a mitad del sprint.
La excepción sería cuando las tareas interdependientes se asignan al mismo sprint. Si la tarea B no se puede iniciar hasta que se complete la tarea A, es posible que la tarea A tenga una fecha de vencimiento lo suficientemente temprana como para asegurarse de que ambas se realicen a tiempo para la entrega. Sin embargo, a menudo no hay una fecha de vencimiento formal asignada, y el equipo simplemente administra estas dependencias en sus reuniones diarias de standup.
Kanban se basa en la idea de entregas continuas. Los equipos kanban a menudo trabajan en tareas, productos o entregables independientes. Por lo tanto, una vez que se completa una pieza de trabajo, se puede entregar al cliente de inmediato.
Los equipos pueden optar por agrupar las entregas, por lo que no envían constantemente un elemento a la vez, pero la forma en que lo hacen depende de ellos. Por ejemplo, puede optar por enviar cada viernes o cada vez que llegue a 20 piezas completadas.
En cuanto a las fechas de vencimiento, el enfoque principal de Kanban tiende a estar en el tiempo de ciclo y el tiempo de entrega en lugar de qué pieza de trabajo se debe cuando. Esto significa que las fechas de vencimiento tienden a basarse en los plazos de entrega objetivo en lugar de en cuando los clientes esperan entregas.
Por ejemplo, si el objetivo es un tiempo de ciclo promedio de cinco días, cada tarjeta puede tener una fecha de vencimiento de cinco días a partir de cuando se asigna el trabajo, incluso si no se entrega al cliente hasta el final del mes.
¿Qué tablero y marco del plan de proyecto es mejor para organizar un proyecto?
La respuesta a cuándo usar Kanban vs Scrum depende del tipo de proyecto que esté planeando. Scrum y Kanban son los más adecuados para diferentes proyectos.
Pero aquí hay un breve análisis:
- Para los proyectos únicos que tienen muchas variables e incertidumbres, están más orientados a la fecha límite e involucran a un equipo más grande, Scrum es un mejor marco y el tablero del plan de proyectos.
- Para los proyectos que ha realizado antes o que son recurrentes, implican muchos entregables y requieren mantener un ojo en la capacidad individual, Kanban es un mejor marco y tablero de planes de proyecto.
Kanban: ¿Tiene que ser cualquiera o cualquiera?
Hay una tercera opción, llamada Scrumban. Es una combinación de los dos marcos que intenta proporcionar un punto medio para los equipos que encuentran Kanban demasiado flexible y Scrum demasiado rígido.
Si desea saber más, echa un vistazo a nuestro artículo Lo que necesita saber acerca de Scrumban.
Independientemente del proyecto con el que se le encargo, el cambio es inevitable. Adoptar una metodología ágil es el primer paso para mejorar la colaboración, perfeccionar procesos consistentes y tener esa flexibilidad incorporada, para que usted y su equipo estén equipados para lo que se le tire a su manera.