Buscar en Gazafatonario IT

martes, mayo 24, 2022

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

miércoles, mayo 18, 2022

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.