Aprende Scrum con Lucho Salazar

Scrum es un marco de trabajo liviano e iterativo que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente.

En esta clase en línea aprenderás un poco más sobre el marco de trabajo Scrum para poder aplicarlo mejor en tu entorno de trabajo.

Si quieres saber más sobre Scrum, con mi gran amigo y coautor Jorge Abad estamos pensando en facilitar un nuevo curso de Scrum a finales de octubre o principios de noviembre en Medellín (presencial) y queremos saber si hay interesados. Si te llama la atención, por favor, diligencia este breve formulario para enviarte información.

Lean Business Agility Model

 

El Lean Business Agility Model o LBAM es un modelo simplificado que reúne en una única perspectiva la agilidad a nivel estratégico, táctico y operativo; también, la agilidad en los equipos transversales y de soporte; la Mentalidad Lean-Agil, el Liderazgo Transformacional y de Crecimiento soportando todas las funciones y áreas de la organización; y toda la organización con un foco en el cliente, como la mayor obsesión de todos en la organización.

Además, el modelo tiene en cuenta y se fundamenta desde su raíz en lo que se conoce como el triple impacto: financiero, ambiental y social. Esta tríada se debe convertir en el cuadrante dominante de las organizaciones que tienen o están pensando tener o proponer acciones basadas en en el enfoque ágil y lean.

Es imperativo: para construir, orquestar y participar en ecosistemas organizacionales con propósito, las empresas necesitarán recodificarse genéticamente para infundir agilidad y adaptabilidad en su ADN. Una organización que base su desarrollo en el triple impacto tiene que ser robusta pero ágil y adaptable, modular pero estrechamente unida. Al pensar en el beneficio social y en el ambiental, además del rendimiento financiero, no solo será capaz de detectar y responder a tiempo y con clase a las necesidades del cliente, sino que también desarrollará habilidades y destrezas para construir y orquestar con voluntad e inspiración todo su ecosistema organizacional. La evolución, transformación y adaptación de las empresas que usen el Lean Business Agility Model será implacable y estas organizaciones autocontendrán las competencias suficientes y necesarias para ayudar a otras a pasar a un modelo de crecimiento sostenible.

En particular, Una buena Business Agility debe llevar a la organización a mantener los recursos disponibles para lograr el éxito financiero, generar ingresos y crear valor económico para todos los interesados. De esto se trata el impacto financiero.

Mientras tanto, el impacto ambiental busca, entre otras cosas, que Las métricas y OKR que uses deben considerar el medio ambiente. Mide el impacto que una organización tiene en el medio ambiente a través de factores como la huella de carbono, la contaminación del aire y del agua, la producción y el reciclaje de desechos, la fuente responsable de materiales, la conservación de la biodiversidad, etcétera.

Y más allá del ROI habitual, busca el ROI Social, el impacto social. Decimos que la agilidad es sobre personas, pero ¿nos estamos teniendo en cuenta realmente? El foco principal de las organizaciones que usan el LBAM son las personas con las que interactúan directa o indirectamente, , incluidos sus propios empleados, clientes, proveedores y otros interesados en la comunidad local y el entorno regional e internacional en general.

Orígenes del Lean Business Agility Model

Este modelo es fruto de un trabajo de muchos años acompañando equipos y organizaciones en su trasegar hacia la agilidad y la agilidad empresarial. Está basado fuertemente en:

·       El pensamiento Lean

·       Los valores y principios ágiles

·       El Corazón de la Agilidad

·       Agilidad Moderna

·       Las tres leyes de ágil*

·       Y la experiencia de sus autores.

Las tres leyes de la agilidad

Estas son las tres leyes de la agilidad de Steve Denning que sirven como uno las bases del modelo:

·       La ley del Cliente: una obsesión con la entrega de valor a los clientes como el todo y el fin de toda la organización;

·  La ley del Equipo Pequeño: la presunción de que todo el trabajo debe ser realizado por pequeños equipos autoorganizados, que trabajan en ciclos cortos y se centran en brindar valor a los clientes; y

·   La ley de la Red: un esfuerzo continuo para eliminar la burocracia y la jerarquía de arriba hacia abajo para que la empresa funcione como una red interactiva de equipos, todos enfocados en trabajar juntos para entregar un valor creciente a los clientes.

En general, el modelo:

·       Es una propuesta, de muchas que existen

·       No es la solución ni la respuesta a todo

·       Empieza con unos principios esenciales

·       Promueve la mejora continua

·       Hemos observado que sirve en cualquier empresa

·       Complementa otros modelos y puede ser complementado por otros modelos e instrumentos

·       No es un marco de trabajo (framework)

·       Es y trataremos de mantenerlo liviano y simple

·       Está compuesto de patrones y abstracciones de la realidad

·       ¡Es nuestro! Es latino. Tiene nuestra idiosincrasia.

Principios del LBAM

El modelo se fundamenta principalmente en unos principios que seguimos y que constituyen la columna vertebral del mismo. Tratamos de no contribuir a la sobredecoración de la agilidad y creemos firmemente que estos principios mantienen simple y limpio el modelo, a la vez que habilitan a quienes lo usen para dar el primer paso en las organizaciones que buscan una mejor business agility.

Estos son los principios:

·       Buscamos siempre generar valor para los clientes y atrapar valor para la organización.

·       Nos ocupamos de:

o   la sostenibilidad organizacional (incluye lo financiero y lo cultural),

o   la sostenibilidad Ambiental, y

o   la sostenibilidad social.

·       Seguimos los principios Lean y Ágil (colaboración, entrega de valor, reflexión, mejora continua, flujo, eliminación de desperdicios).

·       Creemos que la base de una buena Business Agility son los equipos lean-agile, pequeños, multidisciplinarios y autogestionados.

·       Promovemos estructuras cada vez más planas pues hemos aprendido que mejoran la agilidad, aunque creemos que el reto más importante no es la estructura, sino la colaboración. Maximizar la generación de valor a través de la adecuada colaboración es la clave.

·       Todos los equipos y áreas tienen foco en el cliente externo e interno.

·       Todos los líderes ejemplificamos la mentalidad Lean - Ágil y sabemos cómo usarla en su contexto.

·       Los líderes promovemos una mentalidad de crecimiento, un liderazgo transformacional y una cultura de innovación.

·       La agilidad es la misma y buscamos constantemente formas adecuadas para aplicarla en nuestra área, equipo, función o flujo de generación de valor.

·       Creemos en la mejora continua sobre la mejora discontinua. Buscamos cómo mejorar al menos una vez al mes la Agilidad Estratégica, Táctica y operativa, de equipos transversales y soporte; equipos y áreas de trabajo. Y conjuntamente nos reunimos como organización a mejorar al menos una vez trimestralmente.

·       Pocas métricas significativas, que midan lo que importa, compartidas por todos, son la mejor estrategia de alineación.

·       El uso y exploración frecuente de tecnologías que mejoren la entrega de valor, la cultura de la innovación y experimentación son esenciales para responder, e incluso liderar el cambio.

- Jorge Abad y Lucho Salazar -

---

Para continuar en contacto con el modelo y sus autores, puedes compartirnos tus datos y comentarios en:

https://bit.ly/LBAM-feedback

Para ver la presentación del modelo:

Usamos un tablero Mural para elaborar la presentación. Puedes ver y descargar el PDF resultante aquí:

El costo de hacer multitarea

El costo de hacer multitarea

La gráfica es perentoria. Si estás en dos proyectos o iniciativas puedes perder hasta el 20 % solo por cambio de contexto o cambio (“switcheo”) entre tareas.

Si estás en 3 iniciativas, hasta el 40 %. Es decir, en realidad no estás asignado al 33 % en cada una, sino al 20 %.

