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.

El traje ágil del CEO

Ilustración de la edición del cuento de Combel Editorial

En mi artículo Lo que no les enseñan a los CEO sobre agilidad afirmo que no existen las condiciones “correctas” o apropiadas para la agilidad y que ninguna empresa está preparada para cambiar su forma de hacer las cosas. Y más adelante defino como natural que a los CEO y a toda la alta gerencia de la organización los asalten muchos miedos durante los procesos de transformación, especialmente hacia la forma ágil de trabajar.

Esta vez hablaré de algo que normalmente se esconde bajo la alfombra de las compañías tradicionalistas, pero que se grita a voces llenas en los pasillos, en los cafés y en los chats virtuales de las mismas: todos dicen ser ágiles, dicen que piensan como agilistas, que se comportan como agilistas, pero en el fondo no lo son. Algunos saben que no lo son, otros no saben que no lo son, pero aún hay otros que ni siquiera saben de qué se trata la agilidad.

Con todos ellos tenemos un compromiso. Pero lo peor es que no son capaces de hacerlo vox populi, mucho menos ante la media o alta dirección de la empresa.  No son capaces de adoptar una posición de responsabilidad y expresar los hechos tal y como son. Son muchas las razones de este comportamiento, pero la mayoría giran en torno a que en la empresa hay una cultura de miedo arraigada, una cultura de castigo, de represión de ideas, del “siempre lo hemos hecho así”, de “usted nunca tiene la razón”, una cultura de competencia entre líderes, el “yo tengo más poder que tú” y similares.

Es por ello por lo que a estas organizaciones comúnmente llegan consultores que aprovechan la situación y se invisten de un halo de sabiduría y voluptuosidad para ofrecer recetas de cambio cultural a diestra y siniestra, sin ningún análisis previo del contexto actual, sin ningún reconocimiento del problema, mucho menos del problema detrás del problema, de la causa raíz, del porqué la organización debe o debería hacer las cosas de otra forma.

Aquí es donde entra la alegoría del cuentista Hans Andersen que me sirvió como detonante para esta reflexión:

los hermanos Farabutto engatusaron al emperador para que les permitiera confeccionar un traje con una tela mágica. Los ladinos certificaron que era un traje tan singular que era invisible para cualquier persona que fuera estúpida o incapaz para ejercer su cargo. El mismo emperador, temeroso de ser considerado indigno, enviaba a sus sirvientes a revisar el trabajo de los acomodados modistos. Pero todos ellos y el resto de sus súbditos simulaban ver un traje que no existía. Nadie quería parecer idiota. Finalmente, el día del desfile, el emperador y todos afirmaban a mansalva que el traje era una realidad deslumbrante. Sin embargo, un niño simplemente gritó: “¡Está desnudo!”. A partir de ese momento, todos “vieron” la verdad.

Así ocurre con la agilidad. Muchos pueden seguir actuando como si estuvieran vestidos con trajes lujosos y hasta mágicos, o tener el coraje para decir la verdad y aceptar que están desnudos. En particular, muchos CEO, como el emperador, van desnudos de agilidad por los pasillos organizacionales porque nadie es tan intrépido como para decirles que no saben de qué se trata la transformación ágil ni mucho menos están preparados para cambiar su forma de hacer las cosas.

Es un hecho, la transformación ágil no la realizan las consultoras. Estas, apenas están ahí para acompañar el proceso. No permitas artificiosos hermanos Farabutto, ni internos ni mucho menos externos a la compañía. Propicia una cultura auténtica y fuerte basada en valores. Una cultura donde estos valores no solo se definan, sino que se contextualicen, se experimenten y se protejan.

Por ejemplo, uno de los valores de Spotify es la Sinceridad. "No tenemos tiempo para la política interna. Lideramos con transparencia y nos comprometemos con la mente abierta. Crear algo nuevo requiere confianza, por lo que la retroalimentación sincera entregada con buenas intenciones está en el corazón de todo lo que hacemos". [1]

Por su parte, Netflix contrata y promueve personas que demuestren, a manera de comportamientos y habilidades, entre otros valores, el Coraje: [2]

·       Dices lo que piensas, cuando es lo mejor para Netflix, incluso si es incómodo

·       Tomas decisiones difíciles sin agonizar

·       Tomas riesgos inteligentes y estás abierto a posibles fallas

·       Cuestionas acciones incompatibles con nuestros valores

·       Eres capaz de ser vulnerable, en busca de la verdad

Mientras tanto, uno de los valores de LinkedIn es ser abierto, honesto y constructivo. “Nos esforzamos por comunicarnos claramente y compartir comentarios útiles” [3]. Cuando los valores son claros hay una predisposición manifiesta hacia los buenos comportamientos y una mejor cultura. Algunos de los beneficios directos que este entorno seguro trae incluyen que las personas no experimentan ninguna incomodidad o miedo a plantear problemas, sugerir soluciones, realizar experimentos, cometer errores y procesar diferencias, entre muchos otros.

La desnudez ágil no tiene que ser un tabú. El compromiso al que me refería antes, de nosotros como agentes de cambio, es hacer que las personas sean conscientes de que no saben y acompañarlos en la difícil tarea de conocer lo nuevo, sin entrar en batalla con lo antiguo, aunque invitándolos a desaprender y a desarraigarse de las conductas vigentes. Sobre todo, a quienes hacen parte de la alta dirección quienes, en su mayoría, se mantienen alejados de los intentos de cambio profundo de la organización.

Las cosas así, que sea esta la última vez que el emperador CEO camina desnudo de agilidad por los corredores de la empresa.

 

Referencias

Lo que no les enseñan a los CEO sobre agilidad

[1] https://www.lifeatspotify.com/being-here/the-band-manifesto

[2] https://jobs.netflix.com/culture

[3] https://careers.linkedin.com/culture-and-values

Scrumming the Scrum

Imagen de ar130405 en Pixabay

Acordemos esto de una vez: contrario a lo que muchos creen y hacen, las tareas más importantes durante un sprint deben ser las de tareas “Kaizen” o de mejoramiento continuo. Ahora bien, está claro que el objetivo del equipo en cada sprint es entregar valor, esto es, un incremento de producto con valor para el entorno bien sea el usuario, el cliente o consumidor, los interesados, los patrocinadores y, en general, el ecosistema organizacional. No perdamos eso de vista.

Pero muchos piensan que esto es lo único que se debe hacer durante un sprint. Es muy común llegar una retrospectiva y encontrar que las acciones de mejora definidas en la retrospectiva anterior e, incluso, en unas más antiguas no se han empezado a implementar o a adoptar. Las razones van desde el clásico “nos consumió el día a día”, hasta el “las tareas no se priorizaron”, “apareció algo más urgente”, “no tuvimos tiempo”, “tenemos mucho trabajo”, “eso no es urgente”, etcétera.

Es un círculo vicioso: no mejoramos porque no tenemos tiempo y no tenemos tiempo porque no mejoramos. Como siempre, hay que empezar por cambiar esa mentalidad, más que adicionar un proceso que las personas y los equipos necesitan aprender. La mejora continua no aumenta la carga de trabajo, no son más procesos ni herramientas, no se trata de más tiempo “improductivo”. Lo crítico es aprender a integrarla en nuestro trabajo diario.

El Kaizen es una forma de pensar y de hacer las cosas, no algo adicional por hacer. En la práctica, no son tareas para realizar los miércoles a las 9 de la noche o los domingos a las tres de la tarde, cuando se supone que ya “estamos al día” en las tareas habituales de la empresa. No. El kaizen hay que incluirlo como parte del valor que estamos produciendo para la organización. Es de esta manera cómo en el mediano y en el largo plazos seremos más productivos, más innovadores, avanzaremos más que la competencia, cubriremos las necesidades de nuestros clientes y nos adelantaremos a otras exigencias o problemas que tengan, seremos más creativos y disruptivos y podremos transformar no solo nuestra organización sino también el mercadeo que la rodea.

La lista de beneficios que obtenemos cuando adoptamos una mentalidad de mejoramiento continuo puede ser infinitita:

·       Personas más comprometidas y con tendencia a una menor rotación en la empresa

·       ¡Personas más felices!

·       Mejor servicio al cliente. No se nos olvide que estamos en la era de la hiperpersonalización de productos y servicios.

·       Productos y servicios más competitivos

·       Tener una cultura de aprendizaje proactiva

·       Operaciones más eficientes

·       Mayor productividad

·       Tiempos de entrega más cortos

·       Tasas de error más bajas

·       Mayor calidad

·       Mayor innovación

·       Costos más bajos

·       Mayor rentabilidad

·       Mejor ambiente de trabajo

·       Cambio de comportamientos hacia una cultura de colaboración y de innovación

·       Mejor experiencia del cliente

·       Mayor reputación de marca

Y un largo etcétera exponencial.

Hasta allí bien. ¿Y cómo lo hacemos?

Entra Scrumming the Scrum

Una de las múltiples formas de lograrlo, muy práctica por demás, es usar el patrón Scrumming the Scrum. Algo así como “aplícale Scrum a tu Scrum”, en el sentido de “mejora tu Scrum”. Si te ocurre lo que mencioné antes de “no tengo tiempo para mejorar” o de “no trabajamos en las acciones de mejora definidas en la anterior retrospectiva”, entonces este puede ser un buen comienzo.

Es simple: usa Scrum como una mejora del proceso. Es decir, aprovecha Scrum para cumplir o lograr tu visión de kaizen. Para ello necesitas tener retrospectivas efectivas. Como siempre, lo mejor de las retrospectivas ocurre una vez que estas finalizan, cuando empiezas a implementar las acciones que definiste con tu equipo para mejorar.

En la práctica te vas a enfrentar a situaciones como:

·       Bajo desempeño del equipo,

·       incapacidad de detectar y eliminar impedimentos,

·       poca o ninguna generación de Valor,

·       multitarea.

·       Estrés ocasionado por todo lo anterior. Y esto último es el inicio de una serie de eventos desafortunados que conducen a la mala calidad y, peor aún, a la desmotivación y al detrimento de la salud y de la energía de las personas del equipo.

Créeme, no quieres que nada de esto ocurra a tu alrededor. He estado allí, no se lo recomiendo a nadie.

1.    Empieza por realizar un análisis de cómo te fue a ti y a tu equipo en el último sprint en cuanto a personas y sus interacciones, procesos, herramientas y Definición de Terminado, entre otros aspectos. Esto es clásico en toda retrospectiva efectiva.

Siempre viene bien un análisis de causa raíz. Los cinco porqués son un buen instrumento para lograrlo. Pero también está el diagrama de espina de pescado de causa y efecto, también conocido como diagrama de Ishikawa. El método de las 5W + 2H también viene bien en estos casos. Incluso un diagrama de Árbol de causa – efecto, o la técnica de Pareto, en el que el 80 % del problema proviene del 20 % de las causas y El 80 % de las causas restantes solo afectó al 20 % del problema.

2.    Una vez establecida la causa raíz, usa algún tipo de técnica colaborativa para idear soluciones: tormenta de ideas y votación simple, voto de confianza, conversaciones poderosas o estructuras liberadoras, entre algunas otras. El objetivo es que, de una lista de acciones, iniciativas o experimentos, selecciones con tu equipo las que vayan mejor para la ocasión. Una matriz de Esfuerzo versus Impacto siempre viene bien en estos casos.

Advertencia: esto de encontrar la causa raíz y seleccionar la de máxima prioridad se convierte en un imperativo, es algo exigente, no subvalores la forma cómo lo haces. Si trabajas bien en esto y luego implementas la acción de mejora subyacente, verás un incremento inmediato en la productividad del equipo. Al contrario, si esto último no sucede, es que tú y tu equipo no están haciendo una exploración apropiada de lo que está sucediendo, no están usando una visión holística y por ello siguen sin entender ni encontrar la verdadera causa raíz del problema. Las cosas así, hazte acompañar de alguien con experiencia. 

3.    Selecciona una y sola una de las acciones de mejora de la lista anterior. De hecho, “un paso a la vez” es ya una acción de mejora en sí. Como dicen por allí, “el que mucho abarca, poco aprieta”. Puedes promover la práctica de iniciar con una de las acciones que requieren menor esfuerzo y que sean de alto impacto o valor para el equipo y la organización.

Advertencia: a estas alturas siempre estamos hacia el final de la retrospectiva, entonces tienden a presentarse algunas disfunciones como que dedicamos muy poco tiempo a pensar en cuál debería ser esa acción y tratamos de salir rápido con una votación simple sin mayor análisis del impacto que pueda tener. Si eres facilitador de equipos, Scrum Master, coach o mentor, trata de no promover estas “salidas” por la vía rápida.

Recomendación: considera representar o escribir la acción de mejora como una historia de usuario, sobre todo, con criterios de aceptación o con una lista de comportamientos o aspectos visibles una vez que la acción esté implementada o se haya adoptado por el grupo. He usado la técnica de hypothesis-driven development para escribir “historias de usuario kaizen” con muy buen resultado.

Por ejemplo, si uno de los problemas tuvo como causa raíz la falta de conocimiento y experiencia en el uso de historias de usuario como protocolo de comunicación dentro del equipo y con los usuarios o interesados, la historia de usuario de la imagen anterior nos ayuda con una hipótesis de valor: si asistimos a un curso de historias de usuario, obtendremos un resultado de valor; sabremos que la hipótesis es cierta cuando veamos la señal (medible) expuesta luego de la misma.

4.    En la siguiente Sprint Planning, haz visible esta acción Kaizen en el Sprint Backlog. Con el equipo, sitúa las actividades derivadas de la acción de mejora al inicio de la lista o en la cima de la pila de tareas.

Como siempre, ninguna de las tareas es la tarea de una persona, el sprint backlog es propiedad del equipo en pleno y las tareas kaizen no son la excepción.

5.    Como siempre, aunque quizás estas tareas kaizen no están orientadas hacia el logro del objetivo del sprint, merecen un apartado especial en la Daily Scrum. Así, el equipo completo revisa también cómo van hacia esa meta especial.

6.    Finalmente, junto al incremento de valor que inspeccionas en la Sprint Review, presenta los resultados sobre esta acción de mejora. A los invitados a la sesión seguramente les interesará saber que el equipo está mejorando gradualmente, paso a paso.

7.    Cualquiera que fuere el resultado de la implementación o adopción de la acción kaizen, analízalo en la siguiente retrospectiva. Lo ideal es que haya habido, al menos, un avance importante hacia la ejecución completa de la acción. Si no es así, considera revisar las prioridades del equipo y vuelve a empezar.

Para concluir

Es un hecho: vivimos en una era de cambios. Si tú y tu organización se encasillan en lo que saben y en lo que siempre les ha funcionado, muy pronto se quedarán atrás. Adoptar una mentalidad de mejora continua hará que tu equipo y tu empresa giren hacia una trayectoria diferente y más exitosa.

Para saber más de patrones

Para conocer más de patrones Scrum, puedes ver esta presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

En particular, para saber más del patrón Scrumming the Scrum, puedes mirar esta otra presentación:

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.

Un instrumento para ayudarte a mejorar como Scrum Master

 

Un Scrum Master adecuado puede manejar dos o tres equipos a la vez. Si está contento con limitar su función a la organización de reuniones, el cumplimiento de los plazos y la respuesta a los impedimentos que las personas informan explícitamente puede arreglárselas con la atención de medio tiempo a esta función. Es probable que el equipo aún supere la línea de base, las expectativas previas a Scrum en su organización y probablemente no sucederá nada catastrófico.

Pero si puedes imaginarte un equipo que se lo pasa en grande logrando algo que nadie antes creía posible, dentro de una organización transformada, considera ser un Scrum Master extraordinario.

Un Scrum Master Extraordinario puede liderar un equipo a la vez.

Recomendamos un Scrum Master dedicado por equipo de aproximadamente ocho personas o menos al comenzar.

Si no has descubierto todo el trabajo que hay que hacer, sintonízate con tu Product Owner, tu equipo, las prácticas de ingeniería de tu equipo y la organización en el entorno de tu equipo. Si bien no existe una receta única para todos, esta lista describe cosas típicas que muchos Scrum Masters pasan por alto, sobre todo quienes apenas están iniciando a caminar por el sendero de la agilidad.

Esta lista de chequeo es una adaptación, más que una simple traducción, del trabajo de Michael James (mj4scrum@gmail.com). He incluido algunos aspectos que me parecieron relevantes a la luz de los últimos cambios en la guía de Scrum y de mi propia experiencia usando la lista.

Para usar el instrumento

Diligencia la lista de chequeo, puedes seguir algunas de las recomendaciones en la página de Documentación de la herramienta. Luego haz clic en el botón “Todo preparado. Muéstrame las gráficas” que encontrarás en la parte superior derecha de la hoja de “Datos de Entrada”.

Como con otros instrumentos de este tipo, para usar la lista de chequeo correctamente, diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y tendrás la oportunidad de debatirlas en equipo. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo puede ser el comienzo de un plan de mejoramiento! Eso sí, no pienses en juzgar tu desempeño como Scrum Master basado solo en esta lista de chequeo. Recuerda que lo importante es generar Valor, entregar lo que el negocio necesita más y mejorar el proceso continuamente.

Para limpiar los datos y volver a llenar la lista, simplemente haz clic en el botón “Limpiar Datos”.

Usa la herramienta y déjame saber en el foro de tus experiencias y de cómo podemos mejorarla.

Puedes descargar el instrumento aquí. 👇

Daily Scrum Kaizen

Advertencia: que ya no sea un lineamiento de la guía de Scrum, no quiere decir que no podamos seguir usando las “tres preguntas”.

Muchas veces, la respuesta o solución a cómo mejorar la realización o ejecución de un evento Scrum está fuera del evento: por ejemplo, para mejorar la Planning, tenemos que mejorar el refinamiento; para mejorar la Review, tenemos que mejorar la Daily Scrum; para mejorar la Retrospective, tenemos que mejorar la Planning del Sprint siguiente. Siempre he creído que lo mejor de la retrospectiva ocurre cuando esta termina y es la implementación de las acciones de mejora seleccionadas.

Y para mejorar la Daily Scrum mejoremos también la Sprint Planning.

Al definir un Objetivo del Sprint claro, específico, medible, alcanzable y significativo y, por supuesto, circunscrito al Sprint que comienza. Pero definir o establecer el Objetivo del Sprint no es suficiente. ¿Cómo lo vamos a alcanzar? ¿Qué artefacto vamos a usar para verificar que lo logramos? ¿Cuál técnica de validación? ¿Con qué personas lo vamos a hacer? Son algunas otras preguntas que tenemos que poner sobre la mesa y encontrar sus respectivas respuestas.

Recordemos que en la Daily Scrum se inspecciona el progreso hacia el Objetivo del Sprint, entonces se hace necesario dejar de girar el evento en torno a cuáles tareas o actividades hemos realizado o dejado de hacer y enfocarnos más en cómo medir ese avance hacía el objetivo formulado. Además, el Objetivo del Sprint debe tener un vínculo muy íntimo con los elementos del Product Backlog que se van a desarrollar (alias “las historias de usuario”).

Las cosas así, por ejemplo, durante la reunión diaria, responder a la cuestión:

¿Está Terminada la historia de usuario actualmente en desarrollo?

Puede mejorar el rendimiento del equipo y su progresión hacía el Objetivo de la iteración. Incluso podemos complementar esa respuesta con la de esta otra pregunta:

¿Es posible que más personas participen en el desarrollo de esa historia? Sí, ¡pues manos a la obra! Es un poco de Swarming o Enjambre. En desarrollo de software, es posible; pero también lo es en otras actividades.

Otro giro que le podemos dar a la conversación en la Daily Scrum es acercarnos más a los criterios de aceptación de las historias de usuario en desarrollo. Estos criterios también son o deben precisos y medibles, pero más que nada, deben centrarse en el resultado, en el valor a entregar, y deben ser colaborativos, es decir, que inviten a la colaboración de todo el equipo y los interesados.

De esta manera, responder a cuestiones como:

¿Cuál es el estado de los criterios de aceptación de cada historia de usuario en desarrollo?

Es una forma de saber si nos estamos acercando a la meta de Sprint definida. Si el criterio de aceptación aun no ha sido abordado, estamos algo lejos. Si está en desarrollo, ya es un pequeño paso hacia la consecución de los resultados que queremos. Si finalmente está implementado o cumplido, entonces hemos dado un gran paso con miras al logro de ese propósito de la iteración.

Otra alternativa a las tres preguntas es simplemente hablar de “cómo vamos como equipo”, como personas.

¿Cuál es nuestro estado de ánimo? ¿Nuestro nivel de energía?

¡O simplemente aprovechemos esos quince minutos para tomarnos un café! Así sea virtual. Mientras escribo este artículo, seguimos en cuarentena por el virus, catorce meses después. Si estamos haciendo un “buen Scrum”, seguramente justo antes o justo después de la reunión, actualizaremos los radiadores de información a que haya lugar y cada miembro del equipo tendrá la oportunidad de coordinarse o sincronizarse con los demás a medida que avanza la mañana.

En la práctica, no es necesario responder a nada más.

