Cuatro señales de que Agile no funciona en tu organización

En ocasiones, durante los cursos de scrum o de kanban, los alumnos me preguntan cuales son las señales que indican que Agile no funciona. Uso Agile de manera extensa aquí porque independientemente de que framework usemos, estas señales son casi generales para cualquier iniciativa ágil.

Todo el mundo está siempre ocupado

Los sistemas Agile-Lean tienen una característica muy curiosa: son ineficientes. Al poner el foco en el valor, es normal que se generen ineficiciencias a nivel local. Estas ineficiencias son resueltas por los individuos y los equipos. Así se evita que se acumulen a nivel global y se creen colas y excesos de inventario a medio hacer.

Eso hace que sea muy frecuente que haya uno, dos o tres miembros del equipo de desarrollo con poco trabajo, que se encuentren dando apoyo a otros, aprendiendo o directamente descansando. Cuando en una organización todo el mundo está muy ocupado durante el día, lo siguiente que miro es el inventario de trabajo en curso (WIP) para casi invariablmente, encontrar decenas de Product Backlog Ítems y Tickets que estan atascados en alguna fase

El día se divide en tramos de una hora

En el magnífico artículo de Paul Graham: Manager’s schedule, Maker’s schedule, se explica perfectamente por qué estructurar el día en tramos de una hora afecta tanto a la productividad de las personas involucradas en el desarrollo de Software.

Para hacer una presentación en Power Point, el manager puede dedicar una hora por la mañana y una hora por la tarde. Sin embargo, para resolver problemas que se encuentran en el dominio complejo, necesitamos esa misma hora sólamente para hacer una estructura mental de lo que pretendemos hacer. Romper a mitad de proceso significa volver a empezar desde cero.

Las organizaciones ágiles entienden esto y liberan de todas las reuniones a sus desarrolladores, dejando las mínimamente imprescindibles para mantener la transparencia, inspección y adaptación.

No se cuestionan las premisas

Tanto en organizaciones que han adoptado Scrum como marco de trabajo de referencia como aquellas que lo han hecho con Kanban, es habitual que se cuestionen las premisas desde distintos puntos de vista. Desde Scrum, es habitual que el equipo de desarollo pida al Product Owner que explique el motivo de introducir una u otra historia de usuario en el Product Backlog, los datos en los que se basa y cual es el beneficio que quiere conseguir.

En Kanban, los equipos se centran en gestionar el flujo de trabajo y adaptar los límites de trabajo en curso dependiendo de como quieran jugar con el ciclo de vida de desarrollo del software (SDLC). Entienden que si aumentamos el WIP en la fase de análisis ahora, necesitaremos planear más recursos en la fase de testing de dentro de tres semanas.

Los espacios de trabajo se diseñan por marketing

Recuerdo que hace un par de años visité las oficinas de una empresa abanderada como ágil en Madrid. Después de darme un paseo a la hora de los Daily Scrums, me senté en la terraza al sol con la persona que me acompañanaba y me preguntó: ¿Que opinas? ¿Que has visto que cambiarías?

Le dije que me había fijado en cómo los equipos no tenían espacios para hacer el Daily Scrum. Pude observar como a la hora convenida, los Scrum Masters sacaban las pizarras y las llevaban en la mano para mostrar el Sprint Backlog al equipo mientras se reunian en medio de la nada.

También le dije que si yo fuera Scrum Master, lo primero que haría sería clavar esas mismas pizarras en las preciosas paredes cubiertas de vinilos con mensajes positivos. En la oficina no había ni una sola pared o ventana que tuviera nada. El mandato: Las paredes son más importantes que entregar valor había calado.