La agilidad sin control no vale para nada

6 11 2009

Hace unos años en España, se puso de moda un anuncio de una marca de neumáticos que decía que “la potencia sin control no sirve de nada”. Y hoy, leyendo este post de alguien que trabaja en una empresa “tradicional”, me viene a la mente de algo que vengo pensando hace ya mucho tiempo: que la agilidad sin control no sirve de nada.

Cualquiera que haya leído sobre el agilismo, se habrá empapado de sus principios básicos: colaboración de todos con todos, motivación del equipo, adaptación al cambio, buenrrollismo institucionalizado, oficinas cool, etc. Todo esto está muy bien, pero podrás llevarlo a cabo si se cumple una premisa: que exista confianza. Sólo si confías hasta las últimas consecuencias en tu equipo, en tus clientes, en la dirección de tu empresa, etc., puedes aplicar el agilismo puro sin riesgo a que ocurra una catástrofe.
Pero ¿qué ocurre si no puedo confiar en todos al 100%? ¿Y si tengo clientes que no respetan lo pactado? ¿Y si la dirección presiona de forma insostenible hasta abortar los sprints? ¿Y si tengo un equipo que no está motivado y/o no cumple con aquello a lo que se compromete? Entonces entra en juego el lado oscuro de la fuerza: el control.

¿Cómo se puede compatibilizar el control con una filosofía tan abierta y libre como el agilismo? Las propias metodologías ágiles establecen mecanismos de control, aunque muy sutiles, y a veces disfrazadas para que nadie se sienta controlado: por ejemplo el scrum diario, donde el scrum master vigila el cumplimiento de la metodología, revisa la desviación respecto a las estimaciones, hace seguimiento de los impedimentos, etc. O la demostración de fin de sprint, donde el product owner verifica si se han cumplido los hitos con los que el equipo se había comprometido al inicio del sprint. O un proceso de integración continua, que no es más que un mecanismo de control del código a través de test unitarios, análisis estático del código, pruebas de rendimiento, etc.

Además, es típico pensar que el control es un concepto de dos estados: control ferreo (procesos clásicos como CMMI, SPICE, etc). o libertad absoluta (metodologías ágiles, ambientes googleros, etc.) y esto no es del todo cierto. Es verdad que procesos formales como CMMI tienen el control metido en su propia esencia, y metodologías ágiles hacen los mismo con la confianza, pero eso no significa que no se pueda modular tu proceso para acercarlo más a tus necesidades. Por eso, una de las responsabilidades del project manager, o del responsable de mantener y establecer los procesos, es decidir qué nivel de control es necesario para llegar a buen puerto e ir adaptándolo conforme evoluciona el proyecto, el cliente, el equipo, la empresa, etc.

Más de una vez y de dos me ha ocurrido que un programador, firme defensor de los modelos ágiles, se ha ofendido cuando el scrum master ha ido a pedirle explicaciones sobre algún tema. ¡Me estás microgestionando! ¡Esto no es ser ágiles! Pues perdona pero no, ser ágiles no es sinónimo de “hago lo que me da la gana y no doy explicaciones a nadie”, sino ser un buen profesional en el que poder confiar, asumir que el objetivo último del agilismo es ofrecer mejores resultados (y no tener lámparas de lava en la oficina) y entender que el desarrollo de software es un juego de equipo y por lo tanto los aciertos y errores de cada uno afectan y deben ser conocidos por los demás.

Me encantaría que existiesen más proyectos sin ninguna necesidad de control, pero la realidad real me dice que es una utopía, hacia la que caminar, pero utopía al fin y al cabo.

Anuncios

Acciones

Information

7 responses

6 11 2009
Juan Palacio

Hola!
Me encanta la reflexión JM.

Me parece muy acertado el fondo que planteas. A bote pronto se me ocurre que posiblemente haya un cierto paralelismo entre Agilidad – Procesos / Control – Confianza / Teoría X e Y de comportamiento y gestión de personas; y por lo que apuntas al final (¡Me estás microgestionando!), la agilidad necesita no sólo confianza sino confianza y responsabilidad (¡casi nada!).

Un saludo.
Juan

8 11 2009
JM

Efectivamente, yo creo que el mensaje que se transmitió en el manifiesto ágil se ha ido tergiversando a lo largo del tiempo, y al final ha quedado en el “ágil = libertad” cuando no debería ser así.

O más probablemente los firmantes del manifiesto ágil dieron por supuesto muchas cualidades de los equipos que no siempre se cumplen (como confianza, flexibilidad, responsabilidad, multidisciplina, etc). Yo creo que en el contexto donde se gestó la agilidad, todos estos valores estaban muy interiorizados, pero en otros contextos, no es así.

Un saludo!

6 11 2009
luis carlos mera jaramillo

Que concepto tan válido y transversal a cualquier actividad, empresa, producto o servicio máxime cuando las TIC están involucradas.

9 11 2009
Carlos

Hola, viniendo del mundo host desconozco si el agile manifesto se ha tergiversado con el tiempo pero lo que si puedo garantizar es que las metodologías ágiles son perfectamente compatibles con CMMI. Hace un año el equipo al que pertenezco acreditó CMMI-Dev nivel 2 a una compañía gallega que hacían Xprogramming, y funcionó perfectamente.
La clave está en definir el ciclo de vida (iteraciones) y gestionar el proyecto como un todo (conjunto de iteraciones) + control y seguimiento del proyecto global. Es como una gestión de un proyecto de mantenimiento; planificas a medida que creces (rolling wave planning) pero controlas de forma general los aspectos centrales del proyecto (implicados, riesgos, desviaciones frente al plan original, etc.)

Saludos,
Carlos.

9 11 2009
JM

Carlos, gracias por tu experiencia.
¿Nos podías decir el nombre de esa empresa gallega?

¿Y podías hablar un poco más de eso del rolling wave planning?

Un saludo!

10 11 2009
Carlos

Hola JM, preferiría no dar el nombre de esa compañía (entiéndeme, estamos sometidos a acuerdos de confidencialidad). Si puedo decirte que es una compañía que desde sus inicios apostó por el software libre y que desde nuestro punto de vista nos ha sorprendido por sus niveles de productividad y profesionalidad; (gente joven pero con la cabeza muy bien amueblada).

Rolling wave planning es una técnica de planificación que se emplea en ocasiones cuando el proyecto a ejecutar tiene un componente alto de incertidumbre. En ese caso como supongo que comprenderéis, planificar todo el proyecto no tiene mucho sentido. Se planifican las partes que se conocen y se corrige a medida que vamos disponiendo de mayor información. Un ejemplo claro es planificar el análisis y una vez conocido el conjunto de funcionalidades a desarrollar planificar el desarrollo, las pruebas o los procesos de integración y explotación. Rolling wave planning es un término muy empleado en la comunidad PMI (project management institute).

Un saludo
Carlos.

10 11 2009
JM

Sin problema porque mantengas la confidencialidad, Carlos.

No conocía el término de Rolling Wave, pero sí su práctica.

Un saludo y gracias por tu aportación!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: