Ámbito o contexto de las historias de usuario

Haz clic en la imagen para ampliar y descargar en alta definición

Sigo viendo muchas historias de usuario que más bien parecen historias de ficción y hasta de ciencia ficción: el “usuario” de “historia de usuario” no aparece por ninguna parte.

Ahora vengo con esta imagen, a ver si ayuda. ¿Cómo la ven? ¿Qué les dice? Por favor, déjenmelo saber en el foro.

Para saber más sobre el Contexto de las historias de usuario, o de la cuarta C de las historias de usuario, visita:

http://www.gazafatonarioit.com/2019/06/las-historias-de-usuario-se-cuentan-con.html

También, el User Story Conversation Canvas:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

[Nuevo Libro] Scrum: Epítome de experiencias

 

Prólogo

Con suerte y gracias a tu tenacidad y esmero, ya eres parte de un equipo de producto sólido y dedicado exitoso. Y has ganado cierta experiencia en el camino. Con suerte también estás usando Scrum y otras prácticas agiles que potencian tu trabajo y el de tu equipo. Si es así, este libro es para ti. Pero si no estás ahí, o si estás en algún lugar intermedio entre aquel gran objetivo y ese punto inicial, este libro también es para ti.

Lo que vas a encontrar aquí es un cúmulo de experiencias que hemos aunado a lo largo de más de una década de trabajo con agilidad y que hemos estado escribiendo desde entonces. Al principio, contamos las experiencias como fueron dándose, de una manera natural y hasta espontánea.

Más adelante, aunque siguen siendo nuestras experiencias, resultado de innumerables catas, experimentos, historias y conversaciones, se encuentran una serie de recomendaciones producto de nuestro propio aprendizaje y del aprendizaje de una gran cantidad de personas, equipos y empresas que hemos acompañado a lo largo de más de una década con Scrum y otras prácticas ágiles como historias de usuario, Kanban, Nexus y Scrum@Scale.

El libro tiene cuatro grandes secciones:

Los prolegómenos,

Scrum esencial,

Táctica y estrategia, y

Patrones Scrum y otros energizantes Scrum

Los prolegómenos son una plétora de conceptos y pensamientos base para iniciar conversaciones sobre Scrum. Son conversaciones que luego extendemos en Scrum esencial, donde abordamos los elementos subyacentes del marco de trabajo. A partir de allí, en táctica y estrategia, intentamos poner de manifiesto cómo hemos superado muchos de los escenarios que hemos enfrentado en nuestro propio trabajo, sin que estas se conviertan en la única forma de hacer las cosas.

Hacia el final del libro, en Patrones Scrum y otros energizantes Scrum, detallamos nuestras experiencias más avezadas, muchas de las cuales nos han permitido elevar no solo la productividad de los equipos que acompañamos diariamente, sino también la felicidad de las personas que los conforman. Es precisamente ese “cómo mejorar tu práctica ágil para obtener resultados asombrosos” de la portada.

Si apenas estás iniciando con Scrum o llevas poco tiempo probando el marco de trabajo, empieza con las dos primeras secciones. Si eres un prácticamente Scrum experimentado, seguramente encontrarás en la tercera sección, esas tácticas y estrategias que quizás te ayuden a llevar a tu equipo al siguiente nivel de mejora.

Este libro no reemplaza la guía oficial de Scrum de Sutherland y Schwaber. La lectura de esta debe ser obligatoria y frecuente, porque a medida que experimentamos y aprendemos más, entendemos mejor los lineamientos expresados en ella. El libro intenta más bien dar una serie de respuestas que no se encuentran en la guía debido a su propia naturaleza: es liviana, incompleta y solo presenta algunas pocas reglas del juego.

Mucho de este material ya estaba escrito, sino todo. Hemos revisado cuidadosamente cada capítulo y cada tema de estos, los hemos actualizado, no solo acorde a los nuevos lineamientos de la guía de Scrum, sino de acuerdo con nuestra experiencia. Incluso hemos reescrito algunos de ellos casi en su totalidad.

