Revisitando las metodologías ágiles: XP, Scrum, Kanban y Scrumban

Llevo casi 10 años desde que empecé a trabajar en agile, recuerdo que mi primera experiencia fue cuando estaba trabajando en el sur de Francia para la empresa Amadeus. Por aquel entonces la dirección de la compañía planteó cambiar y actualizar la forma en la que los equipos de desarrollo trabajábamos, y llevar a cabo una adopción de metodologías ágiles, principalmente utilizando el framework de Scrum. En mi equipo me ofrecieron hacer la formación de Scrum Master, que duraba 3 días, después de los cuales había que hacer un examen para certificarse. Y así fue como me convertí en Scrum Master certificado..

Desde entonces he tenido la oportunidad de trabajar con Scrum en 3 compañías y 8 equipos diferentes, completando proyectos y desarrollando productos para muy diversos fines. Sin embargo, me he quedado con una sensación agridulce. Por un lado, creo que la idea de Scrum de descomponer el trabajo en pequeñas iteraciones y liberar versiones frecuentemente para que los clientes lo prueben y den feedback, nos ha aportado mucho. Pero por otro lado, en bastantes ocasiones he visto como la productividad de los equipos se iba degradando, y no he sentido que el framework nos diese las herramientas para encauzar la situación. Es más, muchas veces su naturaleza altamente prescriptiva se me hacía algo rígida para resolver nuestros problemas.

En estos últimos años también he trabajado con equipos que usaban Kanban para las operaciones y Scrumban para el desarrollo, pero al igual que con Scrum, no he tenido la sensación de que nos estuviesen aportando todo el valor que esperábamos.

Es por estos motivos por los que me he planteado revisitar los frameworks y metodologías ágiles más comunes para tratar de entender 1) cuál es la filosofía e ideas claves detrás de cada uno de ellos y 2) cuales han sido las posibles deficiencias o fallos cometidos al implementarlos en nuestros equipos. Pero quiero anticipar que este post no pretende ser completo en la descripción de las diferentes metodologías y sus problemas, sino más bien un compendio de ideas y experiencias que sirva como punto de partida para explorar más en detalle la metodología que nos interese. Para lo cual las referencias al final del post son muy recomendables.

Me he centrado en 4 herramientas, metodologías o frameworks ágiles: Extreme Programming, Scrum, Kanban y Scrumban, por ser los más conocidos en la industria del software. Pero antes de nada me gustaría empezar por el principio: el agile manifesto.

Agile Manifesto

Surge el fin de semana del 11 al 13 de Febrero de 2001, en el que un grupo de ingenieros de Software entre los que estaban Martin Fowler, Robert C. Martin, Kent Beck o Jeff Sutherland, entre otros, se juntan en un resort de Ski en las montañas de Utah para hablar e intentar alcanzar un marco común que expresase como veían el desarrollo de software. Surge como respuesta contra el modelo imperante hasta la fecha, que apostaba por procesos largos y dirigidos por extensa documentación. Su objetivo principal era devolver el protagonismo a las personas, que habían sido relegadas a un segundo plano en las grandes organizaciones burocratizadas de la época. Los allí reunidos querían definir los valores y principios de un nuevo movimiento “cultural” que sirviese para crear comunidades y organizaciones donde sintieran que querían trabajar.

agilemanifesto.org

Al volver a releer el manifiesto, me vienen a la cabeza situaciones en las que aún trabajando con frameworks ágiles, no hemos sido fieles al manifiesto. Recuerdo un caso, que representa bien el valor de priorizar: “Colaboración con el cliente sobre negociación contractual”. Hace algunos años, en un proyecto que estábamos ejecutando con un equipo en Scrum, tuvimos que desarrollar una funcionalidad que había sido comprometida por contrato, aunque el cliente nos había comentado a posteriori (durante una de la reuniones semanales) que no la iba a utilizar. Aún así el equipo comercial nos pidió implementarla para no incumplir el contrato. Analizado en retrospectiva y con el manifesto delante, creo que la forma adecuada de proceder hubiera sido aplicar los principios ágiles también durante la redacción del contrato. Se podrían seguir incluyendo las funcionalidades en el contrato, pero añadiendo una cláusula donde se pudiesen cambiar esas funcionalidades por otras (de coste similar) previo acuerdo de ambas partes.

