Kaizen y Kaikaku: Dos formas de implantar proyectos ágiles

Por James Shore [ Acerca del autor ]

Hace ya casi dos años, hubo un poco de inconformidades muy evidentes con respecto de Scrum. Puede que se iniciara con un ensayo que titulé “Declive y Caída de Agile”, que se remonta a Noviembre del 2008 y que después se volvió a encender con una participación de Martin Fowler que se llamó "Scrum flácido". En InfoQ se publicó un resumen, por si desean ver algunos vínculos al respecto de todo aquel debate.

De hecho, no era mi intención atacar Scrum. Mi verdadero punto puede encontrarse en los párrafos de cierre de mi ensayo: “Es naturaleza humana sólo hacer lo que nos resulta conocido y divertido y eso es lo que ha sucedido con lo Agile”. Pero no acusé a Scrum ni a la Scrum Alliance de hacer que la situación fuese peor.



Unas cuantas personas se levantaron para defender a Scrum. Tobias Mayer, que comentaba sobre mi ensayo original, fue particularmente elocuente: “Escuchen. Scrum no es una metodología. No es un proceso. Es una infraestructura para sacar a la luz la disfunción organizacional. En realidad, Scrum no hace NADA. La gente hace las cosas. La infraestructura de Scrum, si se enseña de manera efectiva, le da a las personas la oportunidad de despertar y conocerse de una buena vez. Si no lo hacen, se quedarán sin negocio. Bien. Los otros sabrán cómo hacer cambios rápidamente y, es muy probable, llamarán a buenos consultores en ingeniería. Olvídense del "Agile", pues sólo son buenas prácticas de software, han existido mucho antes de que la etiqueta de “Agile” se les aplicara para denominarlas de manera colectiva. Además de ser un manifiesto, Agile en realidad no es algo en concreto”.

Y esto es absolutamente correcto.

Así que, ¿qué está sucediendo? ¿Por qué hay tantas implementaciones Agile que están fallando?

Kaizen

Kaizen significa "mejoramiento continuo". Viene del japonés, y está asociado con lo que conocemos como manufactura esbelta [Lean], así que se trata de una palabra que está de moda en estos momentos [y lleva décadas en vigor dentro de otros rubros. N. del E.]. Pero la mejora continua ha sido una parte principal de los procesos Agiles desde que se les concibió. Incluso se trata del 12° principio en el manifiesto: "en intervalos regulares, el equipo reflexiona acerca de cómo hacerse más efectivo, luego afina y ajusta su conducta en consecuencia".

Un equipo Agile debe observar de manera continua qué es lo que está haciendo y esforzarse por mejorar. Los métodos de Agile apoyan esta idea al exponer problemas. Diana Larsen me lo describió de esta forma (y creo que estaba citando a Esther Derby): "Es como manejar con un parabrisas sucio. Todo está bien hasta que viras hacia donde se está poniendo el sol. Es entonces cuando no podrás ver nada. Dirás: ‘¿de dónde salió toda esta suciedad?' Pero siempre estuvo ahí —el sol no ocasionó que apareciera todo ese polvo, sólo lo hizo visible".

Así que sí, un equipo Agile debe inspeccionar y adaptarse continuamente, y lo Agile nos brinda las herramientas para hacer justo eso. Y... hay algunas cosas que, al principio, no serán visibles para los equipos.

¿El kaizen ayudará a estos equipos? Eventualmente. ¿Significa eso que debamos dejarlos colgados hasta que se sequen —esperar a que todo salga mal, catastróficamente, y entonces esperar que ellos aprendan de sus errores? Tengan en cuenta que eso es lo que estamos observando en el campo: los equipos comienzan bien, y luego tienen dificultades. Es una buena entrada monetaria para nosotros los consultores, pero preferiría que las personas no se metieran en esos problemas en absoluto.

Kaikaku

Kaikaku también viene del japonés, aunque aún no está tan en boga como kaizen (pero denle tiempo). Significa "transformación"; es cambio rápido —la introducción de enfoques completamente nuevos.

Ahora, en honor a la verdad, kaikaku es una forma de kaizen. Kaizen no necesariamente significa cambio gradual, pero es la forma más popular con la que se le asocia.

Como término de uso popular, kaikaku está en contraste al kaizen. Es un cambio rápido: contratar a un coach para que dirija a tu equipo; leer un libro e implementar las ideas tal cual están escritas; conducir un taller para mapeo del flujo de valor y hacer cambios significativos.

Donde se equivocaron

Ahora, llegamos a la parte donde varias implementaciones Agile se han equivocado —hay que nota que no fueron no todas ellas. Ciertamente, no las de ustedes. Pero muchas sí).

Hay dos maneras de que las implementaciones de Agile se desvíen y produzcan errores:

1. Primera, los equipos aplican kaizen dentro de las limitantes de sus hábitos y patrones establecidos. Hacen mejoras menores, pero se pierden u omiten todas las ideas transformativas.

2. Segunda, los equipos subestiman el costo humano del cambio. Cuando en efecto implementan cambios significativos, lo hacen de manera gradual y eventualmente se agotan.

De hecho, también existen muchas maneras más en las que las cosas pueden salir mal, entre las cuales, como mínimo, destacan la inclusión de la cultura organizacional y el compromiso gerencial, pero en este artículo yo me enfoco en cómo los equipos incluyen nuevas prácticas).

