• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

metrics

¿Que es un OKR?

Cada día los OKRs se vuelven más famosos y muchas organizaciones optan por usarlos, sobre todo por estar Google detrás. Pero no dejo de pensar sobre el propósito de los OKRs. ¿Para qué vamos a usarlos? además, ¿tenemos claro qué quieren decir? Vamos por pasos, veamos de dónde vienen los OKRs.

Historia de los OKRs

A pesar de que Google hizo famosos a los OKRs , no fueron ellos quienes empezaron a usarlos sino Intel. John Doerr es uno de los primeros inversores de Google que vivió su uso en Intel. De ahí Doerr se los llevó a Google a principios de los 2000. Claro, Google vió en ellos mucho valor y a día de hoy Google establece OKRs anuales y trimestrales.

Ahora que sabemos que el gran gigante tecnológico los usa y por lo visto le funcionan ¿qué hago yo? ¿Me uno y me pongo a usarlos? Si a ellos les ha funcionado, me tendrá que funcionar a mi también. Con este pensamiento caemos en lo que se conoce como cargo cult . Mejor vamos a ver qué son esos famosos OKRs.

¿Qué es un OKR?

OKR es el acrónimo de Objective and Key Results. Si vas a lanzarte a usarlos, te recomiendo que te hagas las siguientes preguntas:

  • ¿A dónde quiero ir? Responder a esta pregunta es lo que te proporciona la primera parte, el objetivo.
  • ¿Cómo sé que estoy llegando a ese punto? Responder a esta pregunta te proporciona la segunda parte, los resultados clave.

Los OKRs se utilizan en una amplia gama de organizaciones hoy en día. De hecho desde Jeronimo Palacios & Associates colaboramos con varias organizaciones de muchos empleados que los utilizan y les ayudamos a implementarlos. Observamos que los OKRs tienen mucho impacto positivo en la productividad individual y contribuyen a la consecución de los objetivos estratégicos de la organización.

La implementación de OKRs puede ayudar a alinear estructuras en una organización. Además ayuda a una auto-organización más eficiente, ya que esta última puede conducir a cualquier cosa. Pero hay que tener mucho cuidado a la hora de usarlos y más aún cuando estamos midiendo el avance hacia ellos.

Medir el progreso en tus objetivos

Es importante saber si estamos avanzando hacia la consecución de nuestros objetivos. Pero no debemos caer en el error de considerar las propias métricas un objetivo en sí mismas. Este error es muy típico, ya que la misma medida se convierte en un deseo u objetivo. La medida es un resultado (output) y en base a ese resultado debemos de ser capaces de buscar acciones de mejora. Si el resultado no te ayuda a tomar una acción, piensa en otra medida.

En algunos casos se puede usar más de una medida (resultados clave) para ver el progreso hacia un objetivo. No hay que quedarse con una única perspectiva, sino que hay que adoptar varias si es posible.

Recuerdo mis comienzos como Scrum Master, especialmente cuando tuve que hablar con la dirección sobre métricas. Llenamos con datos y gráficos (sin contar la información de Jira) la sala donde estaba el equipo con el que yo colaboraba como Scrum Master. Pero surgía un problema: cada vez que queríamos hablar sobre acciones cada persona exponía su opinión y generalmente no se ponían de acuerdo. A pesar de tener mucha información que nos podía aportar valor, no  hacíamos uso de esas métricas para ver si realmente nos ayudaban a tomar decisiones.

Si tenemos datos, veamos los datos.  Si todo lo que tenemos son opiniones, entonces vamos con las mías. – Jim Barksdale

Al tener datos es más fácil que las personas estén alineadas y de acuerdo en lo que está sucediendo. Mi compañero Nacho Navarro hace tiempo nos hizo una introducción sobre métricas y su uso en Kanban , por si te puede resultar útil.

