Mira que me gusta AGILE porque es ágil (prometo subir el nivel del texto desde ahora), pero que miedo da que algo que es libre, ligero, eficiente y motivador caiga en manos de los talibanes de la cosa, los gurús soberbios y otras hierbas tan hispanas.
Miedo también de que, una vez que hemos entrado por el aro de las certificaciones personales (mea culpa) lleguen terceros a certificar si mi compañía es ágil o torpe, cuando no hay, ni espero que haya, norma al respecto (Contradictio in terminis)
Bueno, pero hoy no vengo a pelarme con mis fantasmas particulares (me refiero al ejercito infernal que prostituyo la ISO 9000, el modelo EFQM, el modelo EFR y tantos caídos, en muchos casos no en todos, en aras de diplomas hueros), sino a comenzar algunos comentarios entre el mundo agile y el mundo real, ese en el que tantas buenas teorías (dicho sea sin ironía alguna, pues estoy de acuerdo con el genio de David Martí alias @Xsfera cuando dice que “no hay nada más práctico que una buena teoría”) tropiezan de forma definitiva.
Supongo que los del agile en vena tres veces al día no han llegado leyendo hasta aquí (vade retro Satanás) desde que hayan visto algunas expresiones de los primeros párrafos, pero para los demás si es momento de empezar a comentar que algunas cosas de AGILE-SCRUM siendo buenas no se trasladan así como así fuera del mundo del desarrollo SW.
Por ejemplo, es difícil que un equipo trabaje en una empresa en un solo proyecto. No todos los proyectos en una empresa van a ser desarrollos o diseños (como los desarrollos SW) Claro que creí que Sutherland tiene razón cuando nos muestra la tabla de cómo aumentan las rectificaciones cuando se trabaja en varios proyectos. Sí, tiene razón, pero ¿Qué hagooooo….?
Pues como decía un amigo mío: “lo que no puede ser, no puede ser y además es imposible”. Es decir, tenemos que buscar un punto de adaptación y eso es, debe de ser, una de las ventajas de Agile frente a otros modelos.
Agile tiene su origen en equipos de desarrollo SW que no suelen hacer nadas más (ni nada menos) desarrollo SW, el resto de los trabajadores de la creatividad (como nos denomina Jurgen Appelo) nos vemos obligados a la multitarea. La multitarea nos viene desde un esquema de empresa múltiple y de la imposibilidad, material, de dedicar recursos en exclusiva a un proyecto, no tanto por falta de los mismo sino porque las secuencias no siempre lo permiten, es decir, porque hay dependencias externas que condicionan el desarrollo…
Ya oigo las tumbas revolverse… ¡El equipo agile es pluridisciplinar y contiene todas las competencias necesarias! , si y no, en muchas ocasiones voy a depender de proveedores externos, que no se van a dejar enredar en mi equipo agile, o de secuencias temporales inevitables (un vino necesita meses de fermentación, diga lo que diga el ultimo gurú agile)
La multitarea también nos viene del hecho de que no todo el mundo se siente cómodo, ni es necesariamente eficiente, en una única tarea, esto me temo, es pura humanidad, es como los irreconciliables bandos de alondras (todo de madrugada, desde la seis de la mañana) y búhos (todo de madrugada, pero después de las doce de la noche).
Y todo ello, con o sin justificación, porque nos viene impuesto, ¿Y qué hacemos?
- Realismo, el mapa no es el territorio, recuerden, asumamos la realidad para mejorarla. Lo óptimo es enemigo de lo bueno.
Regular, no es lo mismo multitarea de 7 tareas que de 3. También es bueno reducir tareas, pasar de 7 a 3, siempre es bueno, 1 será lo óptimo, pero ya se sabe. - Priorizar, no tanto las tareas, como los ítems o actividades de cada una de las tareas (esto no llega a un scrum escalado, es más sencillo)
- Utilizar la estrategia de los slack time, para los proyectos, reservemos varios espacios de tiempo cerrados (time box) para cada desarrollo o tarea ¿Por qué no trabajar los días pares en un proyecto y los impares en otro?
- Desarrolle reglas de valor, para huir la tragedia de los comunes, es decir, para evitar que cada uno (persona o unidad) barra para su casa, sin considerar los objetivos comunes de la empresa.
- En todo caso, si es usted el jefe, lidere (como facilitador) este tema lo más cerca posible, en mi experiencia es uno de los puntos más difíciles en cualquier organización moderna, con las casi inevitables organizaciones matriciales.
- Mucha retrospectiva, especialmente si está usted comenzando el camino de la agilidad, quizás incluso en plazo ultra cortos al principio. La retro es algo tan sencillo como preguntarse ¿Cómo lo estamos haciendo? ¿Qué podemos mejorar? ¿Qué deberíamos eliminar? Para mí requiere un único factor crítico: funciona solo en ausencia de miedo, por ello, primero mírese al espejo.