Perderse Ideas Transformativas

Jeffrey Liker lo dice en The Toyota Way: "[El gerente] dice es hora de convertirnos en un equipo. Así que todos se agrupan en la sala de conferencias para trabajar en el mejoramiento de la productividad. Lo que es probable que suceda es que los integrantes del equipo se concentrarán en reducir la cantidad de tiempo que toma desempeñar los procesos de valor agregado, el trabajo que ellos desempeñan o trabajarán en cuestiones de comodidad como ajustar la iluminación a niveles óptimos o instalar un dispensador de agua fría. Durante el proceso [de este ejemplo], los trabajadores laboran individualmente, así que es natural que sólo se concentren en sus tareas individuales".

Ahora, vamos a considerar el caso de un experto en TPS [Lean] que llega y analiza este proceso que empleamos como ejemplo. De inmediato, el experto observaría que no existe flujo y que hay una gran cantidad de desperdicio. La primera tarea para el experto en TPS podría ser mejorar el flujo y eliminar la mayor parte del inventario que se está interponiendo en la unión de las operaciones.

Para los equipos resulta muy difícil cambiar sus hábitos de trabajo. Lo intentarán y harán cambios, pero sin la exposición a nuevas ideas esos cambios será incrementales y producto de la evolución, no de una revolución. Los equipos Cascada harán cascadas menores. Los equipos CeD (centrados en documentación) mejorarán sus documentos. Las culturas orientadas a la culpa se las ingeniarán para inventar maneras más eficientes de asignar culpabilidades.

Varias de las mayores oportunidades que ofrece Agile son las ideas transformativas. Son ideas del tipo de desarrollo centrado en pruebas, equipos co-localizados e interfuncionales, participación intensiva del cliente, fases simultáneas, y una disposición de cero defectos. Estas son las ideas más extravagantes. La mayoría de los equipos mal llamados "Agile" no están llevando a cabo ninguna de estas cosas, y muy pocos las están llevando a cabo todas.

Algunas cosas no se pueden alcanzar mediante el cambio gradual.

Agotarse eventualmente

En The Art of Agile Development, Shane y yo escribimos: "La incomodidad y una particular sensación de caos son normales para cualquier equipo que esté pasando por un cambio, pero esto no lo hace menos intimidante como reto. Pueden esperar que dicha sensación caótica continúe durante dos meses, cuando menos. Dense de cuatro a nueve meses para de verdad sentirse completamente cómodos con su nuevo proceso. Sin embargo, hemos de hacerles notar que si están adoptando XP de manera incremental, esto les llevará más tiempo.

... Pueden [adoptar XP en incrementos], pero si tienen un proyecto de nueva creación, de hecho es más fácil y rápido adoptar todas las prácticas de una vez. El caos y la incertidumbre del cambio son los que hace que adoptar XO sea difícil, no las prácticas en sí mismas. Si adoptan XP de manera incremental, cada nueva práctica romperá el equilibrio por el que estarán luchando para lograrlo. De hecho, extenderán el periodo de caos e incertidumbre, haciendo que la transición sea aún más difícil".

Pueden introducir iteraciones (o Sprints) y después integración continua, y luego desarrollo con base en pruebas, y entonces diseño incremental continuo, para luego añadir clientes en las instalaciones, y a continuación un espacio de trabajo compartido, y luego programación pareada, y además...

O al menos pueden intentarlo. A los equipos les lleva años cumplir con esta listas y es agotador. No conozco de alguno que lo haya logrados todavía. ¡En serio! Ni uno —y antes de que me digan que no necesitaban todas esas cosas, déjenme decirles que ni siquiera las probaron. Eso no es kaizen; eso es rendirse.

O bien, pueden tomarse cerca de seis meses, más o menos, y hacerlo todo al mismo tiempo. El cambio gradual es menos atemorizante, pero no es ni más fácil ni más exitoso.

Comiencen con Kaikaku

He trabajado con muchos equipos Agile y he conversado con aún más integrantes de este tipo de equipos. El argumento final es este: los equipos Agile de alto desempeño inician con kaikaku. Comienzan con algo probado, dicen que van a dar su mejor esfurzo y entonces... en realidad lo hacen.

Luego continúan con kaizen, inspeccionando y adaptándose de manera continua, preguntando porqué es que algo que no les gustó funciona y porqué algo que sí les gustaba no funciona. Nunca acaba de aprender o mejorar. Pero esto comienza con una transformación.

Para lograr un equipo Agile de alto desempeño, comiencen con kaikaku. También necesitarán otras cosas, como el compromiso de parte de los directivos y apoyo desde la base. Estas cosas están más allá del alcance de este pequeño ensayo. Pero una vez que las condiciones estén dadas para adoptar la metodología Agile, usen kaikaku. Realicen un gran cambio. Contraten a un coach o llévenlo a acabo siguiendo el libro. Una vez hecho esto, apliquen kaizen. Presten atención, sean receptivos, inspeccionen y adapten.

La ideología y metodología Kaizen es importante... y no es toda la historia. Ustedes requieren de más que sólo el cambio gradual para llegar a donde quieren encontrarse.

Cursos para administradores de proyectos
Consigue aquí libros y herramientas de admin. de proyectos
Cursos SCRUM para administradores de proyectos de software