Desmistificando Kanban y Scrum en el Contexto de Lean

Una célula de manufactura contiene un conjunto de especialistas, máquinas y estaciones de trabajo ordenadas de tal manera que puedan producir valor de la forma mas eficiente posible para lograr lo que le denomina “one-piece flow” o flujo continuo de una pieza con la calidad esperada que pueda contribuir a la elaboración de un producto completo. De hecho “one-piece flow” es la aspiración de una planta que trabaja bajo de filosofia Lean ya que ataca los ocho tipos de desperdicio identificados dentro de esta filosofia.

El concepto de “one piece flow” permite que los operarios trabajen en equipo, obteniendo feedback constante y pensando en como resolver los problemas que salen constantemente a flote. Existe evidencia de que es muy dificil por no decir utópico alcanzar el flujo que se logra a nivel de célula y replicarlo en toda una operación, tomando en cuenta claro está las limitaciones de la fábrica, espacio, estructura, máquinas y sobre todo habilidades de los operarios.

No todo operario puede ser multifuncional en todos los aspectos de la construccion de un producto o familia de productos. Al menos no todos tienen la cultura de Toyota en sus organizaciones que dicho sea de paso nunca ha podido lograr el “one-piece flow” de tal manera que toda su operación se asemeje a una célula.

Jeffrey Liker hace referencia en su libro “The Toyota Way” a la resistencia feroz que encontró Taiichi Ohno en la planta de Toyota cuando acomodó máquinas en lineas paralelas y en forma de L para que un solo operador pueda mantener su misma jornada laboral operando 3 o 4 máquinas en mas de un proceso. Los trabajadores se resistieron a volverse multifuncionales y dejar su arreglo inicial de trabajar con una sola máquina. El mismo Ohno explica cómo decidió no presionar a los trabajadores ya que estos esfuerzos gradualmente sacaron a flote varios problemas que marcaron la dirección hacia la cual debía apuntar para aspirar a lograr un flujo continuo.

El ideal de one piece flow no se pudo replicar en su totalidad en Toyota es alli donde Taiichi Ohno inventa Kanban con el objetivo de ayudar al Sistema de Producción de Toyota a llegar al tal ansiado “one-piece flow”. Kanban en manufactura es una orden que autoriza el retiro de material como instrucción para producir. No se retira ni se produce material si no existe un Kanban asociado. De esta manera se evita uno de los mas grandes desperdicios de la manufactura Lean que es la sobreproducción.

Kanban es por lo tanto una herramienta escencial para la producción “Just-in-Time”. que requiere que el material entregado a la subsiguiente estación esté libre de defectos ya que de encontrarse alguno es posible detener toda la linea de producción para solucionar y encontrar la raiz del problema. Tal como explica Liker en su libro, en Toyota el reto es desarrollar una organización basada en el aprendizaje que permita encontrar maneras de reducir el número de señales Kanban y finalmente no solo reducir sino eliminar el Kanban.

Según Ohno esta es una de las reglas al usar Kanban la cual sin duda se adhiere a la filosofia “Just in Time” de que el inventario es desperdicio. Kanban por lo tanto es una herramienta que permite reducir costos y mejorar el sistema de producción constantemente. Ohno introdujo Kanban para crear una tensión positiva mientras se reduce el inventario en progreso. Según explica esto motiva a las personas a mejorar mas allá de lo que creen posible elevando su potencial en el trabajo.

Podemos explotar herramientas y conceptos que han sido estudiados por mucho tiempo y han venido funcionando fabulosamente en procesos repetitivos de producción pero estos conceptos no pueden ser transalados directamente al ámbito del desarrollo software, por precisamente eso, generar software no es un proceso de producción, es un proceso de desarrollo. Es como crear la receta de la bebida de bandera del Perú -el pisco sour- y preparar la bebida, son dos cosas muy diferentes, probablemente quien inventó la receta participó en un proceso iterativo de ensayo y error hasta encontrar la combinación de ingredientes “perfecta” o al menos agradable al paladar.

Scrum es un framework de inspección y adaptación creado para facilitar la construcción de proyectos complejos. En el proceso el equipo aprende a funcionar como tal mientras en paralelo aprende también sobre el producto que debe construir. Tanto Scrum como XP requieren una disciplina que aspira lograr el “one-piece flow” o flujo continuo de una pieza como parte inherente del framework. La “pieza” (o mejor dicho incremento) en Scrum es una colección de requerimientos que cumplen con un objetivo alineado a la visión establecida por el Dueño del Producto. El incremento deberá ser entregado en un plazo fijo (iteración de entre 1 a 4 semanas) previamente acordado entre el equipo, el ScrumMaster y el Dueño del Producto de acuerdo al contexto.

A veces el contexto y condiciones para lograr “one piece flow” no existen. “One-piece flow” podria también requerir mucha disciplina o simplemente podría carecer de sentido aplicarlo para cierto tipo de trabajo. Vivimos en un mundo imperfecto y tenemos que ver la manera de adaptarnos. Es común encontrar contextos donde los cambios tendrán que ser graduales. Existe un camino alternativo a la agilidad.

Limitar la cantidad de trabajo en progreso en el flujo actual y un sistema de flujo continuo donde el limite disponible autorice a un miembro del equipo empezar mas trabajo podria ser una manera de lograr que los equipos entiendan la demanda que recae sobre ellos dentro de su propia realidad y capacidad. Requerirá que el equipo se ajuste gradualmente de acuerdo a su ritmo de aprendizaje.

La evolución de Kanban orientado al desarrollo de software implica que aparezcan en equipos maduros lo que llamo mini-flujos. Últimamente ha aparecido el concepto de “liquidez en el flujo” (liquidity in flow) que por lo visto es una nueva métrica dentro de los sistemas Kanban para la ingeniería de software que toma la idea de la liquidez de los mercados. A mayor liquidez mas confianza, básicamente se refiere a la cantidad de transacciones tipo “pull” entre las fases dentro del flujo (es decir donde se jala trabajo de una fase a otra según capacidad disponible y las políticas).

A mayor liquidez el equipo se considera mas predecible. Aun veo que hay mucho por descubrir alli pero puedo intuir la lógica. Mientras mas liquidez es probable que el equipo sea mas integrado y podría existir una tendencia al traslape frecuente entre las fases. Según lo que reporta David Anderson:

“liquidity provides more details about the internal affairs of a team”

Algun responsable “downstream” en el flujo incrementa ampliamente su nivel de colaboración “upstream” (ejemplo un tester que ahora comienza testing antes de que el desarrollador termine) eliminando en un momento el “pull” entre esas dos fases separadas (el liquidity se acelera) con el proposito de llegar al concepto Lean de Chaku-Chaku. El mini-flujo entre el tester y desarrollador empieza a canibalizar el Kanban y a medida que existe mas colaboración nos vamos aproximando a one piece flow, aun sea en una pequeña porción del sistema de trabajo que luego podrá generalizarse.

En este punto el equipo habrá evolucionado, esta tendencia puede repetirse y el resultado es que ya no tenemos dos fases separadas de desarrollo y testing porque ahora tenemos una sola “Desarrollo y Testing”. Podría también suceder con la fase de Análisis. El nivel colaborativo o los “internal affairs” como se refiere David Anderson podrian evolucionar positivamente a tal punto que la liquidez se vuelve inherente al sistema de trabajo, es decir se logra un traslape total entre las fases pareciendose al traslape descrito por Takeuchi y Nanaka sobre las compañias tipo B y C en el famoso paper The New New Product Development Game que dió origen a Scrum.

Scrum toma la idea de la célula de manufactura, Kanban en software la toma de habilitar un flujo continuo entre ambas, en todo caso “One-piece flow” es un norte, de acuerdo al contexto un equipo puede mantener la dirección y con el tiempo existirán grados de acercamiento o incluso alejamiento de este norte, es en este último punto donde estarán los principios de Lean y Kanban que son ideales para ayudar a redireccionar a los equipos de trabajo.

 

Comparte...Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+
Manuel Mazán

Manuel Mazán

Fundador de Agiland en el 2010 y Consultor internacional en Metodologías Ágiles e innovación. 20 años de experiencia internacional trabajando en Perú, España, Irlanda y UK. Pionero aplicando el método Lean Kanban en Perú. Manuel ha llevado a cabo transformaciones ágiles exitosas a nivel de equipo y a escala. En el 2015 lideró la transformación ágil de la banca digital en BBVA Continental. Ingeniero de Sistemas (Cum Laude) Universidad de Lima. MBA Ulster University (UK). Certified Scrum Master (CSM), Certified Scrum Professional (CSP), Scaled Agile Framework (SAFe) Program Consultant, Facilitador Management 3.0 y PNL Practitioner. Expositor internacional Lean Kanban Southern Europe 2012 España, Ágiles 2012 Argentina, Ágiles 2013 Perú,Ágiles 2014 Colombia y ScrumDay Perú.
Manuel Mazán
Tagged with: , , ,
Posted in Blog

Enviamos a tu inbox noticias y te mantenemos al tanto con lo mejor de nuestro
BLOG

¡Al suscribirte te daremos acceso inmediato a un caso de estudio tipo "White Paper" y un cupón GRATIS a un curso online!

Leénos en FB !

Algunos testimonios de nuestros cursos

Aprendizaje con casos y dinámicas, perfecto! Usa la experiencia para asimilar conceptos
Jose Luis SánchezTaller de Incepción al Framework Ágil Scrum
Manuel, tiene la facilidad de simplificar los conceptos y pone en práctica lo enseñado de una manera ágil y amena. El entrenamiento logrado ha sido excelente para poder aplicar las metodologías ágiles en los proyectos de desarrollo de software
Carlos PeraltaGestión de Proyectos Lean-Agile
Curso muy Dinámico. El instructor sabe llegar a los alumnos. Casos prácticos que ayudan a entender los conceptos
Kristel NuñezTaller de Incepción al Framework Ágil Scrum
Este es un curso sencillo, claro de entender y muy preciso. Mis expectativas fueron cubiertas en un 100%. Lo recomiendo ampliamente para aquellos que (como yo) se encuentran en proceso de implementar este tipo de metodologías para mejorar su trabajo día con día.        
Jesús V.Principios para entender y aplicar Agile, Scrum, XP y Kanban
Uno de los mejores cursos de metodologías ágiles que he llevado a lo largo de mi carrera profesional, la metodología didáctica y el conocimiento profundo de la materia hace de este curso sea uno de los mas recomendables en su linea.
César Garrido LeccaTaller de Incepción al Framework Ágil Scrum
Este curso me ayudo a entender los diversos conceptos relacionados con el mundo LEAN y me ayudó a darme cuenta que en el proceso actual de desarrollo de software de mi empresa se estaban cometiendo muchas ineficiencias que no generaban valor al producto final. Definitivamente este curso es 100% recomendable.        
Marco CarranzaGestión de Proyectos exitosa con Lean Software Development
Manuel se caracteriza por tener buenos conocimientos en temas de Lean – Agile, los cuales fueron de mucha ayuda para el buen desenvolvimiento del curso, y para ampliar lo ya aprendido, provee buenas dinámicas para poner en practica lo aprendido, comparte conocimientos y consejos, ampliamente recomendado        
Enmanuel MestanzaGestión de Proyectos Lean-Agile
Un curso obligado para comenzar a entender estos conceptos. Muy bien explicado. Me resulta difícil dar una reseña completa del curso porque se presentan varios conceptos nuevos para mi y además se emparejan con conceptos de manufactura, en definitiva debo leer el libro que recomienda al final del curso. La valoración tan alta la doy porque el instructor tiene una excelente fluidez al explicar los puntos tratados y un dominio en los temas que mantiene toda mi atención y crea mayor interés p…
Felipe De Jesús Piña Gestión de Proyectos exitosa con Lean Software Development
El curso me pareció muy interesante y sobre todo dinámico que es lo que me ayudó a entender mucho mejor los fundamentos del Scrum
Francisco CalderónTaller de Incepción al Framework Ágil Scrum
El contenido del curso y la exposición de los temas es muy bueno, cumple con las expectativas del mismo y aporta valiosa información al respecto del tema principal del mismo. Adecuado para aplicar en casos del día a día. Recomendado!        
Hernando RondónPrincipios para entender y aplicar Agile, Scrum, XP y Kanban