Algunas contras de Kanban

Leyendo un articulo recordé un tema que me venia aquejando hace un tiempo; la falta de sentido de tiempo que genera aplicar Kanban. En mayo de este año en una de las charlas de OpenSpace de Agiles.uy propuse como tema "Kanban: Resultados" con el fin de conocer otras experiencias acerca de la aplicación de Kanban en equipos ágiles.
Algunas de las cosas de esa charla y de información que descubrí:

• Kanban parece hacer que el equipo se divida en individuos.
• La falta de objetivos claros y a corto plazo parece desmotivar a los equipos; vi este mismo padecer en más de un equipo con gente diferente.
• Necesita de un deadline fijo en el tiempo para poder medir y mejorar la velocidad de desarrollo.
• Sin embargo los miembros del equipo tienden a convertirse en puntos de una linea de ensamble y empiezan a mejorar su capacidad de producción intrínsecamente.

Algunas de las soluciones que implementamos para mejorar estas falencias fueron tomadas de Scrum:

• Daily meetings para que todo el equipo esté al tanto de lo que sucede.
• Retrospectivas luego de cada release.
• Explicitar la necesidad de pair programming en las tarjetas, esto afecta la estimación.
• A las tarjetas se les pone una estimación luego de que es analizada por el equipo con el fin de darle una idea de esfuerzo al PO y ayudar a la priorización del backlog.

Bajo el contexto de que el equipo puede cambiar así como también las prioridades se vuelve muy difícil la aplicación de Scrum, de busca una alternativa, sin perder los privilegios de Scrum, pero ganando la flexibilidad de Kanban.

Por último, algo que lei del artículo y que pensaba implementar es el hecho de tener milestones o iteraciones, donde el equipo se compromete a que si nada ajeno al equipo sucede, se sube una nueva versión con ciertos requerimientos analizados y estimados para una fecha fija. Esto debería eliminar la falta de sentido de tiempo que sufre el equipo.

Scrum y Kanban en pocos minutos

Scrum

Kanban

Cambiando las daily meetings

Hace algún tiempo leí un articulo propuesto por mi antiguo profesor Gabriel Ledesma (@gafaled) acerca una alternativa para la dinámica de las daily meetings.
En este articulo se habla de cambiar las clásicas preguntas "qué hiciste ayer y que vas a hacer hoy" a orientar la daily en base a las historias que se encuentran en el Sprint Backlog, donde el facilitador (en el caso de Scrum el SM) recorre el Sprint Backlog y pide una actualización de progreso de cada historia. De esta forma todo el equipo participa de la reunión y ninguno se aburre (y consecuentemente no se distrae).

Puesta en practica
Este articulo me vino como anillo al dedo, puesto que venia notando los síntomas que habla el articulo; entre otras cosas pasaba que cuando un miembro del equipo hablaba, el resto está mirando la hora y pocas veces se sabe en que anda el otro.
Inmediatamente a la primera aplicación de esta alternativa frente al sprint backlog el equipo empezó a participar de forma ordenada; el cual era mi principal miedo. Esto además acortó la distancia entre devs y QAs, quienes comenzaron a interactuar mucho más. Consecuentemente todo el equipo apuntaba en una misma dirección.
Luego de recorrer todas las historias, venia la pregunta "¿algún impedimento?".
Una desventaja que le encontré es que muchas veces la reunión se pasaba de los 15 minutos establecidos y eso se hizo notar en la siguiente retrospectiva, por lo cual comenzamos a limitar el tiempo que se hablaba por historia.

Resumen de la experiencia
Pros

• Todo el equipo se involucra.
• Aumenta la interacción/integración del equipo
• Crece el interés/compromiso alrededor del sprint.

Contras

• Se puede extender mucho y pasa a ser improductivo.
• Algún miembro tímido puede perder su oportunidad de hablar.

Fuente

Articulo de Gabriel Ledesma