Parte de este contenido lo escribimos a cuatro manos, por eso nos expresamos como “nosotros”, pero, en general, nos expresamos en primera persona del singular, aun así, todo hace parte de un trabajo colaborativo a lo largo de todos estos años que nos ha permitido comprobar la muy conocida máxima de Aristóteles de “el todo es mayor que la suma de las partes”.

Bien sabemos que la práctica hace la perfección. Nuestro mayor deseo es que este libro empieza a acompañar tu práctica hacia ser mejor un paso a la vez. Disfrútalo.

Jorge Abad y Lucho Salazar

Puedes encontrar el libro en formato Kindle (próximamente en formato impreso) en Amazon:

https://www.amazon.com/dp/B0BB7PW1QL

 

El otro 3-5-3 de Scrum

 Quizás todos conocemos la simbología del 3-5-3 en Scrum:

·       3 Responsabilidades

·       5 Eventos

·       3 Artefactos

No voy a hablar mucho de esto porque a estas alturas hay suficiente ilustración. Sin embargo, si la expresión es nueva para ti, te dejo este infográfico y una referencia en donde puedes encontrar más detalle:

Fuente: https://www.scruminc.com/the-3-5-3-of-scrum/

La traducción y adaptación libre es mía.

Sobre cada uno de estos elementos básicos de Scrum he escrito lo suficiente en mi Gazafatonario como para publicar un libro. Jorge Abad también ha escrito otro tanto que puedes encontrar en sus Lecciones Aprendidas.

De una conversación con nuestro amigo Juan Andrés Ochoa, esta vez llamó mi atención que en Scrum tenemos otro 3-5-3 no menos importante que el anterior, porque se trata precisamente de lo que representa el espíritu ágil de Scrum. Se trata de los 3 pilares, los 5 valores y los 3 compromisos, estos últimos, adicionados en la última edición de la guía oficial, pero que ya estaban presentes en el ámbito del marco de trabajo.

Sobre los tres pilares

La Casa Scrum

Bien sabemos que lo que he dado en llamar “La Casa Scrum” se erige sobre tres pilares fundamentales, que no son más que los pilares de todo proceso empírico: transparencia, inspección y adaptación. Todo proceso empírico requiere de estos tres pilares para que sus practicantes obtengan el mayor beneficio posible de su uso. El empirismo no es más que trabajar basados en hechos o datos, evidencia y experiencia. Un proceso empírico hace que tengamos una gran dependencia del ensayo y el error y, a través de estos, obtenemos aprendizaje validado. De hecho, cuando se practican vehementemente, estos pilares se convierten en elementos clave de la cultura organizacional.

Además de lo que dice la guía de Scrum, he ayudado a muchos equipos y empresas a adoptar estos pilares de muchas formas. Promoviendo que la comunicación entre las personas sea abierta y diáfana, que siempre se aseguren de que los receptores de la información la entiendan y que todos entiendan lo mismo. En este punto juega un papel muy importante La Definición de Terminado, a lo que me referiré más adelante. La transparencia es una mezcla de honestidad y franqueza. Entre otras técnicas, usamos comunicación no violenta y radiadores de información para maximizar la transparencia dentro del equipo y con su entorno. Y, puesto que no todo el mundo está igualmente motivado y tiene el mismo nivel de conocimiento y experiencia, nos aseguramos de que haya una comprensión promedio sobre todos los objetivos a alcanzar, las tareas a realizar y el valor a entregar.

 Con la transparencia sobre el tapete es más simple reflexionar. La inspección se logra analizando precisamente esos datos y hechos y esas evidencias que han surgido de nuestros acciones y experimentos previos. De lo que dicen nuestros propios compañeros de equipo, los interesados, los usuarios o consumidores, y de la forma cómo estos precisamente están consumiendo nuestros productos o servicios. Hacemos análisis de causa raíz usando técnica como los 5 Por qué para asegurarnos de que a continuación encontremos el mejor camino a seguir. Para maximizar la inspección, valoramos inmensamente la perspectiva de cada persona. Como prerrequisito de esto, continuamente promuevo en los equipos que acompaño que se conozcan mejor entre sus integrantes, a veces con preguntas poderosas y profundas, otras veces con cuestiones más divertidas y cándidas, pero que permiten exhibir el verdadero talante de las personas.

