¿Confuso cuando te hablan de Kanban, Scrum y Superman?
… con cara póker, asientes “sí claro, sí… ajá… sí sí…” disimulas, mientras intentas averiguar de que te esta hablando, rezando para que cambien de tema lo antes posible o que no te pregunten nada!
Ajá! Te es familiar! y sí nos pasa a todos ya que si o si hay que pasar por el punto de partida, y por eso estamos aquí, este artículo te ayudará a tener una idea clara, entenderás las diferencias y podrás aportar creando valor.
Incluso si ya tienes más conocimiento, y aquí entenderás qué framework se adapta mejor a tu equipo. Ya que compararé los 2 marcos ágiles: Scrum y Kaban.
¡Centrémonos en nuestros 2 marcos ágiles!
¡Vamos al lío!
Definimos Scrum y Kanban
Para poder entender qué es cada uno, es mejor empezar con cada marco rápidamente y después ver qué diferencias hay entre ellos, para entenderlos mejor.
Definición de Scrum
Es un marco de trabajo que gestiona un proceso, facilitando principios, valores, artefactos, roles y eventos básicos para que, a partir de ahí, usted y su equipo puedan caminar hacia la eficacia y la mayor productividad, centrándose en las personas y su trabajo en equipo como la clave del éxito.
El enfoque Scrum es una forma ágil de gestionar un proyecto, normalmente de desarrollo de software. Siempre hay mucha confusión entre Agile y Scrum, algo es importante que sepas, no son metodologías, eso tiene que quedar claro. Agile es una filosofía y Scrum es el marco más popular hoy en día basado en la filosofía Agile.
Más sencillamente, como ejemplo, la Constitución de un país es lo que llamamos Agile, y una ley es Scrum.
Para hacerlo más fácil puedes encontrar la forma de trabajar de Scrum.
Definición de KAMBAN
Kanban es un sistema visual para gestionar el trabajo a medida que avanza en un proceso. El objetivo de Kanban es identificar los posibles cuellos de botella y solucionarlos para que el trabajo se desarrolle sin problemas.
Fácil de recordar que la palabra, “KANBAN” , originario del país del sol naciente, Japón.
¿Qué significa en japonés? Significa señal visual o tarjeta, vamos nuestras notitas de toda la vida o Post it.
Por supuesto, la sociedad japonesa puede no ser tan simple, pero cuando se trata de crear métodos de trabajo y organización, es uno de los mejores. La clave de Kanban son los signos visuales o tarjetas, en nuestros tiempos, pronto se convirtieron en los famosos post-it (que tanto caracterizan a Scrum) y muy poco a poco, “gracias” a cierto virus, que nos ha empujado a acelerar el uso de los programas que simulan post-it o tarjetas.
Los trabajadores de línea de Toyota utilizaban un Kanban para marcar los pasos de su proceso de fabricación. La naturaleza altamente visual de Kanban permitía a los equipos transmitir eficazmente qué trabajo debía hacerse y cuándo. Además, normalizaba las señales y refinaba los ciclos, lo que permitía disminuir el desperdicio y maximizar el valor. El tablero de Kanban se compone de columnas denominadas ‘TO DO – DOING – DONE’, pero el gestor limita el número de trabajos en curso, WIP, permitiendo detectar cuellos de botella.
Una vez adaptado a la ingeniería de software, Kanban significa que hay un límite en la cantidad de trabajo que el equipo tiene en progreso a la vez. Por lo tanto, un máximo de tarjetas/postes puede estar en la columna de “hacer”, con el objetivo de mejorar el enfoque y disminuir el cambio de contexto.
Otro punto clave es que las necesidades del cliente es una prioridad, la actualización a través de una comunicación constante con el cliente. Todo lo que se produce supone un beneficio económico para el cliente.
Hay cuatro principios fundamentales de Kanban:
1. Visualizar el trabajo para aumentar la comunicación y la colaboración.
2. Limitar el trabajo en curso para evitar una cadena interminable de tareas abiertas no priorizadas.
3. Medir y optimizar el flujo, recoger métricas, predecir problemas futuros.
4. Buscar la mejora continua como resultado del análisis.
Qué diferencias de detalle hay entre Scrum y KanBan
La diferencia clave es que Kanban es continuo, mientras que Scrum es iterativo. Kanban es más adecuado para los equipos que tienen una gran cantidad de trabajo no planificado (problemas de soporte, correcciones de emergencia, solicitudes de características urgentes) durante el Sprint. De esta manera, en lugar de esperar hasta el final del Sprint, el equipo puede empezar a trabajar en los elementos a medida que aparecen y re-priorizar las tareas sobre la marcha.
SCRUM
| FACTOR | Scrum |
| Principios | 1. Control de proceso empírico
2. Auto – organiación 3. Colaboración 4. Priorización basado en valor 5. Time-boxing 6. Desarrollo iterativo |
| Roles específicos | Sí: SM, PO, DT |
| Iteraciones de cajas de tiempo | Sí |
| Empírico | Sí |
| Límite WIP | Sí, a nivel de Sprint |
|
Trabajo puede hacerse simultaneamente |
Sí |
| El trablero es continuamente usado | No, reinicio cada Sprint |
| Tablero puede ser reorganizado | Simple funcionamiento cruzado de equipos |
| Tirada de horarios | Sí |
| Transparencia | Sí |
| Cambio | A nivel de backlog de producto y antes o después de cada Sprint. |
| Estimación | Sí |
| Objetivo | Batch de trabajo rápido |
| Medidas | Sprint |
| Priorities | Centrarse en la predicción |
| Formación requerida | Más |
KANBAN
| FACTOR | Kanban |
| Principles | 1. Focus – reduce multitasking.
2. Decrease waste. 3. Customer needs come first (i.e. their business needs – ROI).
|
| Specific Roles | NO |
| Time boxed iteractions | No (continously Delivery) |
| Empirical | Yes |
| Limit WIP | Yes, for individual items |
| Work can be done simulatenously | Yes |
| Board is continously used | Yes, constinously used. |
| Board can be organized around | Single cross functional team or multiple specialized |
| Pull Scheduling | Yes |
| Transparency | Yes |
| Change | More flexible |
| Estimation | No |
| Objective | Individual items quickly |
| Measures | Cycle time |
| Priorities | Focus on eficient flow |
| Training required | less |
¿Cuál es el mejor Scrum o kanban?
Al comparar Scrum, Kanban, no hay un ganador definitivo. El mejor marco de trabajo depende de su equipo, su proyecto y sus objetivos. Debido a que todos son metodologías ágiles flexibles, usted podría fácilmente tomar los principios de cada uno y aplicarlos como lo considere necesario.
Es importante recordar que el verdadero Scrum es un cambio mucho más grande que Kanban. El equipo tendrá que aprender las ceremonias, los roles específicos y las iteraciones. Por otra parte, Kanban fomenta las mejoras incrementales.
Scrum puede ser el indicado si necesitas un gran cambio dentro de la organización o del equipo. Si ya tienes un marco de trabajo con el que estás contento, puedes probar con Kaban. Pero vamos a ir ahora más en detalle para entender cuando debe ser mejor elegir.
Te puede interesar nuestro artículo: ¿Qué es un Scrum Master
¿Cuándo utilizar Scrum?
- Bueno para los equipos en los que se necesitan cambios fundamentales.
- Si tus equipos luchan por dividir las características en piezas incrementales de valor para entregarlas en menos de una semana.
- La principal prioridad de tu equipo es centrarse en la previsibilidad y la productividad de los proyectos más grandes.
- Su organización/cultura exige un mayor grado de ceremonia y artefacto.
- Si estás diciendo que sí a todo este punto tu marco de trabajo es Scrum.
¿CUANDO UTILIZAR KANBAN?
- Si encuentras la siguiente lista de circunstancias, ¡Kanban es tu solución!
- Si tus equipos tienen una fuerte cultura de mejora continua y autoorganización.
- Son tus equipos altamente disciplinados con prácticas técnicas y artesanales.
- La máxima prioridad de tu equipo es optimizar la capacidad de respuesta a las necesidades del cliente.
- ¿Tus equipos luchan con la estimación o cuestionan su valor/sobrecarga?
- Bueno para equipos en los que solo se necesitan mejoras incrementales.
- Cambio constante de historias y sprint.
- No se necesitan iteraciones
- Libertad para liberar en cualquier momento
- Ya se enfatiza la mejora continua.
- El equipo no acepta bien los grandes cambios
- Necesita mejorar el flujo de trabajo
- El sistema tiene que ser fácil de entender
- Necesita mucha flexibilidad.
Veo que los equipos que tienen más éxito con Kanban encajan en dos áreas: Apoyo a los equipos de negocio – y para equipos maduros, disciplinados y auto-organizados. Están comprometidos con el proceso, entienden cómo desglosar el trabajo y están constantemente pululando para hacer las cosas.
Espero que después de este artículo, puedas entender qué framework es el más adecuado para tu equipo y tengas más clara al menos la diferencia entre ellos.
Muchas gracias por dedicar tu tiempo a leer el artículo.
Y como siempre decir,
¡SI CREES, PUEDES VOLAR, PUEDES TOCAR EL CIELO!
Especialista en Scrum
