Scrum y Kanban: dos poderosas metodologías ágiles explicadas
Publicado: 2021-05-27¿Está a punto de gestionar un proyecto complejo? Hay mucho trabajo por hacer, ¡pero no se asuste! Como gerente de proyecto, serás responsable de planificar, monitorear, administrar el presupuesto, ejecutar, verificar la calidad y entregar el proyecto final a tiempo. Afortunadamente, existen muchas metodologías de gestión de proyectos que pueden hacer que su trabajo (y el de su equipo también) sea más fácil y mucho más eficiente.
En este artículo, me gustaría concentrarme en las dos metodologías ágiles más populares , Scrum y Kanban , que han conquistado el mundo del desarrollo de software en los últimos años. En estos días, difícilmente encontrará una casa de software que no adopte estos dos marcos para la gestión de proyectos. ¿De qué se tratan? ¡Sigue leyendo y aprende todo lo que necesitas saber sobre Scrum y Kanban!
¿Qué es exactamente la metodología Agile en la gestión de proyectos?
Hoy en día, las empresas ya no trabajan en un solo proyecto sin probarlo en todas las etapas del proceso de desarrollo. ¡Simplemente no compensa! ¿Por que no?
Imagínese: todo su equipo trabaja durante varios meses, digamos, en el desarrollo de una aplicación móvil, que solo prueba y evalúa al final una vez que todo el trabajo de sus desarrolladores, diseñadores y redactores de backend y frontend ya está terminado. ¿Qué pasa si solo entonces te das cuenta de que tu producto ya no responde a los requisitos del mercado y las necesidades de los usuarios? Luego, deberá introducir iteraciones posteriores de todo el proyecto, lo que consume mucho tiempo, dinero y energía.
La metodología ágil es, por lo tanto, una gran solución que mejora significativamente el flujo de trabajo y facilita la implementación de cambios en cada etapa. El principio clave detrás de Agile es dividir un proyecto "grande" y complejo en varios elementos (o características) más pequeños y lanzarlos uno tras otro. Aquí, tanto el desarrollo como las pruebas son dos actividades simultáneas, lo que facilita la validación continua del proyecto y la introducción de todas las mejoras necesarias.
Lo interesante es que, si bien durante muchos años prevaleció Agile en las empresas de TI y desarrollo de software, esta metodología resultó ser tan efectiva que hoy en día se utiliza en muchos otros campos, como marketing, ventas, recursos humanos u operaciones. Según el Informe sobre el estado de Agile elaborado por Verison One, en 2020 el 95 % de las empresas de tecnología y las casas de software practicaban varios métodos Agile.
Marco Scrum: ¿por qué es tan increíble?
Muchas personas tienden a mezclar dos conceptos que, aunque parecen bastante similares, no son sinónimos: Agile y Scrum. En pocas palabras, Ágil es un término general que indica todos los métodos y enfoques especificados en el Manifiesto Ágil , mientras que Scrum es, de hecho, uno de esos métodos. ¡Es tan simple como eso!