De allí, los retrasos en las entregas. Y la mala calidad. Ni hablar de cuando estás en cuatro o cinco proyectos o iniciativas, algo que sigue siendo común en muchas empresas.

Algunos estudios además dicen que si las tareas con complejas, por ejemplo, tareas de desarrollo de software o, en general, trabajo de conocimiento, este tiempo puede ser mayor. Nos movemos en el universo de lo complejo, donde no hay relación directa entre la causa y la consecuencia y solo podemos saber cómo nos fue en retrospectiva.

El verdadero costo de la multitarea

Pero esto es lo que las organizaciones apenas alcanzar a ver, al menos, quienes están cambiando a enfoques ágiles para trabajar.

Sin embargo, el costo más grave, el verdadero costo de no tener foco en lo que se hace, es la salud de las personas. Y de eso casi nunca hay recuperación.

Investigaciones [1] muestran que “la multitarea te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento”.

[*] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

Una investigación realizada en la Universidad de Stanford descubrió que la multitarea es menos productiva que hacer una sola cosa a la vez. Los investigadores también encontraron que las personas que son bombardeadas regularmente con varios flujos de información electrónica no pueden prestar atención, recordar información o cambiar de un trabajo a otro tan bien como aquellos que completan una tarea a la vez. [2]

Pero lo más crítico que mostró esta investigación es que, además de ralentizarte, la multitarea reduce tu coeficiente intelectual. Un estudio de la Universidad de Londres descubrió que los participantes que realizaban varias tareas a la vez durante tareas cognitivas experimentaron disminuciones en la puntuación de coeficiente intelectual similares a las que esperarían si hubieran fumado marihuana o se hubieran quedado despiertos toda la noche. Las caídas del coeficiente intelectual de 15 puntos para los hombres multitarea redujeron sus puntajes al rango promedio de un niño de 8 años. [2]

Incluso se presenta daño cerebral si haces multitarea. Un estudio de la Universidad de Sussex en el Reino Unido encontró que quienes realizan muchas tareas a la vez tenían menos densidad cerebral en la corteza cingulada anterior, una región responsable de la empatía, así como del control cognitivo y emocional.

Y hay más. La neurociencia es clara: estamos programados para ser monotarea. Un estudio encontró que solo el 2.5 % de las personas pueden realizar múltiples tareas de manera efectiva. Y cuando el resto de nosotros intentamos hacer dos actividades complejas simultáneamente, es simplemente una ilusión. [3]

Conclusión

Muchas veces te dicen que eres bueno y que por eso te van a dar más responsabilidad. Otras veces tú mismo lo asumes porque crees que es lo mejor. Pero no. Incluso hacer multitarea con cosas “sencillas” como hacer algo en el trabajo y estar mirando el celular y además hablando con el compañero de al lado en la oficina, puede ser muy dañino para tu salud, en ocasiones, de forma irreversible.

Así es que la próxima vez que estés ante la disyuntiva de estar en dos o más iniciativas a la vez, piénsalo. Y a quienes tienen la responsabilidad de formar y liderar equipos, también tengan en cuenta esta reflexión. El verdadero costo de la multitarea no es la pérdida de productividad, a veces invisible; es una baja substancial en la salud mental y física de las personas multifoco, una disminución que en muchas ocasiones es irrecuperable.

Referencias

[1] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

[2] Multitasking Damages Your Brain And Career, New Studies Suggest.

https://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/?sh=6cbca3956ee6

[3] Why Multitasking Is Bad for You.

https://time.com/4737286/multitasking-mental-health-stress-texting-depression/

 

Á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

 

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.

Nuestro Scrum empírico de todos los días

Imagen tomada de Pixabay

“El verdadero método de conocimiento es el experimento”.

-          [William Blake. Poeta, pintor y grabador inglés.]