Este es solo un ejemplo de cómo la filosofía ágil va mucho más allá de la organización del trabajo en equipo y supone un cambio de mentalidad y forma de trabajo para toda la organización. Por eso cuando una empresa quiere llevar a cabo una transformación agile tiene que entender que supondrá un cambio de cultura y de trabajar en muchos de sus departamentos, no solo en los equipos de desarrollo. Desde este enfoque es fácil ver que pagar un curso de Scrum Master a los desarrolladores difícilmente sea suficiente para llevar a cabo esta transformación agile en toda la empresa.

Otro punto que parece interesante mencionar es el que dice “(valoramos) Individuos e interacciones sobre procesos y herramientas”. Pues tengo la sensación que muchas veces se siguen los frameworks y metodologías ágiles de una forma mecánica, marcando casillas en un checklist, ignorando que deben ser herramientas al servicio de las personas y no al revés.

No quiero extenderme mucho más en este punto, pero os recomiendo que visitéis la página del manifiesto y lo leais con atención. Estoy seguro que os servirá de espejo para ver cómo estáis trabajando con agile y ver si hay cosas en vuestra forma de trabajar actual que podéis repensar de acuerdo a los principios ágiles.

Extreme Programming

Es una filosofía de desarrollo de software desarrollada por Kent Beck a finales de los 90, y que se hace pública en 1999 con su libro Extreme Programming Explained. Podríamos decir que sirve para inspirar (junto a otras metodologías existentes) el agile manifesto que desencadena el movimiento agile. El autor dice que elige el adjetivo extreme porque piensa que para desarrollar software de calidad hay que llevar las prácticas de programación al extremo o a su expresión más pura. Una de estas prácticas que prescribe es la de pair programming que según él se debería utilizar para programar todo el código de producción (lo cual a mi personalmente me parece bastante extremo).

Beck dice que XP es un intento de reconciliar la humanidad y la productividad en la práctica del desarrollo de software. Y expresa que ha comprobado que cuanto más humanamente se trata a sí mismo y a los demás, más productivos se vuelven. Aboga por aceptar que los programadores somos personas en un negocio entre personas. Huyendo de las ideas imperantes en las organizaciones, que trataban a los desarrolladores como piezas de un complejo engranaje desprovistas de humanidad.

La filosofía XP introduce una serie de valores, principios y prácticas recomendadas para el desarrollo de software. Y muchas ideas nuevas y contrapuestas a los procesos reinantes en aquella época, principalmente Waterfall, entre algunas de las más importantes están trabajar en pequeñas iteraciones o escuchar feedback del cliente frecuentemente durante el desarrollo. También recomienda que los desarrolladores programen la mayor parte del tiempo en parejas (pair programming) o comenzar el desarrollo por los tests (tests first). Además introduce conceptos como la integración continúa o los builds de 10 minutos (estamos hablando de 1999), que se han adoptado como estándares en la industria.

Ron Jeffries — The Circle of Life: XP Practices

Estas prácticas y principios, se fundamentan sobre los valores de comunicación, feedback, simplicidad, valentía (courage es la palabra en inglés) y respeto. Los dos últimos valores se centran en el individuo, por un lado se comenta que hay que tener la valentía (courage) de hacer un buen trabajo, buscar el éxito y lidiar con las consecuencias (es lo que Beck también describe como extremo o extreme). Y por otro lado los individuos de un equipo tienen que tener suficiente respeto mútuo con todos los stakeholders, y la apertura para probar nuevas formas de trabajar si es la voluntad del equipo.

Una idea importante es que las prácticas tienen que estar fundamentadas en los principios y los valores. Hay que entender el porqué seguimos una práctica, si el motivo es porque nos viene impuesto por los managers entonces se vuelven tediosas y propensas a no realizarse correctamente o evitarse. Personalmente creo que la persona que introduce las prácticas debe explicar la motivación de usar esa práctica a los nuevos integrantes del equipo, para luego hacer seguimiento de la adopción de las prácticas y poner énfasis en el valor obtenido cuando los nuevos integrantes comienzan a usarla. Es cuando usamos y vemos de primera mano el valor que nos da una práctica cuando tenemos la información necesaria para aceptarla e integrarla en nuestra forma de trabajar.

