Desde hace tiempo he estado pensando acerca de qué es mejor, Kanban o Scrum, y no he podido decidirme así que decidí escribir un artículo donde planteo porque me gusta cada uno. Antes que nada creo que es pertinente dar una introducción a cada uno.
Scrum en un minuto
Scrum busca regresarnos a aquellos tiempos en que las empresas eran pequeñas, los proyectos y equipos eran pequeños, y la comunicación era sencilla. Lo mejor de todo es que eramos eficientes.
Viéndolo de forma simplista, en Scrum lo que se hace es dividir un proyecto grande en proyectos pequeños organizados en base a iteraciones con duración fija (timebox) llamadas sprints. Los equipos son pequeños y cruzados (los miembros poseen habilidades y roles complementarios). La comunicación del equipo al resto de la empresa se realiza haciendo visible el plan y estado actual. El plan es conocido como sprint backlog y el estatus se muestra en una pizarra.
Hay una persona que representa al cliente, y se le denomina Product Owner (PO). Él es responsable de priorizar los requerimientos a desarrollarse. Esta lista se conoce como el product backlog. Para facilitar la coordinación y comunicación se agregan algunas juntas breves pero necesarias: junta de planeación para cada sprint, juntas diarias de sincronización, y juntas al cierre de cada sprint para mejorar el producto y el proceso.
Kanban en un minuto
Si Scrum es sencillo, Kanban lo es más todavía. Para que un proceso pueda ser considerado Kanban, basta con que puedas visualizar tu flujo de trabajo y empatar la demanda con la capacidad.
Kanban significa “letrero” en japonés y es un modo de trabajo inventado por Toyota para organizar el flujo de partes en sus líneas de ensamble. En esencia, Kanban consiste en una tarjeta que se agrega a una parte que será utilizada. Una vez que la parte es consumida, se regresa la tarjeta como petición de más partes. Dado que las tarjetas son reutilizadas, y no se generan nuevas tarjetas, esto permite limitar el número de partes en stock y al mismo tiempo asegurar que se ordenan partes nuevas en cuanto se necesitan.
En el caso del desarrollo de software, Kanbanes una promesa de trabajo delimitado. Un pizarrón de Kanban para desarrollo y mantenimiento de software indica un número limitado de slots de trabajo y la tarea que está asignada a cada slot, tal como se muestra en la figura 1.
Cada equipo decide cuanto trabajo puede manejar, lo cual se indica como cuadros donde se ponen tareas. Cuando una tarea se termina, se mueve al siguiente grupo solamente si tienen cuadros disponibles. Si la tarea se queda atorada, tenemos un problema de flujo de trabajo y debemos trabajar juntos para resolverlo.
Así que mientras Scrum se enfoca en cumplir promesas, Kanban se enfoca en mantener un flujo coordinado.
Similitudes
Existen varias similitudes entre Scrum y Kanban. Entre ellas:
• Priorización clara
• Equipos autodirigidos
• Transparencia (mostrar lo que has hecho, el estatus actual y lo que sigue)
• Inspeccionar y adaptar (mejorar el producto y el proceso en base a hechos)
• Asignación de tareas tipo pull
• Buena comunicación y colaboración
La asignación tipo pull se refiere a que el equipo está “jalando” trabajo en lugar de que el líder se los “empuje”. Esto limita el trabajo a la capacidad disponible, disminuyendo el estrés.
Razones para preferir Scrum
Compromiso. Al pedir a un equipo que establezca un compromiso y dar visibilidad a éste, se obtiene un efecto de estrés positivo. También imprime cierta movitación hacia el final del sprint cuando la meta está al alcance. Después del sprint, el equipo se puede relajar y obtener energía para el siguiente sprint. Psicológicamente, es mejor saber que no estás en medio de un flujo interminable.
Estimación. Para que el equipo pueda establecer compromisos, requiere estimar. Durante la estimación se genera información valiosa que se transfiere al Product Owner mientras el equipo pregunta lo que necesita saber para poder estimar.
Historias cortas. Scrum te obliga a dividir los requerimientos (historias de usuario) de tal forma que sean lo suficientemente pequeñas para ser realizables en un sprint. Dividir los requerimientos en partes pequeñas ayuda a reducir la complejidad y aumentar la eficiencia.
Mejoras al final de cada sprint. Hacia el final de cada sprint puede haber tiempo disponible que se puede aprovechar para hacer mejoras al código, al ambiente de desarrollo o al proceso. Esto se traduce en mejoras en eficiencia al largo plazo.
Equipos cruzados. Los equipos cruzados (cross-functional) son capaces de hacer algo de principio a fin (de concepto a producto terminado) sin depender de otros, lo cual los hace más productivos. También se favorece la transferencia de conocimiento.
Es mejor para principiantes. Muchas de las prácticas usadas en Scrum se pueden usar con Kanban. Sin embargo, cuando eres nuevo en el desarrollo ágil, es mejor contar con un método que te guíe sobre cómo hacer las cosas.
Razones para preferir Kanban
Es esbelto (lean). Kanban se basa en los principios del desarrollo esbelto (lean) establecidos hace cerca de 50 años y ha demostrado ser exitoso. El trabajo es visto como un flujo continuo. No hay muchas reglas. Simplemente es una estrategia para reducir/eliminar el trabajo inútil, realizar una priorización adecuada y ajustar la demanda con la capacidad. Además de esto, se basa en los principios Lean tales como: calidad, just-intime, reducción del ciclo de desarrollo, mejora continua y minimización del desperdicio.
La mayoría de estos conceptos se pueden acomodar dentro de Scrum, pero creo que Scrum sí tiene algunos elementos que pueden llegar a ser desperdicio y por lo tanto no tendrían cabida en un enfoque esbelto.
Solo estima si te es útil. Si el Product Owner sabe lo que necesita y su único interés es que se termine lo antes posible, ¿para qué gastar tiempo en estimaciones? En Scrum las estimaciones se necesitan para que el equipo sepa qué tanto se puede comprometer a entregar en un sprint, y se pueda calcular la velocidad como métrica de desempeño del equipo. Pero si nada de esto se necesita, entonces es desperdicio. Si quieres métricas de velocidad, puedes contar el número de historias hechas por semana o mes. Y ya que estamos hablando de métricas, ¿por qué no medir algo que le interese al cliente? Por ejemplo, el tiempo que toma desde que un cliente pide algo hasta que lo obtiene.
Tamaño adecuado de las historias. En Scrum estás obligado a dividir las historias de tal forma que sean suficientemente pequeñas para caber en un sprint. En algunos casos esto puede ser complicado e incluso contraproducente ya que terminas con pseudohistorias que no agregan valor significativo al cliente. En Kanban no hay restricciones sobre el tamaño de una historia, y en aquellos casos donde es difícil dividir una historia puedes dedicarte a implementarla en lugar de romperte la cabeza tratando de dividirla.
Flujo constante. En Scrum, cuando el equipo termina las tareas asignadas a un sprint, se relaja demasiado y eso puede ser un desperdicio. Kanban se trata de establecer un flujo sin estrés pero con alto rendimiento continuo.
Funciona mejor para soporte. Los equipos de soporte y operación continuamente reciben requerimientos no planeados. En este contexto los compromisos de un sprint de Scrum pierden sentido. En Kanban es más fácil recalcular prioridades y reasignar tareas sobre la marcha que en Scrum.
La simplicidad da libertad. Kanban es simple y con pocas restricciones, lo cual te da la libertad para personalizar tu proceso y adoptar las prácticas que tengan sentido. Dichas mejoras se pueden decidir durante juntas periódicas de retrospección.
Conclusión
Todavía no puedo decidirme por Kanban o Scrum. Mi conclusión, para variar, es que depende de la situación. Evalúa cual de estas opciones tiene más sentido para el tipo de proyectos en que trabajas. En un ambiente reacio al cambio, tal vez sea más fácil implantar Kanban, mientras que Scrum se presta más para situaciones donde se va a establecer un proceso desde cero. Sea cual sea la decisión que tomes, recuerda que lo importante es hacer lo que de mayor valor a tus clientes.
Acerca del Autor
Tomas Björkholm trabaja en Crisp en Estocolmo, Suecia. Se dedica a ayudar organizaciones a ser más eficientes por medio de la aplicación de métodos ágiles y esbeltos. tomas.bjorkholm@crisp.se
- Log in to post comments