sábado, 27 de junio de 2009

Panel CMMI vs Ágil (2/2)

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)

Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)
¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?
alumno: ...
yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?
alumno: ...
yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos
alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)
Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis
Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?
La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.
Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?
¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.
En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.
Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?
¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Publicar un comentario en la entrada