Otro punto importante, es entender realmente las prácticas y lo que nos aportan. De este modo evitamos implementar la práctica de forma incompleta o sustituirla por una que parece similar pero no lo es. Esto pasa, por ejemplo, cuando sustituimos Test Driven Development (TDD) por Unit Testing. En Test Driven Development se prescribe comenzar a escribir los tests, ejecutarlos para ver cómo fallan y luego ir escribiendo el código de la aplicación hasta que todos los tests pasen con éxito, y en ese momento detenernos (TDD prescribe que sólo deberíamos escribir el código necesario para pasar todos los tests). De este modo los tests se convierten en el mecanismo para detectar cuándo hemos completado la funcionalidad y podemos dejar de codificar, además de que nos obliga a diseñar la arquitectura del código para que sea testeable. Sin embargo, si solo escribimos Unit Tests al terminar de codificar la funcionalidad, el test ya no sirve para guiar la codificación de la funcionalidad, sino que su valor queda reducido a probar la funcionalidad. Además de que al hacerlo así, la funcionalidad ya está codificada, por lo que en nuestra cabeza hay una sensación de haber terminado aunque nos queda cumplir con el tedioso trámite de los unit tests.

Personalmente no he conocido a nadie que trabaje con Extreme Programming en su expresión más extensa, y tampoco tengo la impresión que hoy en día muchas empresas lo hagan (he realizado una búsqueda rápida en LinkedIn y solo aparecen 30 ofertas de trabajo en España que contienen la palabra Extreme Programming contra más de 6000 que contienen la palabra Scrum). Aún así creo que Extreme Programming es una fuente muy interesante de prácticas y principios que se pueden aplicar en cualquiera de las otras metodologías ágiles, de hecho muchas ya se utilizan cuando trabajamos en Scrum, por ejemplo. Además a diferencia de otras herramientas que funcionan más como recetas que hay que seguir, en el caso de XP se ahonda en los motivos y los porqués, lo cual nos dota de más recursos para tomar decisiones robustas que afecten a la forma en que trabajamos.

Scrum

Es uno de los framework ágiles más populares en la industria del desarrollo de software, aunque ya no es específico para software sino que se usa en diferentes industrias. Aparece en 1995 y se define como una forma de realizar trabajo en equipo, más concretamente en equipos pequeños multidisciplinares y autogestionados (self-managed), donde se trabaja en pequeñas tareas con ciclos de desarrollo cortos (llamados Sprints), al final de los cuales se obtiene un incremento de funcionalidad potencialmente entregable.

Es un proceso empírico que se fundamenta en 3 pilares: la transparencia, la inspección y la adaptación que se manifiestan de la siguiente forma: el proceso y el estado del trabajo en curso es visible para el equipo y el resto de stakeholders (principio de transparencia), esto permite inspeccionar el progreso con respecto a los objetivos marcados (principio de inspección) y adaptar/ajustar el rumbo en el caso de que se produzcan desviaciones (principio de adaptación). Esta adaptación es un resultado de la mejora contínua que deben llevar a cabo los equipos.

Scrum.org: Valores Scrum

Aunque comparte muchas de las prácticas de gestión de proyecto con XP, no prescribe ninguna práctica ni principio técnico, y por supuesto no presenta una filosofía específica de cómo ser desarrollador. Esta falta de prescripción de principios y prácticas técnicas es lo que ha causado y sigue causando muchas de las implementaciones defectuosas, en las que la deuda técnica del proyecto va creciendo y causando la merma de la productividad del equipo, como ya comentaba Martin Fowler allá por 2009, en su artículo Flaccid Agile.

El framework prescribe una serie de roles: Scrum Master, Product Owner y Developers. El Product Owner es el responsable de la visión y objetivo del producto. Además es quien define las historias de usuario y las prioriza en el backlog. El Scrum Master es el garante del proceso, el que entrena al equipo, elimina impedimentos y el que facilita, entre otras cosas. Y luego los Developers son los que planifican y ejecutan el trabajo garantizando su calidad y conformidad a los objetivos del Sprint. Uno de los problemas que me he encontrado habitualmente es que las personas que cubren los roles de Product Owner y Scrum Master tienen otras responsabilidades ajenas al Scrum, lo cual provoca que muchas veces se conviertan en cuellos de botella que impactan la productividad del equipo. Un caso típico es un Product Owner que por falta de tiempo no define los criterios de aceptación en las historias de usuario, causando que los desarrolladores tenga que revisitar historias de usuario ya cerradas para completarlas, con la consecuente frustración de los clientes y los propios desarrolladores.

