Sonrisas y procesos

Sonrisas

Las personas que trabajan contentas transmiten esa alegría a los clientes. Los clientes que comparten esta experiencia placentera vuelven a comprar en el lugar. Y los empleados en ese ambiente quieren seguir en esa empresa y se ocupan de mejorar lo que hacen.

Acabo de hacer un resumen en un párrafo de Fish: Una manera probada de mejorar la moral y los resultados. Y es algo que suena muy razonable. 

Si creemos esto, el problema es  lograr que este círculo virtuoso se ponga en marcha en la organización. Quizás podemos aplicar "lo que se mide es lo que se mejora". Pero ¿que debo medir? No podemos medir "contento", necesitamos una características observable.

¿Y si medimos el porcentaje de tiempo que las personas están sonriendo?
Vean el video de la derecha a donde puede conducir esto.

Procesos

Las personas que se ocupan de mejorar acuerdan un proceso estándar, que corresponde a la forma en la que hacen el trabajo hoy. El estándar es la base a partir la cual se mejora.

Si, como organización, me interesa la mejora y quiero fomentarla, ¿cómo hago? ¿Puedo medirla? 

¿Y si medimos si existe un proceso estándar? ¿Y que existan mejoras sobre eso?

También me gustaría que lo hagan mis proveedores.

Y si como país queremos fomentar la mejora, podemos dar subsidios y beneficios impositivos para los que estén en esa situación.

La tristeza o ¿por qué vuelvo a hablar de esto?

Hey, ¿ya escribí sobre esto, por qué otra vez?

Me encontré en el último tiempo con varias situaciones en las que las mediciones que hacemos con la intención de mejorar provocan resultados no deseados. Es algo similar a lo que ocurre con los genios, como pueden leer en La pata de mono (un cuento breve y muy recomendable).

Uno de los resultados del caso de la sonrisa, es que ya no creemos en las sonrisas de los que nos atienden en los negocios. Asumimos que es forzada.

Forzar a que nos atiendan con una sonrisa no solo no sirve a esa empresa en el largo plazo, sino que la generalización del comportamiento nos ha llevado a descreer y no compartir la alegría ni siquiera en los casos auténticos de empleados contentos.

Esto también se nota desde el punto de vista de los empleados, que reaccionan con cinismo cuando se celebra un éxito individual o grupal. "¿Va aparecer tu foto como empleado del mes?"

Y en el caso de los procesos, ha llevado a que muchas personas descrean de los procesos y se revelen contra ellos. No se quiere reflejar las buenas prácticas actuales en procesos porque es "burocracia". Y si hay procesos, a pesar que fueron hechos por ellos mismos, no lo ven como una base sobre la cual mejorar, sino un objetivo a lograr y una vara contra la que se los medirá.

Y entonces, ¿tristeza nao tem fim?

No estamos condenados a la tristeza sin fin. Es un tema cultural, y así como nos metimos en esto, con el Taylorismo, podremos salir. 

Va para finalizar la moraleja "¡Cuidado con lo que deseas (y mides), porque puede cumplirse! (pero no de la manera que esperabas)"

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?

Panel CMMI vs Ágil (1/2)

Hace un mes tuve la suerte de participar en un panel organizado por Liveware sobre CMMI y Desarrollo Ágil.

Asistió mucha gente, creo que con alto porcentaje de gente de áreas de mejora de procesos, y por lo tanta bastate CMMI.

Antes del panel huvo una presentación de Jorge Boria sobre la evolución de la Ingeniería del Software, para poner en contexto la aparición de CMM/I y de Agile Software Development, explicando brevemente Scrum y XP, y relacionándolos con ideas previas. Es muy dificil hacer todo esto en 2 hs, exige un nivel de síntesis muy grande. Creo que Boria logró hacerlo bien. Algunos puntos de Scrum y XP yo los habría comentado distintos, lo que me pasa con cualquier discertante.

Luego fue el panel, muy bien moderado por Alejandra Goldin (Liveware). Sobre el panel voy a comentar mi resumen, y en otro post algunas preguntas que se hicieron e ideas que me surgieron, todo filtrado por mi subjetividad y memoria. Espero que los otros panelistas y asistentes me corrijan.

Esteban Zuttion (Liveware): planteo el enfoque que tanto el modelo CMMI como las ideas ágiles pueden ser útiles en la mejora, y que ser evaluados con cierto nivel de CMMI puede tener beneficios de negocio. Que se hace es una decisión que debe analizarse con respecto a la estrategia de la compañía y las necesidades del negocio, como algo absoluto.

Martín Salías (Southworks): comentó que las prácticas ágiles soportan los objetivos de CMMI, incluso las métricas. Se generan un montón de datos como subproducto de las prácticas ágiles (nro de build rotos, % cobertura, etc). Comentó que en algunos casos no hay métrias pero las prácticas pueden equipararse a métricas (me hubiera gustado que se explayara en esto).

Santiago Ceria (Hexacta): Si uno aplica la típica combinación ágil de Scrum + algunas prácticas de XP logra un buen cubrimiento de los Niveles 2 y 3 de CMMI, en particular Scrum con prácticas de Nivel 2 y XP con las de Nivel 3. Digamos por ejemplo que la cobertura es de un 50%. El tema es que al implementar el resto de las prácticas que pide CMMI, se deben hacer cosas que presentan incompatibilidades con los principios ágiles expresados en el Manifesto. En particular mencioné la cantidad de documentación que hay que generar, el concepto de Quality Assurance que es incompatible con el principio de “trust” y la presencia por todos lados en CMMI de cosas que llevan a una implementación de una organización jerárquica (“senior management”, “Project manager”, “Project leader”, “team leader”) que es incompatible con las estructuras horizontales auto organizadas propuestas por los métodos ágiles.

Juan Gabardini (Agilar): hablé sobre lo extraño que es ver que, partiendo de premisas parecidas (mejoras continua, Deming), se llegan a culturas a primera vista tan distintas. Me pregunto si esas diferencias culturales son compatibles en una misma organización, si una de las culturas se impondrá o si surgirá una nueva cultura que sea la síntesis de ambas. Más detalle de mis 10 min aquí.

Mariela Rodriguez (Globant): después de mi vuelo estratosférico, Mariela comentó la realidad de Globant, en la que se realizan proyectos de desarrollo ágil aún con contratos de tiempo y costo cerrado. Hay reuniones periódicas, se muestra producto y se puede agregar nueva funcionalidad ... siempre que se saque otra. Algunos puntos muy interesantes: no lo pueden hacer con todos los clientes, algunos no quieren esto de reunirse cada mes. Y por otro lado, los equipos que trabajaron agilmente no quieren trabajar de otra forma.

Viviana Rubinstein (Liveware): tomó el guante de Santiago y diferenció claramente entre la evaluación y el modelo CMMI. En su punto de vista, el modelo no tiene conflictos con el desarrollo Ágil, pero la evaluación si. Me encantó una frase: "Cuando algún evaluado empieza a quejarse sobre lo que tiene que hacer (para que la evaluación de cierto nivel) le digo: yo estoy acá porque vos me llamaste"

También refutó a Santiago sobre la obligatoriedad de algunas actividades. No puedo opinar sobre este cruce, no tengo conocimiento. Resumen: si querés ser evaluado, y si, te va a salis más caro que si no lo haces.

Finalmente Alejandra resumió nuestras ideas y rescató la cercanía de las mismas.

Fue muy interesante participar, y me dejó pensando, con los resultados que pueden verse en este post.

CMMI y Ágil - ¿Choque de civilizaciones?

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.