Con esta información y con estas causas raíz, nos adaptamos para mejorar. La adaptación constante es esencial. Es lo que nos permite mantener el foco en las necesidades reales del cliente final, en lo que significa valor para la organización en cada momento del tiempo, siempre en la justa medida con los objetivos estratégicos y de negocio de la empresa. Adaptación en mejora implacable. Un paso a la vez. Es lo que nos va a permitir sobrevivir ante la alta incertidumbre, atributo inherente al trabajo que hacen nuestras organizaciones hoy por hoy. Si en el proceso de hacer algo, no mejoramos, nuestro fin llegará muy pronto.

Los beneficios de levantarnos día a día sobre estos tres pilares son a todas luces evidentes, pero hablaré de ellos en otra oportunidad.

Sobre los cinco valores

Valores Scrum. Fuente: Scrum.org

Cada equipo tiene su propio distintivo y temperamento. Así como existe una “cultura organizacional”, en la actualidad no es posible hablar de una “única cultura empresarial”. Cada equipo y cada contexto es diferente, incluso en cada momento del tiempo. Dada esa complejidad, los valores entran a jugar un soporte vital en la forma cómo se comportan, se comprometen y entregan resultados las personas de un equipo y de una organización.

Scrum nos propone empezar con 5 valores esenciales: coraje, foco, compromiso, respeto y franqueza. Y quiero aprovechar justo este momento para señalar que, por el contexto y su descripción, la traducción del valor Openness siempre debió ser Franqueza y no Apertura como estaba antes de la edición de 2020.

Pensemos en estos cinco valores de Scrum como en un sistema de valores, uno que diferencia sentimientos, pensamientos, corrientes ideológicas y comportamientos humanos que consideramos correctos para el equipo Scrum y para la organización. Todas las acciones del equipo giran en torno a estos valores y es con ellos con los que creamos armonía interna y con el mundo exterior al equipo. Además de definirlos, en este caso de adoptarlos, los valores se demuestran, es decir, ayudamos a que los demás los entiendan; los valores se demandan, o sea, cada persona es responsable de que los demás lo cumplan y exigen su cumplimiento; y los valores se difunden a lo largo y ancho del ecosistema empresarial. Es algo que se conoce como las 4 D de la cultura, promovido por Fred Kofman en su modelo de coaching consciente.

Sobre los tres compromisos

Esta es la más reciente “adición” a la guía de Scrum. Aunque, como dije antes, siempre estuvieron en el ámbito del marco de trabajo. Cada uno de estos compromisos está vinculado a un artefacto Scrum:

·       Para el Product Backlog, es el Objetivo de Producto.

·       Para el Sprint Backlog, es el Objetivo del Sprint. Y

·       Para el Increment, es la Definición de Terminado.

Para conocer exactamente qué significa cada compromiso, por favor, lee la guía de Scrum. Estos compromisos fomentan la autonomía, encontrando el balance justo con la alineación. Esta última viene dada precisamente por los tres compromisos. Con el objetivo del producto, tenemos alineación en el largo plazo. Es lo que el equipo quiere lograr una vez el producto alcance un estado de uso masivo, ya sea porque contiene muchas características implementadas o porque lo está usando un gran número de consumidores.

Con el objetivo del sprint logramos alineación en el corto plazo, a medida que el producto nace y crece. A medida que los primeros clientes empiezan a retroalimentar al equipo y aprenden más con el uso preliminar del producto en construcción. También ayuda a que el equipo mantenga el foco en el trabajo de cada sprint y no se distraiga con lo que más tarde podría considerarse desperdicio. Se trata de elaborar el producto correcto desde el principio, pero tenemos que estar preparados para lo inesperado, en este caso, para que algunos usuarios rechacen parte de o todo el producto construido hasta cierta fecha.

La Definición de Terminado, por su parte, fomenta la transparencia. Es esa lista de condiciones, a manera de acuerdos, cuyo cumplimiento nos asegura que el producto cumple con lo que necesitan los clientes. La Definición de Terminado es un instrumento que ayuda al equipo a ahorrar mucho tiempo, sobre todo en el largo plazo, porque disminuye ostensiblemente sesiones de revisión redundantes. Si el producto cumple con la Definición de Terminado, está preparado para ser presentado incluso ante tiburones tipo Shark Tank y en horario triple A. Finalmente, la Definición de Terminado da testimonio de consistencia y de la calidad del producto.

Conclusiones

He visto fallar muchas adopciones de Scrum. Mucho de ello se debe a que queremos usarlo como un mero contenedor de prácticas de todo tipo, olvidando desde los primeros instantes su espíritu ágil.

Así que ya sabes, tienes dos alineaciones 3-5-3 para jugar Scrum. Ninguna es más importante que la otra. Tienes que jugar con ambas si quieres tener éxito. Debes jugar con ambas si no quieres despertarte un día y darte cuenta de que el camino que una vez tomaste no era el correcto.

Y déjame saber en el foro qué haces para vivir el espíritu de Scrum.

 

Monólogo de la Product Owner viendo llover en la organización*

 

El invierno de la agilidad se precipitó un martes al finalizar la reunión diaria. El día anterior había sido sofocante por las continuas solicitudes sin pies ni cabeza de la aún establecida oficina de proyectos o PMO. Pero aún en la mañana del martes no se pensaba que pudieran llover los improperios propios de grupos y seudoequipos de una empresa ámbar, más que de una que se preciaba de estar recorriendo ya el camino ágil hacia convertirse es una corporación verde y luego Teal.

Después de la reunión diaria y antes de que los miembros de los equipos tuvieran tiempo de ir por el café de la mañana, sopló un viento espeso y oscuro en forma de correo electrónico, el mismo que apenas tardó segundos en convertirse en un mensaje viral de chat que barrió en una amplia vuelta redonda los acuerdos y planes que se acababan de concertar para ese día. Alguien dijo junto a mí: “Son los vestigios de la gestión tradicional”. Y yo lo sabía desde antes. Desde antes de empezar la reunión y me sentí estremecida por la viscosa sensación en mi mente.

Los miembros de los equipos corrieron hacia los escritorios más próximos con una mano en la cabeza y los ojos arrugados, como tratando de protegerse de las noticias contradictorias y la polvareda de impedimentos que iban a encontrar en el detalle del correo. El techo de la oficina se cubrió como de una sustancia roja, que nos hizo recordar las épocas en la que los así llamados “líderes” demostraban su poder mediante el uso de la violencia y el acoso laboral, un retroceso abismal de esa utopía que suponía el pensamiento ágil y lean de poner foco en el bienestar de los empleados y la autogestión.

Durante el resto de la mañana, mi Scrum Master y yo estuvimos sentadas junto a mi escritorio, preocupadas por la revitalización de las prácticas de gestión antiguas debido al poco éxito que estaba teniendo la iniciativa de transformación ágil en la organización. Habían sido siete meses de primavera intensa, pero el polvo abrasante de la austeridad había vuelto junto al infame tren de las 2 de la tarde, lleno de los preceptos que habíamos abandonado cuando emprendimos el proceso de cambio cultural.

Entonces rebobiné mis recuerdos. ¿Por qué estábamos fracasando? ¿Por qué nos habíamos estancado ante la vegetación ámbar donde se llegaba a la cúspide empresarial por antigüedad y no habíamos logrado llegar a ese punto donde el empoderamiento estuviera en todos y cada uno de los miembros de la organización? Reviví una conferencia donde mi Scrum Master le preguntó al Agile Coach de turno que “cómo lidiaba con un PO con ínfulas de PM” y de otro Scrum Master que se sumó a la conversación para indagar sobre “qué hacer con un PO que habían nombrado a dedo y de manera inesperada”.

Vivifiqué mis pensamientos de entonces. Quise pensar que mi Scrum Master dijo “lidiar” solo como una forma de decir que quería mejorar su relación con el PO, conmigo, o con cualquier otro. Estaba segura de que lo primero en lo que debería pensar es en que no somos “sujetos de lidia”, como los toros, ni más faltaba. Tampoco se lidia con ninguna otra persona del equipo ni de la organización. Lidiar es un término despectivo que no ayuda a la relación. Al PO, aún con delirios de PM, lo acompañas, le facilitas su vida como PO, lo ayudas en la transición. Paso a paso. Despacio. Con paciencia. Sin importar como haya llegado al equipo. A propósito, casi siempre un PO llega al equipo como dijo el otro Scrum Master: nos ponen allí. El viernes a las 7 de la noche me dijeron que, a partir del siguiente lunes, además de lo que ya hacía, ahora iba a ser PO. Nada raro en una empresa de ambiente rojo, que tuvo su origen en las comunidades más primitivas y que se basaba en la existencia de un líder todo poderoso que ejercía su autoridad a través del miedo.

Tampoco se trataba simplemente de explicarme una sola vez cuales eran mis responsabilidades como Product Owner, o cuales eran las distinciones del enfoque ágil respecto al enfoque tradicional que veníamos abrazando desde siempre, ni de decirme que tome un curso de esto o de lo otro. Es un proceso. Es un camino realmente. En estas situaciones es donde el coaching y la mentoría entran a jugar un papel muy importante, es donde las conversaciones conscientes se vuelven el instrumento principal de mejora. Para mejorar la comunicación conmigo como PO, haciéndome pedidos efectivos, asegurándote de brindarme todo lo que necesito para que cumpla con mis compromisos, pero un paso a la vez.

Tienen que saber, estimados Scrum Masters, que el cambio es algo difícil, es el síndrome del “siempre lo hemos hecho así”. El temor a la falla. Es algo natural. Por ejemplo, enséñame que es distinto “fracasar” que “cometer errores” y que de ambas situaciones puedo aprender. Enséñame a experimentar como PO, a hacer planes es un contexto empírico. En los entornos tradicionales eso es algo que desconocíamos. Enséñame distintas maneras de expresar historias de usuario, entre otras, usando Hypothesis-Driven Development, por aquello de los experimentos. Las posibilidades son muchas, por no decir que infinitas.

Como siempre, el equipo en pleno debe estar comprometido en la gesta. Si el equipo no entrega valor, no produce al menos parte de los resultados que quiero como Product Owner, muy poco o nada de lo anterior nos va a servir. Y una vez más, con paciencia, el cambio de mentalidad no va a suceder pronto. Aún los PO con mentalidad de emprendedores tenemos miedo alguna vez o muchas veces.

No sé cuánto tiempo estuve hundida en aquel sonambulismo en que los sentidos perdieron su valor. Solo sé que después de muchas horas incontables oí una voz en el cubículo vecino. Era una voz fatigada, propia de las personas que han vivido bajo una cultura de sacrificio laboral y andando “millas extras” por doquier, como si el permanecer en la oficina produjera resultados de valor. Era una voz casi de persona convaleciente. Una voz que decía: “Ahora tendremos una retrospectiva”. Esa voz tenía razón, las últimas retrospectivas no habían servido de mucho, ¿por qué esta habría de ser distinta?

Solo entonces me di cuenta de que había llegado la cita a la reunión y de que en torno a nosotros se extendía un silencio, una tranquilidad, una beatitud misteriosa y profunda, un estado imperfecto que debía ser muy parecido a la muerte laboral.

* El título y algunos apartes del artículo están basados en el cuento “Monólogo de Isabel viendo llover en Macondo”, de Gabriel García Márquez.

Crédito de la foto de la portada: Foto de Zinkevych en iStockPhoto https://www.istockphoto.com/es/portfolio/Zinkevych?mediatype=photography

La furia de los OKR

El péndulo osciló de nuevo.

Los así llamados objetivos y resultados clave, OKR en su forma corta por sus siglas en inglés, están en boga de todo el mundo. Pero ya sabemos que parlotear sobre algo no es suficiente para hacerlo bien. Lamentablemente las muy malas prácticas también llegaron a ese ámbito. Hoy queremos OKR para todo. Quizás es la primera falla. Queremos OKR primero que todo. Quizás es la segunda falla. O, al contrario. Pero estos son dos de los antipatrones más comunes en la actualidad cuando de adoptar y usar esta práctica se trata.

OKR para la empresa. OKR para las áreas. OKR para los equipos. OKR para las personas. OKR para los productos. OKR para los clientes. OKR para los socios de negocio. OKR para el hogar. OKR para esto y para lo otro. En principio, eso no tendría nada de malo si se hiciera bien desde el comienzo, de manera orgánica, validando paso a paso el aprendizaje, reflexionando sobre lo que está pasando, haciéndolo de manera colaborativa, desligándolos de las prácticas de gestión del siglo pasado; pero no. No es así.

Confundir los temas con objetivos, querer definir todo el trabajo del equipo como OKR, no distinguir entre resultados clave y actividades del equipo, lograr resultados clave por percepción o apreciación, casi por clarividencia, valorar estos resultados clave en escalas insólitas o simplemente incorrectas, Confundir OKR con KPI o definir de aquellos y de estos y tratar de manejarlos bajo el mismo manto de gestión y ejecución, alcanzar el 1 o el 100 % en cada OKR de manera continuada, perseguir, casi que hostigar de manera obstinada, un OKR quimérico; ajustar o acomodar el backlog de producto o de una iniciativa en general a los OKR, o sea, el clásico paradigma de la cola asustando al gato; OKR como vasija contenedora de todas las metas presentes y futuras de la empresa. Estas, entre otras, son algunas de las prácticas erróneas cuando de OKR se trata.

Pero más allá de estas, me he encontrado con la puesta en marcha de programas de OKR sin un sustento aparente, sin conocer el porqué lo están haciendo, la causa raíz. Escenarios donde abundan respuestas como que: los demás lo están haciendo, yo también; o, me los recomendó un amigo. Es porque Google, Amazon, Intel los están usando y les está yendo muy bien. Es que me leí el libro de John Doerr y me pareció buenísimo. Me refiero, por supuesto, a Mide lo que importa, sobre el cual comentaré más adelante. En breve, de mi observación, he llegado a la conclusión de que hemos idealizado a los OKR y a la práctica de estos. Nos hemos enamorado de una entelequia. Y, como con muchas otras iniciativas, los equipos y las organizaciones están fracasando en grande.

No me malinterpreten. Los OKR son una muy buena práctica. ¡Cuando la sabemos usar! Por supuesto, tenemos que empezar por entender de qué se trata. Hay mucha documentación sobre esto. Por ejemplo, están estos dos artículos de mi siempre bien comedido amigo Jorge Abad:

OKR - Pasando de la Intención a la Acción

http://www.lecciones-aprendidas.info/2020/08/okr-pasando-de-la-intencion-la-accion.html

Seguimiento de OKR empleando Scrum como marco de gestión

http://www.lecciones-aprendidas.info/search/label/okr

Y mi sucinta presentación introductoria:

Conociendo OKR

http://www.gazafatonarioit.com/2020/06/conociendo-okr.html

Pero recordemos aquí los aspectos más relevantes:

“Los OKR son un protocolo de colaboración para establecer objetivos en empresas, equipos e individuos”. [John Doerr. Mide lo que importa.]

Hay algunas palabras clave allí y, por si no las notan, aquí las resalto:

“Los OKR son un protocolo de colaboración para establecer objetivos en empresas, equipos e individuos”. [John Doerr. Mide lo que importa.]

Protocolo. Se trata de unas reglas de juego. Algunos lineamientos que le han funcionado a otros para la implementación y uso de OKR.

Colaboración. Específicamente se trata de reglas o de normas para colaborar, para aumentar la confianza, para aumentar y mejorar la comunicación entre las personas de un equipo y entre equipos. Se trata de una forma de interiorizar, practicar y fomentar cultura de servicio, una manera de ir pasando gradualmente de trabajo en silos a trabajo por flujos de valor. La colaboración es una de las formas más bonitas que conozco, condición sine qua non, además, de fomentar el liderazgo que necesitan las organizaciones actuales, uno que inspire y guíe la búsqueda de un propósito superior.