Otro problema habitual es la falta de un definition of done o su no cumplimiento. El definition of done son unos criterios generales que tiene que cumplir una tarea para poder cerrarse. Por ejemplo: tener hecha una code review por 2 personas, haber añadido/modificado nuevos unit tests y haber mergeado las ramas de código en la rama de integración. Por mi experiencia personal, el definition of done es algo que tiene que venir de los desarrolladores. Es importante que al menos un desarrollador en el equipo (idealmente más) entienda la necesidad y el valor que aporta. Si el definition of done viene definido por el manager, pero dentro del equipo no hay convencimiento de su valor, lo más probable es que a la primera de cambio se ignore y caiga en desuso.

Entre las ceremonias que prescribe el framework una de las más largas es el Sprint Planning que tiene como objetivo que el equipo revise las historias de usuario priorizadas por el product owner, las estime y las asigne hasta completar su capacidad para ese Sprint. Sin duda la tarea más larga es la estimación de las historias de usuario, en las que todo el equipo habla acerca de cómo descomponer la historia en subtareas y se discuten aspectos técnicos y de implementación para luego estimar en story points. En ocasiones he visto como una sola historia de usuario ha tardado una hora en estimarse. En un equipo de 8 personas, esto son 8 horas solo para estimar una historia. Es cierto que el ejercicio de estimar minuciosamente en equipo, permite comenzar a diseñar cómo se va a implementar la historia y tener el input de varias personas lo cual proporciona nuevos puntos de vista y permite anticipar cuestiones y potenciales problemas, pero desde mi punto de vista sale demasiado caro. Por no hablar de que muchas veces,solo intervienen 2 o 3 personas, mientras que el resto permanecen callados y muchas veces se desconectan, lo cual suele desmotivar.

En mi opinión, Scrum puede ser un framework interesante a considerar en equipos que comienzan a desarrollar un nuevo proyecto/producto, y que no tienen ya una forma eficiente de trabajar. Pero desde el principio hay que definir unas prácticas técnicas que todo el equipo entienda y siga, siendo muy conscientes de que la deuda técnica estará siempre al acecho. También pondría especial énfasis en visualizar el flujo de trabajo, utilizando un tablero Kanban (si puede ser físico mejor y sino Jira ya incorpora un tablero en los proyectos de Scrum también), para saber minuto a minuto cómo va el trabajo y detectar los bloqueos tan pronto se produzcan. Y si la productividad no es la esperada o merma con el tiempo, consideraría introducir más elementos de Kanban y Scrumban.

Kanban

Es un método lean para la mejora del proceso de trabajo que está basado en el Toyota Production System. Muchas veces es malinterpretado y es entendido como un método para la organización del trabajo dejando fuera justamente su esencia, que es la parte de mejora de procesos.

Se basa en las ideas de Lean Manufacturing que abogan por producir just-in-time y reducir el waste (desperdicio). Se considera desperdicio la sobreproducción y los defectos. Para evitar la sobreproducción se limita el work-in-progress en las diferentes etapas del proceso ajustándose estos para asegurar que la etapa más costosa está siempre funcionando al máximo de su capacidad, de este modo se consigue la máxima productividad (está basado en la Teoría de las restricciones). Para asegurar la calidad, se incluyen procesos de validación y control de calidad en el propio proceso productivo. En el caso de Toyota se permitió que cualquier operario en la cadena de producción pudiese detener la producción si detectaba algún problema, lo cual supuso un cambio radical en cómo venían operándose las fábricas y un empoderamiento de los trabajadores.

A diferencia de Scrum, que es altamente prescriptivo, Kanban es bastante minimalista y sólo prescribe unas pocas prácticas, dejando flexibilidad para que cada equipo encuentre su forma óptima de trabajar en su contexto. Entre sus prácticas principales están: la utilización de un tablero para visualizar el trabajo, con columnas para representar las etapas por los que pasa una tarea y con límites explícitos de work-in-progress (WIP) para cada paso. Se recomienda que el muro sea físico, hoy en día esto es difícil.. pero si el equipo está físicamente en el mismo espacio, creo que es interesante porque se crea un espacio de reunión y socialización, donde ver el flujo de trabajo y hablar sobre él, lo cual con un muro virtual no es igual. Aunque si no hay más remedio, se puede hacer así también.