Muchos dicen usar Scrum, dicen usarlo bien. Según los “lineamientos” ágiles, los he escuchado decir. Pero he aquí una observación: la gran mayoría quizás ni lo están haciendo, a pesar de los eventos, las responsabilidades y los artefactos. En general a casi todos les hace falta lo que llamo “el espíritu de Scrum”. Ese que tiene que ver con la teoría del marco de trabajo, con sus pilares y con sus valores.

Me concentraré específicamente en la teoría. En esa que nos dice que Scrum se basa en el empirismo y en el pensamiento Lean. De hecho, mi foco será esto del empirismo. Para empezar, es bueno reconocer que un entorno empírico es aquel en el que la mejora y la dirección están guiadas por los experimentos y la experiencia.

Esta última se basa en lo que ya ha ocurrido, en el pasado. Muchos siguen usando Scrum tratando de predecir lo que va a pasar en el futuro, a veces incluso, en un futuro distante. Nada más alejado de las prácticas erróneas. Mi primera recomendación: usa la experiencia para experimentar con la planificación en el muy corto plazo, la planificación de un sprint; es más, con la planificación de un día de trabajo.

Para hacerlo, haz que tu equipo planifique teniendo en cuenta lo que pasó en el último sprint. Quizás en los tres últimos. Tampoco te vayas tan atrás. Seguramente hay cosas que han cambiado en el entorno. No es lo mismo si hace unas semanas tu equipo estaba disperso por el mundo y apenas si lograbas identificar un icono en una pantalla de alguna de las herramientas favoritas de comunicación, a si en este momento están trabajando con un modelo “híbrido” o presencial del todo. Mientras escribo esto, algunas empresas ya lo están intentando.

Promueve un entorno donde todos en el equipo y los interesados clave, además de los usuarios, esperen lo inesperado. Es lo que sucede cuando trabajas bajo el manto de la incertidumbre y la volatilidad inherentes a los escenarios que enfrentas habitualmente, sin hablar de la complejidad propia del ADN de las iniciativas con las que convives a diario. Es en estos escenarios donde un proceso empírico tiene vigor.

La realidad del Scrum que haces

Photo by Yan Krukov from Pexels

Todo el tiempo escuchas decir:

La mejor duración de sprint es de dos semanas. Pero ¿has experimentado con otra duración? ¿Una mejor, por ejemplo?

En nuestras Daily Scrum seguimos usando las “tres preguntas”. Nos parecen muy buenas. Sí, pero ¿has experimentado con otro tipo de conversaciones?

Nuestra definición de terminado es muy completa. Pero ¿la has mejorado con el tiempo?

En cada sprint implementamos entre 4 y 8 historias de usuario. Pero ¿has experimentado con otros rangos?

Nos funciona bien un equipo de 8 personas. Pero ¿has ensayado con otro tamaño de equipo?

Te haré otras preguntas:

¿Has dejado de usar la velocidad como medida de capacidad para el equipo?

¿Sigues usando puntos de historia para estimar las historias de usuario?

¿Has intentado con tu Product Owner alguna técnica distinta a MoSCoW para ordenar el Product Backlog? ¿Has usado MoSCoW?

¿En realidad todos en el equipo y en el entorno, es decir, interesados clave, patrocinadores y usuarios, entre otros, comparten no solo la misma información sobre lo que está sucediendo, sino el mismo significado de las cosas?

¿Has experimentado o has promovido cambios en la forma como hacen la planificación del sprint, el refinamiento, la revisión o la misma retrospectiva? Sobre esta última, ¿te limitas a los “pasos” generados por Retromat, Fun retrospectives o el muy buen libro sobre el tema de mi gran amigo Jorge Abad, pero nunca has intentado crear tu propia retrospectiva, más adecuada a las necesidades de tu equipo en un momento dado?

Finalmente, ¿te basas y promueves que el equipo y la organización se basen en lo que ya ha sucedido, datos cuantitativos, sobre todo, para tomar decisiones sobre qué hacer y cómo hacerlo en el futuro inmediato?

Algo del Scrum que deberías estar haciendo

Photo by fauxels from Pexels

¿Y por qué todo este cuestionamiento?

Bueno, precisamente porque Scrum es útil en un entorno donde la experimentación debe(ría) estar a la orden del día. Como dije al principio, a eso se refieren Schwaber y Sutherland cuando dicen que Scrum se basa, además del pensamiento Lean, en el empirismo. Este último “afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado”.

Por ejemplo, no te desgastes mucho, ni entretengas a tu equipo haciendo estimaciones, aunque sean “ágiles”, en el primer sprint. Simplemente empieza. Al final del primer sprint tendrás un dato verificable de cuánto hizo el equipo. De inmediato, en el segundo sprint, toma la decisión de que la velocidad del equipo sea justamente el número de puntos que acaban de lograr en el sprint anterior. De hecho, esto es un patrón Scrum conocido como El clima de ayer.

Ahora bien, los experimentos no tienen que proponer cambios sustanciales a lo que se está haciendo. Puedes usar mejoramiento continuo de un paso a la vez, crea una expectativa de experimentación y mejora bastante baja, de tal forma que para nadie sea una carga impositiva sino más bien un camino a transitar, desafiante pero divertido. Eso sí, primero enséñales a todos a mejorar, a proponer esos experimentos que tanto quieres.

Por ejemplo, enséñales a prepararse para una Daily Scrum.

Puedo contar por centenares las reuniones diarias a las que he asistido con personas que van muy mal preparadas a la misma. Todo el tiempo están titubeando, desenfocados, desmotivados y mirando el reloj a que simplemente terminen los infames 15 minutos de la reunión porque saben que eso sí lo van a respetar. Una de las principales razones que he encontrado para que esto suceda es que es una sesión subvalorada, a la que le dan poca o ninguna importancia, porque no terminan de entender qué significa la inspección y adaptación como pilares esenciales de un entorno empírico.

Lo he resuelto con entrenamiento, preparación y acompañamiento. Además de crear todo un movimiento cultural alrededor del evento:

1.    Al principio del sprint fijas una táctica o técnica para llevar a cabo la reunión.

2.    Les enseñas a todos en el equipo cómo será, haces una simulación. Llevas a cabo conversaciones de mejora para que cada uno llegue a conocer muy bien los detalles.

3.    Antes de las primeras sesiones, te aseguras de que todos efectivamente estén preparados. Indagas si necesitan ayuda para estarlo. Les proporcionas la ayuda que necesitan.

4.    Durante el evento estás atento a cómo lo llevan a cabo para, a continuación de este, mantener otras conversaciones de mejora y perfeccionar en consecuencia.

5.    Indaga cómo se sienten, qué les hace falta, qué quieren proponer.

6.    Precisamente sobre este último asunto, lo más importante es, enséñales a mejorar ese paso a la vez. Por ejemplo, enséñales con ejemplos claros a que cada vez digan más con menos palabras. Pero sin atribularlos.

Por sobre todas las cosas, siempre ten en cuenta lo que sucedió los días anteriores. Y haz que ellos en el equipo también lo tengan presente. No puedes encontrar nada de eso que sucedió en un cuerpo de conocimiento, mucho menos en la guía de Scrum. De hecho, Scrum se basa en la inteligencia colectiva de las personas que lo usan. Y es precisamente esa diversidad de perspectivas, una de las formas cómo enfrentamos la complejidad que nos rodea, lo que posibilita que encontremos soluciones más acertadas o apropiadas a los problemas que nos desafían cotidianamente.

Quieres saber más

Para saber más del Scrum que deberías estar haciendo, te invito a mi próximo curso para Scrum Masters. Encuentras toda la información de este en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

Mientras tanto:

Para saber más de cómo mejorar la Daily Scrum:

http://www.gazafatonarioit.com/2022/01/como-ayudar-tu-equipo-mejorar-su-daily.html

https://luchosalazar.com/2021/04/23/daily-scrum-kaizen/

Para saber más sobre el clima de ayer y otros patrones Scrum:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/