Agile, Scrum y Kanban: ¿Cuál elegir?

Imagina una majestuosa cascada, cayendo con gracia de un nivel a otro. Ahora, visualiza la gestión de un proyecto de la misma manera. La metodología Waterfall (Cascada) puede parecer eficiente al principio, pero conlleva su propio conjunto de desafíos. Al igual que el flujo lineal de una cascada, esta metodología utiliza una estructura secuencial. Cada fase debe completarse antes de que comience la siguiente.

Lamentablemente, los proyectos del mundo real a menudo enfrentan incertidumbres y cambios. Visualiza a tu equipo precipitándose por la cascada, incapaz de cambiar de rumbo a mitad del descenso. La rigidez de la metodología Waterfall puede llevar a una falta de adaptabilidad, retroalimentación tardía y la incapacidad de abordar requisitos cambiantes, lo que resulta en un viaje de proyecto que se asemeja a un descenso accidentado, en lugar de un flujo suave y ágile.

¿Qué es Agile y por qué es importante?

El movimiento Agile comenzó como una respuesta a la naturaleza rígida e inflexible de la gestión de proyectos tradicional, con el objetivo de mejorar los ciclos de desarrollo. Arraigado en los principios ágiles y la mentalidad ágil reflejada en el Manifiesto Ágil, el movimiento Ágile enfatiza la flexibilidad, la adaptabilidad y la colaboración, valores fundamentales de varios marcos de trabajo como Scrum, Kanban y Extreme Programming.

Los cuatro valores fundamentales del Manifiesto Ágil son:

• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación exhaustiva.
• Colaboración con el cliente sobre negociación de contratos.
• Respuesta al cambio sobre seguir un plan.

Estos valores, junto con los doce principios que los respaldan, guían a los equipos hacia formas de trabajar más adaptables y centradas en el cliente. Ser Ágile no se trata solo de usar un conjunto específico de herramientas o seguir un ritual, sino de adoptar una mentalidad que prioriza la entrega de valor de forma iterativa y responder al cambio de manera efectiva.

Marcos de Trabajo Ágiles Populares: Scrum y Kanban

Si bien un marco de trabajo no es esencial para ser Ágile, puede servir como una herramienta útil. Existen varios marcos que ayudan a los equipos a implementar la filosofía Ágile. Dos de los más populares y ampliamente adoptados son Scrum y Kanban. Ambos comparten el objetivo común de fomentar la agilidad dentro de un equipo de proyecto u organización, pero lo abordan de maneras distintas.

Scrum: Un Enfoque Estructurado e Iterativo

Scrum es un marco de trabajo para desarrollar, entregar y mantener productos complejos. Se basa en el empirismo y el pensamiento lean. El empirismo afirma que el conocimiento proviene de la experiencia y de tomar decisiones basadas en lo observado. El pensamiento lean reduce el desperdicio y se enfoca en lo esencial.

Con Scrum, tu equipo se compromete a entregar un incremento de trabajo valioso y potencialmente entregable al final de cada periodo fijo llamado sprint. Los sprints suelen durar entre una y cuatro semanas. Este marco está construido sobre la transparencia, la inspección y la adaptación.

Cadencia de Scrum

Scrum se mueve rápido, con sprints que suelen durar entre una y cuatro semanas, los cuales tienen fechas de inicio y fin claras. El corto plazo obliga a que las tareas complejas se dividan en historias más pequeñas y ayuda a que tu equipo aprenda rápidamente. Una pregunta clave es: ¿Puede tu equipo entregar código utilizable tan rápido? Los sprints están puntuados por reuniones de planificación del sprint, revisión del sprint y retrospectiva del sprint, y salpicados con reuniones diarias de Scrum (stand-up). Estas ceremonias de Scrum son ligeras y se ejecutan de forma continua.

Roles de Scrum

Scrum tiene tres roles claramente definidos que colaboran estrechamente:

• El Propietario del Producto (Product Owner): Es el responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. Gestiona el Backlog del Producto, lo que implica crear y refinar elementos del backlog, priorizarlos y asegurarse de que sean transparentes y entendibles. Aboga por el cliente y los stakeholders.
• El Scrum Master: Es un líder servicial que ayuda al equipo a entender y adherirse a la teoría, prácticas y reglas de Scrum. Elimina impedimentos para el progreso del equipo y facilita las ceremonias de Scrum. Ayuda a la organización a adoptar Scrum.
• El Equipo de Desarrollo (Development Team): Son los profesionales que realizan el trabajo de entregar un Incremento potencialmente entregable de 'Hecho' de un producto al final de cada Sprint. Son auto-organizados y multifuncionales, lo que significa que tienen todas las habilidades necesarias para crear el Incremento sin depender de terceros.

Los equipos de Scrum son auto-organizados y todos son iguales, a pesar de tener diferentes responsabilidades. El equipo está unido por el objetivo de entregar valor a los clientes.

Prácticas y Artefactos de Scrum

Scrum define una serie de eventos (ceremonias) y artefactos clave:

• Planificación del Sprint (Sprint Planning): Una reunión al inicio del sprint para definir qué se hará en el sprint y cómo se hará.
• Scrum Diario (Daily Scrum): Una reunión corta diaria para sincronizar actividades y crear un plan para las próximas 24 horas.
• Revisión del Sprint (Sprint Review): Una reunión al final del sprint para inspeccionar el Incremento y adaptar el Backlog del Producto si es necesario.
• Retrospectiva del Sprint (Sprint Retrospective): Una oportunidad para que el Equipo Scrum se inspeccione a sí mismo y cree un plan de mejoras para ser llevado a cabo durante el siguiente Sprint.
• Backlog del Producto (Product Backlog): Una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a ser realizado en el producto.
• Backlog del Sprint (Sprint Backlog): El conjunto de elementos del Backlog del Producto seleccionados para el Sprint, más el plan para entregar el Incremento y lograr el Objetivo del Sprint.
• Incremento (Increment): La suma de todos los elementos del Backlog del Producto completados durante un Sprint y el valor de los Incrementos de todos los Sprints anteriores.

Filosofía de Cambio

Los equipos se esfuerzan por entender cuánto pueden lograr dentro de los límites de tiempo de su sprint. Se comprometen a su entrega dentro de un sprint. Sin embargo, los equipos de Scrum pueden recibir retroalimentación del cliente que los aliente a pivotar y cambiar el sprint para entregar el mayor valor al cliente. Durante la retrospectiva del sprint, los equipos de Scrum deben discutir cómo limitar el cambio en el futuro, ya que los cambios ponen en riesgo el incremento potencialmente entregable. Si un equipo cambia frecuentemente el alcance a mitad del sprint, puede significar que se seleccionó trabajo que no se entendió adecuadamente. También podría significar que el equipo tiene trabajo operativo/no planificable que interfiere con el plan. Para más información sobre metodologías Scrum, consulta ¿Qué es Scrum? (Aunque no podemos incluir enlaces, el concepto se menciona).

Kanban: Mejora Continua, Procesos Flexibles

Kanban es otro marco de trabajo Ágile que se enfoca en visualizar el flujo de trabajo, limitar el trabajo en progreso (WIP) y maximizar la eficiencia. Proviene de la manufactura lean de Toyota y se adapta al desarrollo de software.

Kanban es ideal para equipos que tienen muchas solicitudes entrantes que varían en prioridad y tamaño. Mientras que los procesos de Scrum requieren un alto control sobre lo que está en alcance, Kanban te permite seguir el flujo.

Cadencia de Kanban

