Descubra las consideraciones clave al elegir entre Scrum o Kanban, y qué hacer si no puede decidir.
El primer paso en su transformación ágil es decidir qué marco ágil funciona mejor para usted y su equipo. Ágil es un conjunto de ideales y principios que sirven como nuestra estrella del norte. Kanban y Scrum son marcos. Se basan en principios ágiles y describen cómo usted y su equipo colaboran, aprenden y hacen cosas.
Cuando decida entre Scrum y Kanban, sepa que está en buena compañía. Kanban y Scrum son dos de los marcos ágiles más populares y han demostrado su valía en miles de empresas durante casi dos décadas. Pero no consigas estrellas en tus ojos por el momento. Kanban y Scrum no son las únicas opciones. Está el proyecto de agilidad de SAFe, Scrumban, Kanplan y Atlassian.
Agile 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 proporciona una metodología para que los equipos auto organizados respondan a los cambios sin desviarse. Hoy, ágil no es una ventaja competitiva. Nadie tiene el lujo de desarrollar un producto durante años o incluso meses en una caja negra. Esto significa que es más importante que nunca hacer las cosas bien.
Kanban tiene que ver con el desarrollo y la entrega continuos, abordando un pequeño número de tareas de forma fluida y concurrente. Los equipos de Kanban usan una herramienta de planificación visual, la placa Kanban, que muestra cada proyecto (historia del usuario) en una tarjeta y mueve las tarjetas a través de columnas que representan etapas progresivas de finalización. Si su equipo tiene un flujo continuo de solicitudes de trabajo, Kanban puede ser adecuado para usted.
Scrum también divide tareas complejas en historias de usuarios y las visualiza en un flujo de trabajo. Los equipos de Scrum se comprometen a enviar software en funcionamiento al final de los intervalos establecidos, llamados sprints. Si necesita enviar valor a los clientes de forma regular, Scrum es el camino.
La agilidad es algo diferente, que progresivamente agrega más estructura cuando la necesita. Si no puede decidir entre Scrum y kanban, vaya con un proyecto de agilidad.
SCRUM |
KANBAN |
|
| Cadencia | Sprint regulares de longitud fija (es decir, 2 semanas). | Flujo continúo. |
| Metodología de lanzamiento | Al final de cada sprint si lo aprueba el Product Owner. | Entrega continua o a discreción del equipo. |
| Roles | Product Owner, Scrum master, equipo de desarrollo | Sin roles existentes. Algunos equipos requieren la ayuda de un entrenador ágil. |
| Llaves métricas | Velocidad. | Tiempo del ciclo. |
| Cambiar filosofía | Los equipos deben esforzarse por no realizar cambios en el pronóstico de sprint durante el sprint. Hacerlo compromete los aprendizajes en torno a la estimación. | El cambio puede suceder en cualquier momento.. |
Scrum: un enfoque ágil estructurado
¿El Scrum es adecuado para ti? La primera pregunta para responder es esta: ¿está todo su equipo de desarrollo comprometido solo con este equipo y su trabajo, u otros equipos y otros trabajos también?
Con Scrum, su equipo promete enviar un valioso incremento de trabajo al final de cada sprint. Si tiene desarrolladores que no pueden hacer ese compromiso, o que rutinariamente son arrastrados a otras fuentes de trabajo no relacionadas, es mejor que no haga esos compromisos y el Scrum no sea para usted. Aquí hay algunas consideraciones más:
Cadencia de Scrum
Scrum se mueve rápido, con sprints de dos a un máximo de cuatro semanas con fechas de inicio y finalización claras. El corto espacio de tiempo obliga a dividir las tareas complejas en historias más pequeñas y ayuda a su equipo a aprender rápidamente. Su pregunta es esta: ¿su equipo puede enviar código utilizable tan rápido?
Los sprints están marcados por la planificación de sprints, la revisión de sprints y las reuniones, retrospectivas y con la reunión diaria de Scrum (StandUp). Estas ceremonias de Scrum son livianas y son básicamente un requisito. Si no puede incluir cuatro reuniones más en el cronograma de su equipo, entonces no se moleste.
Metodología de lanzamiento
Durante la revisión del sprint, el equipo ve una demostración del incremento (el producto final de un sprint) y la aprueba para su lanzamiento o no. Es necesario que haya un incremento potencialmente realizable al final del sprint. No hay lanzamientos ad hoc en Scrum; el equipo lanza al final de un ciclo de sprint o no lo hace.
Scrum Roles
Scrum tiene tres roles claramente definidos.
- El Product Owner posee y gestiona la cartera de pedidos del producto, comprende los requisitos del negocio y prioriza el trabajo que debe realizar el equipo de desarrollo.
- El Scrum Master administra el tablero de Scrum y el flujo de trabajo, y ayuda al equipo a mantenerse enraizado en el marco de Scrum.
- El equipo de desarrollo completa el trabajo y demuestra la responsabilidad colectiva.
¿Quién maneja el equipo de Scrum? Bueno, nadie. Los equipos de Scrum se auto organizan y todos son iguales, a pesar de tener diferentes responsabilidades. Hay una tensión saludable entre intereses en competencia y un objetivo unificador de valor de envío para los clientes.
Llaves métricas
La velocidad -la cantidad de puntos de historia completados en un sprint- es la medida central para los equipos de Scrum. Orienta los compromisos de sprints futuros, o la cantidad de trabajo que se compromete el equipo de Scrum. Si el equipo completa un promedio de 35 puntos de historia (Velocidad = 35), no aceptará una acumulación de sprints que contenga 45 puntos.
Cambiar la filosofía
Los equipos se esfuerzan por no hacer cambios en el alcance durante un sprint. Los equipos de Scrum a veces reciben comentarios y aprenden que aquello en lo que están trabajando no es tan valioso para el cliente como pensaban. En tales casos, el alcance del sprint debería cambiar para reflejar la importancia del valor de envío para el cliente en primer lugar. Durante la retrospectiva del sprint, los equipos de Scrum deberían analizar cómo limitar el cambio en el futuro, ya que los cambios ponen en riesgo el incremento potencialmente embargable.
Kanban: Mejora continua, procesos flexibles
Si respondió «No» al Scrum, es probable que diga «Sí» a Kanban. Primero, considere el control de su equipo sobre lo que trabaja. Kanban es ideal para equipos que tienen muchas solicitudes entrantes que varían en prioridad y alcance. Mientras que los procesos Scrum requieren un alto control sobre lo que está en el alcance, Kanban, déjalo ir con el flujo. Echemos un vistazo a las mismas cinco consideraciones para ayudarlo a decidir.
Kanban Cadence
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 Kanban, pasan de una etapa del flujo de trabajo a la siguiente hasta que se marcan como Listo. Las etapas comunes del flujo de trabajo son Tarea, En progreso, En revisión, Bloqueado y Listo. Pero eso es aburrido.
La mejor parte de Kanban es crear columnas personalizadas para la forma en que trabaja su equipo. Mi equipo envía contenido, por lo que nuestras columnas (simplificadas) van desde Atrápalo, a Priorizado , a Contornos Listo , a Escritura , Diseño , Revisión técnica y Enviado .No tenemos una cadencia establecida, pero hemos aprendido que enviamos aproximadamente una pieza de contenido por semana.
Metodología de lanzamiento
En Kanban, las actualizaciones se publican cuando están listas, sin un horario 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 liberar según sea necesario sin tener que esperar un hito de lanzamiento preestablecido, como en el caso del Scrum.
Papeles Kanban
Todo el equipo es dueño de la junta de Kanban. Algunos equipos contratan a un entrenador ágil para que las cosas funcionen según sea necesario, pero, a diferencia del Scrum, no hay un solo «maestro Kanban» que mantenga todo funcionando sin problemas. Es responsabilidad colectiva de todo el equipo colaborar y entregar las tareas en el tablero.
Llaves Métricas
El tiempo de ciclo es una medida importante para los equipos de Kanban. Es la cantidad de tiempo promedio que tarda una tarea en pasar de la línea de inicio a la final. Mejorar los tiempos de ciclo indica el éxito de los equipos de Kanban.
El Diagrama de Flujo Acumulado (CFD) es otra herramienta analítica utilizada por los equipos de Kanban para comprender el número de elementos de trabajo en cada estado.CFD ayuda a identificar los 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 Work In Progress (WIP) . Un límite de WIP limita el número de tarjetas que pueden estar en cualquier «etapa» a la vez. Cuando llegue a su límite de WIP, el equipo se enjambrará en esos elementos para moverlos hacia adelante.
Cambiar la filosofía
Un flujo de trabajo Kanban puede cambiar en cualquier momento. Los nuevos elementos de trabajo pueden agregarse a la acumulación y las tarjetas existentes pueden bloquearse o eliminarse todas juntas según la priorización. Además, si la capacidad del equipo cambia, el límite de WIP se puede recalibrar y los elementos de trabajo se pueden ajustar en consecuencia. Se trata de ser flexible en Kanban.
Agilidad
Scrum y Kanban son «ágiles por los libros». Trabajan de una manera probada y verdadera que es francamente difícil de discutir. Tomando prestado de otra frase de pesca famosa, podría decir que «nadie es despedido por elegir el Scrum».
Para aquellos de nosotros que Scrum y kanban no son lo mejor, existe el proyecto de agilidad en Jira Software. En lugar de un marco que se ajuste a los principios ágiles en primer lugar, la agilidad se ajusta a usted, con barandillas incorporadas para mantenerse ágil. Usted crea su propio flujo de trabajo creando y moviendo columnas, agregando problemas en línea y personalizando su tablero.
En lugar de implementar todo el framework desde el primer día, la agilidad le permite agregar más y más funciones de gran alcance, tomando lo mejor de Scrum y kanban. Como tal, no hay dos proyectos de Agility iguales, por lo que no se puede comparar la agilidad de las manzanas con las manzanas. Lo que puedes hacer es probarlo.
Kanban vs Scrum vs Agility: ¿Qué marco elegir?
En cualquier caso, elija uno y quédese con él, al menos por un tiempo. Recomendamos ejecutar un ciclo completo de sprint si usa Scrum, o durante el tiempo que sea necesario enviar algunas tarjetas con su tablero Kanban. Luego, sostenga una retrospectiva y pregunte qué fue bien y qué salió mal.
Aquí hay algunos pensamientos de cierre:
- Elija Scrum si su equipo de desarrollo puede dedicar el 100% de su tiempo a su proyecto y es importante enviar valor a los clientes de forma regular.
- No elija Scrum si no es el mejor ajuste posible para su equipo.
- Elija Kanban si valora la flexibilidad más de lo que valora la previsibilidad y si su trabajo se correlaciona muy bien con un flujo de trabajo.
- No elijas kanban si no es lo mejor para tu equipo.
- Elige Agility si valoras los principios ágiles, pero ni Scrum ni Kanban encajan perfectamente.
Fuente: Atlassian
