Sí, estoy tratando de provocarlo deliberadamente. Y sí, de una forma mucho más específica, creo que la última mitad de la pregunta es la verdad.
Eso puede ser sorprendente, ya que LeanAgile parece haberse convertido en una palabra en el mundo del desarrollo de software. Así que tal vez, algunas advertencias no vienen mal.
Conozco a Mary y Tom Poppendieck por más de una década. Fuimos amigos y colegas en el grupo más grande de usuarios en el mundo - en Minneapolis. Tom fue mi alumno en la Universidad de St. Thomas. Tom fue uno de los revisores técnicos de mi libro sobre objetos.
Excepto por el hecho de que el libro de él vendió mas que el mío por mas o menos 100 a 1 (y, por tanto, yo nunca lo perdonaré), sólo tengo respeto y adimiración por su contenido e ideas. El libro de él es un discurso de maestro y debería ser aprendido y aplicado por los desarrolladores de software en todo el mundo. Incluido, tal vez, los desarrolladores ágiles.
Entonces, ¿cuál es el problema?
Resumidamente Lean y ágil se basan en visiones fundamentalmente diferentes y, por tanto, se encontrarán inevitablemente en oposición en los puntos críticos.
En los próximos párrafos intentaré mostrar los puntos de vista opuestos, ilustrar un punto de conflicto y, a continuación, sugerir cómo los dos puntos pueden reconciliarse.
Visión del mundo Lean = Producción
Algunas citas del libro Lean Software Developmente, An Agile Toolkit, para introducir mi declaración que la visión de Lean es una visión de producción.
El prólogo de Jim Highsmith "... Mary y Tom Poppendieck llevaron las prácticas de lean industrial a un nuevo nivel - ellos nos enseñan la manera de aplicarlas al desarrollo de software." y "... se proporciona información saludable sobre la aplicación técnicas lean de perspectiva industrial al desarrollo de software."
La página xxii de la introducción, "Sin dejar de reconocer el peligro de aplicar incorrectamente metáforas, nosotros creemos que la industria de desarrollo de software puede aprender mucho examinado cómo los cambios abordados en el desarrollo de productos han mejorado el proceso de desarrollo de productos."
Producción, vocabulario de proceso y metáforas están presentes a lo largo de todo el libro. Aunque existe un claro rechazo de las ideas sobre la producción del siglo 19 (ex: Tailorismo) hay una adopción igualmente clara de los modelos de producción destacados (por ejemplo, el modelo de producción de Toyota)
Las prácticas ágiles específicas se evalúan desde la perspectiva de la contribución a la producción. Si una práctica ágil se considera en conflicto con el modelo de proceso de producción lean, esta práctica, debe ser modificada o eliminada.
Lean no sólo trata el proceso. Por ejemplo, los siete principios de Lean,
- Eliminar el desperdicio
- Amplificar el aprendizaje
- Decidir lo más tarde que sea posible
- Entregar lo más rápido posible
- Fortalecer el equipo
- Construir la integridad
- Ver la totalidad,
sólo el primero está claramente conectado con el proceso de producción.
Estos principios sugieren una forma de trascender la visión de la producción evidentemente en cada uno de los otros aspectos de Lean. Vamos a volver a esta posibilidad en la última parte de este artículo.
Visión de Ágil = Construcción de la Teoría
Tuve el gran privilegio de estar asociado con, y contar a mí mismo como uno de los amigos de, la mayoría de los creadores y defensores de la agilidad. Discutí la siguiente idea sobre los fundamentos filosóficos de ágil y descubrí que ellos están de acuerdo. Sólo uno, Alistair Cockburn, la idea sobre el papel.
APÉNDICE B, páginas 227 a 239 de Agile Software Development de Cockburn contiene una reimpresión de un artículo escrito por Peter Naur en 1985, titulado "Programando como Construcción de la Teoría."
Naur argumenta que el acto de desarrollar software a sido incorrectamente tomado por un acto de producción - la producción de "un programa y ciertos otros textos". Cita varios ejemplos de inconsistencia de datos empíricos con el modelo de producción de desarrollo, incluido el hecho de que la documentación arbitraria y extendida tiene poco, tal vez nada, al ver como la comprensión de un programa para aquellos que no están envueltos en su creación original .
Construir teoría, a la Naur, es el esfuerzo individual y colectivo para:
- Comprender el Mundo
- Comprender cómo el software es formado por el Mundo y cómo él se integrará con este Mundo
- Comprender la esencia del software y como mejor articular (codificar) esta esencia
- Entender que usted llegó a los tres primeros entendimientos correctamente.
Las actividades observables asociadas con la construcción de la teoría incluyen contarmuchas historias, explorar ideas, probar cosas para ver si ellas funcionan, probar su comprensión, llenar suespacio físico con recuerdos evocadores de su comprensión y hacer estas cosas iterativamente en incrementos comprensivos y cada vez mas crecientes.
Muy parecido a un entorno ágil, pero recuerda un poco un entorno de producción.
Exepto para citar las ideas de Ryle sobre la posesión de una teoría, Naur no presenta explícitamente un conjunto de principios para la construcción de teorías. Si lo hubiera hecho, esos principios serían consistentes con los valores de XP para Simplicidad, Comunicación, Coraje y Feedback.
Visiones en conflicto
Lean ve el desarrollo de software como un proceso para salir de una concepción de un producto. Él quiere optimizar el proceso, incluso en una forma radicalmente diferente y con valores radicalmente diferentes a los tradicionales (por ejemplo, Tailorismo) intentando una optimización.
Ágil ve el desarrollo de software como un proceso para construir una teoría consensual del mundo: con un artefacto siendo un producto - una expresión - de esta teoría.
Debido a que la visión fundamental de las dos partes son radicalmente diferentes, es inevitable que existan conflictos. Estos conflictos suelen manifestarse normalmente en términos de herramientas y prácticas.
Por ejemplo: el product backlog.
Ágil está basado en la idea de módularizar el trabajo sobre una base de historias de usuario. Una historia de usuario es "algo que el cliente quiere que el sistema haga." (Kent Beck)
Historias de usuarios son originadas a partir del usuario, también llamados de, clientes o negocio. Las historias se pueden producir mucho más rápido que implementarse, sobre todo en el comienzo de un gran proyecto, o cuando el objetivo es "agilizar" una empresa entera.
Casi todos los proyectos ágiles establecen un product backlog, un conjunto de historias a ser implementadas. Este conjunto puede ser bastante grande. He visto proyectos con una acumulación de cientos de historias.
Lean analiza el product backlog y vé "inventario" y "desperdicio". María Poppendieck sugiere que el product backlog debería ser eliminado o, al menos, limitado a un tamaño más acorde con la velocidad de los equipos.
El ágil ve el product backlog como una previsión de una teoría emergente. Incluso si esta previsión se manifiesta físicamente como una pared llena de tarjetas de historias, este no es un inventario! Las tarjetas en la pared servirán como una forma de memoria externa, con cada tarjeta de evocando (reavivando en la mente) las conversaciones detalladas y la comprensión de cómo funcionan las cosas.
Ágil funciona mejor cuando hay una gran product backlog y cuando hay una gran cantidad de gordura en la composición del backlog. La gordura derivada de las conversaciones acerca de la esencia de la historia, prioridad de la historia; feedback de los desarrolladores sobre las historias que no son comprendidas 'historias que acabarán siendo bien mas fáciles o difíciles de desarrollar que lo esperado, las historias que había que refactorizarlas para hacerlas más comprensibles y mas reastreables para el desarrollo y el feedback de aceptación de los usuarios en relación a la historias completa.
Eventualmente, la gordura disminuye y el product backlog se torna estable. La cantidad de nuevas historias agregadas se reduce a pocas y la priorización de historias cambia sólo nominalmente. En este punto se vuelve aún más tentador considerar el product backlog como un inventario.
Resista la tentación. El backlog es todavía una manifestación física de la teoría. Él proporciona el contexto absolutamente esencial para todo el trabajo de desarrollo que se está realizando.
El backlog proporciona el mismo tipo de soporte crítico para el desarrollo de software que los editores de continuidad y los consejeros técnicos proveen a la producción de películas. Cuando la atención se centra en una única escena, es fácil olvidar que el héroe llevaba una camisa azul, no roja en el último cuadro de la escena anterior. Es fácil olvidar que usted no puede escuchar una explosión en el espacio. Errores similares se producen cuando se trabaja sobre la implementación de las historias y este es el contexto - el product backlog - que proporciona la continuidad y corrección de los malosentendidos de la esencia.
En todos los proyectos ágiles en que yo era el coach, insistí en mantener el product backlog en la pared en forma de tarjetas de historias al lado de la información de monitorización del sprint. Las reuniones diarias (stand-up meetings) eran conducidas con una visión facilitada tanto de las historias de foco inmediato como de las historias del product backlog. El product backlog era revisado y discutido en detalle en cada juego de planificación y en cada retrospectiva - simplemente para refrescar la memoria de todos los involucrados con el estado de nuestra teoría actual.
El punto de este ejemplo: su visión necesariamente colorea su interpretación de las "cosas". Un simple artefacto, como un product backlog, tiene muchas realidades, propósitos, valores y funcionalidades diferentes, basado en su perspectiva del mundo. En este caso, la "visión de producción" resulta en una mal interpretacióno que es actualmente perjudicial al desarrollo ágil de software.
Sé que estoy argumentando, de forma general, y ofreciendo apenas un solo ejemplo para apoyar este argumento. Esta es una cuestión de limitación de espacio, no faltan ejemplos.
Reconciliación
Un matrimonio es pura felicidad - a excepción de los desacuerdos, argumentos y objetivos contradictorios. Lean y ágil forman una bella pareja. ¿Estás seguro de que este matrimonio puede estár a salvo?
Claro que puede, pero hay 3 requisitos previos, uno para el Lean, uno para ágil y uno para ambos.
Lean tiene sacar los "ojos de producción" y mirar para lo ágil y los elementos del proceso de desarrollo ágil desde una perspectiva holística que incluye a todos los siete principios de Lean. Si el product backlog se estima que es algo más que el principio de "eliminar desperdicio", su contribución para "ampliar el aprendizaje, decidir lo más tarde que sea posible, fortalecer el equipo, construir integridad y ver el todo" serían evidentes.
Las prácticas Ágiles deben, irónicamente, hacer lo mismo. Cuando usted escucha a practicantes de ágil hablar de lo que hacen - su vocabulario, metáforas y la implementación de prácticas reflejan la perspectiva ágil como un modo de producción alternativa. Pregunte a la mayoría de los agilistas sobre Naur y la construcción de la teoría y usted recibirá una mirada en blanco.
Tanto Lean y como Ágil deben parar de aplicar, de manera literal, herramientas y prácticas. Herramientas y prácticas no son nada más que expresiones de valores, principios y filosofía. Ellas no son las únicas expresiones posibles y pueden no ser las mejores expresiones. Ninguna de las partes será capaz de comprender los consejos de sus fundadores de "utilizar, adaptar y trascender" a menos que y hasta que llegaran a entender por qué las prácticas y herramientas son lo que son.
AgiLean fue un caso de amor a primera vista. La luna de miel fue un excitante intervalo para encontrar nuevas ideas y combinar ideas. Mas este tiempo ya a pasado. Si este matrimonio va a sobrevivir, ambas partes deben dejar atrás sus atracciones superficiales - ya que este tipo de conflictos surgirán inevitablemente.