Son comunes implementaciones incompletas de Kanban, como por ejemplo utilizar un tablero para organizar el trabajo, pero sin definir límites de WIP o no definir explícitamente las políticas de validación para las diferentes etapas. Algunas de las herramientas disponibles en el mercado, como Jira, no ayudan, puesto que por defecto no se establecen límites de WIP al crear un nuevo proyecto Kanban (hay que hacerlo por configuración). Esto impide obtener el verdadero valor de la herramienta para detectar los cuellos de botella y mejorar el proceso.

A continuación os comparto un ejemplo de tablero para una empresa de fotografía a la que he ayudado a implementar Kanban. Las tarjetas superiores son las políticas de proceso, que son explícitas, lo cual permite que todo el equipo siga el proceso sin tener que tirar de memoria. Además permite que los nuevos sepan cómo es proceso y todo esté en el muro.

Ejemplo de Tablero Kanban. Utilizado en empresa de fotografía

La idea principal de Kanban es visualizar el trabajo y limitar el work-in-progress con el objetivo de detectar problemas y bloqueos tan pronto como se produzcan, analizar las causas de raíz y ponerles solución. Y repetir, para mejorar el proceso iterativamente.

A diferencia de Scrum que es un push system donde las tareas se “empujan” en el Sprint Backlog y son asignadas a un miembro del equipo durante el Spring planning, Kanban es un pull system en el que las tareas están en el backlog sin asignarse y el equipo las va cogiendo según tienen capacidad y siempre respetando los límites de WIP. Esto además permite liberar al manager de tener que asignar la tareas a cada persona. En el caso de la empresa de fotografía que comentaba antes, el manager me comentó que ya no tiene que ir puesto por puesto repartiendo tareas, sino que son los miembros del equipo los que van al muro y cogen tareas cuando están disponibles. Es la idea de Kanban: “Gestionar el flujo de trabajo, no a los trabajadores”.

La concepción de que es un método solo para equipos de operaciones y mantenimiento, no se corresponde con la realidad. Por ejemplo en Microsoft tienen múltiples equipos de desarrollo de productos como Xbox y Windows trabajando con Kanban. Muchos de estos equipos hacen la transición desde Scrum porque ven como el exceso de ceremonias del framework les produce una merma de la productividad (como cuenta Eric Brechner en su libro, ver en referencias).

Scrumban

Es el más nuevo de todos y quizás el menos conocido. Es un hibrido entre Scrum y Kanban, que combina el foco en la gestión de proyectos y product delivery de Scrum con el pull system, visualización de flujo de trabajo y mejora de procesos de Kanban.

Las ceremonias y prácticas son principalmente las de Scrum, pero utilizando el tablero de Kanban donde se definen las etapas del flujo de trabajo, los límites de WIP y las políticas para validar y transicionar tareas entre etapas.

Otro de los cambios importantes con respecto a Scrum, es en la forma de hacer los plannings: en Scrum se estiman las historias de usuario individualmente (normalmente en story points), se calcula la capacidad del equipo para el Sprint y se asignan estas a los miembros del equipo hasta completar la capacidad. En Scrumban sin embargo, no es necesario estimar todas las tareas, solo hacer un cálculo aproximado de la media de tamaño de las tareas y usar el número de tareas completadas en los Sprints anteriores para rellenar el backlog. Es una diferencia sustancial ya que la estimación de historias de usuario es una tarea bastante costosa y tediosa en los equipos de Scrum (los que las habéis vivido sabréis de que os estoy hablando). Otra diferencia es que en Scrumban los plannings se hacen bajo demanda cuando se va vaciando el backlog, a diferencia de Scrum en el que estos son fijos en el tiempo, y muchas veces se realizan cuando todavía quedan muchas tareas abiertas del Sprint anterior.

La única experiencia que tengo trabajando con Scrumban fue corta y fue en un equipo que la adoptó para flexibilizar los Sprints, y celebrar las ceremonias de Scrum bajo demanda, con el objetivo de evitar hacer plannings teniendo mucho trabajo en progreso. El problema es que no adoptamos el muro Kanban ni en consecuencia la fijación de los límites de WIP, por lo que no vimos una mejora significativa de la productividad. Esto se debió a que hicimos la transición a Scrumban en un momento que estábamos desbordados de trabajo y queríamos quitar barreras de Scrum, pero nos faltó parar un poco para entender Scrumban e implementarlo correctamente.

Según el introductor de Scrumban (Corey Ladas), este es un framework de transición y que los equipos que lo adopten correctamente verán con el tiempo como muchas de las ideas de Scrum ya no les son útiles y podrán trascender el framework quedándose con el pull system de Kanban.

