1

Desmistificando Kanban y Scrum en el Contexto de Lean, por Manuel Mazán

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 filosofía Lean ya que ataca los ocho tipos de desperdicio identificados dentro de esta filosofía.

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 difícil 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 construcción 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 allí 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 esencial 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 raíz 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 filosofía “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 trasladados 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 nivel de desarrollo de software existen limitaciones, y a veces no es posible lograr el ansiado “one piece flow”. Los equipos y empresas deben acomodar las cosas a su realidad y no forzar un modelo ideal que podría no adaptarse a su cultura. “One-piece flow” podría ser utópico y requerir mucha disciplina o simplemente podría carecer de sentido aplicarlo en determinado contexto. El contexto ideal para que funcione Scrum o XP podría no encontrarse en una organización ahora ni nunca. Ni tampoco estar disponible un ScrumMaster con la habilidad para que lo haga sostenible acompañando al equipo en un proceso de mejora continua. Y si estas condiciones se dieran finalmente los equipos como sistemas adaptativos complejos que son cambian, se va o viene gente, se trabaja onshore/offshore, etc como es usual podríamos contar con un mix de habilidades que no necesariamente están preparadas para atender la demanda. Vivimos en un mundo imperfecto y tenemos que adaptarnos. Es común encontrar equipos atendiendo demanda de distinta naturaleza.

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 podría 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. One-piece flow podría funcionar muy bien, hay bastante evidencia pero también podría en ciertos contextos ser utópico.

La evolución de Kanban orientado al desarrollo de software implica que aparezcan en equipos maduros lo que yo 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. Aún veo que hay mucho por descubrir allí 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 propósito 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 más colaboración nos vamos aproximando a one piece flow, aún 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 podrían 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 pareciéndose al traslape descrito por Takeuchi y Nanaka sobre las compañías tipo B y C en el famoso paper The New New Product Development Game que dio 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.


Artículo redactado por Manuel Mazán.
Manuel es Consultor internacional en metodologías ágiles e innovación. Puedes seguir sus tweets o ver su perfil profesional.
Original reproducido aquí con autorización del autor.


Tags:
Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273