Existen muchas dudas sobre cuándo debemos aplicar Scrum y cuándo Kanban en un equipo. Hay una regla, extendida en las empresas, que dice que debemos usar Scrum para hacer el Desarrollo (de un proyecto) y Kanban para el mantenimiento. O, también, usar Scrum para los evolutivos y Kanban para incidencias e imprevistos. ¿Estamos entendiendo para qué se usa Scrum y para qué Kanban?
Scrum o Kanban no van a resolver tu caos
Imagina que eres mecánico en un taller de barrio de éxito y que todo el mundo lleva sus coches a tu taller. Una mañana, comienzas arreglando el líquido de frenos de un coche que entró hace una semana y cuyo cliente se está impacientando. De pronto, aparece el hijo del dueño del taller, que necesita un cambio urgente de ruedas. Dejas lo que estás haciendo y empiezas a cambiar las ruedas. Cuando estás con el segundo, entra el coche de un cliente, está rota una pieza que habías cambiado la semana pasada y exige que te pongas a solucionarlo cuanto antes. ¿Y ahora qué?
Seguramente, acabarás con varios clientes enfadados, tu reputación por los suelos y puede que llegue a haber repercusiones penales graves si alguno de esos coches falla por culpa de un mal arreglo. Este ejemplo, por exagerado que pueda parecer, describe la realidad de muchos equipos que gestionan conocimiento, software entre ellos.
¡Cuidado! aquí Scrum o Kanban no tienen mucho que decir… ¡Estás en el Caos! En situaciones caóticas, la recomendación es tomar decisiones cuanto antes para salir de ahí. El nivel de incertidumbre es excesivo y el cambio de contexto nos hará bajar la productividad y la calidad de nuestro trabajo. Si algo necesita Scrum, Kanban y Agile para funcionar es la disciplina. Sin disciplina no tendremos estructura con la que organizarnos en un mundo complejo.
Orden dentro de caos
En Scrum, Kanban o Agile, en general, buscamos ser adaptativos, entender el problema que tenemos delante y tomar decisiones pequeñas que podamos inspeccionar y adaptar. Hay momentos para pensar y momentos para ejecutar, no se trata de ser ágil en cualquier momento o circunstancia. Un equipo que no puede frenar una petición o imposición externa difícilmente será ágil. La sumisión no es agilidad, es caos que suele llevar a situaciones desagradables de poca entrega de valor y de resultados.
Para mantener cierto orden, debemos tener preestablecidos momentos para inspeccionar y adaptar. Después, ejecutamos el trabajo y vamos tomando decisiones a medida que aprendemos, que tomamos datos, que vemos el resultado de nuestras decisiones. La forma es ordenada, pero no hay una planificación ni orden sobre lo que va a ocurrir, por eso es vital preestablecer el objetivo. ¿Por qué existe este equipo? ¿qué buscamos? ¿cómo conseguimos el éxito? ¿cómo lo medimos? Estas son preguntas clave que nos acompañarán para saber si estamos tomando buenas decisiones.
¿Por qué elegir Scrum?
Muchos equipos y empresas utilizan Scrum para “hacer proyectos”. Ya estudiamos que hay una gran diferencia entre la cultura de producto y la de proyecto. Con Scrum buscamos efectividad, es decir, hacer el producto correcto de la manera correcta (“do the right things right”).
Para poder usar Scrum, tenemos que responder a una pregunta muy importante: ¿Por qué queremos construir este Producto? o mejor dicho, ¿qué problema queremos resolver? La respuesta a estas preguntas nos darán el Product Goal, el objetivo del producto que queremos perseguir y, algo más importante, métricas sobre las que inspeccionar y adaptar.
Sin métricas de negocio y un objetivo claro sobre el que inspeccionar y adaptar, Scrum no es recomendable. Sus elementos están pensados para inspeccionar y adaptar de manera iterativa buscando resolver ese problema o reto.
Si, por el contrario, lo que tengo es un conjunto de tareas que hay que realizar en una fecha y cuyo resultado no voy a medir, Scrum no terminará de encajarte. Esto puede derivar en una lucha poco productiva que no querrás tener ni en tu equipo ni en tu organización.
Una vez establecido ese porqué, todo cobra sentido. En mitad de un Sprint, podemos introducir cambios siempre que se alineen hacia ese porqué. En una Review, nos interesará que los stakeholders o usuarios finales estén presentes para saber si estamos logrando resolver el reto que nos hemos marcado. La retrospectiva tendrá sentido usándola como medio para alcanzar objetivo que tenemos por delante.
¿Por qué elijo Kanban?
El método Kanban de David Andersson es una adaptación al mundo del conocimiento de Lean/Kanban que surgió en en Toyota. El método Kanban siempre se ha asociado a “equipos de mantenimiento”, sin una justificación de por qué se hacen las tareas y sin tener que esperar a una planificación para arrancarlas. El método Kanban busca la continuidad en la entrega, eso es cierto, pero tampoco es incompatible con Scrum.
Con el método Kanban buscamos la eficiencia de flujo, es decir, que las tareas fluyan lo mejor posible desde que entran en nuestro sistema (equipo) hasta que las terminamos. Por tanto, es vital definir el punto de entrada y salida de nuestro equipo. Estos puntos marcarán una de las métricas claves de un equipo Kanban: el Lead Time. Un equipo tratará de mejorar para que ese Lead Time se reduzca y permita la mayor cantidad de entrega de tareas.
El método Kanban utiliza la estadística para tomar decisiones. Para poder medir es importante que definamos muchos elementos de nuestro equipo: tareas que realizamos, clases de servicio, categorizaciones… Todas estas políticas de trabajo deben estar claras para que las mediciones nos aporten la mejor información posible.
El objetivo de Kanban es que el trabajo salga lo antes posible.
¿Scrum o Kanban?
Si tienes por delante un problema a resolver, tienes un trabajo muy innovador o tienes requisitos abiertos, Scrum puede ser tu aliado y es lo más recomendable. Recuerda definir métricas de valor que te alerten sobre el resultado que estáis dando.
Por el contrario, si tienes múltiples clientes solicitando trabajo, o un proyecto donde el éxito principal es una fecha comprometida, o estás prestando un servicio donde medir valor no es tan relevante, el método Kanban es la opción correcta.
Es decir, si podemos trabajar sobre un problema, Scrum y si queremos que un trabajo salga lo antes posible, Kanban. Cuidado, el método Kanban no garantiza que cumplirás tu fecha, sin embargo, si lo haces bien, te dará información realista del estado de tu equipo y de la probabilidad que tiene de llegar a esa fecha.
¿Y Waterfall?
Aprovechando que analizamos Scrum y Kanban queríamos dar la opinión sobre Waterfall o cascada. Si tienes claros los requisitos, están definidos y no van a cambiar, quizás Waterfall sea la manera correcta que deberías elegir. Por nuestra experiencia, aquellos proyectos que no se pasan de 6-8 semanas se pueden hacer en el modo cascada.
Ahora bien, si estás buscando ayudar a tu cliente de la mejor manera posible, piensa que Waterfall se centra en la fecha, pero no en el resultado.
Y tú, ¿qué método utilizas?
