Razones por las que puede interesar usar Kanban en vez de Scrum

He tenido parado el blog, me he cambiado de trabajo y la gestión del cambio consiguiente no me ha dejado demasiado tiempo para mis aficiones, entre ellas este blog.

Mi nueva compañía se llama Kairós Digital Solutions y me mola mucho, en un mes he aprendido más que en un año en la anterior. He pasado de planteamientos viejunos a un contexto de colaboración, compartición y valoración del talento por encima de todo.

A partir de ahora contaré experiencias de las buenas, casos de éxito y no aprendizajes sólo basados en la observación de cosas mal hechas.

En un cliente en el que hemos trabajado no tenían claro si usar Scrum o Kanban, y a partir de información que he recopilado he preparado una serie de razones por las que puede interesar trabajar con un método Kanban.

Kanban es un enfoque ágil para la gestión de proyectos, que se basa en el flujo continuo de trabajo a diferencia del desarrollo iterativo propuesto por Scrum. A continuación 10 motivos para plantearse usar Kanban en vez de Scrum:

Poder realizar entregas en cualquier momento

  • En Scrum no se pueden hacer entregas a mitad de la iteración. En Kanban se pueden hacer entregas en cualquier momento. Cuando una historia de usuario está lista, la podemos entregar. Obviamente que todo un desafío preparar al entorno de desarrollo de esta manera. Requiere que se haga un “branch por característica” en el controlador de versiones, que se hagan merge frecuentes, integración continua y pruebas. Y todo esto nos da la habilidad de entregar seguido.
  • A un PO le interesa mucho esta capacidad. Nuestros clientes se beneficiarán con esta entrega lo antes posible. Menor tiempo de espera – clientes más contentos.
  • Un detalle importante: necesitamos tener una buena suite de pruebas automatizadas, sino será muy difícil hacer entregas pequeñas con buena calidad.

Poder cambiar las prioridades en cualquier momento

  • En Scrum (usualmente) no podemos agregar historias al vuelo dentro de un sprint. O al menos no es un proceso fácil, y los equipos de desarrollo suelen resistirse a reemplazar una historia del backlog del sprint. La historia ya fue discutida, estimada, etc. La nueva historia se podría discutir de forma apresurada, perdiendo detalles y como consecuencia se podría generar un re-trabajo importante. Por lo tanto, en general las iteraciones tienen contenido fijo.
  • En Kanban, si tenemos un requerimiento urgente o una historia de usuario muy importante, la podemos agregar como primer elemento de la cola. Será tomada en cuanto haya capacidad disponible.

No hay necesidad de iterar

  • Las iteraciones sirven para descubrir rápidamente problemas reales en el proceso de desarrollo. Más aún, establecen un ritmo sustentable y varios rituales. Sin embargo, hay un punto donde el proyecto puede no necesitarlas más.
  • Lo primero que necesitamos es iterar para después fluir. El backlog ya no está tan definido, los planes cambian con frecuencia. Aprendimos a ser ágiles en general, y las iteraciones ya no ayudan tanto. Sin las iteraciones no hay necesidad de reuniones de planificación y demos. Son desperdicio. En cambio, tenemos reuniones justo-a-tiempo con las personas interesadas en cada historia de usuario.
  • Kanban establece un ritmo más complejo y puede llevar tiempo en ajustarse. De todas formas, las iteraciones brindan un ritmo estable, y puede ser un motivo por el cual mantener las iteraciones sobre el final del desarrollo.

No hay necesidad de estimar

  • En el desarrollo iterativo necesitamos predecir cuántas historias podremos completar en la próxima iteración. Incluso podemos predecir la fecha de entrega basándonos en un backlog estimado y la velocidad del equipo. Otro motivo para estimar es que el Dueño del Producto quiere saber qué tan grande son las historias. Si es muy grande, el Dueño del Producto puede decidir moverla a la siguiente entrega. Sino, puede decidir incluirla en la próxima iteración.
  • Obviamente, el desarrollo iterativo necesita de las iteraciones. Pero si dejamos de iterar, deja de ser un problema. Cuando el equipo ya tiene un ritmo en el Kanban, lo único que puede necesitar un Dueño del Producto es saber si una historia es grande, mediana o pequeña.
  • En nuestra situación, las estimaciones son un desperdicio. No perdemos tiempo estimando. Tenemos un backlog priorizado y tomamos las historias de usuario más importantes y las implementamos. En algunas situaciones podría no funcionar, pero tenemos un producto maduro y cientos de requerimientos de los clientes. No hay un campo claro de desarrollo, así que normalmente no tenemos fechas de entrega definidas. Hacemos entregas cuando está listo.

