Archivo de la categoría: Kanban

A vueltas con el Manifiesto Lean Kanban

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.

Sobre la transparencia y los tests hechos por desarrolladores

Hace poco me contaron que un CEO de nuestra competencia vio un vídeo en Youtube diciendo que no teníamos equipo de QA. El vídeo en cuestión es la charla que di para el Lean Kanban South Europe 2015. En esta charla hablaba de cómo usabamos Kanban para reducir el tiempo de feedback entre desarrollo y testing y cómo podíamos responder a requerimientos de proyectos, a soporte y además avanzar en producto.

Mi frase  “No tenemos ningún tester ni equipo de QA” se sacó de contexto y se usó como comentario para crear malestar. En VSN tenemos cerca de los 2000 tests automáticos que se pasan varias veces al día y que incluyen de unidad, de integración y de interfaz. Tenemos procedimientos muy concretos, certificados con una ISO 9001 sobre hacer el test cuando terminamos de desarrollar y además realizamos una batería completa de tests manuales de regresión en la que todo el equipo comprueba de manera transversal todo el producto antes de dar por buena una entrega. Usamos muchas de las técnicas incluidas en las certificaciones internaciones de Agile Testing. El no tener equipo de tests separado cada vez se está adoptando más para conseguir una respuesta rápida al cliente sin bajar en calidad. Además empresas como Atlassian estan descubriendo y demostrando que los desarrolladores pueden ser buenos testers. Piensan igual que yo que cuando los desarrolladores tienen el mismo criterio de calidad que los testers, los productos de alta calidad se CONSTRUYEN desde el principio.

Volviendo al tema de la charla, creo que el hablar sobre cómo trabajamos en VSN es más beneficioso que perjudicial. VSN cada vez está mas presente en charlas y conferencias a nivel nacional e internacional. Aquellos que usan frases sueltas de lo que decimos  y basan su “perfección” en su oscurantismo son los que deberían reflexionar sobre cómo hace las cosas. Nosotros esta reflexión la hacemos cada 3 semanas desde hace más de 6 años de manera contínua y es la que nos permite ser cada vez mejores, piensen lo que piensen otros.