Cosas a tener en cuenta al usar los OKRs

  • ¿Qué propósito hay detrás de este OKR?
  • No deben de ser impuestos por la empresa ni por el manager para medir el rendimiento individual de los empleados.evitar de usar los okrs para medir el rendimiento individual de los empleados
  • Deben de ser ambiciosos pero alcanzables. Es importante que sean alcanzables de alguna manera, porque pueden llegar a ser desmotivadores al no alcanzar nunca nuestros objetivos.
  • No ligar los objetivos con los incentivos o bonos. Esto puede romper la motivación intrínseca de las personas.
  • Los resultados clave tienen que ser cuantificables, al no ser así, no sería fácil medir el avance hacia nuestros objetivos ( Google utiliza una escala de 0 a 1 ).
  • Hacerlos transparentes. Esto puede ayudar a ver en qué están trabajando el resto de nuestros compañeros.
  • Busca un umbral de satisfacción. Es muy difícil, sobre todo en un entorno complejo. Superar el umbral te puede llevar a la siguiente reflexión ¿he sido poco ambicioso? y quedarte por debajo a ¿he sido muy ambicioso?
  • Evita poner objetivos de bajo valor, estos suelen surgir cuando los objetivos están ligados a los incentivos.
  • Fijar objetivos claros y bien definidos. Si te lleva tiempo explicar el objetivo y los resultados clave, piensa en otra cosa.

Ejemplos de OKRs

Objective: Mejorar la calidad de las pruebas del producto

Key Results:

  • Aumentar la cobertura de las pruebas unitarias en un 75%.
  • Incrementar las pruebas automatizadas en un 70%.
  • Reducir el número de bugs por debajo de 20 bugs por release.

Objective: Mejorar la satisfacción del cliente

Key Results:

  • Realizar 80 entrevistas (presenciales, telefónicas, etc.) con los principales clientes durante los próximos tres meses.
  • Crear un plan de acción de 20 mejoras para el próximo trimestre
  • Superar el 8.0 en la evaluación NPS (Net Promoter Score)

Conclusión

Si estás pensando en usar los OKRs en tu organización, intenta explicar el para qué de su uso. Te será muy útil tener claro lo que son, por qué pueden ser útiles y cómo serán utilizados. Hay que pensar en la motivación intrínseca de las personas al fijarse objetivos que les motiven y además que contribuyan a los de la organización.

A veces nos equivocamos al pensar que esto es lo mejor y debemos cambiar todo ya mismo. Antes de lanzarte, entiende el contexto actual, obsérvalo y mira de qué manera los OKRs realmente te pueden ayudar.

Por último si estás interesado en profundizar sobre temas de OKRs y su relación con Management 3.0 déjanos un comentario o escribinos por correo.

Kanban Metric Layout (I)

El objetivo de estos dos posts es establecer el punto de partida sobre un marco de trabajo de métricas para equipos que estén bajo el método Kanban.

La guía viene separada en dos grandes secciones:

  • Indicadores: Qué es lo que queremos medir (primer post).
  • Gráficas: Donde podremos ver estos indicadores y cómo poder interpretarlos (segundo post).

 

Indicadores

Introducción

Cuando hablamos de indicadores usualmente se utilizan términos como leading y lagging. ¿Pero qué significan?

Lagging indicators suelen ser “output oriented”, fácil de medir pero difícil de mejorar o influenciar, mientras que los leading indicators suelen ser “input oriented”, difíciles de medir pero fáciles de influenciar.

Pongamos un ejemplo. Imagina que nuestra meta personal es perder peso. Un lagging indicator claro que es fácil de medir. Te subes en la báscula y obtienes la respuesta al momento. Pero … ¿como podemos alcanzar nuestra meta? Para perder peso podemos establecer dos “leading indicators”:

1.- Calorías tomadas

2.- Calorías quemadas

Estos dos indicadores son fáciles de influenciar pero difíciles de medir. Cuando pides en un restaurante la cantidad de calorías no están señalizadas en el menú. Y la mayoría de las personas no tenemos ni idea de cuántas calorías quemamos a lo largo del día.

También te puede ayudar a pensar en la diferenciación en que los leading indicators suelen ser de actividad, y los lagging indicators de resultado.

WIP (Work In Progress)

El número de elementos de trabajo empezados pero no terminados.

Aquí no estamos hablando del WIP Limit (extra: ¿Cómo elegir un buen WIP Limit?) . El WIP Limit es una política que los equipos utilizan para crear un sistema Kanban restringiendo la capacidad máxima de su sistema. La meta del WIP Limit es reducir la cantidad de trabajo en progreso (WIP).

