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?

6 comentarios:

Matias dijo...

Muy, pero muy bueno. En especial esta parte:

"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."

Simplemente excelente!

Sergio Villagra dijo...

Juan,

Muy bueno todo lo que posteaste.

Aunque a lo mejor no lo creas, estoy completamente de acuerdo con vos :-)

La tan mentada "revolución japonesa" no fue obra de Deming ni de Juran. Fue el trabajo de Ohno el que realmente los sacó adelante. El problema es que los americanos recién lo terminaron de entender hace relativamente poco. Estaban convencidos que lo que había ayudado a Japón era el control estadístico de procesos. Como ya sabemos, fue en realidad la combinación de Kanban, JIT, los círculos de calidad, etc.ideados por Ohno y compañía.

CMMI parte de la base de que un proceso estadísticamente controlado es deseable, y es ahí en donde arranca el problema. ¿Hace falta?

El mismo problema tienen todos los demás modelos y estándares que andan dando vueltas por ahí, desde ISO-9001 hasta BPMM.

Una cuestión adicional es la poca visión que tiene el management. Muchos persiguen la certificación, no la mejora. Las veces que he intentado poner a ésta por encima de la primera se me ha hecho muy cuesta arriba.

De todas formas, en todo esto subyace un tema cultural muy fuerte y difícil de cambiar: el de la pirámide. En un librito muy bueno llamado "Pensar al Revés", el autor cita a un empresario japonés. Más o menos dice lo siguiente:
"...Uds. van a perder porque están convencidos de que las organizaciones rentables y competitivas son aquellas en las cuales están por un lado los que piensan -en lo alto- y por el otro los que ejecutan -los de abajo-..."
Probablemente, cambiar la manera en la cual tratan a sus colaboradores sea uno de los desafíos más grandes que tienen los managers.

Sorry por lo largo del comentario!

Juan Gabardini dijo...

Gracias Matías y Sergio.

Sergio, ¿quién es el padre de la criatura? ¿Dónde arranca todo?

Definitivamente Ohno hizo un gran aporte. Pero siempre se construye sobre lo existente. Te dejo una cita de Shingo que posteo Stuart Charlton,

"In 1931, I ran across a translation of Taylor's book [Principles of Scientific Management] in a neighborhood bookstore. Thumbing through it, I found a most unusual statement. "Inexpensive goods," it said, "can be produced even when workers are paid high wages." The apparent impossibility of such a proposition aroused my suspicions, and as I continued to leaf through the book, I saw that Taylor claimed the feat was possible if efficiency was raised to a high level. For me, this argument was utterly novel, so I bought the book and did not sleep until I had read it from cover to cover. At that point I resolved to devote my life to scientific management." -- Sheigo Shingo (from the book, The Sayings of Sheigo Shingo)

Podés usar la cita en tu libro ;)

Sergio Villagra dijo...

Gracias, Juan! Voy a usar la cita...

Coincido con vos. Todo tiene que ver con todo. Shingo fue otro de los importantes.

Lo que me asusta un poco es la siguiente relación de hechos:

1) Éxito de Japón -> Según Deming, debido al uso del control estadístico.

2) Éxito en la manufactura-> Control estadístico -> Usemos lo mismo en el software (Humphrey)-> SW-CMM -> CMMI

3) Éxito de Japón (entendido en los albores del siglo XXI)-> Ohnismo, Shingo, TPS, etc.

En qué quedamos? Seguro que un papel importante habrá tenido el control estadístico, pero por lo que estoy leyendo no fue un elemento "central". En ese caso, los fundamentos de CMMI tiemblan un poco...¿Es una solución incorrecta (o al menos, mejorable) a un problema no del todo entendido?

¿Qué opinás?¿Fue el control estadístico un componente esencial del milagro japonés, como nos vendieron los gurúes en los ochenta?

Un abrazo,
Sergio
PD: Capaz que ya viste esto alguna vez http://www.youtube.com/watch?v=kq-8WblMKMw (es un fragmento del famoso documental de la NBC, If Japan can, why can't we?

Juan Gabardini dijo...

No conozco suficiente (experiencia o lectura) de CMMI como para discutir tu cadena de razonamiento.
Si creo que se ha puesto mucho énfasis en el control estadístico, incluso para actividades en las que creo no es aplicable (casos de Artful Making). Pero en IT y a veces en software pueden haber situaciones en las que aplique el control estadístico (Industrial Making), y por otro lado, muchas veces el software es sólo una parte del producto, y el producto se produce con Industrial Making.

Por último, creo que Deming es más que el control estadístico. Los pincipios, por ejemplo, me parecen muy buenos.

Sergio Villagra dijo...

Gracias por tus comentarios, Juan!

Coincido con lo de Deming. Solamente simplificaba un poco.

Nos vemos!