Hace un par de semanas vi este tweet de David J Anderson, creador de Kanban para desarrollo de sofware. Sé que hace tiempo que viene dandole vueltas a tener un manifiesto Lean Kanban y no sé si este será finalmente el que tomen pero sí tiene muchos puntos para reflexionar. Empieza así:

I believe in…
Empirical Process over Defined Process
Kanban, Scrum y otras metodologías ágiles están basados en el empirismo: transparencia, inspección continua y adaptación. Definir los procesos es necesario para estandarizar el trabajo y buscar mejores formas de hacerlo pero la situación real de cada momento es lo que manda.

System Thinking over Analytical Thinking
System Thinking se caracteriza por visualizar cualquier trabajo u operación como una serie de pasos interconectados que forman un flujo. Una vez definido y estandarizado este flujo de trabajo es posible ser ejecutado por más personas sin depender de un análisis concienzudo de cada petición de cliente por parte de dirección. Permite escalar una organización, buscar la mejora contínua y el empowerment de los que trabajan en ella. 

Effectiveness over Efficency
A esta le estuve dando muchas vueltas. Siempre se piensa en la eficiencia como algo que hay que perseguir pero, ¿es realmente lo más importante?. Pensando en cualquier sistema adaptativo, lo primero que hay que conseguir es un resultado de la manera más simple y lo antes posible con los medios y los conocimientos que se tienen en el momento de empezar. Por ejemplo, si el cliente piensa en tener un coche dentro de un año, nosotros le entregamos un monopatín en dos semanas. Realmente no es la forma más eficiente de trabajar ya que podríamos empezar a construir el coche sin tener que rehacer nada, pero podríamos fallar completamente buscando la forma más eficiente desde el primer momento. La eficiencia se busca poco a poco, historia tras historia, iteración tras iteración. Hazlo ya, vuélvelo a hacer de forma más eficiente, hazlo otra vez de forma aún más eficiente, y otra y otra…
Flow Efficiency over Resource Efficiency
Tradicionalmente se ha intentado aprovechar mejor los recursos individuales que ocuparse en el flujo completo de valor, desde la primera fase hasta la última. La gente de backend haciendo servicios a todo trapo sin que posiblemente los de front end tengan tiempo de integrarlos a tiempo. Es como si yendo un grupo de amigos en varios coches a un concierto cada coche fuera lo más rápido que pudiera sin pensar en el resto de amigos. Hacer esto no sólo no sirve para nada porque el coche más lento es el que define a qué hora entrarán sino que provocan problemas de sincronización que hace que vayan aún más lentos.
Small Batches over Big Batches
Trabajar en pequeños lotes tiene una serie de ventajas: se entrega antes trabajo terminado y se obtiene feedback antes, se obtiene progreso basado en software funcionando más contínuo, emergen los problemas antes, se reduce el stock de trabajo sin entregar, se puede controlar mejor la calidad… ¿Qué más razones necesitas?
Pull System over Push System
Base del sistema Lean. No hacer más trabajo de lo que necesitan las fases posteriores. Por ejemplo, no enviar a testing más de lo que puede manejar, no planificar más historias de las que se pueden desarrollar, etc.. Y por supuesto no hacer más producto de lo que pide el cliente.
Emergence over Command and Control
Las empresas están aprendiendo a cambiar su estilo de dirección reduciendo capas de jerarquía. En lugar de intentar dirigir todo top-down, se deja espacio a los trabajadores a que seas sus propios managers y resuelvan ellos mismos los problemas. De este modo se puede conseguir que empresas grandes y pequeñas respondan rápidamente a los nuevos retos que requiere la sociedad digital.
Problem Focus over Solution Focus
Es facil empezar a pensar en soluciones teniendo en consideración solamente la superficie del problema, los síntomas. Sin embargo hay que analizar más el propio problema, buscando las causas raices del mismo mediante técnicas como 5Whys o Fishbone. Una vez encontrado y estando centrados en el problema raíz ya podemos buscarle soluciones.
Omission Error over Commission Error
Preferimos quedarnos cortos y tener la posibilidad de hacerlo bien en un segundo paso que hacer algo erroneamente y tener que corregir, arreglar, deshacer y volver a hacer. Lo segundo generá más retrabajo que lo primero. Por ejemplo, sacamos de alcance la parte de una historia de usuario que no está clara para desarrollarla más adelante con máyor información.
Products Development over Project Execution
Cuando desarrollamos software es facil centrarse en los requerimientos del proyecto (plazo, cliente, necesidades solicitadas,..) sin pensar que estamos realizando un producto que tiene una vida mucho más larga que el propio proyecto, que puede usarse por varios clientes o incluso que el mismo cliente puede solicitar cambios grandes en el futuro. Esto hace que debamos prestar atención a factores como la calidad de código, la adaptabilidad y una buena elección de la tecnología.