Fui invitado por Liveware para un evento sobre CMMI y métodos ágiles (parte 1, parte 2). Después de consultar con la comunidad sobre opiniones, di varias vueltas para elegir un tema y buscar un balance entre algo picante que haga interesante el panel y mi natural postura ecléctica. Decidí hablar sobre una diferencia cultural que percibo entre los viene del campo CMMI y los que vienen de Desarrollo Ágil.
Posteo la versión larga, tuve que reducirla para que entre en 10 min.
Una comparación superficial entre empresas CMMI y Ágiles muestra grandes diferencias. Pero en ambos casos los espacio de posibles implementaciones son amplios, con intersección, y hay implementaciones que son tanto CMMI como Ágiles, como lo demuestran casos de empresas como las que estuvieron representadas en el panel.
Podemos encontrar bases comunes, como las ideas de Deming, y en el foco en la mejora continua.
Tuve la suerte de escuchar a Watt Humphrey en Santiago de Chile (SEPGLA 2007), en su presentación comentó "La clave para manejar trabajadores del conocimiento es: los trabajadores deben manejarse a sí mismos." … Lo podría haber dicho un gurú Ágil.
En el libro de Boehm “Balancing Agility and Discipline”, Boehm comenta una comunicación personal de W. H. diciendo que un equipo XP cumple con el TSP con “sólo agregar algunas métricas”. “sólo agregar algunas métricas”… después vuelvo sobre esto. Alan Cyment comentó alguna vez que lo que define a Scrum es la mejora continua, todo el resto es modificable.
Podría seguir con similitudes y puntos de contacto… pero hablemos de las diferencias.
Antes de seguir, un disclaimer. Se puede hablar de “qué es CMMI”, está el SEI para decirlo. Es más difícil con Desarrollo Ágil, no hay una fuente oficial.
Al recibir la invitación para el panel, decidí hacer un experimento, pregunté en una lista Latinoamericana que pensaban de la interacción de CMMI y Ágil. Recibí algunas respuestas negativas, pero la mayoría de los que tuvieron experiencia real con ambas formas de trabajo, dicen que se pude implementar ideas ágiles con CMMI. Sin embargo no hubo ninguna respuesta que recomendara implementar CMMI para empresas ágiles.
Esto llama la atención. ¿Cómo es posible que un modelo hecho para que las empresas mejoren no sea recomendable?
Se entendería para barreras de entrada, como SOX. Nadie espera ser más eficiente por cumplir con SOX. Es un mal necesario si quiero entrar en cierto mercado.
CMMI tiene dos caras: ser una barrera de entrada (evaluación), y por otro lado un modelo de mejora. No voy a discutir la primera parte. Hablemos de la mejora, desde varios puntos de vista.
Observo que las empresas CMMI tienen algunas características que no se encuentran en empresas ágiles:
- Mejora cuantificada: Existencia procesos y sus métricas como precondición a la mejora.
- Mejora centralizada: un grupo de mejora o un consultor externo.
- Foco en la repetibilidad y el cumplimiento de normas.
Mejora cuantificada: Los procesos en las metodologías ágiles
Un amigo empezó a trabajar en la planta de Toyota en Zárate desde el día uno. Me comentó que el layout inicial era ultra sencillo, lineal, sin paralelismos. El único objetivo: producir la primera camioneta, como sea. ¿Era eficiente? No. Pero a partir de ahí, se ponía en marcha la mejora continua. Con todo lo que sabía Toyota de fabricación, podrían haber hecho un mejor layout, no? NO. La planta es sólo un paso en la generación de valor, todo el ecosistema de autopartistas, canales de distribución, … es necesario para entregarle una camioneta al cliente, y ese ecosistema es único y cambiante. La forma óptima es que la planta local se amolde al ambiente existente y influya en el ambiente, en un proceso de continua adaptación y mejora.
Los procesos surgen como las reglas que cada equipo se impone. Son el resultado de un trabajo ordenado y de la mejora continua, no al revés.
Pero si yo mido existencia de procesos como forma de medir la madurez, promuevo que aparezcan procesos aunque no tengan valor para el equipo. Doy un ejemplo: si creemos que un cliente que va a un restaurante va a están más satisfecho si lo atienden personas que están contentas con lo que están haciendo, podría verme tentado a sugerir a los empleados que atiendan siempre con una sonrisa, pero si planteo esto como obligatorio, obtendré de los empleados una continua sonrisa vacía, que tiene un efecto contrario al esperado.
Mejora centralizada: El control y la confianza
La estructura de los programas es un reflejo de la estructura del grupo que lo hizo. No sé quien es el autor de la frase, pero creo que muchas veces es verdad. Si un equipo no está aglutinado, se tendrán un producto hecho por pedazos, cada uno de los pedazos más o menos integrado con el resto.
Creo que algo así pasa con las organizaciones. El SEI y el CMMI nacen de la relación de desconfianza institucionalizada que existe entre el DoD y sus proveedores. Esta estructura macro (dos partes involucradas, que desconfían entre si, usan un tercero “neutral”) se repite a nivel empresa (QA: valida que los procesos se cumplan) y equipo (Test: valida que lo que pidió el usuario se cumpla).
La falta de confianza está también reflejada en organizaciones fuertemente jerárquicas, en la que cada nivel “superior” comanda y controla al nivel “inferior”.
Foco en repetibilidad y cumplimiento: Cómo analizamos los problemas y cómo aprendemos
La forma CMMI de mejora tiene mucho en común con el método científico. Fijo las condiciones (proceso), planteo la hipótesis (cómo mejorar el proceso), hago el experimento, mido los resultados. ¿Es lo esperado? Si, mi hipótesis es la correcta. Paso a la próxima hipótesis. ¿Cuál es el problema?... ¿de dónde surgen las hipótesis? No es algo que el método científico resuelva.
¿Es la única forma de mejorar? ¿Cómo hacen los grupos de teatro?¿Los músicos? No parece que sepan mucho de control estadístico de procesos, por lo tanto debe haber otra cosa.
El desarrollo de software tiene un fuerte componente social. Si queremos resolver la dinámica de grupo con el método científico, me parece que no llegamos a nada.
Por otro lado, si queremos lograr aumentar la confiabilidad de un servicio, un análisis de modos de fallo, Ishikawa y otras técnicas de mejora de proceso probablemente nos ayuden mucho más que una retrospectiva en que tratemos de evaluar como nos sentimos (enojado, triste, contento) cuando se cayó el servicio y nos llamó el cliente para decir que no cumplíamos con el SLA.
Ahora la pregunta del millón, si quiero innovar, ¿me alcanza con el método científico?
Estas tensiones aparecen incluso dentro de la comunidad ágil.
¿Hay diferencias culturales?
No sé suficiente de CMMI como para asegurar que las diferencias observables en cultura son una consecuencia inevitable o, si por el contrario, es sólo un resabio indeseable de formas superadas de implementar el modelo.
Lo que si tenemos que tener en cuenta es que esa diferencia cultural suele estar presente y debemos considerarla. No sé si pueden convivir dos culturas tan diferentes en una organización. Me parece que lo más probable es que una de ellas prevalezca, absorbiendo o desplazando a la otra.
En cualquier caso creo que en el intercambio ambas culturas pueden salir enriquecidas.
