Meetup: Kanban con José Casal

En esta charla, José Casal nos mostrará como podemos usar los principios y las prácticas del método Kanban para mejorar nuestro ambiente de trabajo.

Como ejemplo, José usará un equipo de gestión de proyectos y compartirá ideas sobre como la visualización, la limitación de trabajo en curso, el control de flujo, etc. nos ayuda a mejorar considerablemente nuestros resultados de negocio asi como el disfrute de nuestro trabajo.

Esta será una charla informal y esperamos que los participantes contribuyan con sus observaciones, experiencia e ideas.

Viernes 30 de Octubre desde las 19:00 hasta las 21:00 horas
En las oficinas de Nisum Chile, Apoquindo 4700 Piso 14, a pasos de la estación de metro Escuela Militar.

Jose Casal-Gimenez (Español, trabaja en Escocia): Asesora al gobierno Escocés en metodologías para desarrollo de productos digitales, es uno de los charlistas internacionales que vienen a la StarTechConf.

Gracias a todos por asistir! Estuvo genial la charla. Gracias José Casal por compartirnos tu charla, aquí los slides:

2 Me gusta

varios momentos “A ha” en la charla

1 me gusta

Muchísimas gracias a todos por vuestra asistencia y participación en la conversación.

Para mi es sensacional establecer un intercambio de opiniones y observaciones entre todos los que estamos en la sala.

100%'de acuerdo, gracias José por esta charla magiatral., nos faltó tiempo para navegar todos los temas.

De especial importancia me pareció kaizen, la mejora continua., partir de donde estamos actualmente e ir mejorando de a poco.

Según he leído es mejor partir de Scrum con XP, que son más rígidos, y a partir de ahí ir mejorando con kanban.

Ahora bien si al fin y al cabo todas las metodologías ágiles son los mismo y lo único que cambia es el énfasis, cual es el énfasis de kanban?

Hace muchos años leí que kanban usa tarjetas en los ambientes de manufactura de manera de no tener demasiado stick en proceso. La idea es que en cada estación de trabajo nada esta “por hacer” y todo esta “hecho”.

De esa manera nadie trabaja a menos que su " bandeja de salida" se vacíe (o este medio vacia).

Y como no tiene en su bandeja de entrada nada por hacer, porque de hecho no existe la bandeja de entrada, entonces se ve obligado a buscar bandejas de salida de otros con lo que el necesita. En realidad es lo mismo que la bandeja de entrada, salvo que no puedes reservar “esto lo voy a hacer yo”.

Tu muy bien mencionaste que en un proyecto kanban la gente esta en su mayoría desocupada, de modo que cuando alguien tiene que hacer un batch, levanta una bandera y el resto le ayuda, con el único fin de rellenar su bandeja.

Esto implica que el cliente nunca esta esperando, el flujo siempre es just in time.

Tu mencionaste que el trabajo no podía estar mucho tiempo amedio terminar, esperando para continuar, porque quedaba desactualizado, entonces concluiste, hay que evitar el trabajo a medio hacer porque eso es desperdicio cuando queda desactualizado. Suena razonable… Pero quede pensando esto último y tiene varios problemas:

  1. Contradice el just in time. Si para entregar una historia de usuario tengo que ir hasta el principio y hacer todo el proceso, estamos hablando de al menos 2 semanas para que pase a producción, eso implica que no voy a entregar nada en 2 semanas. Llevado a la reposición de una coca cola en una vending machine, cada vez que alguien compra una coca cola, voy a plantar los ingredientes de la coca cola… Me voy a demorar meses en reponer esa coca cola.

  2. El argumento de que el trabajo a medio hacer es desperdicio, es cierto, puede quedar desactualizado y eso sería un desperdicio, pero es mayor desperdicio si lo término y queda desactualizado. ?como se maneja esto en la vida real? Lo que yo haría sería marcar ese trabajo a medio terminar como “no seguir, esta en proceso de actulizacion” y seguimos inmediatamente con otro… Ese proceso de actualizacion es simplemente una tarea en el kanban board y el trabajo sobre la mina debe tener una marca que diga “bloqueado”.

Esto podría parecer que contradice la filosofía de kanban, ya que la idea esantener el flujo. Si la tareas que están en proceso intermedio deben ser suficientes para continuar y no interrumpir el flujo, y suponiendo que las tareas deben ser actualizadas el 50% de más veces (ie: no sabemos) entonces automaticamente debemos tener el doble de tareas esperando pasar de un proceso al siguiente.

Esperó que les haya resultado interesantes las disquisiciones metafísicas.

Hola Guillermo,

Muy buen artículo. Voy a intentar comentar en algunos de los temas, pero es posible que algunos de ellos necesiten una pizarra blanca y hablar en persona :smile:

Como siempre aviso: Lo que expongo en esta respuesta son opiniones personales y, como tal, se que no estoy en la posesión de la verdad. Es mas, espero que alguien me contradiga y me ayude a seguir avanzando en mis conocimientos y aprendizaje!

Lo importante, para mi, es entender el contexto actual de la empresa y, a partir de ahí, empezar a buscar la mejora.

Planteemos el punto de partida con los 2 primeros principios de Kanban en la mente:

  1. Empieza donde estes ahora
  2. Acuerda la busqueda del cambio evolutivo

Si es una empresa tradicional, mi experiencia me dice que intentar empezar por Scrum puede ser un cambio demasiado sustancial. Sobre todo porque la mentalidad y la formas de trabajo de trabajo son muy diferentes entre el modelo tradicional y Scrum.

Siguiendo la explicación que usamos en el curso de Kanban, hay tres aspectos:

  • La mejora de los servicios que ofrecemos (service delivery)
  • Ser un catalizador de la mejora continua
  • Generar una evolucion del negocio hasta llegar a ser “fit for purpose” (Proposito adecuado?)

Aqui tengo que hacer una aclaración muy importante que creo que contribuye de una forma regular a generar problemas en un nuestra industria.

Es un error comparar lo que se hace en la industria de manufactura con la industria del conocimiento

Vistas desde la Ciencia de la Complejidad en el Ambiente Empresarial, la industria de manufactura y la industria del conocimiento (TI, por ejemplo) no son equivalentes.

Usando el modelo de Cynefin (http://cognitive-edge.com/), la manufactura trabaja en un ámbito complicado, mientras una empresa de TI suele trabajar en un ámbito complejo. Ante tal situación, usar prácticas creadas para el ámbito complicado en un ámbito complejo es un error que tiende a dar malos resultados.

Como ejemplo de esto, usar los métodos de gestión Tayloristas (cadenas de montaje con gestores y trabajadores) en el software es un error muy extendido. Es a lo que hoy en dia nos referimos como Gestión Tradicional, en cascada o waterfall.

En el caso de Kanban, existe el concepto de Kanban en manufactura. Pero el Método Kanban de David J Anderson es una adaptación a trabajos complejos en empresas del conocimiento. (como nota interesante, la David J Anderson llegó a plantearse recientemente cambiar el nombre para evitar este tipo de confusión)

Otro apunte, una gran diferencia entre la manufactura y el software es la VARIABILIDAD en el producto.

  • En la manufactura buscamos eliminarla como podamos (la base de Six Sigma) y esperamos que todos las piezas que salen de la cadena de montaje sean prácticamente iguales
  • En el software, la variabilidad es grande, innata y necesaria. Si todos el software que hacemos fuese igual, lo bajariamos de Google y no harían falta ingenieros informáticos. La realidad es que cada producto de software que creamos, lo creamos precisamente porque hace algo nuevo. Es el Valor Áñadido (o USP).

Para esto querria tener una un pizarra!

El concepto de Just-in-time creo que es más un ideal que una realidad. Incluso en las fábricas más avanzadas en el mundo de Lean (Toyota, por ejemplo) trabajan con un número reducido de inventario, pero sin llegar al “just-in-time”

En el software, el just-in-time como lo describes seria extraordinariamente ineficiente. Sobre todo por la variabilidad que tenemos en nuestro trabajo.

Refiriendome a la práctica de Kanban de “Gestionar el Flujo de Trabajo” a lo que me refería es que solemos tener distintos trabajos (tickets) en marcha, pero en todas las fases de nuestro sistema. Como hay variabilidad, solemos introducir buffers (amortiguadores) o queues (colas de espera) para que el trabajo pueda fluir sin parones ni atascos. Tambien usamos los limites de WIP (trabajo en curso) para mantener un flujo regular a traves de nuestro sistema.

Usando el ejemplo de la coca-cola que usas, en un sistema Kanban, el equipo estaría sirviendo latas, reponiendo latas, creando latas, produciendo el liquido, cultivando lo ingredientes, etc. en todo momento…pero de una manera equilibrada para que ninguna fase de la producción tenga sobre-producción (de nuevo, lo que llamamos “Gestionar el Flujo”)

Si alguien quiere explorar todo esto, os recomiendo 2 lecturas:

Estoy de acuerdo contigo. Si somos conscientes que un trabajo que está en marcha esta desactualizado, mejor pararlo y actualizarlo que seguir y entregar algo que no queremos. Lo importante en este caso es estudiar las causas de que haya llegado a desactualizarse y evitarlas.

Una cosa que si que es necesario ensalzar es que en un sistema Kanban, cuando un ticket (requerimiento, feature, historia de usuario, etc) es aceptado en el sistema, el equipo genera una promesa:

“Queremos completar este trabajo y queremos hacerlo en el menor tiempo posible”

Con esto en mente, y en paralelo con el movimiento Ágil, la velocidad de entrega (Lead Time en Kanban) es importante y dos de los factores principales en el Lead Time son:

  • El tamaño de cada ticket. A menor tamaño, más velocidad de entrega (y mas compresión de lo que hay que entregar)
  • El número de trabajo en curso. A menos trabajo en curso, más rápida es la entrega (y de más calidad).

OK. Lo dejo hasta aquí o escribo una novela de varios tomos :smile:

Espero que mis comentarios tengan sentido!

Saludos

Jose

2 Me gusta

Si, José esta genial, gracias por tus aclaraciones, me hicieron mucho
sentido.

De hecho recuerdo vagamente que en tu polera decía no acumular cosas por
hacer sino cosas hechas, lo que recordó mucho lo que había leído de kanban.
Aunque ahora parece que te contradices con esa idea, porque entonces
seríamos repositorios de software ya construido y no tendríamos tantos
proyectos “por hacer”.

Desde un punto de vista simple, de optimización económica global, tiene
mucho sentido que todo el software ya este construido y uno fuera
simplemente juntando las piezas y armando algo más grande.

Desde el punto de vista de los trabajadores del conocimiento probablemente
no tenga sentido si nos pagan por hora, pero si recibiéramos millones de
dólares por el trabajo terminado, yo si lo haría…

El repositorio tendría que ser enorme eso si, y tendríamos que ser los
únicos con acceso a el, porque si todos pueden entrar y hacer lo mismo, nos
vuelven a pagar por hora y se convierte en un mal negocio.

Me interesó mucho lo que dijiste, esa idea de que nuestro trabajo se basa
en la variación ya se lo había escuchado a la gente de XP. Que básicamente
si algo ya esta hecho, hacerlo de nuevo de manera idéntica tiene un valor
de exactamente $0. Y como no te puedes demorar 0 segundos, tiene
necesariamente productividad negativa.

Esto se debe a que el software es diseño. Como el diseño de un nuevo avión
o el diseño de un nuevo auto, una vez terminado el diseño, hacer otro
diseño idéntico tiene exactamente valor cero.

Cuando haces cambios en el diseño es cuando puedes agregar valor.

Otro tema interesante:

“Usando el ejemplo de la coca-cola que usas, en un sistema Kanban, el
equipo estaría sirviendo latas, reponiendo latas, creando latas,
produciendo el liquido, cultivando lo ingredientes, etc. en todo
momento…pero de una manera equilibrada para que ninguna fase de la
producción tenga sobre-producción (de nuevo, lo que llamamos “Gestionar el
Flujo”)”

Acá veo una diferencia con lo que leí.

El objetivo de kanban es estar desocupado,es decir, llenas tu bandeja de
salida rapidamente y te desocupas.

Al estar desocupado, permites que cuando alguien tiene mucho que hacer,
todos los que están desocupados tiene tiempo libre y pueden ayudarle.

Eso permite que todos los “trabajos en proceso” o "bandejas de salida"
estén siempre llenas… Eso permite siempre mantener el flujo y tener just
in time.

Aquí el video de la charla de José (un extracto)

1 me gusta