Han pasado ya 24 años desde la creación y formalización del Manifiesto Ágil, un documento fundamental en el mundo del desarrollo de software, considerado por muchos como las “Tablas de Moisés” de la informática. Este manifiesto fue elaborado en Estados Unidos por un grupo selecto de expertos en Tecnologías de la Información (TI) y marcó un antes y un después en la forma de gestionar proyectos.
El propósito de este blog es analizar la evolución de la Filosofía Ágil en el ámbito de la Mejora Continua, un campo en el que, como bien sabe, PXS es líder.
Para comprender a fondo este tema, es fundamental abordar dos aspectos clave:
- Qué es realmente el Agilismo
- ¿Cuál es su origen?
Con frecuencia, encontramos prácticas que se autodenominan “ágiles” sin realmente serlo. Mi intención con este artículo es ayudarle a identificar qué enfoques aplican genuinamente los principios ágiles y cuáles, en realidad, no lo hacen.
Agile se fundamenta en cuatro valores y doce principios. Los valores establecen un enfoque general y estratégico, mientras que los principios proporcionan un enfoque táctico, accionable y específico. Lo más relevante es que los doce principios derivan directamente de los cuatro valores, formando un marco coherente y estructurado.
A continuación, repasemos cada uno de ellos:
Valor | Explicación |
---|---|
1. Individuos e interacciones sobre procesos y herramientas | Este valor prioriza a las personas y su colaboración, porque son quienes realmente impulsan los proyectos y resuelven problemas. Los procesos y herramientas son importantes, pero no deben sustituir la comunicación y el entendimiento humano. |
2. Software funcional sobre documentación extensiva | El enfoque está en entregar un producto que funcione y cumpla con los requisitos del cliente. La documentación es útil, pero no debe retrasar el progreso o convertirse en un fin en sí misma; debe ser lo suficientemente útil para el propósito del proyecto, sin ser innecesariamente detallada. |
3. Colaboración con el cliente sobre negociación contractual | En lugar de solo seguir estrictamente un contrato, se fomenta una relación de colaboración continua con el cliente. Esto permite adaptarse mejor a cambios en las necesidades del cliente, asegurando que el producto final sea relevante y de valor. |
4. Respuesta al cambio sobre seguir un plan | Aunque planificar es importante, es fundamental ser flexibles y adaptarse a los cambios cuando sea necesario. Los planes no deben ser rígidos, ya que los proyectos son dinámicos y las condiciones pueden cambiar, especialmente en entornos de alta incertidumbre. |
Los cuatro valores del Manifiesto Ágil contienen elementos esenciales que, si realmente buscamos fomentar una cultura ágil, pueden resumirse en palabras claves más fáciles de similar y aplicar. En un contexto más amplio, fuera del ámbito informático, el Agilismo puede expresarse de la siguiente manera:
- Priorizar lo humano
- Priorizar lo funcional
- Colaboración continua
- Adaptabilidad
Si analizamos estos valores desde una perspectiva organizacional, podemos notar que fomentar una cultura ágil no es un concepto complejo en sí mismo. Esto no significa que su implementación sea sencilla, pero sí deja claro que cualquier gerente debería reconocer la importancia de desarrollar una cultura organizacional alineada con estos cuatro principios. En el mundo de los negocios actuales, lograrlo no es solo deseable, sino esencial para la competitividad y la innovación.
El desafío radica en que la implementación del Agilismo no es sencilla. Para empezar, existe una barrera significativa al intentar trasladar sus valores más allá del contexto informático. No podemos olvidar que el Agilismo nació en entornos de desarrollo de software, lo que implica que, para aplicarlo en otros ámbitos empresariales, primero es necesario interpretar y adaptar sus principios. Además, no basta con comprenderlos; Es fundamental saber cómo desplegarlos y respetarlos en la práctica.
Si analizamos los valores en profundidad, el primero —priorizar lo humano— se enfrenta hoy en día a un reto importante: la fuerte adopción del teletrabajo. El Manifiesto Ágil nunca contempló escenarios como una pandemia global, y en el mundo empresarial se discute cada vez más que el teletrabajo puede estar debilitando las culturas organizacionales y el trabajo en equipo, al incentivar indirectamente el individualismo.
Es importante reconocer que no todo el trabajo puede ejecutarse desde una computadora en casa. Existen dinámicas sociales e interacciones que se pierden o se debilitan considerablemente en entornos virtuales. Un ejemplo claro es la dificultad de realizar sesiones efectivas de análisis de causa raíz mediante tormentas de ideas. En un entorno presencial, un facilitador puede guiar el proceso, observar el lenguaje no verbal de los participantes y asegurarse de que todos estén plenamente comprometidos. En cambio, en sesiones virtuales, la atención se dispersa fácilmente y la calidad del análisis tiende a deteriorarse.
No digo que sea imposible lograr buenos resultados en un entorno remoto. Con equipos altamente maduros y hábiles, es factible. Sin embargo, la evidencia empírica sugiere que los resultados suelen ser mediocres en comparación con los obtenidos en sesiones presenciales. Por lo tanto, es crucial reconocer que, si bien el Agilismo sigue siendo un marco valioso, su aplicación en el contexto actual requiere ajustes y estrategias adicionales.
El análisis del segundo valor del Manifiesto Ágil no es complicado en esencia: lo fundamental es que el producto funcione o que el servicio prestado sea satisfactorio. En otras palabras, el fondo es más importante que las formas. Sin embargo, es importante reconocer que las formas son las que construyen el fondo.
Existen muchas formas de abordar este principio. Ágil es un enfoque general, mientras que Scrum, Lean, Seis Sigma y otros marcos metodológicos representan formas específicas de aplicarlo. Aquí surge una pregunta crítica:
¿Cuál es la forma más apropiada para alcanzar el resultado que necesito?
La respuesta no es sencilla, ya que ingresa al juego. Múltiples factores que pueden influir en la elección del enfoque adecuado.
En mi experiencia como auditor de calidad en sistemas de gestión empresarial, lideró equipos de auditoría y constató de primera mano este desafío. Un aspecto que siempre me ha preocupado es garantizar que los resultados de las auditorías sean adecuados, es decir, que los hallazgos identifiquen incumplimientos basados en normas de calidad y evidencia verificable.
Sin embargo, observe un patrón recurrente: los equipos de auditores tienden a enfocarse en los aspectos que les resultan más atractivos o que comprenden mejor, dejando de lado aquellos que les resultan más complejos o menos interesantes. No es lo mismo auditar un proceso de I+D altamente innovador que una gerencia financiera, donde predominan números y prácticas técnicas que pueden resultar ajenas a su conocimiento.
Como mencionaba antes, encontrar la “forma óptima” para realizar auditorías de manera efectiva es un reto complejo. Esto implica:
- Seleccione la técnica de auditoría adecuada.
- Contar con conocimientos complementarios para evaluar correctamente cada área.
- Desarrollar la habilidad para identificar hallazgos clave en cualquier tipo de proceso.
En definitiva, la elección de la metodología más adecuada dependerá del contexto, los objetivos y las capacidades del equipo, lo que refuerza la idea de que no existe una única solución universal, sino que se requiere criterio, experiencia y adaptabilidad para aplicar el enfoque más efectivo.
Otro ejemplo altamente relevante es la Administración de Proyectos. Durante décadas, la evolución en la gestión de proyectos fue mínima. La máxima autoridad en el campo, el Project Management Institute (PMI), mantuvo su guía de mejores prácticas prácticamente sin cambios durante años. Esto resultó ser un grave error, ya que las necesidades de los Project Managers estaban evolucionando, impulsadas por la creciente sofisticación de los objetivos y resultados esperados por los clientes.
El impacto fue claro: cientos de Project Managers abandonaron su certificación PMP en busca de enfoques más flexibles y adaptativos.
Podemos comparar dos tipos de proyectos:
- Proyectos Predictivos (clásicos): Aquí el reto técnico es fácil o altamente conocido. A lo largo del ciclo de vida del proyecto, los cambios son mínimos y el contrato establece claramente los requerimientos y el resultado final con cierta predictibilidad.
- Proyectos Adaptativos (modernos): En estos casos, los clientes no tienen una visión clara del resultado final desde el inicio. La ejecución del proyecto implica un alto nivel de incertidumbre, ya que muchas veces se requiere inventar, crear y explorar nuevas soluciones para alcanzar los objetivos esperados.
En el contexto actual, la gestión de proyectos carga con una gran dosis de incertidumbre. Por ello, aspectos como la funcionalidad del producto, la participación activa del cliente y, sobre todo, la adaptabilidad a los cambios se ha convertido en elementos clave para el éxito.
Este cambio de paradigma explica por qué muchas organizaciones han migrado hacia metodologías ágiles y flexibles, reconociendo que la planificación rígida y la predictibilidad absoluta son cada vez menos viables en un mundo empresarial en constante evolución.
Si analizamos la colaboración continua y la adaptabilidad desde una perspectiva práctica, una excelente manera de garantizar los resultados es asegurarnos, durante la ejecución, de que realmente estamos cumpliendo con las expectativas. La Agilidad se basa en la entrega constante de valor, y en este punto es donde debemos aprender lecciones clave. En PXS, como es posible que sepa, ofrecemos una amplia gama de cursos de capacitación empresarial. Durante años, aplicamos una evaluación de satisfacción al finalizar cada curso, lo que nos permitió medir el desempeño de nuestros instructores y la calidad de la formación. Sin embargo, con el crecimiento de nuestra oferta y la incorporación de nuevos profesores, nos dimos cuenta de que esperar hasta el final para evaluar la experiencia del cliente no era lo más efectivo. En algunos casos, encontrábamos cursos con evaluaciones no tan favorables cuando ya no había margen de acción, lo que significaba que el cliente insatisfecho simplemente no regresaba a comprar y, lo más preocupante, se ponía en riesgo nuestra misión de excelencia. Para abordar esta situación, implementamos técnicas del agilismo, como las ceremonias de retrospectiva durante las clases, lo que nos ha permitido identificar y corregir aspectos que afectan la calidad en tiempo real. Gracias a esta práctica, hemos logrado mejorar significativamente las calificaciones de nuestros cursos y garantizar una mejor experiencia para nuestros clientes.
Malas prácticas
El tema central que quiero discutir a continuación es qué realmente es el Agilismo y qué no lo es. La palabra en sí resulta muy atractiva en nuestro idioma. ¿A quién no le gustaría ser ágil, ya sea físico o mentalmente, para resolver problemas, conducir un auto o enfrentar cualquier reto? Incluso en el ámbito corporativo, la palabra “ágil” genera interés y entusiasmo entre muchos gerentes y líderes.
Sin embargo, observe que esta percepción ha llevado a muchas empresas a adoptar prácticas erróneas en nombre del Agilismo, aplicándolo de manera ineficiente o equivocada. Algunos ejemplos que he visto de primera mano incluyen:
- Evitar la planificación , bajo la creencia de que ser ágil significa actuar de inmediato sin perder tiempo en diseñar una estrategia.
- Tomar decisiones sin sustento estadístico , justificándolo con la urgencia de resolver algo rápidamente.
- Eliminar o reemplazar métodos efectivos simplemente por preferencia personal o porque “hacerlo de manera ágil es mejor”.
- Omitir el uso adecuado de técnicas específicas , descartándolas por no considerarlas ágiles.
Gestionar cambios de manera antojadiza, sin analizar el impacto o las consecuencias de su implementación. - No documentar acciones importantes , argumentando que el Agilismo se opone a la sobredocumentación, cuando en realidad cierto nivel de documentación es necesario, especialmente en decisiones basadas en cálculos o análisis.
- Realizar cualquier acción que no pueda trazarse directamente a los cuatro valores ágiles .
Frente a esto, cabe preguntarse: ¿cuántos de nosotros realmente nos detenemos a reflexionar si una acción que proponemos es verdaderamente ágil? [1] La clave del Agilismo no está en hacer las cosas apresuradamente o sin estructura, sino en encontrar un equilibrio que permita entregar valor de manera continua, eficiente y con sentido.
Veamos algunos ejemplos de este razonamiento. Responda mentalmente si considera que cada acción propuesta realmente representa el Agilismo:
- Permitir cambios constantes en el presupuesto anual de la empresa.
- Sustituir agentes de call center por robots automatizados para la atención al cliente.
- Incorporar a un nuevo empleado en su puesto lo más pronto posible, sustituyendo una inducción formal por una informal.
- Dejar un contrato con términos generales para facilitar cambios en caso de ser necesarios.
- Reunir constantemente al cliente con el equipo del proyecto para evaluar cómo se está ejecutando el trabajo.
- Permitir que el equipo del proyecto lidere su trabajo en lugar de depender de un Project Manager.
Muchas veces nos quejamos de la rigidez de los presupuestos, y flexibilizarlos durante su ejecución podría verse como una aplicación del Valor 4: Adaptabilidad. Sin embargo, al mismo tiempo, implica negociar con la gerencia financiera, lo que también se relaciona con el Valor 3: Colaboración continua, ya que en muchos casos los ajustes presupuestarios tienen justificaciones de negocio válidas. En este sentido, la esencia del Agilismo no es solo cambiar, sino cambiar con propósito y de manera colaborativa.
En el segundo caso, es común ver cómo la automatización y el uso de robots en la atención al cliente se presentan como sinónimos de Agilismo. Sin embargo, esto es un error frecuente. Ser tecnológico no significa ser ágil. Una de las quejas más recurrentes de los clientes es precisamente la deshumanización del servicio. Lean Manufacturing maneja el concepto de Jidoka, que significa automatización con un toque humano. Este principio deja claro que la tecnología debe mejorar la experiencia, no sustituir la interacción humana sin justificación.
Otro aspecto a considerar es la inducción de nuevos empleados. Si bien ninguna empresa quiere pagar salarios sin obtener productividad inmediata, el fracaso de muchas contrataciones está relacionado con una mala integración al puesto de trabajo. Tanto el entrenamiento formal como el informal son esenciales, pero no deben sacrificarse en nombre de la urgencia operativa. En este caso, la verdadera pregunta no es si la práctica es ágil, sino si es una buena práctica. La solución no es lanzar a los nuevos colaboradores “a la guerra” esperando que sobrevivan, sino corregir los procesos de inducción para que sean eficientes sin comprometer la calidad de la formación.
En cuanto a los proyectos que requieren formalidad contractual, es evidente que la relación cliente-proveedor debe protegerse a través de acuerdos bien definidos. Sin embargo, en proyectos internos, es fundamental que la colaboración con el equipo se estructure adecuadamente para garantizar que el cliente realmente participe en la definición y validación de los entregables.
Finalmente, la idea de que el equipo de proyecto lidere su trabajo mientras el Project Manager actúa como facilitador es un tema complejo. Primero, es necesario evaluar si el equipo está preparado y desea asumir ese nivel de autonomía, ya que, en muchas culturas, especialmente en entornos latinos, no es común que los equipos quieran asumir esa responsabilidad sin un liderazgo fuerte. Por otro lado, muchos Project Managers están acostumbrados a ejercer un liderazgo vertical, más directivo que colaborativo.
La pregunta clave es: ¿Podemos realmente avanzar hacia el modelo de liderazgo de proyectos que propone Agile en nuestros? Personalmente, creo que sí, pero no como una simple forma de “cumplir con el Manifiesto Ágil”. Más bien, porque está demostrado que el empoderamiento del equipo y el liderazgo de servicio del Project Manager generan mejores resultados que los modelos tradicionales. No obstante, alcanzar este nivel de madurez no es algo que ocurra de la noche a la mañana. Pasar de una gestión tradicional a una ágil requiere tiempo, preparación y una implementación estructurada. No es algo que pueda imponerse por decreto ni, peor aún, adoptarse solo porque “está de moda”, como algunos gerentes de mejora están intentando hacer.
Relación con gestión en la mejora continua, el caso de la hibridación de proyectos.
El concepto central que quiero desarrollar a continuación se basa en la necesidad de obtener mejores resultados en los proyectos. Tradicionalmente, los proyectos de mejora continua pueden gestionarse bajo dos enfoques principales:
- Un enfoque predictivo , basado en el Ciclo DMAIC, donde se sigue una planificación detallada y estructurada.
- Un enfoque adaptativo , apoyado en el marco de trabajo Scrum y la Filosofía Ágil, que permite mayor flexibilidad ante cambios y aprendizaje iterativo.
Sin embargo, entre estos dos enfoques es común encontrar prácticas que, al combinarse, generan resultados interesantes e incluso los potencian. No se trata de elegir un extremo u otro, sino de identificar aquellas estrategias que pueden aportar valor en la gestión de proyectos de mejora.
Bajo esta perspectiva, podemos enumerar varias ideas valiosas sobre la gestión de proyectos de mejora continua que aprovechan las mejores prácticas del Agilismo:
1-Gestionar cada etapa DMAIC como un Sprint para garantizar una etapa terminada a tiempo: aunque usted no lo crea, una cuestión común en muchos proyectos de mejora continua es la poca disciplina para respetar la fecha de término pactada con el patrocinador de cada etapa DMAIC (si usted es Green Belt o Black Belt piense cuantas veces le ha puesto un tiempo de duración a por ejemplo la generación y aprobación del chárter del proyecto, creo que su respuesta es casi nunca). Esto se amplifica especialmente en las etapas de MEDICIÓN (complejidad de obtener datos) y de IMPLEMENTACIÓN (atrasos en aprobaciones o recursos necesarios para las acciones correctivas). Los atrasos son constantes y, en ocasiones, la gestión de los líderes de proyecto es poco estructurada, lo que tiene como consecuencia lógica el retraso en la finalización del proyecto.
Por lo tanto, incorporar el concepto de sprint [2] como una forma de gestionar en un término rápido y acotado cada etapa DMAIC es sumamente valioso. Un sprint dura lo que está definido porque absolutamente todas las actividades están delimitadas con el concepto de “time box”; es decir, toda actividad tiene un tiempo pactado de duración, además de un responsable. No hay tiempos muertos entre actividades a ejecutar, lo que facilita completar un sprint o una etapa completa en una o dos semanas. Relacionado a esto, el sprint también está asociado a la entrega máxima de valor en un período corto de tiempo, algo así como el concepto original en atletismo donde el corredor entrega el máximo de su desempeño en un corto tramo de la pista, por lo que es un argumento poderoso si usted logra como líder calar este concepto en la mente de los miembros del equipo.
Si usted logra planificar todas las actividades de cada etapa DMAIC como un sprint, es muy probable que no solo cumpla con las fechas pactadas de resultados con su patrocinador, sino que también consiga disminuir los “lead times” del proyecto.
[1] Tome en cuenta muy seriamente un escenario de los muchos posibles: puede existir acciones que se alineen a los marcos de trabajo “ágiles” pero que en definitiva puede que no sean de su gusto y agrado. Hay temas en agilismo que simplemente de aman o se odian a la primera, y se lo digo por experiencia propia.
[2] Recuerde que un sprint en Scrum o Agile es un período de tiempo donde el equipo entrega el máximo esfuerzo para sacar adelante una lista derivada de actividades del Backlog. Todas las actividades tienen tiempo y responsable definido desde el inicio y hay una revisión de avance y bloqueantes sistemáticos cada día llamada“reunión diaria”

2-Realizar un Product Backlog para las actividades de proyecto DMAIC para definir objetivamente la duración del proyecto: una buena forma de definir la duración del Proyecto DMAIC es mediante un Product Backlog. Por lo general, la duración de un Proyecto DMAIC se establece de manera subjetiva y con poca argumentación sobre cuánto tiempo debe durar realmente.
Si partimos del hecho de que un proyecto Lean Six Sigma generalmente se enfoca en resolver un problema de gran apremio para una organización, no está de más considerar que la correcta definición del tiempo en que estará listo debe hacerse de manera objetiva y realista. Por lo tanto, una excelente forma de establecer las fechas de término del proyecto y sus cinco etapas es creando un Product Backlog con definición de puntos de historia. Esto permitirá determinar con mayor precisión cuánto deben durar las etapas y el proyecto en su totalidad, evitando dejar esta consideración a la subjetividad habitual.

No está de más mencionar que en Lean Six Sigma, por lo general, este tema no se trata adecuadamente, lo que genera que los proyectos duren más de lo debido o, en el caso contrario, que se otorguen plazos poco realistas para su ejecución. Es raro, y lo digo por experiencia propia, ver un proyecto de mejora continua terminar en la fecha establecida en el contrato al inicio. Sin embargo, que sea raro no significa que deba aceptarse como una ley física comprobada. También es evidente que, en muchos casos, los mismos líderes de proyecto facilitan y validan la generación de atrasos y el incumplimiento de fechas, lo cual definitivamente no es excelencia.
3- Realizar un Sprint Planning para cada etapa del proyecto DMAIC como una forma de potenciar el término en tiempo de la etapa DMAIC: parecido, pero no igual al primer punto, es adecuado que el Equipo tenga pleno conocimiento de las actividades por realizar en cada etapa del DMAIC. Por lo general el realizar las actividades o las herramientas de la etapa DMAIC correspondiente no esta definida en una programación formal y depende más de la organización del Black o el Green Belt por lo que UN Sprit Planning puede ayudar a dar claridad al trabajo por realizar ya las fechas y responsables de realizarlas. Esta práctica definitivamente mitiga el riesgo de no cumplir el plazo de término pactado en el cual la etapa debe estar lista.

4-Entregue valor siempre y no solo al final: una gran crítica al proyecto LEAN SIX SIGMA gestionado con DMAIC es que se supone que el problema se resuelve hasta las etapas finales de MEJORAR (IMPROVE) y se termina de consolidar con los resultados de CONTROL. Sin embargo, el tercer principio de Agile habla de entregar valor (software) que funciona constantemente. Además, la misma conceptualización de un enfoque de desarrollo de proyecto de tipo “incremental” pregona que desde el principio un proyecto debe entregar valor al cliente.
Por lo tanto, incorporar al Proyecto DMAIC esta práctica general, en lugar de la tradicional práctica de entrega valor hasta las dos últimas fases, permite potenciar los proyectos, entregar más valor y, sobre todo, mantener a las partes interesadas satisfechas. Así, por ejemplo, en DEFINE el valor entregado es dirección al equipo, claridad y confianza a los stakeholders, y valor al patrocinador en cuanto a resolver un problema de apremio para él, ella o la organización.
Cuando hablamos de la etapa MEDIR , el valor incremental que se entrega es la argumentación técnica y objetiva necesaria para hacer un adecuado ejercicio de causa raíz, comprendiendo realmente los aspectos causales que generan el problema de negocio. Además, a esto se le puede sumar algún tipo de informe y presentación oral a partes interesadas y patrocinador, generando confianza y credibilidad en el trabajo del proyecto y del equipo. Recuerde que los proyectos LEAN SIX SIGMA están rodeados de altísimas cuotas de incertidumbre al tratar de resolver problemas divergentes, que son problemas complejos y cuya solución no es trivial.
Evidentemente, en ANÁLISIS la entrega de valor más notable es el resultado del análisis de causa raíz que usted aplica. Dado esto, el diseño del plan de acción estará basado en las causas raíces reales y garantizará una probabilidad mucho mayor de resolver el problema de negocio que dio origen al proyecto, lo que constituye una entrega de valor incremental.
Finalmente, las etapas de MEJORAR (IMPLEMENTAR) y CONTROLAR entregan la implementación del plan de acción, lo que confirma el buen trabajo realizado en las etapas previas del DMAIC (valor incremental acumulado). Como puede ver, DMAIC puede gestionarse no tanto como un proyecto tipo cascada, sino más bien como una hibridación de proyecto incremental con mejores prácticas ágiles.

5- Realizar retrospectiva para cada etapa DMAIC como forma de mejorar siempre: Realizar retrospectiva para cada etapa DMAIC como forma de mejorar siempre: un aspecto que se reconoce en los proyectos basados en marcos de trabajo ágiles son los ejercicios de retrospectiva. No por nada, el doceavo principio ágil establece que, “a intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia”.

Los proyectos de mejora continua suelen realizar, durante la última etapa de Control , ejercicios de lecciones aprendidas que buscan facilitar el camino a futuros proyectos de mejora sobre una misma situación de negocio que se debe optimizar a través de varias iteraciones. Sin embargo, el accionar del equipo y los resultados generados no reciben una crítica constructiva en las cuatro primeras etapas de DMAIC, lo que puede derivar en efectos no necesariamente correctos y afectar la calidad de los resultados de cada etapa.
La mejora práctica planteada es realizar ejercicios retrospectivos en todas las etapas DMAIC, de manera similar a las etapas Sprint ágiles. Esto permitirá al equipo aplicar el doceavo principio ágil y, sobre todo, mejorar su desempeño en la siguiente etapa DMAIC, en lugar de dejar esta práctica solo para la última fase del proyecto.
Definitivamente, esto puede potenciar significativamente los resultados del proyecto al crear el espacio formal necesario para que los equipos se autocritiquen y mejoren la calidad de las actividades técnicas, el liderazgo ejercido por el Green Belt o el Black Belt, y, en general, los resultados de valor esperados en cada etapa DMAIC.
6-Aprovechar los artefactos Scrum en las etapas DMAIC, sobre todo la Pizarra Kanban : el concepto en sí mismo de la Pizarra Kanban, enfocado en tres sencillas columnas de trabajo: “por hacer”, “trabajo en proceso” y “trabajo hecho”, permite crear transparencia en la gestión.

Es común que, durante los proyectos de mejora continua, la visibilidad del avance del trabajo recaiga en el Black o Green Belt, posiblemente mediante una hoja de cálculo o una herramienta de programación de proyectos. Sin embargo, en los proyectos ágiles, la presencia del artefacto Pizarra Kanban en cada etapa del proyecto beneficia en gran medida la predictibilidad del trabajo en proceso, generando claridad sobre si se logrará terminar cada actividad del proyecto en la fecha pactada para esa etapa específica.
Por lo tanto, emular la práctica de uso de la Pizarra Kanban durante las etapas DMAIC podría proporcionar visibilidad sobre el trabajo que cada miembro del equipo está realizando y facilitar la identificación del flujo de trabajo en la etapa. Esto permitiría al líder del proyecto y al equipo reaccionar ante atrasos o circunstancias que puedan afectar las fechas pactadas de término.
Eliminar la discrecionalidad que, en ocasiones, muchos Black o Green Belts tienen respecto a la programación del trabajo mediante un artefacto tan sencillo como la Pizarra Kanban puede potenciar significativamente la calidad y la velocidad del trabajo del proyecto, así como el cumplimiento de las fechas establecidas.
7-Establecimiento de roles: en los proyectos ágiles están muy bien definidos los roles de los miembros del equipo, existiendo por lo general un líder de facilitación, un dueño de producto y los miembros del equipo.
En los proyectos de mejora continua, aparte del líder del proyecto, el Black Belt o el Green Belt, los demás integrantes del equipo de proyecto no suelen tener un rol definido. Esta falta de definición genera ambigüedad e incertidumbre entre los mismos miembros del equipo, especialmente en la primera etapa, DEFINIR, del proyecto.

Por lo tanto, la mejor práctica que se recomienda considerar es planificar, antes de iniciar el proyecto, una clasificación sencilla de roles con las respectivas actividades de proyecto que pueden desempeñar, que potencie las competencias de cada integrante del equipo. De esta manera, en el momento de asignar trabajo, la asignación será más natural y alineada con las capacidades de los miembros. Además, esto fomenta que sean ellos mismos quienes se sugieran y se empoderen para asumir retos y llevarlos a cabo.
Cabe recordar que, por lo general, en los proyectos de mejora continua existe una fuerte dependencia de un estilo de liderazgo vertical derivado del Black Belt o el Green Belt. Sin embargo, este enfoque no es del todo adecuado en los contextos modernos de gestión, especialmente considerando el tipo de recursos humanos que se maneja en la actualidad.
Finalmente, aplicar los valores y principios ágiles en la medida de lo posible es todo un reto. Es fundamental incentivar que el equipo los conozca y los aplique sistemáticamente en cada una de las oportunidades que surjan en la gestión de los proyectos. Para ello, usted, como líder, debe estar preparado para identificar con habilidad las situaciones propicias en las que los valores y principios ágiles pueden beneficiar y potenciar los resultados del proyecto Lean-Seis Sigma.
Esto no es una tarea fácil; comienza por usted como Black Belt o Green Belt, pero continúa con cada uno de los miembros del equipo. El cuidado debe centrarse en garantizar que las prácticas de gestión de proyectos estén alineadas con los principios y valores ágiles, asegurando así un verdadero agilismo que potencie los resultados que usted y su empresa desean alcanzar.
Si le gustó esta entrega, estoy planeando generar una segunda parte más enfocada en desarrollar las prácticas ágiles en los proyectos de mejora continua. Sin embargo, esto dependerá del interés que genere el tema. Si le llama la atención, escríbame con confianza y con gusto atenderé su requerimiento. Además, estos temas los abordaremos sistemáticamente en nuestros cursos regulares de Professional Scrum Master y Professional Product Owner, con énfasis en la mejora continua de procesos. ¡Suerte en sus proyectos!