Kanban se basa en una estructura de flujo de trabajo continuo que mantiene a los equipos ágiles y listos para adaptarse a las prioridades cambiantes. Los elementos de trabajo, representados por tarjetas, se organizan en un tablero Kanban donde fluyen de una etapa del flujo de trabajo (columna) a la siguiente. Las etapas comunes del flujo de trabajo son Por Hacer, En Progreso, En Revisión, Bloqueado y Hecho. Pero eso es aburrido. La mejor parte de Kanban es hacer columnas personalizadas para cómo trabaja tu equipo. Mi equipo envía contenido, por lo que nuestras columnas (simplificadas) van de Backlog, a Priorizado, a Esquemas Listos, a Escritura, Diseño, Revisión Técnica y Enviado. Nuestro tablero nos ayudó a aprender que enviamos aproximadamente una pieza de contenido por semana y dónde están nuestros cuellos de botella (¡mirando la Revisión Técnica!).

Metodología de Entrega

En Kanban, las actualizaciones se entregan cuando están listas, sin un cronograma regular o fechas de vencimiento predeterminadas. En teoría, Kanban no prescribe un tiempo fijo para entregar una tarea. Si la tarea se completa antes (o después), se puede entregar según sea necesario sin tener que esperar un hito de entrega como la revisión del sprint.

Roles de Kanban

El equipo completo es dueño del tablero Kanban. Algunos equipos enlistan a un coach ágil, pero, a diferencia de Scrum, no hay un único "Kanban Master" que mantenga todo funcionando sin problemas. Es la responsabilidad colectiva de todo el equipo colaborar y entregar las tareas en el tablero.

Métricas Clave

El Tiempo de Entrega (Lead Time) y el Tiempo de Ciclo (Cycle Time) son métricas importantes para los equipos Kanban. Se refieren a la cantidad promedio de tiempo que tarda una tarea en moverse de principio a fin. Mejorar los tiempos de ciclo indica el éxito de los equipos Kanban. El Diagrama de Flujo Acumulado (CFD) es otra herramienta analítica utilizada por los equipos Kanban para comprender el número de elementos de trabajo en cada estado. Los CFD ayudan a identificar cuellos de botella específicos que deben resolverse para un mejor rendimiento. Otra forma de lidiar con los cuellos de botella es a través de los Límites de Trabajo en Progreso (WIP). Un límite de WIP establece un tope en el número de tarjetas que pueden estar en una columna a la vez. Cuando alcanzas tu límite de WIP, una herramienta como Jira limita esa columna y el equipo se concentra en esos elementos para hacerlos avanzar.

Filosofía de Cambio

Un flujo de trabajo Kanban puede cambiar en cualquier momento. Se pueden agregar nuevos elementos de trabajo al backlog y se pueden bloquear o eliminar tarjetas existentes según la priorización. Además, si la capacidad del equipo cambia, el límite de WIP puede recalibrarse y los elementos de trabajo ajustarse en consecuencia. En Kanban, todo se trata de ser flexible. Para más información sobre metodologías Kanban, consulta ¿Qué es Kanban? (De nuevo, sin enlaces).

Scrum vs. Kanban: Una Comparación

Si bien ambos son enfoques ágiles, sus prácticas y enfoques difieren significativamente. Aquí tienes una tabla comparativa basada en la información proporcionada:

Ambos marcos te ayudarán a construir mejores productos (y servicios) con menos dolores de cabeza, pero se adaptan mejor a diferentes contextos o tipos de trabajo. Scrum es ideal para proyectos con un objetivo claro y un equipo estable que puede comprometerse con entregas regulares. Kanban es excelente para equipos que gestionan un flujo constante de tareas diversas e impredecibles, como un equipo de soporte o mantenimiento.

Agile en la Práctica: El Caso Amazon

Amazon es uno de los pioneros de la Agilidad. Desde 1999, ha utilizado métodos Ágiles para la gestión de sus equipos. Entre 2004 y 2009, Scrum fue ampliamente adoptado en la organización de manera descentralizada y no planificada. Aunque Amazon no lo proclame, es una de las empresas más ágiles del planeta. Examinemos la cultura corporativa de Amazon desde los tres ángulos clave de la agilidad:

Auto-organización

Incluso con 12 niveles de jerarquía, Amazon tiene una organización muy plana comparada con otras empresas de su tamaño. Se deja una gran autonomía a los equipos para resolver los problemas de los clientes. Desde los primeros tiempos de Amazon, Jeff Bezos insistió: "Si un equipo no puede ser alimentado por dos Pizzas, es demasiado grande". ¿Por qué un equipo de más de 8 personas es menos eficiente? Simplemente porque cuanto más grande es el equipo, más compleja es la comunicación interna y más lenta es la toma de decisiones. Los empleados se involucran cuando perciben el impacto de su trabajo. El enfoque está principalmente en los resultados, como se observa en la cultura startup "do-or-die". Esto se alinea con el principio Ágile de Individuos e interacciones y la auto-organización de los equipos.

¿Cómo alinea Amazon tantos equipos hacia los mismos objetivos? Amazon define las directrices de su estrategia en forma de "Funciones de Forzamiento" (Forcing Functions). Obtienen los resultados deseados de forma funcional y cuantitativa, dejando gran libertad en la forma de lograrlos. Las características se describen como si se anunciaran en un comunicado de prensa futuro. En el caso de abrir la plataforma a los vendedores, el futuro comunicado de prensa decía que "un vendedor podría registrarse, listar un artículo, completar un pedido y atender a un cliente como si Amazon hubiera recibido el pedido detallado". La formulación es bastante cercana a una "Épica" en el lenguaje Ágile. Los equipos luego diseñaron todas las herramientas, procesos y medidas para permitir a los vendedores lanzar su tienda. A través del seguimiento de datos, toda la organización evaluó las capacidades y procesos para lograr este objetivo. Esto fomenta la entrega de Software funcionando y la alineación en torno al valor.

El intercambio de información entre los equipos no funcionó desde el principio. No era raro que dos o más equipos trabajaran en la misma idea. Para abordar estos problemas, hay expertos funcionales disponibles en forma de ingenieros senior, gerentes de producto senior y otros. La organización se asegura de que cuando varios equipos trabajan en la misma idea, aprovechen los errores de otros y también tomen caminos diferentes para evitar el trabajo duplicado. Jeff Bezos definió las reglas de colaboración en los equipos y pidió que trabajaran de una manera definida: "Si un equipo necesita información de otro equipo, esta información debe estar disponible en un panel de control". El objetivo era reducir el número de reuniones y el esfuerzo de coordinación, favoreciendo la comunicación eficiente y las interacciones necesarias.

Generación de Valor

El CEO anunció en su carta a los accionistas de 1997 ser "Obsesión por el Cliente" (Customer Obsessed): "Es trabajo de todos conocer y tener empatía y pasión por el cliente. Asegúrense de que todos conozcan los detalles de la experiencia del cliente y qué causa fricción para los clientes". Hasta hace unos años, Jeff Bezos tenía la costumbre de leer personalmente los mensajes de quejas de los clientes. Los gerentes luego recibían estos mensajes transmitidos por el propio Bezos con un sucinto signo de interrogación "?". Otra práctica en Amazon es simbolizar la presencia del cliente con una silla vacía en cada reunión, y así recordar que todo lo que se hace sirve para satisfacer al cliente. Este enfoque implacable en el cliente es la esencia de la Colaboración con el cliente y la entrega de valor en el Manifiesto Ágil.

En 1999, Amazon era una empresa pública y Jeff Bezos era multimillonario. Sin embargo, la empresa utilizaba escritorios improvisados con puertas de segunda mano. "Estábamos frente a un Home Depot. [Bezos] miró los escritorios en venta y las puertas en venta, y las puertas eran mucho más baratas, así que decidió comprar una puerta y ponerle patas", explica Nico Lovejoy, el quinto empleado de Amazon. Es un símbolo de gastar dinero en cosas que importan a los clientes. La explicación de Bezos a un reportero de CBS. Esta mentalidad de simplicidad y enfoque en el valor real se alinea con los principios Ágiles que priorizan el software funcionando sobre la complejidad innecesaria.

Según un artículo de The Seattle Times en 2020, Amazon tuvo una impresionante tasa de rotación del 100%, más del doble del promedio de la industria. Amazon es conocido como un lugar desafiante y exigente para trabajar. Desafiante en la obtención de resultados, lo que significa los resultados correctos. Desafiante para las personas para producir y dominar su dominio. Desafiante para los equipos y líderes para lograr lo imposible: la perfección en la experiencia del cliente. Esto potencialmente entra en conflicto con un ritmo sostenible y la satisfacción de los empleados, un aspecto del Manifiesto Ágil que promueve un ritmo constante y sostenible para el desarrollo.

Adaptabilidad

Migrar los servicios a su propia nube ha permitido a Amazon realizar varios miles de cambios de software por día. Como se recomienda en el Manifiesto Ágile, un ciclo de entrega corto ayuda a entregar valor más rápido y reduce el riesgo de interrupción del servicio. Todo esto solo fue posible invirtiendo fuertemente en la excelencia técnica para la implementación continua (DevOps), otro principio ágile que facilita la Respuesta al cambio y la entrega frecuente de Software funcionando.

"Día 1" es el nombre del primer edificio de Amazon y resume su filosofía: pensar siempre en sí misma como una startup en su primer día, cuando tiene todo por construir por delante. La Obsesión por el Cliente y la toma rápida de decisiones son esenciales para evitar el estancamiento organizacional. Estos dos factores han permitido a Amazon ingresar rápidamente al mercado de productos y servicios innovadores. Fomenta la toma de riesgos, la creatividad y los métodos de trabajo ágiles. Esta "Cultura del Día 1" encarna la Respuesta al cambio constante y la mentalidad de mejora continua.

A principios de la década de 2000, Amazon hizo una gran apuesta en Pets.com que resultó ser un fracaso total. Fracasó en la creación de un teléfono, un mercado de gama alta y un sinfín de otros proyectos. Sin embargo, entre estos riesgos, muchos han dado sus frutos, como el lanzamiento de AWS, que representa el 10% de su facturación hoy en día. En el corazón del dinamismo de la organización está la aceptación explícita de la experimentación, la valoración de los errores y el aprendizaje rápido. Esta disposición a "Fallar y Crear" es fundamental para la agilidad, ya que permite aprender y adaptarse rápidamente.

Para ayudar a compartir la retroalimentación, el departamento de Recursos Humanos de Amazon introdujo "Connections", una herramienta que pregunta a cada empleado una pregunta cada día al iniciar sesión en su computadora. Las preguntas cubren temas como la dinámica del equipo, la efectividad del gerente o los impedimentos. Las respuestas proporcionan retroalimentación agregada a los gerentes sobre áreas a mejorar y les dan recomendaciones sobre capacitaciones y recursos de aprendizaje relacionados con los temas. Esto es similar a la verificación de salud en teammeter, que puede planificar encuestas cortas a los empleados. Esta cultura de retroalimentación constante alimenta la inspección y adaptación que son pilares de la agilidad.

En conclusión, si bien Amazon no se autodenomina "Ágile", su cultura incorpora varios principios del Manifiesto Ágile. En lugar de los términos ágiles 'Auto-organización', 'Enfoque en el Cliente' y 'Aceptar el Cambio', utiliza su propio vocabulario como 'Equipos de Dos Pizzas', 'Obsesión por el Cliente' y 'Día 1'. Sin embargo, debido al contexto altamente competitivo en el que opera, la empresa ha tenido que adoptar una actitud muy exigente hacia sus empleados y socios. Este aspecto de la cultura de Amazon entra en conflicto con el ritmo sostenible que promueve el manifiesto ágile. Esta es la razón por la que Amazon rara vez se cita en la literatura Ágile, a pesar de que implementa la Agilidad a un nivel muy alto.

Eligiendo tu Camino Ágile

Scrum y Kanban son "ágiles según los libros". Funcionan de una manera probada y verdadera que es francamente difícil de rebatir. Siguiendo otra famosa frase, podrías decir que "Nadie es despedido por elegir Scrum". Pero tu decisión no tiene por qué ser tan blanco o negro.

Cientos de equipos están utilizando modelos híbridos influenciados tanto por Scrum como por Kanban. Por ejemplo, un equipo puede usar sprints de duración fija como en Scrum, pero gestionar su flujo de trabajo con un tablero Kanban y límites de WIP. O un equipo de Scrum puede incorporar métricas de flujo de Kanban como el tiempo de ciclo para identificar cuellos de botella.

La comunidad ágile cree que esta conversación no debería centrarse en las herramientas. A menudo vemos que la herramienta elegida impulsa el marco de trabajo elegido y el marco de trabajo impulsa los principios que el equipo adopta. Creemos que la decisión debería fluir en la dirección opuesta. Una vez que estés alineado con los principios ágiles y satisfecho con un marco de trabajo (o una combinación), entonces es hora de encontrar una herramienta que te sirva bien. Hay muchas herramientas disponibles que soportan tanto Scrum como Kanban, permitiendo flexibilidad en la implementación.

Independientemente de lo que elijas, mantente con ello por un tiempo. Lleva algo de trabajo desde el backlog hasta que esté hecho y luego pregunta a tu equipo qué salió bien y qué salió mal. Al probar Scrum y Kanban y hacer estas preguntas, estás en el camino correcto hacia la felicidad ágile.

Preguntas Frecuentes sobre Agile, Scrum y Kanban

• ¿Es Agile una metodología o una mentalidad? Agile es más una mentalidad y un conjunto de principios que guían cómo trabajar. Scrum y Kanban son marcos de trabajo específicos que ayudan a implementar la filosofía Ágile en la práctica.
• ¿Cuál es la principal diferencia entre Scrum y Kanban? La diferencia fundamental radica en la cadencia y la estructura. Scrum utiliza iteraciones de tiempo fijo (sprints) y roles definidos, enfocándose en la entrega de incrementos al final de cada sprint. Kanban se enfoca en un flujo continuo de trabajo, visualización en un tablero y limitación del trabajo en progreso (WIP), permitiendo una mayor flexibilidad en la entrega.
• ¿Significa Agile que no hay planificación? ¡Absolutamente no! Agile implica planificación, pero de una manera diferente. Se enfoca en la planificación adaptativa e iterativa. Se planifica lo suficiente para el próximo sprint o para un corto período de tiempo, y el plan se ajusta a medida que se obtiene más información y retroalimentación.
• ¿Cuál marco es mejor, Scrum o Kanban? No hay un "mejor" marco. La elección depende del contexto del equipo, el tipo de proyecto, la naturaleza del trabajo (predecible vs. impredecible), y la cultura organizacional. Algunos equipos encuentran que un enfoque híbrido funciona mejor.
• ¿Amazon usa Scrum? Aunque Amazon no se autodenomina formalmente como "empresa Scrum" y utiliza su propia terminología, la información proporcionada sugiere que han adoptado ampliamente prácticas y principios que se alinean fuertemente con Scrum y la filosofía Ágile, como la auto-organización de equipos, la entrega frecuente y la adaptación basada en la retroalimentación.
• ¿Qué son los "Equipos de Dos Pizzas" de Amazon? Es una metáfora utilizada por Jeff Bezos para describir el tamaño ideal de un equipo: lo suficientemente pequeño como para ser alimentado por dos pizzas. Esto promueve la auto-organización, la comunicación eficiente y la autonomía, conceptos clave en la agilidad.

Adoptar un enfoque ágile, ya sea a través de Scrum, Kanban o un modelo híbrido, puede transformar la forma en que tu equipo gestiona proyectos, fomenta la colaboración y entrega valor de manera consistente en un mundo en constante cambio.

Si quieres conocer otros artículos parecidos a Agile, Scrum y Kanban: ¿Cuál elegir? puedes visitar la categoría Automóviles.