Visualización perfecta del flujo.

  • El tablero Kanban muestra una vista clara del trabajo en progreso. Visualiza el flujo y permite una planificación y seguimiento rápido.

Se ha probado Scrum y no ha funcionado.

  • Al trabajar con clientes, es recomendable usar el marco completo de Scrum de tres a seis Sprints. Después de tres a seis Sprints, una organización va a saber si Scrum va a trabajar o no trabajar para el equipo, el proyecto y el cliente. Si Scrum claramente no está funcionando en este momento (o antes), habrá que admitir que es tiempo de probar algo nuevo. En estas situaciones, Kanban es una buena alternativa.

Se ha probado Scrum y no ha satisfecho las expectativas de la organización.

  • Scrum no es para todos, ni todos los equipos de una organización tienen que usar el mismo proceso Ágil. Scrum y Agile se supone que mejoran las vidas de las personas que hacen el trabajo y mejorar su relación con el trabajo. Si los miembros del equipo y / o las partes interesadas están claramente insatisfechos con Scrum, necesitamos cambiar el proceso. Kanban es una buena alternativa porque se trata de un cambio, pero específicamente desafía a los miembros del equipo a apropiarse de la mejora de sus procesos existentes.

El equipo no es realmente un equipo.

  • Muchas veces la gente se junta y se llama un “equipo”, pero en realidad son grupos de trabajo. Entonces, ¿cómo definir un equipo? Katzenbach y Smith, los autores de “La sabiduría de los equipos”, definen un equipo como “un pequeño número de personas con habilidades complementarias que están comprometidas con un propósito común, objetivos de rendimiento y enfoque por el cual son mutuamente responsables”. En Scrum, el equipo multifuncional DEBE trabajar juntos para tener éxito. Un grupo de trabajo no tiene ese requisito. Puesto que todo es opcional en Kanban – incluso equipos – los grupos de trabajo pueden adoptar Kanban con éxito.

El trabajo es complicado, no complejo.

  • En sistemas complejos, las interacciones de los componentes y actores individuales son impredecibles y emergentes. Gran parte del trabajo en el desarrollo de nuevos productos es complejo, por lo que un marco como Scrum, que está perfectamente ajustado para manejar la complejidad, funciona bastante bien. Cuando el trabajo es complicado, es decir, las interacciones de las diferentes piezas y personas es predecible, entonces Scrum es demasiado pesado. Esta situación es común para el trabajo de proyectos de corta duración, ciertas tareas de operaciones de TI y el trabajo de mantenimiento. Kanban, que se centra en la entrega rápida de valor en altos niveles de calidad mediante la visualización del value stream, es a menudo un mejor ajuste.

La organización está buscando la optimización sobre cambios profundos

  • En su núcleo, Scrum es fundamentalmente cambiar la forma en que los miembros del equipo y los interesados interactúan entre sí, el trabajo y sus clientes. Muchas organizaciones pueden decir que quieren un cambio profundo, pero lo que realmente quieren es la optimización y una mayor eficiencia. Otras veces, los líderes que promueven el cambio no tienen mucha influencia fuera de su esfera de control. En estas situaciones, Kanban es un ajuste mejor porque el enfoque de Kanban es mejorar incrementalmente las partes de la cadena de valor dentro de la esfera de control del equipo. Las partes interesadas y los clientes no están obligados a cambiar sus comportamientos como resultado del proceso Agile del equipo.

Y ahora cada compañía debe elegir en función de sus características qué método es más adecuado, aunque también pueden crearse su propio método, why not?.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *