WIP: El eterno olvidado de los proyectos ágiles

WIP, work in Progress, proyectos ágilesgiles

El WIP o Work in Progress o los trabajos en proceso que aún no están terminados debe tener límites, si no, no se logra la agilidad.

No pocas veces me ha tocado apoyar a organizaciones que se lanzaron en su transformación organizacional ágil y no lograron los resultados que esperaban. Estas organizaciones, luego de un gran esfuerzo terminan con equipos desarrollando con Scrum apoyados por tableros Kanban y gráficos de Burndown.

Lamentablemente lo único que logran es, tristemente, demostrar que no son tan “ágiles” como esperaban, y que incluso el futuro se ve más complicado de lo imaginado.

Identifiqué que casi todas ellas cometen el mismo error: se olvidan de que andan en busca de mayor agilidad.

Terminan confiando en el medio, en este caso Scrum, dejando completamente de lado el objetivo de tener un flujo más rápido en la creación de soluciones que puedan ser utilizadas. En el camino de la transformación se olvidan de perseguir un mejor Time to Market.

Un buen tablero Kanban con seguridad nos entregará una buena visualización del trabajo. Es decir, del avance de las historias de usuario (lo que este quiere o necesita). Sin embargo, no tiene la capacidad de mostrarnos o hacernos evidentes los problemas disfuncionales propios del sistema.

Muchas de las organizaciones que me han pedido ayuda para efectivamente agilizar sus procesos se caracterizan por presentar demasiado trabajo dentro de su sistema. Sus Kanban se muestran de manera similar a lo indicado en la figura:

Kanban

Claramente se puede percibir que los equipos están trabajando simultáneamente en muchas historias de usuario. Sin embargo, la realidad es bastante distinta. Lo que realmente sucede es que se tiene mucho trabajo en curso, pero poco progreso.

El caso anterior, bastante típico por lo demás, presenta un sistema colapsado, en el cual es muy difícil predecir cuándo se concluirá el trabajo.

Volvamos al origen de todo esto: la organización persigue un flujo eficiente de sus actividades de modo de mejorar el Time to Market. Esto es el principio básico que busca Lean, además de poner al cliente al centro obviamente.

WIP o Work in Progress

Decíamos que WIP es el acrónimo de Work in Progress, es decir, los trabajos en proceso que aún no están terminados.

Recordemos un poco la ley de Little, que indica que “el promedio de tiempo que un trabajo permanece en un sistema es proporcional a la razón entre el número de trabajos en curso en el sistema y el número de trabajo concluidos”.

En términos de una fórmula la Ley de Little se expresa como:

Tiempo de ciclo

Por ejemplo, si tenemos 20 historias de usuario dentro del tablero y terminamos 5 por día, el promedio del tiempo de ciclo será de 4 días. Si buscamos, por ejemplo, reducir el tiempo de ciclo, debemos tratar de encontrar el WIP adecuado que permita la optimización de todo el sistema. Naturalmente a menor WIP, tendremos ciclos más cortos.

Ante lo anterior la respuesta aparece como obvia: asigne límites para el WIP dentro del sistema, en aquellos lugares donde requiera un impacto significativo.

Beneficios de poner límites al WIP

Como resultado de limitar el WIP:

  • Se reducirá la multitarea, facilitando la concentración del equipo.
  • El riesgo de incumplimiento de plazo se reducirá, ya que con un WIP bajo disminuye la presión al ir entregando de manera continua.
  • Se aumentará la capacidad de predecir tiempos de entrega y finalmente se reducirá el tiempo de ciclo, con lo cual mejorará el Time to Market.

Un equipo Scrum que hace un tablero Kanban con límites de WIP analizados, es la mejor representación de lo que significa un sistema de tipo pull.

 

Actualízate con el curso sobre gestión ágil de proyectos (online) de Clase Ejecutiva UC.





¿Te gustó? Inscríbete a nuestro newsletter

Artículos más recientes del autor