Lean Software Development con Mary y Tom Poppendieck
Mary y Tom Poppendieck han sido los pioneros en adaptar las técnicas de producción Lean al desarrollo de software. Esta pareja, ya retirada, comenzó su carrera en el sector de la fabricación y el control de procesos y posteriormente llevaron su experiencia al mundo del software proponiendo un nuevo paradigma con el uso de principios y metodologías agile. Son autores de los reconocidos libros:
El pasado 2 de Febrero tuvo lugar el evento mensual sobre Arquitectura de Software de O’Reilly. En esta ocasión Neil Ford (Thoughtworks) moderó una sesión de Q&A con Mary y Tom sobre Lean Software Development en la que hablaron sobre roles, organización y estimaciones.
Frecuentemente se oye hablar de una gran variedad de tipos de arquitecto: de software, de aplicaciones, de sistemas, técnicos, incluso el arquitecto accidental. Y no existe una referencia o un estándar sobre cuáles son necesarios, hay organizaciones que tienen de un tipo y otras una docena. En todo caso, son dimensiones de la arquitectura de las que existen herramientas y técnicas maduras y mucha experiencia dentro de la comunidad.
Sin embargo, existe un aspecto igual de critico que los anteriores, aunque menos desarrollado, que es la Arquitectura Organizacional (AO). La AO nos permite entender el funcionamiento de la organización como un sistema que busca conseguir los resultados de negocio deseados. Es un sistema que está dirigido por las políticas y la propia estructura de la organización (Ley de Conway).
Muchas veces la resistencia a las transformaciones agile ocurren por la disonancia entre la arquitectura de la organización y el sistema que se quiere crear. Una organización con seis divisiones seguramente creará un sistema con seis partes. En este sentido Team Topologies es un reflejo de la idea de transformar la organización desde la estructura de los equipos, de tener en cuenta la ley de Conway desde el principio.
A la cuestión de cómo hacer estimaciones en Lean y Agile destacaron que lo importante es ser honestos.
Es legitimo que el departamento de contabilidad quiera saber los costes y negocio pida una estimación porque puede existir un umbral a partir del cual no tenga sentido hacer un trabajo. Se presta poca atención a un aspecto importante de la arquitectura que es la viabilidad. Hay veces que no se puede conseguir un objetivo con los recursos disponibles o en el tiempo requerido pero decimos: intentémoslo, si hacemos horas extra, trabajamos duro y no hay ningún imprevisto(?!) quizás lo consigamos, pero en tu interior sabes que no.
Si se trata de una tarea en la que el equipo tiene experiencia, ya tenemos una referencia, y es razonable poder dar una estimación incluyendo un pequeño margen para imprevistos. Si es una tarea en la que tenemos experiencia, pero se introduce una nueva tecnología, en su opinión el grado de incertidumbre permite añadir un margen extra del 30-50%. Y si hablamos de un problema nuevo, que ni siquiera entendemos todavía de qué se trata o tiene un alcance muy difuso, tenemos que aceptar que la estimación va a ser una suposición que se irá refinando a medida que sepamos más sobre su solución.
También es importante revisar la forma en que estimamos. Negocio debe ser responsable de plantear de forma clara el problema y las restricciones pero dejar que sea el equipo, los expertos, el que determine la mejor forma de resolverlo cumpliendo con las restricciones. Por ejemplo: necesitamos un sistema de control que funcione, que sea facilmente mantenible por el equipo de ingenieria, facil de usar por el equipo de planta, tenemos este deadline porque la planta tiene que estar funcionando este día y tiene que usar la última tecnología, es todo, con esto se puede estimar porque nadie está dando la respuesta final, ni los detalles de como deber ser. Cuanto más detalle o más especifico sean los requisitos más dificil es estimar.
El problema es la definición y quien decide qué hay que hacer. Si es una petición detallada de funcionalidades o es una petición del tipo: este es el problema que queremos resolver. Son dos cosas diferentes. Si se piden cosas detalladas pero irrelevantes de las que nadie es responsable estamos volviendo al agile de los 90.
¿Y sobre el movimiento no-estimates que surgió hace unos años? En su opinión no tiene sentido hacer estimaciones pequeñas sobre las próximas tareas a corto plazo, pero como hablábamos antes, cuando el proyecto ya es grande, si es preferible trabajar con estimaciones temporales y hacer eventos de integración periódicamente. Un buen ejemplo es Tesla o SpaceX, ellos dicen: en tres meses probamos el cohete, no se retrasa la fecha, tienen mucha instrumentación, muchos videos, si el test falla tienes 24h para averiguar que salió mal y corregir.
La forma en que a veces se implementa Agile no tiene en cuenta este tipo de deadlines y eventos de integración y se enfoca más en estimaciones iniciales de cuanto va a llevar todas las tareas para completar todo a tiempo. En toyota el jefe de ingenieros dice: necesitamos estar en este punto dentro de 3 meses, hagan lo mejor que puedan y esten listos. Es un concepto. Muy diferente a estimar y aún así sigue habiendo restricciones de tiempo y coste. Generalmente es mejor hacer eventos de integración periodicos con los responsables para mantenerse en el presupuesto y plazos que hacer estimaciones detalladas de pequeñas tareas.
¿Para que sirven las estimaciones? en muchas organizaciones son el latigo, una forma de hacer cumplir, también puede ser usado como medida de la productividad, pero ¿qué es la productividad? es el valor del resultado del grupo dividido por el coste del equipo, no es el número de puntos de historia de usuario realizados. Una estimación real solo tiene dos valores: sí, podemos hacerlo con las restricciones o no, no podemos hacerlo.
El concepto de hacer estimaciones al comienzo de cada iteración y el concepto de iteraciones en si mismos son raros. ¿Por qué los sprints de 1-2 semanas son una buena idea? El Continuous Delivery es una idea mejor, en software se puede ser muy rápido que construyendo hardware (1-2 semanas no encaja ni en una ni en otra). ¿Qué magia tienen los sprints de 1-2 semanas? Ninguna.
A veces puede funcionar dividir los proyectos de IT en 3 fases, realizar el primer tercio y evaluar si merece la pena hacer los otros 2/3. Decidir y estimar al inicio de una iteración lo que vamos a hacer en ese sprint es una idea basado en tareas en lugar de un concepto basada en la resolución de problemas y queremos que la gente piense como resolver problemas, no como realizar tareas.
Tiene más sentido el concepto de eventos de integración. Los equipos tratan de probar y aprender lo más rápido posible y para eso necesitan feedback y para tener feedback necesitas entregar algo en una situación que puedas testear. Ciclos cortos de aprendizaje son piezas esenciales y en el mundo del software estos ciclos pueden ser muy rápidos.
Uno de los consejos más fundamentales en Lean thinking se resume en una frase simple: Pull don't Push. En lugar de decir las tareas que tienes que hacer dices: tienes que solucionar este problema para esta fecha. Y cada equipo debe ser responsable de ofrecer su mejor solución y entender su rol dentro del sistema global. Cuando los equipos entienden donde están dentro de la organización y se sienten responsables de objetivos que ayudan al éxito de sus clientes, a hacer avanzar el sistema, entonces tienes una situación diferente a: aquí tienes 5 cosas que terminar para el proximo martes.
Para terminar comentaron su opinión sobre las tres cosas que menos les gusta de Lean o Agile.
La primera el nombre, o la mala fama de “Lean”, el “Lean on me”, la mala interpretación de que Lean busca la optimización de la organización mediante despidos.
La segunda, de nuevo, el concepto de iteraciones y también el de Product Owner que se han corrompido hasta tal punto que deben ser abandonados.
Por último el Cargo Cult, copiar las practicas sin entender los principios. Manufacturing Lean fracasó en los 90 porque otras empresas fueron a Toyota y copiaron las practicas, en lugar de crear las suyas propias, copiaron las fórmulas, las reuniones y ceremonias. Y no funcionó.
¿Cuantas empresas están copiando el modelo Spotify? Tampoco va a funcionar, ni Spotify usa ya su modelo.