Imaginen si existieran perillas para manejar la capacidad (o velocidad), el tiempo de ciclo, la calidad y la predictibilidad de los proyectos, y que pudieramos configurar nuestro proceso moviendo estas perillas. "Quiero alta capacidad, tiempos de ciclo bajos, alta calidad y alta predictibilidad. Así que voy a girar estas perillas a 10, 1, 10, 10 respectivamente".
¿No sería fantástico? Desafortunadamente no existen estos controles directos. Al menos, no los conozco. Si alguno los encuentra, por favor avise.
En cambio, lo que tenemos son un grupo de controles indirectos:
- Menos personas ................... Más personas
- Pocos equipos grandes ................... Muchos equipos grandes
- Poco trabajo en progreso ................... Mucho trabajo en progreso
- Sin iteraciones ................... Iteraciones largas
- Poca planificación ................... Mucha planificación
- etc ................... etc
Scrum y Kanban son empíricos porque se espera que experimentemos con el proceso y lo personalicemos para nuestro entorno. De hecho, tenemos que experimentar. Ni Scrum ni Kanban nos dan todas las respuestas - tan sólo nos brindan un conjunto básico de restricciones para guiar nuestro propio proceso de mejora.
- Scrum dice que tenemos que formar equipos multi-disciplinarios. Entonces, ¿quién debería estar en cuál equipo? No lo sé, experimentá.
- Scrum dice que los equipos deciden cuánto entra en un sprint. Entonces, ¿cuánto trabajo debe entrar en un sprint? No lo sé, experimentá.
- Kanban dice que se debe limitar el Trabajo en Progreso. Entonces, ¿cuál es el límite? No lo sé, experimentá.
Kanban impone menos restricciones que Scrum. Esto significa que hay más parámetros en los cuales pensar, más perillas para girar. Esto puede ser tanto una ventaja como una desventaja, dependiendo del contexto. Cuando abrimos la ventana de preferencias de una aplicación, ¿preferimos tener 3 opciones para configurar, o 100 opciones? Probablemente querramos algo en el medio. Depende de cuánto necesitemos configurar y qué tan bien conozcamos la herramienta.
Entonces, supongamos que reducimos el límite de Trabajo en Progreso (WIP), basándonos en la hipótesis de que esto mejorará el proceso. Luego observamos cosas como la capacidad, el tiempo de ciclo, la calidad y los cambios en la predictibilidad. Sacamos conclusiones de estos resultados y después cambiamos algunas cosas más, mejorando continuamente nuestro proceso.
Todo esto tiene varios nombres: Kaizen (mejora continua en Lean), Inspección & Adaptación (en Scrum), Control Empírico de Procesos, o porqué no El Método Científico.
El ciclo de feedback
El elemento más crítico es el ciclo de feedback.
Cambiar algo >> Averiguar cómo salió >> Aprender >> Cambiar algo otra vez
En general queremos que los ciclos de feedback sean lo más chico posible, para poder adaptar al proceso rápidamente.
En Scrum, el ciclo de feedback básico es el sprint. Sin embargo, hay muchos más, en especial si los combinamos con XP (eXtreme Programming):
Cuando se aplica correctamente, Scrum + XP nos brindan muchos ciclos de feedback muy valiosos.
El ciclo de feedback interno, la programación de a pares, es un ciclo que dura segundos. Los defectos se encuentran y arreglan a segundos de su creación ("Che, ¿no se supone que esa variable tenga un 3?"). Este es el ciclo de feedback de "¿estamos construyendo las cosas bien?".
El ciclo de feedback externo, el sprint, nos da un ciclo de pocas semanas. Este es el ciclo de feedback de "¿estamos construyendo las cosas correctas?".
¿Y qué pasa con Kanban? Antes que nada, podemos (y probablemente debemos) poner todos estos ciclos de feedback en el proceso, usemos o no Kanban. Lo que nos da Kanban son métricas en tiempo real muy útiles:
- Tiempo de ciclo promedio. Se actualiza cada vez que un elemento llega al estado "Terminado" (o cómo se llama la columna de más a la derecha).
- Cuellos de botella. Un síntoma típico es que la Columna X está llená de elementos mientras que la Columna X+1 está vacia.
Lo bueno de las métricas en tiempo real es que podemos elegir la duración del ciclo de feedback, basándonos en qué tan seguido queremos analizar las métricas y hacer los cambios. Los ciclos de feedback largo harán que el proceso mejore con lentitud. Los ciclos de feedback cortos harán que el proceso pueda no tener tiempo para estabilizarse entre cambios, generando demoras.
De hecho, la duración del ciclo de feedback en si mismo es algo para experimentar... algo así como un meta-ciclo de feedback. Ok, y hasta acá llegué :)
