El método Lean Startup

Se empieza a trabajar en el proyecto A. D y E están en fase de desarrollo. F espera validación.
Pendientes
En curso
Acabados
Validados
G
D
F
H
I
B
C
Se ha validado F. D y E esperan validación. G, H y I son nuevas tareas que esperan ser llevadas a cabo. B y C se están
creando. A finaliza la fase de desarrollo.
E
A
Pendientes
En curso
Acabados
Validados
G →
D
F
H →
B →
E
I →
C →
B y C se han completado, pero bajo el sistema kanban no pueden avanzar hacia el siguiente cubo para su validación hasta
que A, D y E hayan sido validados. No se puede empezar el trabajo en H e I hasta que no haya espacio en los cubos
siguientes.
A
He implementado este sistema varias veces, y el resultado inicial es siempre frustrante: cada cubo se rellena,
empezando por el cubo de «validados» y avanzando hacia el de «acabados», hasta que no se puede empezar
otra tarea. Los equipos que están acostumbrados a medir su productividad de forma muy estrecha, a través del
número de historias que entregan, se sienten atascados. La única manera de empezar a trabajar con nuevos
elementos es investigar algunas de las historias que están hechas pero no validadas. Esto a menudo requiere
esfuerzos no relacionados con la ingeniería: hablar con los consumidores, analizar los datos de los split-test, etc.
Pronto todo el mundo se adapta al nuevo sistema. El progreso ocurre de golpe y empieza desde el principio.
Los ingenieros acaban un gran lote de trabajo, seguido de un proceso extensivo de prueba y validación. A
medida que los ingenieros buscan maneras de incrementar la productividad, empiezan a darse cuenta de que,
si incluyen el ejercicio de validación desde el principio, el equipo en su conjunto puede ser más productivo.
Por ejemplo, ¿por qué crear una nueva característica que no participa en un experimento de split-test? Puede
ahorrar tiempo a corto plazo pero después requerirá más tiempo para probarla, durante la fase de validación.
La misma lógica se aplica a una historia que el ingeniero no entiende. Bajo el viejo sistema, él o ella debería
construirlo para luego descubrir su finalidad. En el nuevo sistema, este comportamiento es claramente
contraproducente: sin una hipótesis clara, ¿cómo se puede validar una historia? Observamos este
comportamiento en IMVU. Una vez vi a un joven ingeniero enfrentarse con un ejecutivo por un cambio
relativamente menor. El ingeniero insistía en que la nueva característica se sometiera a un split-test, como
cualquier otra. Sus compañeros le apoyaban; se consideraba absolutamente obvio que todos los elementos
debían probarse de forma rutinaria, sin importar quién los hubiera puesto en marcha. (Vergonzosamente,
demasiado a menudo el ejecutivo en cuestión era yo.) Un proceso sólido sienta las bases para una cultura
saludable, donde las ideas se evalúan en función de su mérito y no del nombre del puesto de trabajo.