¿Y los impedimentos, riesgos o problemas? Cambiemos un poco la postura sobre este asunto y reorientémonos precisamente hacia el trabajo colaborativo. A los miembros del equipo les podemos enseñar a “levantar la mano” cuando de problemas se trata en el momento en que estos ocurren, ¿por qué esperar a la cita diaria para mencionarlos? Es posible que falten muchas horas hasta la siguiente Daily Scrum y esto puede traer como resultado una baja en la productividad de algunas personas del equipo y, a su vez, que no se pueda conquistar la Meta pretendida.

Como ven, podemos seguir usando las tres preguntas, pero también podemos usar muchas otras tácticas y estrategias para mejorar no solo la Daily Scrum, sino cualquiera de los demás eventos. ¿Y tú, qué técnicas estás usando para mejorar tus reuniones diarias? Por favor, déjamelo saber en el foro.

Sobre multifuncionalidad y la creación de un incremento de producto

Image by Alexandr Ivanov from Pixabay 

Sobre multifuncionalidad y la creación de un incremento de producto

O de las minicascadas en el Sprint y de cómo deshacernos de ellas

“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee

De dónde venimos

Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?

Estos escenarios son mucho más comunes de lo que creemos. Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando con prácticas tradicionales de gestión en las últimas décadas y cuya área de Tecnología cuenta con proveedores externos: unos para desarrollar el software y otros para realizar las pruebas de este. Y tanto las personas de un proveedor como del otro no se hablan sino a través de procesos y herramientas, como un bug tracker o actas formales de entrega y recepción de partes del producto.

Es muy probable que en esos equipos prime la alta especialización: el así llamado desarrollador de front-end, el analista de requisitos, el desarrollador de back-end, el arquitecto del software, de un lado. El analista de pruebas funcionales, el de pruebas no funcionales, el automatizador de pruebas, lo que sería un gran avance, del otro lado. Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus propios roles y responsabilidades dentro de todo este intrincado ecosistema de trabajo.

Imaginemos ese escenario: aquí los unos y los otros son de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores actuales y decide invitarlos a embarcarse en un viaje que los llevará por los caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas, nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando, “metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!

Para dónde vamos

Image by Merhan Saeed from Pixabay 

Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.

Es algo para tener en cuenta cuando se hace refinamiento o, simplemente, cuando se dividen elementos del product backlog en piezas más pequeñas. Eso es necesario porque el trabajo en el sprint será una minicascada: si se trata de desarrollo de software, por ejemplo, primero se realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas breves fases, haya etapas más pequeñas que se lleven a cabo de manera secuencial.

Las cosas así, no será posible cumplir la promesa de tener elementos del product backlog (alias las historias de usuario) terminados durante los primeros días del sprint. Esto, como sabemos, sube la presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados por el Product Owner. Es un hecho: llegar a la mitad del sprint o más allá, independientemente de su duración, sin que ninguna historia de usuario alcance la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en una baja de energía en el equipo.

Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

·       Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.

·       Un refinamiento que “mire” dos o, mejor, tres Sprints hacia adelante.

·       Manejo de expectativas con los usuarios e interesados, vía la Product Owner o el Scrum Master o alguna otra persona del equipo o muy cercana a este.

·       Ordenamiento por valor del product backlog, más que hacer priorización. Es decir, ordenar uno a uno, por valor e impacto para el negocio, para los usuarios o clientes, cada historia de usuario. Muchas veces la priorización se hace por grupos de elementos. El ordenamiento se hace de manera individual. Esto asegura que en cada sprint se entregue Valor, aunque este sea en pocas cantidades.

·       Foco en una historia a la vez y concentrarse en su finalización.

·       Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.

Pero lo más importante y crítico es poner en marcha un plan de desarrollo de competencias que faculte a las personas para adquirir habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo, requiere de una inversión considerable, pero es lo que va a permitir hacer las cosas de una manera diferente de una vez por todas y para siempre. Un plan que incluya:

·       Adquisición de nuevas prácticas y, si es necesario, de nuevas herramientas.

·       Trabajo en pares.

·       Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

Los beneficios de desarrollar este plan no girarán solo en torno al aumento de la productividad del equipo, sino también a la entrega de mayor valor en cada iteración, al incremento de la calidad, a la mayor satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán a energizar al equipo, a su bienestar, a menos estrés y a más motivación.

¿Qué te parecen estas ideas? Por favor, cuéntamelo en el foro.

---

*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay