Kanban frente a scrum: ¿qué metodología ágil prefieres?

Resumen: kanban es un marco de gestión de proyectos que se basa en tareas visuales para gestionar los flujos de trabajo, mientras que scrum es un marco de gestión de proyectos que ayuda a los equipos a estructurar y gestionar su trabajo mediante un conjunto de valores, principios y prácticas.

La metodología ágil constituye un conjunto de ideales y principios que actúan como el faro que nos guía. La metodología DevOps es una forma de automatizar e integrar los procesos entre los equipos de operaciones y de desarrollo de software. Kanban y scrum ofrecen distintas estrategias para implementar la metodología ágil y DevOps.

Resulta sencillo señalar las diferencias entre las prácticas de scrum y las de kanban, pero solo en las cuestiones superficiales. Aunque las prácticas difieren, los principios son en gran medida los mismos. Ambos marcos te ayudarán a crear mejores productos (y servicios) con menos dolores de cabeza.

A ver, ¿por dónde íbamos?

La metodología ágil es un enfoque estructurado e iterativo para la gestión de proyectos y el desarrollo de productos. Reconoce la volatilidad del desarrollo de productos y aporta una metodología para que los equipos autoorganizados reaccionen ante los cambios sin que se les vaya de las manos. Hoy en día, la metodología ágil apenas supone una ventaja competitiva. Nadie puede permitirse el lujo de desarrollar un producto durante años, o incluso meses, en un entorno aislado, sin contacto con el exterior. Esto quiere decir que hacer las cosas bien resulta ahora más importante que nunca.

Kanban consiste en visualizar el trabajo, limitar el trabajo en curso y maximizar la eficiencia (o el flujo). Los equipos de kanban se centran en reducir el tiempo que se tarda en llevar un proyecto (o historia de usuario) del principio al fin del proceso. Para ello, utilizan un tablero de kanban y mejoran continuamente su flujo de trabajo.

Los equipos de scrum se comprometen a completar un incremento de trabajo, que potencialmente se puede entregar, a través de intervalos establecidos llamados sprints. Su objetivo es crear bucles de aprendizaje para recopilar e integrar rápidamente los comentarios de los clientes. Los equipos de scrum adoptan funciones específicas, crean artefactos especiales y organizan ceremonias periódicas para que el trabajo siga saliendo adelante. La mejor definición de la metodología scrum se encuentra en la guía The Scrum Guide.

Sea cual sea el marco de gestión de proyectos más adecuado para ti, tenemos plantillas de Jira para que te pongas a trabajar cuanto antes. Echa un vistazo a nuestra plantilla de scrum o a nuestra plantilla de tablero de kanban; ambas se pueden usar de forma gratuita.

Con scrum, tu equipo se compromete a lanzar valiosos incrementos de trabajo al final de cada sprint. Scrum se basa en el empirismo, y se centra en pequeños incrementos de trabajo que te ayudarán a aprender de los clientes y a fundamentar mejor qué hacer a continuación. Consta de lo siguiente:

Scrum avanza con rapidez, con sprints que suelen durar entre una y cuatro semanas, y que tienen fechas claras de inicio y finalización. Este plazo tan breve obliga a dividir las tareas complejas en historias más pequeñas y a que el equipo aprenda más rápido. Una de las preguntas clave es: ¿puede tu equipo lanzar código utilizable con semejante celeridad?

Los sprints se acotan mediante la planificación de los sprints, la revisión de los sprints y las reuniones de retrospectiva, y se aderezan con reuniones diarias de scrum (reuniones rápidas). Estas ceremonias de scrum son ligeras y se llevan a cabo de forma continuada.

La metodología scrum presenta tres funciones claramente definidas.

• El propietario del producto aboga por el cliente, gestiona el backlog del producto y ayuda a priorizar el trabajo que desempeña el equipo de desarrollo.
• El experto en scrum ayuda al equipo a mantenerse firme en los principios de scrum.
• El equipo de desarrollo elige el trabajo que hay que llevar a cabo, entrega incrementos y demuestra responsabilidad colectiva.

¿Quién dirige el equipo de scrum? Pues bien, lo cierto es que nadie. Los equipos de scrum se autoorganizan y todos sus integrantes son iguales, a pesar de tener responsabilidades distintas. El equipo está unido por el objetivo de lanzar valor a los clientes.

Las métricas de scrum son datos que los equipos de scrum pueden utilizar para mejorar la eficiencia y la eficacia. Sirven para tomar decisiones más fundamentadas y poder planificar y ejecutar el trabajo de una forma más eficiente. Durante la fase de planificación de sprints, los equipos pueden usar métricas como los objetivos del sprint, la velocidad del equipo, la capacidad del equipo y el tipo de trabajo. Durante las reuniones rápidas, a los equipos también les puede venir bien medir el progreso hacia los objetivos del sprint, evaluar el trabajo pendiente del sprint, revisar la distribución de la carga de trabajo, etc.

Los equipos se esfuerzan por comprender cuánto pueden lograr dentro de los límites de tiempo de un sprint. Se comprometen a su entrega dentro de un sprint. Sin embargo, los equipos de scrum pueden recibir feedback de los clientes que los anima a modificar el sprint para aportar el máximo valor a los clientes. Durante la retrospectiva de sprint, los equipos de scrum deben analizar cómo limitar los cambios en el futuro, ya que los cambios ponen en riesgo la posibilidad de que se lance el incremento afectado. Si un equipo cambia con frecuencia el alcance a mitad del sprint, puede ser síntoma de que se seleccionó un trabajo que no se entendía adecuadamente. También podría significar que el equipo tiene trabajo operativo o no planificable que interfiere en el plan.

Si deseas más información sobre las metodologías de scrum, consulta ¿Qué es scrum?.

Kanban ayuda a visualizar el trabajo, a limitar el trabajo en curso y a avanzar rápidamente del trabajo "en progreso" al "terminado".

Kanban resulta ideal para equipos que tienen muchas solicitudes entrantes con prioridades y tamaños variables. Mientras que los procesos de scrum requieren un gran control sobre lo que está dentro del alcance, kanban te permite dejar que todo fluya. Examinemos las mismas cinco consideraciones para ayudarte a tomar una decisión.

Kanban se basa en una estructura de flujo de trabajo continuo que hace que los equipos se mantengan ágiles y listos para adaptarse a las cambiantes prioridades. Los elementos de trabajo (representados por tarjetas) se organizan en un tablero de kanban, donde pasan de una etapa del flujo de trabajo (columna) a la siguiente. Las etapas habituales del flujo de trabajo son Por hacer, En curso, En revisión, Bloqueado y Finalizado. Pero eso es aburrido.

Lo mejor de kanban es que puedes crear columnas personalizadas que se adapten a la forma de trabajar del equipo. Mi equipo lanza contenido, por lo que estas son nuestras columnas (simplificadas), en el siguiente orden: Backlog, Prioritario, Esbozos listos, Escritura, Diseño, Revisión técnica y Lanzado. Nuestro tablero nos ha ayudado a detectar que lanzamos alrededor de una unidad de contenido por semana, y dónde están nuestros cuellos de botella (¡no miro a nadie, Revisión técnica!).

En kanban, las actualizaciones se publican en cuanto están listas, sin ninguna planificación periódica ni fechas de vencimiento predeterminadas.

En teoría, kanban no establece un momento específico para entregar una tarea. Si la tarea se completa antes (o después), se puede publicar según convenga sin tener que esperar a que se produzca un hito de publicación como, por ejemplo, la revisión de un sprint.

Todo el equipo es propietario del tablero de kanban. Algunos equipos recurren a un orientador en metodología ágil, pero, a diferencia del scrum, no existe un único "experto en kanban" que haga que todo funcione con una fluidez constante, sino que todo el equipo se responsabiliza colectivamente de colaborar en las tareas del tablero y de entregarlas.