Personalmente, ahora que entiendo el concepto, y que he visto Kanban funcionando, si tuviera que elegir un framework para un equipo de desarrollo nuevo, que tiene que comenzar un proyecto, probablemente me decantaría por Scrumban, creo que junta lo mejor de los dos mundos: Scrum y Kanban. Además de flexibilizar alguno de los aspectos más tediosos de Scrum como son las estimaciones y los plannings. Y dar libertad al equipo para ir encontrando su propio proceso.

Conclusiones TL;DR

En este post he tratado de hacer un repaso de algunas de las ideas del movimiento agile y de sus manifestaciones en framework y metodologías. Por supuesto que no cubre todas las ideas ni conceptos, pero he intentado que pueda servir como punto de partida para revisitar las herramientas disponibles con el fin de analizar y refinar cómo las utilizamos en las empresas y equipos que trabajamos.

Estos son algunos de los puntos que considero más importantes:

Adoptar una metodología ágil requiere no solo un cambio de hábitos, sino también un cambio de cultura y de mentalidad a nivel de equipo pero también a nivel de organización. Releer los principios del agile manifesto siempre puede ser un buen punto de partida.
Es muy común encontrar implementaciones de las metodologías ágiles incompletas que reducen su efectividad, principalmente porque no se conocen completamente, y muchas veces se eliminan o malinterpretan prácticas y principios fundamentales. Cambiar la metodología de trabajo en medio de un proyecto puede ser delicado puesto que todo cambio de proceso grande, requiere de un margen de adaptación y un período de gracia en el que la productividad puede mermar temporalmente. Si lo hacemos en un proceso que ya acumula retrasos es fácil caer en la trampa de implementar solo la parte de la metodología que no impacte a la productividad inmediata.
Las formaciones y certificaciones de herramientas ágiles, pueden ayudar para familiarizarse con los frameworks y metodologías. Pero interiorizar una filosofía de trabajo nueva y cambiar la mentalidad, es un proceso más lento y que requiere de práctica, reflexión y re-estudio.
Extreme Programming va más allá de ser una metodología y se define mejor como una filosofía para programadores, que les guía en cómo ser buenos profesionales, organizarse en equipos sanos y entregar valor al cliente de forma contínua. Aunque parece que no se usa mucho actualmente, sigue siendo una excelente fuente para complementar al resto de frameworks.
Mientras que XP prescribe múltiples prácticas técnicas, Scrum, Kanban y Scrumban no lo hacen. Pero si hay algo clave, independientemente de la herramienta que seleccionemos, es que tenemos que tener bien definidos unos valores, principios y prácticas técnicas porque es la única forma de desarrollar software de calidad.
Kanban no es una forma de organizar el trabajo, es una manera de visualizar y mejorar cómo trabajamos. Lo cual requiere de una evaluación y adaptación continúa de cómo trabajamos. El outcome de Kanban es un proceso de trabajar refinado y adaptado a nuestro equipo.
A veces las herramientas y plataformas disponibles pueden llevarnos a implementaciones erróneas o incompletas. Por ejemplo, en Jira los limites de WIP (work-in-progress) no se fijan durante la creación de un proyecto Kanban, sino que se tienen que fijar a posteriori por configuración. Por ello es importante conocer las metodologías antes de implementarlas.
El muro Kanban es el lugar donde se visualiza el flujo de trabajo y donde los trabajadores van a buscar las tareas. El manager ya no tiene que asignar las tareas el mismo. Se gestiona el flujo de trabajo, no a los trabajadores.
Scrumban une la forma de trabajar en iteraciones que aporta Scrum con la mejora de procesos de Kanban. Y flexibiliza la duración de las iteraciones y la forma de estimar historias de usuario, entre otras cosas. Además de dar más libertad que Scrum para que el equipo vaya definiendo su propia forma de trabajar.

Como nota final decir que las metodologías y herramientas ágiles, como cualquier otra herramienta creada por el hombre, no son perfectas y tienen sus limitaciones que experimentamos cuando las aplicamos en el mundo real. Es en estas situaciones cuando el sentido común y volver a los valores y principios ágiles nos pueden permitir seguir avanzando. Y nunca debemos olvidar que son herramientas que deben estar al servicio de las personas y no al revés. Ya lo decía el agile manifesto, valoramos “Individuos e interacciones sobre procesos y herramientas”.