¿Cómo maximizar el valor del producto? ¡Priorizando!

Resumen: Realizar una buena priorización es clave para el éxito de proyectos, productos y servicios, incluso para nuestras decisiones personales. Bien sea porque eres el Product Owner (PO) de tu equipo, o un Scrum Master que ayuda al PO en la priorización del backlog, o quieras realizar mejores decisiones sobre aspectos relevantes de tu vida, acordar criterios y aplicar técnicas de priorización, facilita maximizar el valor de lo que hacemos. Una correcta priorización del backlog logra poner el trabajo en orden, asegurando que enfocamos esfuerzos y recursos en aquello que es más relevante en ese momento, sin olvidar el carácter dinámico de las prioridades. En este artículo se describen los criterios más habituales que se tienen en cuenta para priorizar los elementos del Product Backlog (PBIs), se desarrollan 2 de las técnicas más usadas en agilidad (Moscow y WSJF), se explica brevemente como estimar utilizando la serie de Fibonacci y póker planning, y para terminar, se presenta un ejemplo de cómo utilizar estos criterios y técnicas de priorización para priorizar y ordenar tus pendientes personales.

En Scrum, el Product Owner (PO) es el responsable de maximizar el valor del producto, y lo hace a partir de la adecuada gestión de los elementos del Product Backlog (PBI- Product Backlog Item), expresando claramente estos elementos y ordenándolos para alcanzar los objetivos del producto, de la mejor manera posible.

Al ordenar el Product Backlog se coloca en la parte superior los elementos más prioritarios y en la base los menos prioritarios. Al priorizar, se decide qué solucionará el equipo primero y qué solucionará después. La priorización es un principio, que en palabras de Covey significa "hacer primero, lo primero".  

La priorización es responsabilidad del PO y cuenta con la ayuda del equipo ágil. Se prioriza tanto al inicio del proyecto/producto, como en cada iteración, ya que el backlog vive en constante adaptación.

Con una correcta priorización del backlog se logra poner el trabajo en el orden que mejor maximice el valor del producto, asegurando que el equipo siempre esté desarrollado trabajo relevante y necesario, aportando la visión y la perspectiva del negocio.

Algunos de los factores más habituales que se tienen en cuenta para priorizar los PBIs son: el Valor que aporta el desarrollo al usuario, cliente o negocio, nivel de Importancia, nivel de Urgencia, Esfuerzo o tamaño del desarrollo requerido, Dificultad o Riesgos asociados al desarrollo, entre otros criterios.

A partir de los criterios de priorización han surgido distintas técnicas para priorizar los PBIs, tales como: el Método Moscow, la Matriz de Eisenhower, la Matriz de Impacto vs Esfuerzo, la Comparación en pares de Historias de Usuario, WSJF - Weighted Shortest Job First, y el Modelo de Kano, entre otros.

Describiré 2 de las técnicas más utilizadas: Moscow y WSJF.

Moscow, como la capital de Rusia, es una nemotecnia de Must, Should, Could y Won’t. que en castellano sería:

• MUST: Lo que debemos hacer, y haremos de inmediato.
• SHOULD: Lo que deberíamos hacer, y haremos en lo posible.
• COULD: Lo que podríamos hacer, y haremos si nos da la capacidad. 
• WON’T: Lo que no haremos ahora, y quizás haremos más tarde.

Su objetivo es ordenar los elementos de la lista del producto, considerando la necesidad y entrega de valor a la organización. 

La estimación del tipo de Requisito es responsabilidad principal del PO, y junto al equipo acuerda los criterios que aplicará para establecer cuando un requisito es esencial, importante o deseado, son mejoras, o características que el producto o proyecto no tendrá por ahora.

Para cada PBI el PO estima el tipo de requisito, asignando la prioridad:

• Los requisitos Esenciales que debe tener el producto o proyecto, como características críticas, que no tienen reemplazo o alternativa, se les asigna Prioridad 1.
• Los requisitos Importantes y Deseados que pueden ser obtenidos de otra forma, si fuese necesario, mientras son desarrollados, y que se harán luego de la prioridad 1, se les asigna Prioridad 2.
• Las Mejoras para el producto o proyecto, donde puede haber varias alternativas, que se analizarán y harán cuando se disponga de capacidad, y hayan sido cubiertos los requisitos de prioridades 1 y 2. A éstos se les asigna Prioridad 3.
• Las características que se han acordado no tendrán el producto o proyecto por ahora, se les asigna Prioridad 4. Dado el carácter dinámico del backlog, esta prioridad podría cambiar con el tiempo.

WSJF - Weighted Shortest Job First - El trabajo más corto ponderado primero, permite priorizar los requisitos o PBIs que entregan más valor en el menor tiempo, en entornos donde el coste de la demora (Cost of Delay - CoD) y el esfuerzo o duración de los elementos de trabajo cambian o pueden cambiar.

Su objetivo es ordenar los elementos de la lista del producto según el impacto que tendrán para la organización y el esfuerzo que demandará su desarrollo.

Para ello, se prepara una matriz con los PBIs en la primera columna de la matriz y se añaden las siguientes columnas: Valor, Criticidad, Riesgo/Oportunidad, Coste del retraso, Esfuerzo (tamaño) y WSJF.

·      Para cada PBI el PO con su equipo de negocio estima Valor, Criticidad y Riesgo/Oportunidad y el Equipo de Desarrollo estima el Esfuerzo.

·      Se calcula el Coste del retraso (CoD) sumando el Valor del negocio, su Criticidad en el tiempo y el Riesgo/Oportunidad.

·      Se calcula WSJF dividiendo el CoD entre el Esfuerzo.

·      Se ordenan los elementos de la lista del producto de mayor a menor por su valor de WSJF. El resultado es una lista priorizada de PBIs.

¿Cómo estimar utilizando Fibonacci y Póker Planning?

La secuencia de Fibonacci comienza con los números 1 y 2, y a partir de estos, el siguiente valor es la suma de los dos anteriores, así la serie contiene los números:  1, 2, 3, 5, 8, 13, 21, permitiendo representar que algunos parámetros como el esfuerzo o el riesgo no aumentan linealmente, sino exponencialmente. Algunos equipos acuerdan utilizar como valores máximos el 13 o el 21, y en algunos casos, utilizar el valor 20 en lugar del 21.

Una de las técnicas de estimación más utilizada por los equipos es el Póker Planning, donde cada participante deberá votar en secreto por el tamaño o riesgo relativo de cada PBI, y al revelar el valor, se consensua entre todos, la estimación que será utilizada.

Se disponen de varias aplicaciones en línea para aplicar esta técnica, y si se utiliza en una reunión presencial, se utiliza un mazo de cartas. En todo caso, es una dinámica que facilita una estimación colaborativa y por consenso.

Por último, ¿podrías utilizar estos criterios y técnicas de priorización para priorizar y ordenar tus pendientes personales?

Como he compartido en otras ocasiones, la agilidad es una forma ser, acompañada de técnicas y herramientas para poner en práctica sus valores y principios. Cuando eres agilista aplicas sus prácticas en proyectos y procesos laborales y personales.

Así, por ejemplo, dado que la capacidad y los recursos son limitados, y buscando productividad y eficiencia haciendo una cosa a la vez, sí necesitamos tomar decisiones y priorizar entre varios pendientes, que pudieran ser todos importantes, podríamos experimentar haciendo una matriz WSJF:

Propósito: Mejorar y ampliar mis opciones laborales:

Pendiente	Valor	Criticidad	Riesgo/Oportunidad Laboral	CoD	Esfuerzo	WSJF
Estudiar Inglés	5	8	8	21	8	2,63
Certificarme Agile Coach	8	3	5	16	5	3,20
Certificarme PMP Agile	5	3	3	11	8	1,38

Fibonacci: 1 (muy poco), 2 (poco), 3 (medio), 5 (alto), 8 (muy alto)

En este ejemplo, WSJF, recomienda comenzar con una Certificación Agile Coach. Claro está, estas técnicas te facilitan información adicional para apoyar la toma de decisiones, pero finalmente, quien decide es la persona responsable de la priorización.

¿Cuál ha sido tu experiencia con la priorización? ¿Te parece algo trivial y sencillo, o estás de acuerdo que el disponer de criterios y técnicas de priorización ayuda a obtener un mejor resultado?

Gracias por leerme, compartir y comentar

Saludos,

María Esther Remedios

@Soy.Agile.Coach

Políticas explícitas: práctica de Kanban útil para todos los equipos

Establecer políticas explícitas es una de las 6 prácticas Kanban, donde los miembros del equipo acuerdan criterios para alinear sus preferencias, facilitar la toma de decisiones, la autogestión y su mejora continua.

