Kanban: Las 8 metas "realistas" que puedes alcanzar

Kanban: Las 8 metas "realistas" que puedes alcanzar

Antes de afrontar un proyecto o llevar a cabo un cambio importante en cualquier ámbito de nuestra vida es importante plantearnos por qué nos interesa afrontarlo, qué esperamos conseguir, personal o profesionalmente, tras realizar el cambio.

Este mismo razonamiento debes realizar si estás planteándote cambiar la forma de trabajo de tu departamento de desarrollo para adoptar alguna práctica ágil. Definir qué pretendes obtener en su aplicación es de vital importancia puesto que una u otra práctica tienen "prescripciones" diferentes y por tanto te llevarán a distintas metas.

En este post repasaremos las metas que David J. Anderson en [1] "promete" que podemos alcanzar a través de la aplicación del método Kanban a nuestro proceso de desarrollo de software. Mi opinión personal, después de su aplicación en equipos de desarrollo, es que sí son metas realistas. Probablemente ninguna de estas metas debieran ser fuerzas motrices de tu cambio, pero estarás de acuerdo conmigo que no te hará ningún daño alcanzarlas.

1. Optimizar el proceso existente.

De las ocho esta es la principal puesto que si están afrontando el esfuerzo (los cambios siempre tienen un coste) de cambiar la forma de trabajar de un equipo es porque te interesa mejorar esta forma de trabajo y esto es el proceso. El método Kanban es un agente facilitador que te permite optimizar gradualmente tu proceso, sin cambios disruptivos en la forma de trabajar del equipo ni duros procesos de reingeniería (algo que normalmente genera rechazo).

2. Entregar con Alta Calidad.

Kanban permite establecer claros criterios de calidad como políticas definidas del tablero. No es algo que se deba realizar en la primera semana de aplicación pero gradualmente se pueden incluir esas políticas que "obliguen" a todos los miembro del equipo, por ejemplo, a verificar que no rompemos la Build ni ningún test automatizado antes de poder poner en HECHO una tarjeta o la necesidad de mantener o bajar las alertas de análisis estático de código.

3. Mejorar la predictibilidad de nuestros tiempos de entrega.

Debes tener claro que el mero hecho de limitar el trabajo en curso (WIP) acorta los tiempos medios de entrega. Pero si además de limitar el trabajo reduzco suficientemente bien los tamaños de los trabajos y dispongo de una estimación razonable del esfuerzo de desarrollo de esos trabajos, un vistazo a la situación del tablero y a los tiempos medios de entrega (Lead Time) y de ingeniería (Cycle Time) me permitirán predecir (sin necesidad de bola de cristal) un rango de entrega suficientemente razonable.

4. Mejorar la satisfacción del equipo

Si tu equipo está muy acostumbrado al estrés, a las prisas, a los cambios de foco, notarás que el sólo hecho de limitar el trabajo y definir una serie de medidas objetivas de rendimiento mejora notablemente su satisfacción.

5. Generar “tiempo-libre” para posibilitar la innovación

Como ya comentamos en KANBAN, el origen: The Goal (Theory of Constraint) la definición de diferentes políticas, la limitación del trabajo en curso y la gestión de los cuellos de botella pueden generar tiempos "ociosos" en los miembros de tu equipo. Aprovechar este tiempo libre individual puede ser altamente beneficioso para el grupo y la organización en su conjunto si se reorienta adecuadamente (ver el ejemplo de Spotify comentado en el

...