El plazo y la duración del ciclo son métricas importantes para los equipos de kanban. Hacen referencia al promedio de tiempo que le lleva a una tarea pasar del principio al fin del proceso. La mejora en las duraciones de los ciclos indica el éxito de los equipos de kanban.

El diagrama de flujo acumulado es otra herramienta analítica que utilizan los equipos de kanban para conocer el número de elementos de trabajo de cada estado. Los diagramas de flujo acumulado ayudan a identificar cuellos de botella específicos que hay que resolver para mejorar el rendimiento.

Otra forma de enfrentarse a los cuellos de botella es a través de los límites del trabajo en curso. Un límite del trabajo en curso restringe el número de tarjetas que puede haber en cualquier columna a la vez. Si alcanzas el límite de trabajo en curso, una herramienta como Jira aplica un tope a la columna en cuestión y el equipo acomete en masa dichos elementos para que avancen.

Los flujos de trabajo de kanban se pueden modificar en cualquier momento. Se pueden añadir elementos de trabajo nuevos al backlog, y las tarjetas existentes se pueden bloquear o eliminar según el nivel de prioridad. Además, si la capacidad del equipo cambia, el límite de trabajo en curso se puede recalibrar y los elementos de trabajo se pueden ajustar en consecuencia. En kanban, todo consiste en ser flexible.

Si quieres más información sobre las metodologías kanban, consulta ¿Qué es kanban?.

En la comunidad de la metodología ágil se considera que este debate no debería girar en torno a las herramientas. A menudo observamos que la herramienta elegida guía el marco de trabajo escogido y que este determina los principios que adopta el equipo. Nosotros creemos que la decisión debería ir en la otra dirección.

En cuanto os hayáis coordinado con los principios de scrum y estéis satisfechos con el marco de scrum, será el momento de encontrar una herramienta de scrum que os sirva. Lo mismo ocurre con kanban. Sabemos que no somos imparciales, pero dado que se trata de la herramienta de desarrollo de software número 1 que utilizan los equipos de metodología ágil, creemos que Jira tiene todo lo que necesitáis.

Con los tipos de proyectos específicos de Jira para scrum y kanban, podéis trabajar con los principios de cada marco. Además, estamos a vuestra disposición para ayudaros a dar los primeros pasos con nuestras guías sobre cómo seguir una metodología scrum con Jira y cómo seguir una metodología kanban con Jira.

Scrum y kanban son metodologías ágiles de manual. Se ha comprobado y demostrado que funcionan de una forma que resulta francamente difícil de refutar. Parafraseando otra cita recurrente, podríamos decir: "Busque, compare, y si encuentra algo mejor, cómprelo".

Ahora bien, no todo tiene por qué ser blanco o negro. Existen centenares de equipos que usan modelos híbridos influenciados tanto por scrum como por kanban. Nosotros nos propusimos ayudar a los equipos a hacerlo en Jira, razón por la cual creamos proyectos gestionados por el equipo.

Estos proyectos, como su nombre indica, permiten a los equipos elegir a su gusto las funciones de la metodología ágil que estimen oportunas, ya se trate de funciones pertenecientes a scrum, a kanban o a una mezcla de ambas metodologías. En lugar de implementar un único marco desde el primer momento, los proyectos gestionados por el equipo permiten aplicar progresivamente más y más funciones potentes a medida que vas descubriendo qué funciona para tu equipo (y qué no).

Puedes optar tranquilamente por plantillas scrum o kanban gestionadas por el equipo a sabiendas de que ambas pueden evolucionar para adaptarse a las necesidades de tu equipo.

Independientemente de lo que elijas, debes ser fiel a tu decisión durante un tiempo. Toma parte del trabajo del backlog y llévalo a cabo completamente, y luego pregúntale al equipo qué fue bien y qué fue mal. Al probar scrum y kanban y plantear estas preguntas, estarás en el camino adecuado para disfrutar de las bondades de la metodología ágil.