Retrospectivas y Revisión de Operaciones en Sistemas Kanban

Para entender patrones de calidad y productividad en un equipo de trabajo no solo tenemos que remontarnos a revisar conjuntamente hechos importantes tales como cambios en el equipo mismo o cambios a nivel organizacional.

Tampoco se puede ignorar el aspecto emocional. Aquellos momentos donde el equipo o alguien en particular se sintió presionado, estresado, confundido, quizás con temor. No menos importantes también son aquellos momentos donde se sintieron productivos, energéticos, efectivos y motivados.

La Indagación Apreciativa es una práctica eficaz para lograr el cambio desde una perspectiva holistica enfocandose en los aspectos positivos de las personas y potencializándolos para corregir aspectos negativos.

Algunos psicólogos terapistas utilizan esta técnica para ayudar a descubrir soluciones basándose en signos tangibles de momentos positivos dentro del contexto de los problemas de sus pacientes.

La indagación apreciativa fusiona el pensamiento sistémico, la visualización, la psicología positiva, design thinking, dinámica de sistemas complejos, ley de atracción, ontología del lenguage, inteligencia emocional y neurociencias entre otras.

El objetivo es que los pacientes identifiquen las situaciones excepcionales dentro de sus patrones de comportamiento para que ellos mismos analicen lo que hicieron distinto para lograr esa situación positiva y por un momento considerar una posible solución a su problema.

Personalmente me gusta mucho realizar experimentos con ideas y conceptos de disciplinas que no tienen nada que ver con software o tecnología y qué mejor que el método Kanban para facilitar ese contexto de experimentación. Si quieres ahondar mas sobre experimentos en proyectos con Kanban te recomiendo te bajes mi caso de estudio sobre Lean y Kanban aplicado a un proyecto caótico.

En el caso de una retrospectiva que facilitamos con un cliente luego de introducir Lean y Kanban en el área de soporte y desarrollo, dibujamos una linea de tiempo para examinar conjuntamente la evolución del equipo y comprender por qué llegaron a un punto donde estaban sumerjidos en actividades de soporte sin poder atender y terminar requerimientos estratégicos.

Aunque era evidente la cultura “apaga-incendios” e interrupciones  que impedian al equipo avanzar se examinaron hechos y emociones especificos que permitieron la emergencia de tanto patrones positivos como negativos en el pasado.

La intención se centró en tratar de reforzar aquellas situaciones excepcionales donde hubieron signos de productividad y energia. Este tipo de retrospectivas con base anecdótica y emocional son cruciales como parte del proceso de mejora continua de los equipos de trabajo y deben hacerse frecuentemente.

Retrospectiva Avanzada Kanban

Cuando nos referimos a una revisión de las operaciones del área conjuntamente con la gerencia, la realidad es que en este tipo de sesiones hablar de la parte anecdótica y emocional del cambio tiene poca relevancia para los stakeholders y allí es donde quisiera centrar este artículo.

 Revisión de las Operaciones de Soporte de TI

Veamos algunas estadisticas interesantes para la gerencia con el objetivo de sustentar que es lo que ocurrió con la operación en lo que respecta a soporte TI al día 38, pero antes si no tienes muy en claro como se interpreta un diagrama de flujo acumulativo te recomiendo el blog post de Pawel Brodzinski. 

Pawel explica qué está sucediendo en un proyecto desde distintas perspectivas del comportamiento del diagrama. Si quieres algo mas light te recomiendo que leas mi post sobre el Ball Flow Game para simular sistemas Kanban.

¿Qué podemos inferir en el diagrama de abajo? Aunque esto no se refleja en el gráfico la demanda se clasificó en tres clases de servicio (entrega de fecha fija, estandar y expeditos). El diagrama de flujo acumulativo presentado abajo es simple, sin embargo en esta muestra de 38 días  existen algunos aspectos relevantes:

 

Diagrama de Flujo Acumulado

El backlog de soporte ha ido disminuyendo a partir del dia 26 (franja naranja mas delgada). En menos de 4 semanas se ha identificado y atacado progresivamente la raiz de los problemas mas críticos, por ejemplo equipos de hardware que fallaban frecuentemente fueron reemplazados por equipos nuevos.

Desde un inicio se atacó la demanda fallida (failure demand). La demanda fallida es todo aquello que consume capacidad del equipo que de otra manera hubiese podido ser utilizada para completar trabajo de valor. Adicionalmente tuvimos dentro de esta categoria fallas de hardware recurrentes, defectos en el sistema o incluso tareas repetitivas candidatas a automatización.

Un ejemplo claro de esta última categoría fueron requerimientos de ajustes dentro de la base de datos para acomodar pedidos de clientes con características especiales. Para eliminar esta demanda se ha introducido al backlog del producto un item que permitirá al usuario hacer este tipo de cambios desde la interfaz del sistema.

Se gestionaron las interrupciones logrando un mayor foco en terminar items de soporte adecuadamente de principio a fin en vez de comenzar mas trabajo introduciéndolos al kanban. La calidad del soporte mejoró notablemente con políticas explícitas y el hecho de limitar la cantidad de trabajo en progreso permitió reducir el tan venerado pero a la vez traicionero multitasking.

El gráfico de abajo muestra como ejemplo la evolución de la carga de trabajo pendiente de hardware por día hasta el día 38 y se puede apreciar como esta ha ido disminuyendo.

evol cant hw al dia 38

Vale decir que las conversaciones con la gerencia para solicitar un cambio en el parque tecnologico eran anecdóticas antes de implementar Kanban ya que no existia data cuantitativa ni estadisticas que soporten esta decisión.

El gráfico de abajo muestra el promedio diario de carga de trabajo pendiente lo cual indica que la demanda de software representa la mayoria de la demanda al dia 38, esa tendencia se revirtió ya que hasta hace poco el hardware la superaba.

kanban carga de trabajo soporte

Si le echamos un vistazo a la relación entre el WIP (Work in Progress – Trabajo en Progreso) y Lead Time se puede apreciar que al aumentar el WIP a partir del dia 30 el Lead Time promedio aumenta mostrando una tendencia mas o menos proporcional y eso se debe a que a mas items en progreso mas tiempo tardan estos en terminarse. Esto se entiende con la Ley de Little y la teoría de colas.

Kanban WIP y Lead Time promedio

 

Sin embargo se puede apreciar también que a partir del dia 35 el Lead Time promedio tuvo tendencia a lograr estabilizarse mientras que el equipo se adecuó a planear su capacidad para atender una mayor cantidad de items por día. La figura no podria explicarse mejor si no revisamos el gráfico de Tasa de Entrega a partir del dia 32 la tendencia es a entregar mas items en un contexto donde el equipo gestiona su demanda de manera mas eficiente con un enfoque en valor (mejoras puntuales en el sistema). Contamos ahora con un equipo en camino de ser mas productivo y efectivo.

Throughput

Revisión de las Operaciones de Desarrollo

Estas estadisticas de desarrollos nuevos se recopilan semanalmente. A poco mas de un mes se llevó a cabo la revisión de operaciones que incluyó Soporte y Desarrollo con la gerencia pero para cuestión de ilustrar mejor examino aquí 23 semanas de desarrollo.

El diagrama de flujo acumulativo abajo en general muestra que comparado con otras fases, el trabajo pasa la mayor parte del tiempo en la etapa de desarrollo (franja amarilla).

Diagrama Flujo Acumulativo Kanban desarrollo

Considerando que es un equipo pequeño donde los desarrolladores también hacen analisis y testing lo mas llamativo de este diagrama es que tienen mucho trabajo en progreso en la cola de desarrollo al menos hasta la semana 6. Se repite este patrón desde la semana 13 hasta la 18.

De la semana 12 a la 15 se puede apreciar que el equipo no entregó nada para de alli entregar una cantidad alta de items de golpe en la semana 16 (Producción – en celeste indica trabajo entregado). Por el tamaño de la cola de análisis (franja gris) es probable  que el equipo se preocupara mas en comenzar trabajo y no terminar lo que tenian ya en progreso. Habría también que analizar el log de interrupciones para ver si se dejó trabajo en desarrollo para atender soporte.

La relación entre el WIP (Work in Progress) y Lead Time de desarrollos nuevos muestra picos en la cantidad de trabajo en progreso que finalmente impacta en el Lead Time promedio. El Lead Time a partir de la semana 9 tiende a estabilizarse con rangos promedio de entrega de entre 1 a 3 dias lo cual indica que los requerimientos fueron pequeños o que han asignado mas capacidad a atender desarrollos nuevos.

WIP and Lead Time avg dev
Finalmente abajo se muestra la tasa de entrega de items de nuevos desarrollos que se calcula a unos 3.5 items por semana que no está mal considerando que se trata de un equipo pequeño que reparte su capacidad entre demanda de soporte y desarrollos nuevos. El pico de entrega de 10 items en la semana 15 corresponde al comportamiento de la gráfica en el diagrama de flujo acumulado en el mismo periodo.

kanban tasa entrega x sem des

 

Conclusiones

En este post no pretendo hacer un análisis exhaustivo de lo que sucede en una revisión de operaciones de sistemas de trabajo basados en Kanban pero si pretendo proporcionar información suficiente en base a mi experiencia para ilustrar las bases de un proceso de mejora continua con data cualtitativa y cuantitativa.

La demanda fallida tiende a eliminarse con la mejora continua y un mejor entendimiento de cómo la capacidad disponible puede atacar los problemas sistémicos temprano.  La data cuantitiva es muy facil de recopilar a partir del tablero kanban y los gráficos se arman rápidamente en Excel o Google Spreadsheets.

Es típico de algunas empresas peruanas que un mismo equipo distribuya su capacidad para atender demanda de desarrollos nuevos y demanda de soporte de TI. Luego ocurre muchas veces que el soporte TI y la demanda fallida terminan absorbiendo gran parte de la capacidad del equipo llegando a no entregar el valor esperado por la gerencia. La consecuencia es que el área de TI pierde su sentido estratégico.

Es común también que las decisiones de incremento de la capacidad de los equipos permanezca como una decisión anecdótica sin soporte de ninguna estadística o data cuantitativa de la operación.

En base a data y estadísticas el área sustenta a la gerencia la necesidad de incrementar el tamaño del equipo humano. A su vez el equipo es capaz de sustentar la capacidad dedicada al desarrollo de productos e innovación.

Una revisión de operaciones permite analizar toda un área desde el punto de vista sistémico. Las métricas e indicadores relevantes permiten a la organización lograr Kaizen en su área y llevar esa cultura de mejora continua a otras áreas de la organización.

Gran sorpresa me llevé luego de tres semanas en las que las áreas de Licitaciones y Marketing tuvieron la iniciativa de armar su tablero kanban para visualizar su flujo de trabajo. No hay duda que Kanban tiene poca resistencia a ser adoptado en áreas fuera de TI al menos comenzando con la gestión visual del trabajo que es el punto de partida para mejorar los procesos.

Me gustaría saber sobre iniciativas con sistemas Kanban en Perú donde al evaluar DevOps pasaron de lo puramente anecdótico a combinarlo con estadisticas convincentes.

 

 

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. Casi 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

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 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
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
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 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
Curso que explica de manera clara las bases fundamentales para llevar acabo un proyecto de software de manera exitosa, ideal para aquellos que nos encontramos inmersos dentro de la gerencia de proyectos. Este curso toca temas y problemas reales con los que uno tropieza al liderar proyectos de este tipo. Buen curso.        
Christian DelgadoPrincipios para entender y aplicar Agile, Scrum, XP y Kanban
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
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
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
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