¿Qué es Scrum y cuándo se puede utilizar?
Scrum es un marco de gestión de proyectos, que se aplica principalmente a la creación de productos complejos en los que el proceso de desarrollo lleva al menos varios meses. Se basa, sobre todo, en la transparencia, la comunicación permanente entre todos los miembros del equipo y la responsabilidad colectiva. Esta estrategia facilita entregar la versión final del proyecto que satisfaga las necesidades del público objetivo y responda a las demandas actuales del mercado.
Aunque Scrum se ha convertido en un marco líder, especialmente en los últimos años, en realidad no es nada nuevo. Volvamos a 1986 cuando Harvard Business Review publicó el artículo The New Product Development Game . Allí, los autores describieron un enfoque de gestión empleado por empresas como Honda o Canon que las condujo al éxito. Luego, en 1993, estos conceptos inspiraron a Jeff Sutherland y al equipo de Easel Corporation a establecer un proceso basado en equipos llamado Scrum.
Roles y responsabilidades en un Equipo Scrum
En un equipo Scrum, todos los roles están claramente definidos desde el principio y, por lo general, no cambian a lo largo de todo el proyecto. Por regla general, este framework tiene 3 roles fundamentales: Product Owner, Scrum Master y Development Team.
Maestro Scrum
Un Scrum Master es una especie de líder de equipo (pero no del todo) que se asegura de que todo se haga de la manera correcta y que el proceso de desarrollo funcione sin problemas. Las principales responsabilidades de un Scrum Master son:
- entrenar a los miembros del equipo para que todos trabajen de manera más eficiente para ofrecer nuevas características del producto digital
- planificar todas las tareas para los próximos sprints (a continuación, les cuento más sobre los sprints en Scrum) y mantener el Product Backlog
- educar a las partes interesadas y a todos los miembros del equipo sobre la importancia de los principios de Scrum para la gestión de proyectos
- evaluar si todas las tareas se llevan a cabo de acuerdo con el plan
- tratando de eliminar todos los obstáculos que dificultan la realización de las tareas en un sprint determinado.
Es extremadamente importante que un Scrum Master siempre trabaje en estrecha colaboración con un propietario del producto . Juntos planifican los sprints posteriores, evalúan la calidad de las tareas completadas, establecen una dirección para el equipo y determinan si el proyecto requiere la introducción de cambios. En pocas palabras, Scrum Master hace todo lo posible para ayudar al equipo de desarrollo a tener éxito y entregar todas las funciones a tiempo.
Dueño del producto
Un Product Owner es responsable de entregar la versión final del producto que puede generar ganancias comerciales reales. Por tanto, en todo el equipo Scrum, es el Product Owner quien marca las prioridades y tiene el papel más decisivo . Lo que es importante aquí es que la cartera de pedidos del producto sea administrada por el Product Owner, quien determina qué características del producto deben desarrollarse como una prioridad, ya que tienen el mayor valor comercial.
Estas son las principales responsabilidades de un Product Owner:
- gestionar la cartera de productos
- contactar a las partes interesadas
- definir el objetivo principal de cada sprint
- planificar el lanzamiento de nuevas características
- evaluar el trabajo del Equipo de Desarrollo y cancelar el sprint cuando sea necesario
Equipo de desarrollo
Sin un equipo de desarrollo, Scrum no sería posible, ya que hacen el trabajo real y completan todas las tareas programadas para sprints particulares.
Por lo general, el equipo de desarrollo está formado por personas con experiencia en un campo en particular , como iOS, aprendizaje automático, desarrollo backend o frontend. Todos unen fuerzas para ofrecer características de alta calidad de un producto digital. Sin embargo, debe tener en cuenta que, aunque el término "equipo de desarrollo" generalmente se refiere a los ingenieros, esto no siempre es exacto. Los especialistas en marketing, diseñadores, analistas, evaluadores, redactores o especialistas en ventas también pueden aportar algo de valor y ser parte de un equipo Scrum.
Una de las cosas a considerar al construir un Equipo de Desarrollo es el número de sus miembros. ¡Incluso aquí Scrum especifica algunas reglas básicas! Se dice que dicho equipo debe constar de 3 a 9 personas y deben tener las habilidades necesarias para ofrecer todas las funciones. Por supuesto, todo depende de la complejidad del proyecto y de las necesidades del cliente; a veces, 4 o 5 desarrolladores son suficientes para crear un producto digital.
Pero, ¿cuál es exactamente el rol del Equipo de Desarrollo en Scrum? Básicamente, debería:
- crear todas las funciones del producto de acuerdo con las instrucciones del propietario del producto
- determinar cuántos elementos construir en un sprint dado
- administrar la carga de trabajo de manera eficiente para que todas las tareas se completen al final del sprint
- tomar todas las decisiones pertinentes de forma conjunta
- tener una actitud de 'nosotros': el equipo toma todas las decisiones, resuelve los problemas juntos y cada persona se siente responsable de los demás colegas

El proceso de desarrollo de Scrum en pocas palabras
Ya sabes qué es Scrum y quién forma un equipo Scrum, así que ahora es el momento de entender cómo es el proceso de desarrollo en esta metodología y cómo hacerlo bien.
En el proceso Scrum, cada paso cuenta y aporta valor real a su equipo. Estas son las etapas principales que no debe omitir:
- Product Backlog : una lista de todos los elementos que deben construirse en los siguientes sprints. Es administrado por un Product Owner junto con un Scrum Master que saben exactamente cuándo se debe lanzar cada función o elemento.
- Reunión de Planificación de Sprint : El objetivo principal de esta reunión es definir qué hará cada miembro del Equipo de Desarrollo en el próximo sprint. Siempre se organiza antes de que comience el sprint para que todos puedan evaluar si pueden completar todas las tareas antes de la fecha límite. Asegúrese de que cada miembro del equipo comprenda completamente el objetivo principal del sprint.
- Sprint Backlog : Estas son las tareas seleccionadas tomadas del Product Backlog que el equipo ha elegido realizar en un Sprint determinado.
- Sprint : Aquí es donde sucede toda la magia. Sprint es un período corto, que generalmente toma de 1 a 4 semanas cuando el equipo de desarrollo trabaja para completar todas las tareas asignadas durante la reunión de planificación de primavera.
- Daily Scrums (también llamado Standup): Reuniones extra cortas que se llevan a cabo todos los días a la misma hora, durante las cuales todos informan sobre el progreso de su trabajo en 1-2 oraciones: hablan sobre lo que se ha completado y lo que aún queda por hacer.
- Revisión de Sprint : cuando finaliza el Sprint, todos tienen la oportunidad de presentar lo que han completado a otros compañeros de equipo e incluso a las partes interesadas, que a menudo asisten a las Revisiones de Sprint.
- Retrospectiva de Sprint : ahora es el momento de la última reunión que finaliza todo el ciclo de Sprint. Si algún miembro del equipo tiene alguna sugerencia o idea sobre lo que podría mejorarse para el siguiente sprint, puede hacerlo durante la reunión de retrospectiva del sprint.

Para el proceso de Scrum, es esencial asegurarse de que cada ciclo de Scrum tenga la misma estructura : comienza con una reunión de planificación de Sprint, luego todos se ponen a trabajar y completan las tareas establecidas para el Sprint, y al final cada miembro del equipo muestra lo que han logrado.

Hay una cosa más que quiero que recuerde: Scrum tiene una filosofía de cambio muy estricta. ¿Qué significa esto en la práctica? Los miembros del equipo Scrum no deben cambiar las tareas o los objetivos principales durante el sprint. Si no logran entregar los resultados planificados, debería ser una lección para el futuro estimar mejor el tiempo necesario para completar los elementos.
Algunas palabras sobre Kanban
Ahora que ha aprendido qué es Scrum y cómo crear un producto digital con él, es hora de centrarse un poco más en la segunda metodología Agile. Estoy seguro de que ya lo conoces, ¡incluso si aún no te das cuenta!
¿Qué es Kanban y cuándo se puede aplicar?
El término Kanban proviene del japonés y puede traducirse simplemente como “señal visual”. De eso se trata básicamente esta metodología. En Kanban, cada elemento tiene su representación visual : una tarjeta que los miembros del equipo colocan en las pizarras y cambian su estado (como 'pendiente', 'en proceso' o 'terminado').
Cualquier industria puede aplicar fácilmente este enfoque, pero lo eligen con mayor frecuencia los equipos de desarrollo de software que participan en proyectos complejos y que consumen mucho tiempo. Y por una buena razón: Kanban facilita la comunicación en tiempo real y hace que el trabajo de todos los compañeros de equipo sea totalmente transparente.
Curiosamente, Kanban es, de hecho, una metodología mucho más antigua que Scrum. Sus inicios se remontan a la década de 1940 cuando Toyota introdujo en sus fábricas un sistema de tarjetas separadas colocadas en pizarras blancas que los trabajadores podían cambiar en cualquier momento. Como resultado, esta estrategia hizo que su trabajo fuera mucho más fluido y aceleró la comunicación entre los equipos.
¿Quién es quién en un equipo Kanban?
Al hablar de Scrum, describí las funciones, responsabilidades y competencias exactas de cada miembro del equipo (Scrum Master, Product Owner y desarrolladores). Aquí, las cosas son muy diferentes. Kanban no define quién tiene más poder o responsabilidades, ya que prácticamente todos los miembros del equipo son iguales y unen fuerzas y conjuntos de habilidades colectivamente.
Además, Kanban no especifica cuántas personas pueden trabajar juntas en un proyecto, por lo que cualquier estructura de equipo es aceptable. Sin embargo, si desea mejorar el flujo de trabajo, puede considerar la creación de un equipo de desarrollo cruzado. Gracias a esta solución, los miembros del equipo con diferentes áreas de especialización pueden compartir sus conocimientos y dar su opinión en cada etapa del desarrollo del producto. ¡De esta manera, no habrá necesidad de consultar a otros equipos en absoluto!
¿Qué es un tablero Kanban y cómo crearlo?
El tablero Kanban es el corazón y el alma de esta metodología. Es una herramienta de gestión de proyectos creada para visualizar el progreso de cada tarea en tiempo real. Si se pregunta si sus compañeros de equipo ya comenzaron a trabajar en una característica importante, o tal vez ya la terminaron, ¡simplemente revise el tablero y ahora lo sabe!
Este ejemplo muestra exactamente qué es Kanban y cómo visualiza el trabajo:

Entonces, el concepto general detrás de los tableros Kanban es bastante simple: tiene varias columnas etiquetadas y en cada una de ellas coloca tarjetas visuales. Estos pueden ser adhesivos o boletos. En cada una de estas tarjetas, escribe el nombre del proyecto en el que está involucrado actualmente o el elemento de trabajo específico que está construyendo. Luego, todo lo que necesita hacer es asignar una tarjeta en particular a una columna específica para que el resto de su equipo esté actualizado y sepa exactamente en qué está trabajando ahora.
El ejemplo que puede ver arriba muestra categorías de columnas típicas, que son:
- 'que hacer'
- 'en progreso'
- 'pruebas'
- 'hecho'
Tenga en cuenta, sin embargo, que puede describir su flujo de trabajo de manera más amplia y agregar columnas adicionales ; su elección dependerá del proyecto que esté administrando.
Si desea que su equipo tenga éxito, hay una cosa más que debe tener en cuenta: debe definir límites para los elementos en los que su equipo puede trabajar al mismo tiempo. Esta es la razón por la que Kanban también recomienda establecer límites de trabajo en curso (WIT) . ¿Cómo ponerlo en práctica? Debe especificar cuántas tarjetas pueden permanecer en una columna (por ejemplo, 'En progreso') al mismo tiempo. Si su equipo alcanza este límite, simplemente no pueden agregar más tarjetas. Establecer estos límites siempre es una gran solución para lidiar con la sobrecarga de trabajo.
Scrum vs. Kanban: ¿qué framework gana esta batalla?
Bueno, la respuesta a esa pregunta en realidad no es tan simple. Estas dos estrategias ágiles comparten algunos principios similares, pero las prácticas que emplean son dos cosas completamente diferentes. Mientras que Kanban es más fluido y favorece el cambio continuo y la retroalimentación periódica, Scrum es mucho más estricto y organizado.
¿Listo para su próximo proyecto de software?
Vamos a trabajar juntosEstas son las principales diferencias entre estos dos marcos de gestión de proyectos:
Melé | Kanban | |
---|---|---|
roles | Scrum Master, propietario del producto, equipo de desarrollo | Roles indefinidos |
Equipos | solo equipo | Varios equipos trabajan en un tablero Kanban |
flujo de trabajo | Sprints cortos (1-4 semanas) | Continuo |
Entrega | Nuevo elemento/característica al final de cada sprint | Continuo |
Cambiar filosofía | No se pueden realizar cambios durante todo el sprint. | Los cambios se pueden introducir en cualquier momento. |
Llaves metricas | Velocidad | WIT, tiempo de ciclo |
Herramienta popular | jira | Trello |
Entonces, ¿cuál de estos marcos ágiles elegirá para administrar sus proyectos? ¿O prefieres que los expertos lo hagan por ti? No dude en contactarnos: al introducir varias metodologías ágiles, ¡hemos entregado más de 150 productos exitosos listos para usar!
¿Cuándo usar Kanban en lugar de Scrum?
Kanban es una metodología significativamente más efectiva para los equipos que operan en un flujo de trabajo continuo . Entonces, supongamos que administra un equipo que recibe nuevas solicitudes entrantes con diferentes prioridades de manera regular. En este caso, Kanban será una opción mucho mejor, ya que este enfoque no tiene límite de tiempo: no restringe el flujo de trabajo de su equipo a sprints y no define plazos rigurosos.
En pocas palabras, use Kanban si desea lograr una mayor flexibilidad y una entrega continua .
Por otro lado, si su trabajo se centra en ofrecer nuevas funciones dentro de plazos específicos y tiene objetivos a largo plazo claramente definidos, entonces Scrum será mucho más efectivo.
¿Es Trello Scrum o Kanban?
Trello es una de las herramientas más populares que utiliza el método Kanban para la gestión de tareas. De forma predeterminada, le permite mover tareas de una columna a otra según su estado actual. De esta manera, todos los involucrados en el proyecto siempre pueden estar al día con el flujo de trabajo.
Sin embargo, Trello también se puede aplicar con éxito a pequeños equipos Scrum. Para este propósito, Scrum master puede crear varias columnas con diferentes estados, como Backlog , Sprint Planning , Current Sprint , En progreso y Terminado , y colocar las tareas en una de ellas.
¿Kanban tiene sprints y standups diarios?
Kanban es un enfoque ágil centrado en el flujo en el que se agregan continuamente más tareas al flujo de trabajo y no especifica la fecha límite para entregar una tarea. Por esta razón, no utiliza sprints, y los equipos de Kanban no organizan Sprint Plannings o reuniones de Sprint Retrospective .
Además, Kanban no obliga al equipo a realizar reuniones diarias. Sin embargo, aún permite organizarlas si el equipo siente que reuniones tan cortas aportan algún valor y mejoran el flujo de trabajo.