Sugiero que independientemente si eres parte de un equipo Kanban, Scrum, o utilices cualquier otro marco de trabajo, promuevas establecer con tu equipo de trabajo acuerdos que faciliten mejorar sus interacciones y su desempeño. 

Ejemplos de políticas explícitas:

• Nuestros dailies son a las 8:30 am por Teams y con el tablero de trabajo actualizado.
• Somos puntuales y terminamos las dailies en 15 minutos.
• Convocamos las reuniones entre 9 y 13.
• Los viernes no tenemos reuniones.
• Documentamos estrategias, planes y acuerdos en OneDrive, conversamos y aclaramos dudas en nuestro canal de Teams. Evitamos el uso del correo electrónico.
• En reuniones virtuales e hibridas colocamos las cámaras, al menos los primeros 5 minutos, mientras nos saludamos y rompemos el hielo.
• Las incidencias son la prioridad del equipo, quien se ocupe colocará su trabajo en espera hasta resolver la incidencia.
• No hacemos multitasking, respetamos el WiP poniendo foco en terminar el trabajo que tenemos en progreso.
• El dueño del producto o gestor de la demanda prioriza el trabajo pendiente, y el equipo de desarrollo se autogestiona y autoasigna el trabajo, poniendo en práctica el sistema pull.
• Nuestra definición de hecho, además de cumplir los criterios de aceptación definidos por el peticionario, cumplimos con los criterios de calidad y de tecnología definidos en la organización.

Las políticas explícitas son acuerdos y criterios vivos, que evolucionan conforme evoluciona el equipo. El equipo debe reflexionar con frecuencia sobre sus políticas, incluir nuevos acuerdos, modificar los existentes y comprender que estas políticas existen y las respetamos con la convicción de que están allí para favorecer las interacciones del equipo y su entrega frecuente y continua de valor.

Gracias por leerme y comentar (^.^)

Product Owner: su rol en los eventos Scrum

Scrum es un marco de trabajo iterativo e incremental que divide la ejecución del trabajo en eventos de longitud fija que se ejecutan uno tras otro, llamados Sprint, el latido del corazón de Scrum.

Cada sprint contiene todo el trabajo necesario para lograr el objetivo del producto por lo que el rol de Product Owner (PO) es clave para su éxito.

Comencemos con la planificación del sprint (sprint planning), donde el PO, en línea con la visión y objetivo del producto, propone cómo el producto puede evolucionar y aumentar su valor en el sprint, facilitando que el equipo Scrum defina un Objetivo del sprint valioso para los stakeholders. Con el objetivo en mente, el PO expone al equipo de desarrollo el detalle funcional de las historias de usuario que se encuentran priorizadas en el backlog, y participa en el debate donde los desarrolladores seleccionan los elementos que conforman el Sprint Backlog.

Al terminar el tiempo del sprint, en la sesión de trabajo de revisión del sprint (sprint review), el PO asegura la participación de los stakeholders, que junto al equipo Scrum, revisan el trabajo realizado, actualizan el Product Backlog y definen el trabajo posible del siguiente sprint. El equipo de desarrollo hace una demostración del trabajo terminado, explica las dificultades presentadas y responde a las preguntas de los stakeholders. Con el feedback de los stakeholders y del equipo, el PO actualiza y reorganiza el Product backlog, y teniendo en cuenta el objetivo del producto, definen entre todos qué se va a hacer en el siguiente sprint.

Luego de la revisión del sprint, se realiza la retrospectiva del sprint (sprint retrospective), donde el equipo Scrum planifica formas de aumentar la calidad y la eficacia. El PO, como un miembro activo del equipo Scrum, analiza junto al equipo cómo ha sido el último sprint en relación con las personas y sus interacciones, procesos, herramientas, definición de hecho, etc., debate junto al equipo los cambios y mejoras que favorecen la eficacia del trabajo y deciden que acciones deben abordarse en el próximo sprint.

Un evento adicional, no propuesto en la guía de Scrum, pero que es una práctica que implementan muchos equipos Scrum es el refinamiento del sprint (sprint refinement o grooming), cuyo propósito es agregar detalles, estimar y ordenar las historias de usuario que haya dentro del Product Backlog, a fin de tenerlo reparado para el siguiente evento de sprint planning. El PO debe asegurar la participación de stakeholders especialistas en las historias de usuario a refinar.

#Scrum, #Product_Owner, #Eventos_Scrum

Product Owner: Gestión del trabajo y valor a través de los artefactos Scrum

Scrum define un conjunto de elementos para gestionar el trabajo y la entrega de valor que llama artefactos, cada uno diseñado para maximizar la transparencia, facilitar la inspección y la adaptación, valores Scrum que aplicamos para obtener el mejor resultado posible.

Los artefactos que propone Scrum son: a) para gestionar el trabajo pendiente del producto: el Product Backlog, b) para gestionar el trabajo a desarrollar en un Sprint: el Sprint Backlog, y c) para gestionar las entregas de valor en cada Sprint: el Incremento del Producto.

Para garantizar que cada uno cumple su propósito, el Producto Backlog tiene el Objetivo del Producto (Product Goal), b) el Sprint Backlog tiene el Objetivo del Sprint (Sprint Goal), la Definición de preparado (Definition-of-Ready) y Gráfico de quemado de puntos (Burndown chart), y c) el Incremento del producto, la Definición de Hecho (Definition-of-Done).

El Product Owner (PO) es responsable de maximizar el valor del producto, y del negocio, a través de la gestión continua del Product Backlog. Para ello, define una visión y objetivo del producto, que, junto a una hoja de ruta de nivel estratégico, facilita un objetivo a largo plazo y una guía al equipo Scrum y partes interesadas (stakeholders).

En cada Sprint, el PO propone al equipo de desarrollo el objetivo del Sprint, en línea con el objetivo del producto. El equipo acuerda durante el Sprint Planning el Sprint Goal y selecciona del trabajo pendiente, aquellos elementos, que cumplen con la Definición de preparado que podrán completar durante el sprint, moviéndolos al Sprint Backlog. El Sprint Backlog es responsabilidad del equipo de desarrollo.

El incremento del producto, que se obtiene en cada sprint, es una pieza del producto utilizable, que, junto a los demás incrementos, van conformando el Objetivo del producto. El trabajo realizado es parte del incremento, sí cumple la Definición de Hecho.

En la Sprint Review, el PO invita a los Stakeholders, quienes validan el nuevo Incremento con los elementos que habían acordado y definido juntos. El éxito de la revisión dependerá de un buen refinamiento, y de esta sesión se obtiene feedback y aprendizajes que el equipo puede utilizar para expandir la Definición de Hecho, y el PO conseguir de los stakeholders la definición de nuevos elementos a incluir en el Product Backlog.

#Scrum, #Product_Owner, #Artefactos_Scrum

Sprint: Latido del corazón de Scrum

 
 “Los sprints son el latido del corazón de Scrum, donde las ideas se convierten en valor” (guía Scrum, 2020). 

Que buena metáfora, dado que una buena salud, requiere un corazón con un ritmo constante, es decir, latidos que duran el mismo tiempo.

 Asimismo, en Scrum, los sprints son ciclos o iteraciones de duración fija, entre 1 y 4 semanas, que facilitan la creación de consistencia, predictibilidad y foco en lo importante, la entrega frecuente de valor.

Los sprints son ciclos iterativos de duración fija, entre 1 y 4 semanas, que se ejecutan uno tras otros.

Cada sprint contiene todo el trabajo necesario para alcanzar un incremento de valor del producto.

Como un proyecto corto, el sprint contiene una meta (sprint goal), comienza con un evento de planificación (sprint planning), durante su ejecución, el equipo realiza reuniones diarias de sincronización y trabajo colaborativo (daily), el backlog se clarifica y refina (sprint refinement), y el sprint termina con la revisión del trabajo realizado (sprint review) y una sesión de retrospectiva que promueve la mejora continua del equipo (sprint retrospective).

Mantener los sprints de la misma duración, y dentro de él, eventos que se dan en forma periódica, en el mismo lugar y con la misma duración, favorece una cadencia con un ritmo regular de desarrollo que facilita al equipo conocer su capacidad, estimar mejor, ganar previsibilidad y una mejor gestión de la complejidad e incertidumbre.

Cada nuevo sprint comienza inmediatamente después de la finalización del sprint anterior, generando un ritmo de desarrollo constante.

Veamos un ejemplo:

Evento	Cuándo	Duración
Sprint	Cada 2 semanas	2 semanas (10 días)
Planificación	Día 1 del sprint	2 horas
Daily	Todos los días	15 minutos
Refinamiento	Día 7 del sprint	1 hora
Revisión	Día 10 del sprint	1 hora
Retrospectiva	Día 10 del sprint	1 hora

Dentro de cada sprint las historias de usuario que conforman el sprint backlog cumplen criterios comunes de preparado (Definition of Ready o DoR) y el equipo acuerda las características que debe cumplir cada historia para ser dada por hecha (Definition of Done o DoD), lo que facilita una guía de las tareas que debe realizar el equipo de desarrollo para disponer al final de cada sprint de incrementos del producto potencialmente entregables y usables.

El ritmo y criterios comunes de trabajo ayudan a los miembros del equipo a organizar su tiempo, a estimar, anticiparse y adaptarse mejor a las circunstancias, trabajar con menos estrés e incertidumbre, poniendo foco en lo que verdaderamente importa, el desarrollo de actividades que generan valor.

Cambiar la duración de los sprints rompe el ritmo de trabajo, dificultando al equipo la planificación y estimación de esfuerzos, tener una velocidad estable, autoorganizarse y la entrega de incrementos de productos en intervalos regulares.

Pueden presentarse excepciones, como en períodos vacacionales, festivos o eventos especiales dentro de la organización que pueden impactar el ritmo de los sprints. En todo caso, la planificación de los sprints deberá ajustarse temporalmente a estas circunstancias y retomar su ritmo habitual a la brevedad posible.

Conocer la duración apropiada del sprint es un desafío que enfrentan los nuevos equipos ágiles. Dependerá de la madurez del equipo, la complejidad del producto, la necesidad de retroalimentación, lo cambiante de los requerimientos, etc.

Recordemos que Scrum es empírico, el equipo asumirá una duración inicial que podrá adaptar una vez conozca mejor el producto y contexto de trabajo, y una vez establecida, lo recomendado es mantenerla.

@Soy.Agile.Coach

Productividad: 1. El trabajo está en línea con mis intereses y Objetivos

Les escribí en la anterior publicación, las condiciones que para mí, te hacen productivo.

En las próximas publicaciones, desarrollaré cada punto, comenzando con El trabajo está en línea con mis intereses y objetivos.

En primer lugar, te invito a reflexionar y escribir sobre cuáles son tus intereses y objetivos, en materia laboral y personal. Cuáles son, asimismo, tus valores y principios.

Nuestro trabajo, las acciones que ejecutamos día a día, se realizarán con mejor disposición, si sentimos que impactan positivamente en nuestra vida, y sucederá lo contrario si impacta negativamente.

Imagina, que valoras en primer lugar tu Salud, física, mental y emocional. Por respeto a nosotros mismos, no tendríamos que aceptar un trabajo que nos genere angustia, temor o rabia, es decir, un estrés negativo (distress). No solo por su impacto negativo en nuestra salud, sino también por que difícilmente seremos productivos en estas condiciones.

Otro ejemplo, si valoras tiempo de calidad con tu Familia, un trabajo que te genere distress, te pondrá de mal humor, llegarás a casa quejándote, quizás regañando y pagándola con tus seres queridos.

Si además valoras tu Tiempo, te alejarías del sobretiempo laboral, y de otros tipos de sobretiempo, como, por ejemplo, el digital (exceso de tiempo en redes, videos, series, juegos, etc.).

El tiempo, objetivamente hablando, es finito, no es renovable, ni se recupera, se mueve inexorablemente, siempre hacia adelante, a un ritmo constante. Por otra parte, no somos seres omnipresentes, por lo tanto, al decidir estar en un lugar, automáticamente renunciamos a estar en otro. O estás en la oficina, o estás en casa.

Tener claros objetivos (SMART) y los resultados claves (OKR) que queremos mantener o conseguir, más allá de metas y números, destaca los por qué y los para qué de nuestra labor. Conocer el propósito, y porque es relevante para la organización, y también han de estar en línea con nuestros valores y principios. Si eres vegano, difícilmente estarías bien en un matadero de reses, o si estás en contra del cigarrillo, imagínate colaborando para la expansión de la industria del tabaco.

Los anteriores son ejemplos muy tangibles. Hay otros casos más sutiles, que de igual forma afectan nuestra productividad y calidad de vida. Si te consideras agilista, y valoras la autonomía y trabajar en un ambiente de confianza, no estarás a gusto con un jefe controlador que cuestiona los errores, de formas que inhiben la experimentación.

En mi caso, forman parte de mi propósito de vida, aprender y enseñar, por lo que mantenerme estudiando y dar clase han de ser parte de mi desempeño laboral y profesional.

Aunque suene a cliché, Amar lo que se hace, es clave para ser productivo. Más que cuestión de tiempo, tiene que ver con tener energía y ganas, elementos presentes cuando estás a gusto y disfrutas con lo que haces.

Comprendo que conseguir una actividad laboral que respete tu individualidad, y que esté en línea con tus valores y principios, puede ser desafiante, pero créeme, somos merecedores de ello, y te hará ser más productivo, por lo que todos ganan.

Podría ser que, en tu trabajo, no todas las tareas te resulten gratificantes, pero si no contradicen tus principios, y apoyan los objetivos, dales un significado positivo. Esto podría cambiar tu actitud y estado de ánimo a favor de la productividad.

Y no te estoy sugiriendo que dejes ya tu trabajo, sí este no te satisface. Agradécele, hazlo lo mejor posible, y realiza pequeños cambios que te acerquen a tu trabajo ideal. En paralelo, puedes activarte y prepararte para conseguir una oportunidad laboral más apropiada para ti.

Somos responsables de nuestras decisiones y acciones, no te sientas obligado por las circunstancias, pero si en movimiento para mejorar y cambiar positivamente.

Gracias por leerme y compartir.

@Soy.Agile.Coach

 

Productividad: 2. Dispongo de Competencias para realizar el trabajo eficientemente

 

¿Quieres recuperar tiempo de tu día a día?, y quién no, tiempo para realizar más entregas con mejores resultados, realizar otras tareas más enriquecedoras, o poder tener tiempo para otras actividades que disfrutamos, y que, por estar, normalmente, tan liados, no tenemos tiempo para realizarlas, como leer, estudiar, compartir, ir al gimnasio, o simplemente, descansar y dormir bien.

Te iré compartiendo diferentes técnicas para ser más productivos, y en este artículo vamos a enfocarnos en cómo ser más eficientes siendo más competentes en las tareas que realizamos frecuentemente.

Te invito a realizar una lista de tus tareas frecuentes, y para cada tipo de actividad, identifica y mide el tiempo aproximado que le dedicas al día o a la semana. Así mismo, determina, según tu criterio, el nivel de conocimiento y competencia que tienes realizando la tarea. Por ejemplo:

No hay texto alternativo para esta imagen

Prioricemos, definiendo criterios que faciliten la elaboración de un plan ordenado de acciones. Por ejemplo, tareas que exigen mayor tiempo y el nivel de competencia es bajo o medio, o seleccionar acciones de mejora de poco esfuerzo o costo, y alto o medio impacto en el desempeño de la tarea.

Identifica las estrategias que permiten mejorar tus competencias, como recibir formación especializada, solicitar el apoyo de un experto, y lo más importante, poner en práctica lo aprendido, es lo que te hará más competente realizando la tarea.

Toma en cuenta, que desarrollar una competencia pasa por, al menos, 4 etapas:

Tienes la necesidad e interés de mejorar tu desempeño.

Adquieres conocimientos, técnicas y herramientas para realizar, de forma más eficiente, y diferente, tu trabajo.

Pones en práctica, una y otra vez, de forma disciplinada, lo aprendido.

Sientes la mejora de tu desempeño, lo que te motiva a seguir practicando y mejorando, hasta ser muy competente en la tarea.

Otra acción que podrías emprender, si es aplicable, es delegar o buscar la automatización de las tareas más repetitivas.  

Finalmente, mide nuevamente tus tiempos y valora la mejora obtenida. Siguiendo nuestro ejemplo:

En el ejemplo, se tiene un plan de acción de 4 tareas de mejora en forma secuencial, para lograr en 6 meses, una mejora en la productividad de un 25%, pudiendo observar mejoras a lo largo del proceso.

Hay que destacar, el valor de la medición para analizar, objetivamente la situación, y para validar la ruta de mejora que hemos seleccionado. Y de ser necesario, adaptar o cambiar las estrategias de mejora.

También he de señalar, que los planes de mejora suelen competir con el cumplimiento de lo objetivos de la organización, y que nos exigirá, durante su implementación, un esfuerzo extra. Habrá momentos en que la tensión del entorno nos obliga a ir un poco más despacio, y en otras circunstancias podemos acelerar. En todo caso, nuestros planes han de ser flexibles y adaptarse a los cambios del entorno. Lo importante, es no renunciar a la oportunidad de hacer las cosas, cada día, un poco mejor, y ganar en productividad.

Como diría Covey, Detenerse para afilar la sierra, y con ello mejorar el desempeño.

Gracias por leerme y compartir.

@Soy.Agile.Coach