Objetivos. Este es el punto definitivo. El propósito superior por el cual todas y cada una de las personas de un equipo y de una empresa se levantan cada mañana y “asisten” al trabajo. Hacer de este mundo algo mejor de lo que estaba cuando empezamos a transitar por él.

De eso se trata. Pero es aterrador lo que ocurre en la práctica:

·       OKR definidos por unas pocas personas, por aquellos que “deciden” el destino del equipo y de la empresa. Por personas que no se preguntan si están dadas las condiciones para lograrlos.

·       OKR mal desplegados, luego de lo cual cada uno se aísla en su mundillo corporativo a trabajar por sus propios intereses sin que nada ni nadie los perturbe.

·       El seguimiento y control a la ejecución de los OKR me recuerda las épocas en las que se medían el número de líneas de código escritas por día, la cantidad de errores encontrados en el producto o el número de horas adicionales que trabajabas y que demostraban tu compromiso con el proyecto y con la empresa.

·       OKR “seudodelegados”. Los jefes asignando la responsabilidad de los resultados a su equipo, pero al mismo tiempo no les ceden la autoridad para hacer lo que tengan que hacer para lograr los objetivos planteados.

·       Incluso me he encontrado con el síndrome del “solo yo puedo hacerlo”. Personas que no trabajan de manera colaborativa o que no empoderan a su equipo para ejecutar los OKR porque creen que son indispensables para alcanzar los objetivos propuestos. Sin ellos no es posible conseguirlos.

·       Cuando finalmente buscan el compromiso del equipo y tratan de delegar la obtención de los resultados, los impulsores de los OKR no proporcionan el equipo los recursos y no fomentan el entorno adecuado para que se conquisten las metas trazadas.

Así es que cuando te vayas a comprometer en una iniciativa que involucre OKR, practica lo contrario a esto que te he contado aquí. Quizás así encuentres una salida al éxito que quiere tu equipo y tu organización, quizás así puedas hacer frente a esta infame furia de los OKR.

Mientras eso sucede, por favor, cuéntame en el foro que otras cosas se te ocurren para desafiar ese furor dañino que supone el mal uso de los objetivos y resultados clave.

Addendum

Sobre el libro Mide lo que importa, de John Doerr.

Les confieso que soy poco amigo de recomendar libros. La responsabilidad en ese sentido es muy grande y a veces creo no poder con tanto. Así que esta vez trataré, quizás por primera vez, de soltar mis emociones, incluso mis juicios, subjetivos por demás, sobre esta pieza técnica de Doerr que leí hace ya algunos años.

Voy a destripar en grande: ¡el libro me quedó debiendo!

Tiene una gran historia sobre los orígenes de los OKR, con diversos ejemplos de cómo lo han estado usando empresas para mejorar como organizaciones, para ser más efectivas. Pero no encontré placer con esos ejemplos, no lo sé, quizás debido a que desde el título del libro o de su introducción, esperaba algo distinto.

Si estás esperando una guía para concertar y definir “buenos” OKR para tu equipo y tu empresa, quizás este no sea el medio para lograrlo. Afortunadamente puedes ir a Internet y encontrar copiosos ejemplos para ello: OKR para Talento humano, OKR para desarrollo de producto, OKR para ventas, OKR para la alta dirección, OKR para esto y para lo otro. Eso sí, siempre haz chequeo cruzado, no vayas asumiendo que todo lo que encuentras por allí es de buena calidad.

Volviendo al libro, me quedé con la convicción de que la mayoría de los ejemplos adolecían de detalles prácticos. Eran más como historias para demostrar la versatilidad de los OKR. Eso sí, como escritor, creo que esto es un proceso natural. Estoy haciendo conjeturas cuando digo que el autor se situó en cada momento de la historia y usó la experiencia de ese momento para escribir cada aparte del libro y cada historia y cada ejemplo.

De algo sí estoy bien seguro: algunos de los resultados clave me parecieron imposibles o cuasi imposibles de medir.

¿Estás de acuerdo? ¿No? Bueno, el foro es un buen espacio para que lo hablemos.