El objetivo de dar transparencia al WIP es mostrar a Stakeholders, e incluso a toda la organización, como la reducción de WIP impacta en las demás métricas.

Una buena manera de observar el WIP es utilizar el Cumulative Flow Diagram (CFD).

 

Customer Lead Time

La cantidad de tiempo transcurrido desde que un elemento de trabajo es solicitado por un peticionario y un elemento de trabajo está disponible para el usuario.

Este es el tiempo que más interesa al peticionario. El Customer Lead Time está compuesto por cycles time parciales (dentro de cada estado del workflow) y de waiting states entre un paso y otro.  ¡Ojo! El Customer Lead Time puede depender de más de un equipo por lo que el workflow total está compuesto por el workflow de diferentes equipos.

 

Lead Time o System Lead Time

Es el tiempo que transcurre desde que un ítem de trabajo entra en un punto de compromiso hasta que se entrega.

El punto de compromiso suele recibir el nombre de seleccionadas, ready o next.

La gran mayoría de las veces las prioridades de un servicio no están estipuladas por el equipo si no por la organización. Imaginemos que un peticionario realiza una petición “A” con una prioridad 3 sobre 5, siendo 1 la más baja y 5 la más alta. Pero cuando el equipo ejecuta el siguiente replenishment ha llegado otra petición “B” con prioridad máxima 5. Esto deja fuera del sistema a la petición A alargando su Customer Lead Time.

Este es el motivo por el que un equipo se compromete a tener un lead time lo más estable posible y suficientemente bajo y muchas veces no puede comprometerse con un Customer Lead Time. El Lead Time representa el tiempo que el trabajo está en la zona que pertenece al equipo. Mientras que el Customer Lead Time depende de factores que escapan al equipo y puede dispararse por razones externas como un cambios de prioridades.

Esta métrica es un “lagging indicator” de flujo. Está disponible sólo cuando un elemento está ya terminado desde la perspectiva del workflow. Normalmente se utiliza, junto con el Cycle Time,  para impulsar trabajo de mejora, así como para poder establecer expectativas internas / externas en cuanto al tiempo de respuesta del equipo en elementos específicos.

 

La métrica más usada para observar el Lead Time medio aproximado es el Cumulative  Flow Diagram.

 

Lead Time medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

 

 

Cycle Time

La cantidad de tiempo transcurrido entre que un elemento de trabajo “comienza” desde que pasa un punto de commitment y un elemento de trabajo “termina”. En la siguiente imagen por ejemplo desde que entra en desarrollo hasta que está terminado. También puedes tener cycle time parciales por cada uno de los estados del workflow.

La gráficas más usadas para visualizar y analizar los Cycles Times son:

  • Cycle time scatterplot (control chart)
  • Histograma de cycle time

 

Throughput

El número de elementos de trabajo “terminado” por unidad de tiempo.

Nótese que la medición del throughput es el número exacto de elementos de trabajo, sin ningún tipo de compensación por el tamaño del mismo. El throughput se puede medir en cualquier paso del workflow y generalmente se utiliza el final del mismo.

El throughput se puede observar utilizando:

  • Run chart
  • Cumulative  Flow Diagram

Work Item Age

La cantidad de tiempo transcurrido entre cuando se inició el trabajo y la fecha actual.

Work Item Age complementa el Cycle Time. Si el Cycle Time es un lagging indicator relevante sólo para elementos terminados, Work Item Age es un leading indicator solo relevante para los elementos aún en desarrollo. La idea principal de este indicador es proporcionar transparencia sobre qué ítems están fluyendo correctamente y cuales están algo “atascados”, incluso si no están formalmente bloqueados.

El Work Item Age debería ser transparente en el ticket de cada elemento para facilitar buenas decisiones pull. Además, podremos consultarlo en el Aging Work In Progress.

Medir el Work Item Age permite también reducir los riesgos y mejorar la predictibilidad, mejorando la eficiencia global del sistema.

 

En el siguiente post vemos las gráficas donde analizar estos indicadores. ¡No te lo pierdas! Pulsa aquí para ir directo

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad