El primer Scrum: ¿Era Scrum o Lean?

Hoy he recibido una pregunta por correo electrónico sobre Scrum y Lean, consecuencia del reciente taller que impartí con Mary Poppendieck en el MIT. ¿Está relacionado el Scrum con Lean? ¿Estamos descubriendo cosas nuevas sobre Scrum o Lean? ¿Los clientes piden Lean?

Después de pensar en los primeros días de Scrum, creo que la raíz tanto de Scrum como de Lean es la teoría de los sistemas adaptativos complejos. Cuando creamos Scrum no hablábamos de Lean, sino de sistemas adaptativos complejos. Creo que Scrum y Lean son implementaciones complementarias de formas de enfrentarse a la realidad física, donde las cosas no suelen ser lineales, sencillas ni predecibles.

Por supuesto, el nombre de Scrum procede de que los profesores Takeuchi y Nonaka observaron los equipos de Toyota, Honda, 3M en Estados Unidos y otras empresas "lean". Los pequeños equipos multidisciplinares con un líder que facilitaba la entrega de prototipos de producción en intervalos cortos les recordaban al Rugby y a la formación Scrummage. Así pues, Scrum es "lean" por definición, pero Takeuchi y Nonaka nunca mencionan la palabra "lean". Lo consideran un concepto occidental que intenta describir las prácticas de la cadena de montaje en Toyota, que cambian constantemente y no son el valor central del Toyota Way. 95% de los beneficios de Toyota los obtienen los Ingenieros Jefes, que son los que hacen Scrum.

El primer Scrum implementó todas las prácticas que hoy conocemos como Scrum más todo lo que más tarde se conoció como prácticas XP más alguna salsa secreta que crea equipos hiperproductivos.

La programación en parejas se utilizaba regularmente con Jeff McKenna, el consultor principal, que pasaba medio día con cada desarrollador cuando estaba en Easel una semana al mes. Después de una de estas sesiones se oyó a los desarrolladores quejarse de que 75% de su base de código se había desechado en un frenesí de refactorización. El 25% restante lo hacía todo de forma más limpia y elegante.

La integración continua era la norma. Todavía me asombra que los desarrolladores piensen que pueden programar sistemas de producción sin esto. (¡Pueden, pero apestan!)

El concepto de "Conjunto" era la clave del diseño basado en componentes. Contábamos con sofisticadas estrategias de pruebas basadas en componentes y en el diseño de chips de silicio.

Teníamos ingenieros experimentados en el equipo de control de calidad que automatizaban las pruebas a nivel de componentes. Se trataba de pruebas a nivel de características. Fue un precursor de la prueba de humo que se ejecuta en cada compilación en mis empresas posteriores.

Desplegamos versiones para su uso al final de cada Sprint mensual. Cada versión tenía la funcionalidad suficiente para que los consultores de Easel la utilizaran en proyectos reales.

Pero lo más importante es que hemos conseguido el efecto de "equilibrio puntuado", algo que aún no he visto hacer a ningún otro equipo Scrum. Es uno de los secretos de los equipos hiperproductivos. Antes de que un desarrollador elija una tarea en la reunión Scrum, todo el equipo debate con el desarrollador si esa tarea será el camino más rápido hacia una característica de uso final observable. Se trata de una sofisticada puesta en práctica de la "autoorganización" y del desarrollo "probar primero".

Después de que el primer Scrum se pusiera en marcha en Easel en 1993, empecé a hablar sobre el proceso en los grupos de noticias de Internet en 1994, en particular en comp.object, y en 1995 ya teníamos un hilo bien documentado de mis discusiones sobre Scrum en comp.objectcon comentarios de Bob Martin, Kent Beck y otros.

Así que los orígenes de Scrum están bien documentados y se pueden investigar en los grupos de Google buscando en los archivos. Mi Página web original del Scrum comenzó en 1994 y fue muy visitado en la web durante 1995 y actualizado regularmente hasta la reunión del Manifiesto Ágil en 2001.

En 1995 invité a Ken Schwaber a echar un vistazo al primer equipo Scrum, lo que nos llevó a colaborar en la primera ponencia formal sobre Scrum, presentada en otoño de ese año en la OOPSLA. No hablamos en absoluto de Lean, pero sí de sistemas adaptativos complejos.

Mike Beedle se vio influido por la descripción en línea de Scrum, puso en práctica el proceso en su propia empresa y dirigió el esfuerzo para impulsar Scrum a través de las conferencias sobre Lenguajes Patrón de Diseño de Programación. Esto convirtió al Scrum en el primer (y único) patrón organizativo formal que describe un proceso ágil completo. En su libro "Patrones organizativos en el desarrollo ágil de software."

Si consulta "scrum.txt", verá que Scrum se deriva directamente de las mejores prácticas en el desarrollo de nuevos productos documentadas por Takeuchi y Nonaka en su artículo de 1986 en HBR. El ejemplo principal del artículo era Honda (Toyota no era tan conocida en aquella época). Takeuchi no aborda específicamente el Lean tal y como lo conocemos hoy en día.

En 1995, hice un comentario en el grupo de noticias comp.object:

Los estudios de usabilidad... nos han convencido de que sólo hay un artículo en la literatura que describa el rápido entorno de desarrollo de aplicaciones conseguido con Object Studio (la combinación de Enfin Smalltalk y Synchronicity Business Object Modeling and Persistent Object Mapping).

Takeuchi, Hirotaka y Nonaka, Ikujiro. El juego del desarrollo de nuevos productos. Harvard Business Review, enero/febrero de 1986, pp. 137-146.

Takeuchi y Nonaka describen la metodología Scrum (un término de Rugby) que utilizamos internamente. Es muy diferente de todo lo que se ha visto hasta ahora, porque no existe un calendario de gestión de proyectos, sino sólo un plazo de entrega comprometido para un lanzamiento. Las empresas japonesas de automoción y electrónica la utilizan para limpiar nuestros relojes en la economía mundial. ¿Se ha dado cuenta de que las empresas automovilísticas estadounidenses tuvieron un año excepcional y aún así perdieron cuota de mercado en 1994?

A los equipos pequeños se les asignan objetivos que deben cumplir en un plazo fijo. Toman el software existente (nunca se construye nada desde cero) y se asignan pequeños proyectos (de 2 días a 2 semanas por persona) como SynchSteps. Los SynchSteps son impulsos dinámicos generados contra la estructura de código existente que provocan mutaciones (como en un organismo biológico).

Un equipo de proyecto suele estar formado por 3 desarrolladores, 3 responsables de control de calidad, 3 responsables de documentación y uno o dos usuarios. Se reúnen a diario y todos se ponen de acuerdo sobre los pasos realizados y los siguientes. En los proyectos grandes, equipos pequeños de este tamaño construyen componentes y un SCRUM de SCRUMs se reúne con menos frecuencia para resolver las interfaces entre componentes. Los Developers deben ser superados en número en el equipo por gente de QA y documentación o generarán demasiado código demasiado rápido (funcionalidad maligna).

El código evoluciona como un sistema biológico a través del equilibrio puntuado. Puede leer sobre este proceso modelado por Denny Hillis en una Máquina de Conexión en el libro "Vida Artificial". Cuando se producen suficientes mutaciones en varias partes del organismo, el sistema pasa a una meseta superior de funcionalidad. En ese momento decimos que se emite un "paquete". Será una nueva pieza del sistema de software que estamos construyendo. Por ejemplo, estamos añadiendo Casos de Uso al producto Synchronicity en este momento y cuando el paquete aparece, se cumple un objetivo para el ciclo de lanzamiento.

Un ciclo de publicación, normalmente de seis meses, se compone de paquetes que se definen vagamente como objetivos al inicio del ciclo de publicación.

La dirección debe soltar el control del equipo y dejar que funcione como una entidad autoorganizada que hace crecer un sistema como una planta. Hemos comprobado que, con este planteamiento, obtenemos una funcionalidad mucho mayor en menos tiempo y un producto mucho más fresco. Este enfoque racionaliza los comentarios que Fred Brooks hizo en 1987 en su artículo "There is No Silver Bullet". En él afirmaba que la única forma de acelerar el desarrollo era cultivar un prototipo como una planta.

Hacemos un seguimiento del proceso mediante la velocidad de las asignaciones de SynchStep (elementos del Sprint Backlog) frente a la velocidad de finalización de SynchStep. Esto nos da una estimación del tiempo de finalización del paquete, algo así como lanzar un cohete, observar su trayectoria y predecir el punto de impacto. Podemos ajustar el punto de impacto bajando el arco (menos funcionalidad) o añadiendo combustible de cohete (más recursos) para alcanzar el plazo comprometido con la dirección.

Supervisamos los progresos regularmente mediante demostraciones. Nada cuenta con la gestión excepto el código entregado que funciona. Los paquetes se envían regularmente como componentes alfa que la gente puede soltar en la versión actual de Synchronicity. Synchronicity cambia dinámicamente, con menús y todo, para que la gente pueda probar la nueva funcionalidad y ver si le gusta.

Con SCRUM, los calendarios son obsoletos (a los desarrolladores les encanta) y las fechas de entrega nunca se retrasan (a la dirección le encanta). Si esto suena demasiado bueno para ser verdad, supongo que lo es, pero la dirección estará de acuerdo en que hay más funcionalidad y menos retrasos con este proceso que con cualquier otra cosa que hayan visto nunca. Nuestros usuarios nos piden que alarguemos el calendario de entrega de productos porque lanzamos demasiadas versiones nuevas con actualizaciones importantes...".
demasiado rápido (lo que no impide que se quejen de no tener todo lo que desean).

Consideramos que el cambio de paridigma necesario para la utilización óptima del proceso SCRUM es significativo. El paridigma orientado a objetos requiere un cambio de mentalidad, pero Scrum requiere un cambio en la organización y en la forma de trabajar y relacionarse de las personas.
------------------------------------------

Scrum estuvo muy influido por la teoría de los sistemas adaptativos complejos: el trabajo de Peter Senge en el MIT, Christopher Langdon en el Sante Fe Institute y muchos otros. También por la teoría de las restricciones de Goldratt y por la arquitectura de subsunción de Rodney Brooks, la base de la empresa iRobot, que ayudé a poner en marcha poco antes de que comenzara Scrum. Al final de mi página web original de Scrum comenté:

"SCRUM se basa en la teoría de la complejidad y en experimentos de vida artificial realizados en Thinking Machines mediante simulación altamente paralela de la evolución de sistemas. Induce el fenómeno conocido como "equilibrio puntuado" observado en la evolución de las especies biológicas."

La razón por la que el primer equipo de Scrum llamaba SyncSteps a los elementos del Sprint Backlog era que los desarrolladores ejecutaban el Sprint Backlog en un orden cuidadosamente elegido: aquel orden que producía el camino más rápido hacia la aparición de la siguiente característica desde el punto de vista de los usuarios. Al igual que el orden correcto del Product Backlog optimiza los ingresos, el orden correcto del Sprint Backlog optimiza la producción de valor. Acelera la evolución del software y puede producir efectos observados en sistemas biológicos.

El efecto de "equilibrio puntuado" se consigue en Toyota mediante la ingeniería concurrente basada en conjuntos. Por ejemplo, Toyota no fabrica un radiador para un coche nuevo. Construye seis y espera hasta el último momento para elegir el mejor radiador para la producción. Esto es similar a la competición entre especies biológicas en un ecosistema y gana la especie que mejor se adapta al entorno. La comunidad Scrum aún tiene que aplicar las estrategias de ingeniería concurrente basadas en conjuntos que utilizó el primer equipo Scrum.

En Google me preguntaron por qué ningún equipo Scrum aplicaba esta estrategia de ingeniería concurrente basada en conjuntos. Esto me obligó a reflexionar sobre el problema. La respuesta parece ser que los equipos Scrum (1) no tienen una arquitectura de componentes clara y coherente, (2) los miembros del equipo no tienen una visión global de la arquitectura y el estado de cada componente, y (3) los equipos no tienen un método formal para las pruebas automatizadas a nivel de componentes.

Sin embargo, el desarrollo "primero la prueba" impulsa el proceso de creación de software en la dirección correcta, ya que las pruebas tempranas muestran inmediatamente lo que no funciona y permiten un rápido despliegue de estrategias alternativas. La clave es la evolución del software como un sistema biológico basado en construcciones de implementación que compiten entre sí y en la supervivencia del más apto.

En mi artículo sobre Scrum se describe el desarrollo "Test first" en una empresa con CMMI de nivel 5, en el que las pruebas aceptadas para las características se describen en primer lugar, la característica se implementa en orden de prioridad y se prueba inmediatamente. La ingeniería de software sistemática demostró que esto duplicaba la velocidad y reducía los defectos a la mitad. El desarrollo dirigido por pruebas consiste en escribir código de prueba antes de escribir la funcionalidad y es útil en las manos adecuadas. Esto tiende a centrarse en el nivel de prueba de la unidad y ayuda con la refactorización. Como señaló Ron Jeffries en nuestro taller conjunto del MIT, deja que el código hable y emerge la arquitectura. Sin embargo, muchos desarrolladores no pueden escuchar al código hablar y pueden generar un lío en el que hay más código de prueba que código de producción y más errores en el código de prueba que en la aplicación. Puedo ver la forma del diseño en la mente de Ron mientras trabaja en el código y está claro que no es el programador medio. Él ve las alternativas del espacio de diseño desplegándose mientras codifica y tiene el buen juicio para tomar el camino correcto hacia una arquitectura flexible y mantenible. Esto me recuerda por qué Jim Copien afirma que el "Arquitecto de Códigos" es un patrón de organización muy importante que es la mejor práctica en las empresas líderes. (Jim también afirma que TDD está roto por las razones aludidas aquí).

Un análisis detenido de la relación entre los sistemas adaptativos complejos y Lean demostrará que tanto Scrum como Lean son instancias de la teoría de los sistemas adaptativos complejos. Un subconjunto de la teoría de los sistemas adaptativos complejos es la vida artificial, término inventado por Christopher Langton en el Instituto Sante Fe en los años ochenta. Su artículo seminal, que demuestra que los organismos simulados en un ordenador evolucionan más rápido a medida que se acercan a regiones caóticas, influye enormemente en Scrum. En Scrum, introducimos el caos en el proceso de desarrollo y luego utilizamos un arnés de control empírico para inspeccionar y adaptar un sistema que evoluciona rápidamente.

Al intentar describir Scrum en JAOO en 2005, utilicé Lean para mostrar por qué Scrum funciona. Scrum es una forma de aplicar Lean en la construcción de software. De hecho, tiene la ventaja de que si lo sigues de cerca y lo aplicas bien, estarás haciendo Lean tal y como lo articulan Mary y Tom Poppendieck sin ni siquiera entender Lean. A la gente le cuesta entender la teoría de los sistemas complejos, por lo que es difícil utilizarla como motivación. También es difícil que la gente entienda Lean, pero Toyota se ha convertido en una fuerza tan dominante en la industria que el miedo, la incertidumbre y la duda despiertan a la gente de su sueño.

En 1995, trabajé con Hubert Smits y Jean Tabaka en Rally para desarrollar un curso para personas que quieren llevar su implementación Scrum al siguiente nivel, todo basado en Lean como la forma más fácil de articular en qué hay que centrarse para optimizar Scrum. Ken Schwaber argumenta que simplemente centrándose en el marco Scrum y la lista de impedimentos lo conseguirá. Esto es absolutamente correcto. Lean no es más que una herramienta didáctica adicional.

También está el documento sobre Scrum y CMMI Nivel 5 sobre la implantación de Scrum por Systematic Software Engineering, una implantación totalmente impulsada por Lean. En Dinamarca, la política nacional es introducir prácticas Lean en todos los sectores. Como resultado, es fácil vender Scrum como una forma de implantar Lean en el software.

Scrum es un marco de trabajo de inspección y adaptación cuyo diseño es extremadamente sencillo para que el desarrollador medio de Ford Motor Company pueda empezar a utilizarlo en un par de días. Sin embargo, es difícil de implementar. Menos del 10% de los equipos Scrum de todo el mundo pueden pasar la prueba de Nokia, principalmente porque no pueden entregar software potencialmente despachable (totalmente probado) al final de un Sprint. Hablar a la gente sobre sistemas adaptativos complejos no parece ayudarles tanto como hablarles de Toyota para mostrarles cómo su implementación de Scrum está rota, cómo está plagada de interrupciones en el flujo (muri), estresada por todas partes (mura) y desperdicios (mudah). Utilizar a Toyota como ejemplo de empresa de éxito que elimina sistemáticamente el muri, el mura y el mudah les muestra la mejor manera de arreglar su proceso.

Así pues, Lean es útil como herramienta didáctica porque deriva de las leyes básicas del universo articuladas a nivel teórico por la investigación de los sistemas adaptativos complejos. Scrum deriva de los mismos principios fundamentales. Lean cuenta con métodos prácticos para abordar el mapeo de procesos, el coste de los retrasos, los problemas de colas, los tiempos de reajuste, etcétera. Todos ellos son útiles para tratar las restricciones, el rendimiento global del sistema y otros factores que eran una preocupación primordial para Scrum a la hora de tratar el sistema adaptativo complejo llamado desarrollo de software.

Lean deriva de Edward Deming y del trabajo de otros que enseñaron a los japoneses que la optimización local causada por la gestión tradicional por objetivos era autodestructiva. Deming, tras consultar a los dirigentes de muchas empresas estadounidenses, llegó a la conclusión de que la gestión estaba totalmente averiada en Estados Unidos, causando daños incalculables e inconcebibles (como la destrucción de la industria automovilística). La optimización global promovida por Deming y sus prácticas de control estadístico de la calidad tienen sus raíces en la teoría de los sistemas adaptativos complejos, siendo la teoría de las restricciones un área especializada que se centra en la optimización global. El trabajo del profesor Senge sobre la teoría de sistemas en el MIT es el recurso más legible para estas primeras influencias Scrum.

Así que la conclusión es que:

1. Scrum no es un descendiente directo de Lean. Deriva de los sistemas adaptativos complejos con un vínculo indirecto con Lean a través de Takeuchi y Nonaka.

2. La dirección está interesada en Lean, sobre todo en Europa. Partiendo de ese interés y de sus conocimientos sobre Toyota, resulta más fácil describir por qué funciona el Scrum.

3. Lean es una buena herramienta de enseñanza para mostrar a los equipos Scrum por qué sus implementaciones no funcionan. Por ejemplo, si no tienes código totalmente probado y no puedes crear código potencialmente enviable en un Sprint, tienes 100% trabajo en curso para el siguiente Sprint.

El exceso de trabajo en curso se considera un error horrible e intolerable en una operación Lean, sin embargo, los equipos de desarrollo de software y la dirección parecen tener dificultades para entender por qué este trabajo en curso duplicará sus defectos y reducirá su velocidad a la mitad. E incluso cuando lo entienden, a menudo carecen de la voluntad política para solucionarlo. Enseñar la mente Kaizen y detener la línea es una medicina útil para esta disfunción.