El último día del sprint

Imagen tomada de Pixabay

"Comenzar fuerte es bueno. Terminar fuerte es épico". [Robin Sharma]

Desde siempre he visto como los equipos de desarrollo de producto, especialmente los de desarrollo de software, emprenden los más titánicos proyectos con unas ganas inconmensurables, una fuerza interior, personal y grupal, que parece infinita y una pasión energizante que enciende los motores de la creación, el trabajo en equipo y los deseos de triunfar.

Nada muy distinto a lo que ocurre hoy en cada iteración de cualquier iniciativa o esfuerzo de desarrollo: el primer día los equipos planifican su propósito de vida para las siguientes jornadas y hasta son capaces de hacer un pronóstico de cómo alcanzarán la meta del sprint que comienza. Y diariamente acuden a la cita de la colaboración y la creación de valor con la mejor sonrisa y disposición.

O así es… ¡hasta que se acerca el fin de la iteración!

Un sprint es un bloque de tiempo breve en el que hay que mantener el foco y el esfuerzo regulado para terminarlo como lo empezamos. Con brío y pundonor. Pero eso no está ocurriendo con muchos equipos. En mis continuos ejercicios de acompañamiento y consultoría me sigo encontrando las historias de nunca acabar:

• Es que no hicimos retrospectiva para terminar las historias de usuario
• Programadores escribiendo programas minutos antes de la revisión con los interesados. ¿Y las pruebas?
• Vamos a aplazar la revisión. Mañana hacemos la planificación del próximo sprint, luego la retrospectiva. Pasado mañana hacemos la revisión de este sprint que termina.
• Solicitemos un aplazamiento del paso a producción para el próximo sprint.
• Pidamos una extensión del sprint. Necesitamos dos o tres días más para terminar lo prometido.
• Y la lista continúa.

Entre otras cosas, es a lo que se refieren Jeff y Ken cuando dicen que Scrum es “difícil de llegar a dominar”. Pero no se trata solo de Scrum. Es esa falta de disciplina que tenemos para hacer que las cosas terminen, ese apego a lo que es y no queremos dejar ir, inherente a todo ser humano. Es esa facilidad para conjugar el verbo empezar pero a la vez esa dificultad para conjugar la voz finalizar.

El último día del Sprint comienza el primer día del Sprint

Imagen tomada de Pixabay

Hagamos un plan hasta el penúltimo día del sprint, sea cual fuere su duración. Sí, con historias de usuario más pequeñas es posible. Y sí, todavía pueden ser entre 6 y 10 historias de usuario.

Recordemos en la planificación que la revisión y la retrospectiva requieren de preparación. No es algo que ocurre solo porque llegó la hora de hacerse o porque el marco de trabajo lo exige. Nunca veo esas tareas de preparación en el backlog del sprint. Y no, no son historias de usuario. Son actividades que bien pueden realizar el Scrum Master, pero también el Dueño de Producto o cualquier otro miembro del equipo, aunque preferiblemente uno de los dos primeros.

En cada reunión diaria, examinemos efectivamente cómo vamos hacia el cumplimiento de la meta del sprint y qué estamos haciendo específicamente para preparar esa gran fiesta que es la revisión del incremento con los interesados, no solo con el Dueño de Producto. Y, ni más faltaba, vayamos pensando qué clase de retrospectiva queremos hacer. Y sí, quince minutos es suficiente para ello. Durante la preparación de estos eventos finales también surgen impedimentos que hay que resolver con prontitud.

Recordemos, si no aseguramos la calidad del producto, no está terminado. Siempre pongamos de manifiesto que solo revisaremos lo que verdaderamente está terminado. Y no, casi terminado no es terminado.

El Scrum Master bien puede crear una campaña de expectativa hacia el exterior del equipo, dirigida a los interesados, sobre la próxima revisión, el siguiente gran hito. Y también hacia el interior del equipo: la siguiente gran oportunidad de inspección y adaptación, la retrospectiva. Sin que esto quiera decir que los demás eventos no son oportunidades de evaluación y ajuste, en el sentido de mejora continua.

Promovamos el descanso placentero y el sueño profundo, incluso la relajación y la meditación, la noche antes del día final del sprint. Descansemos, estemos con nuestras familias o amigos, salgamos a cenar, a disfrutar de una caminata a la luz de la luna con quien mejor nos sintamos o simplemente reposemos al ritmo que nuestro corazón dicte. Preparémonos así para la gestación de un día de buenas noticias con el resto del ecosistema organizacional.

Participemos de los preparativos, una revisión interna previa del producto no está demás. Lleguemos antes que todos los demás y recibamos a los invitados a la revisión, si los hay, con una gran sonrisa, con sendos mensajes de bienvenida, con una bebida. Y no, no es hora de licor.

[De la revisión propiamente dicha hemos hablado en variadas ocasiones así que no voy a entrar detalles sobre lo que debe o debería ocurrir durante la misma]*.

Aunque esto es del ámbito de la reunión misma, no dejemos de solicitar y recibir con la mente bien abierta toda la retroalimentación que nos brinden los asistentes. Ese será el motor que nos permita hacerlo mejor la siguiente vez. Y finalicemos con los agradecimientos respectivos, los aplausos, los abrazos, ¿por qué no? Después de todo, estamos todos en el desafío de deleitar a los consumidores finales de nuestro producto.

Finalmente, hagamos una pausa, tomemos un café y vamos a la retrospectiva. Esa cita íntima y necesaria en cada iteración. [Tampoco me extenderé mucho en este apartado]**

Al final del día, piensa que mañana seguirás mejorando. Es todo lo que necesitas para triunfar.

Apostilla:

No solo el último día, sino todos los días de tu vida, tiende la cama antes de salir. Si al final tienes un mal día o muchos malos días, siempre te recibirá una cama limpia y tendida. ¡Es la clave para cambiar el mundo!

-----

* Por ejemplo, además de lo que dice la guía de Scrum, mi gran amigo Jorge Abad ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[AgendaScrum] Pasos para Realizar el Review o Revisión

Tipde Scrum: La calificación del Product Owner al finalizar el Sprint

Buenasy Malas Prácticas en el Review / Demo de Scrum

Lacara del santo hace el milagro. Efectividad del Planning y Review

Los invito a que los lean. Encontrarán consejos muy útiles cuando de preparar y realizar este evento del que les he hablado se trata.

** Por ejemplo, pueden leer mis artículos:

De Retrospectivas y de Ratones

Directiva Primaria de las Retrospectivas

Dueño de Producto, usted ha sido invitado a la Retrospectiva

Aquí mismo en este Gazafatonario.

El contexto de tu producto importa: aquí te cuento el porqué

Imagen tomada de Pixabay

Escucha el audio de este artículo aquí:

Los dueños de producto virtuosos utilizan una combinación de análisis de negocios, experiencia de usuario y habilidades de gestión de productos para determinar cuál es el siguiente producto correcto a diseñar y construir y para compartir con el equipo de desarrollo el entendimiento que tienen de su visión.

Mucho antes de la era ágil ya enseñaba y acompañaba a los gerentes de producto y líderes de equipos de producto a:

• Entender mejor a los interesados, a los usuarios y a todo aquel que se viera impactado de una u otra forma por el producto y por su desarrollo
• Comprender el contexto de su producto
• Tener una percepción más íntima de las necesidades de sus consumidores
• Entender y juzgar el producto derivado de su trabajo con el equipo
• Organizar la información recopilada del aprendizaje del uso del producto, más del contexto de este.

El movimiento ágil me enseñó posteriormente que una técnica específica puede o no ser apropiada en cada situación. También me enseñó que el diseño y la elaboración de productos impresionantes es una forma de pensar, una mentalidad. De esta manera, el mensaje que llevo a los Dueños de Producto actuales para ayudarlos a determinar el momento adecuado para usar una u otra técnica y la forma más sencilla de aplicarla, es conocer en profundidad los diferentes escenarios, las circunstancias o condiciones bajo las cuales será usado el producto que tienen en mente, lo que casi siempre incluye conocer al detalle a los usuarios o consumidores.

Pero en el camino de establecer una comprensión compartida del problema y más allá, de la causa raíz, el problema detrás del problema, y de las mejores soluciones para resolverlo, nos encontramos con ciertos impedimentos como:

• Muchos backlogs de producto
• Dificultad en la priorización de cada uno de ellos y entre unos y otros
• Poca percepción del valor de cada producto y de cada uno de sus componentes, el valor para el negocio
• Muchas interdependencias entre unos y otros y hasta con productos que no están en el radar de nadie
• Los equipos no necesariamente están trabajando en los productos correctos desde una perspectiva del negocio, aunque los Dueños de Producto no ayudan mucho en este sentido

Para sobrepasar estas dificultades ayuda conocer el contexto en el cual estamos trabajando. Es útil encontrar las respuestas a preguntas como:

• ¿Quién necesitará o usará nuestro producto?
• ¿Quién es nuestro consumidor final?
• ¿A qué mercado o segmento de mercado queremos llegar?

Pero ya no estamos en el momento de quedarnos con las respuestas simples. Estamos en la era de la hiperpersonalización de productos. Cada consumidor o usuario quiere tener su propia experiencia, única, así es que dediquemos tiempo a conocer a muchos de ellos. No es que necesitemos salir con un MVP para cada uno, se trata de salir lo más rápido posible con un producto en excelentes condiciones, listo para usar o consumir y,  a partir de allí, incrementarlo y desplegarlo a más y más usuarios de manera frecuente.

Dediquemos un tiempo importante a repensar el producto. No caigamos en la trampa del “MVP muy temprano”. El mayor miedo de las organizaciones hoy es llegar al mercado con el producto incorrecto. Está bien lo de fallar rápido y barato pero no se trata de fallar por fallar. Nos enfrentamos a la paradoja de las organizaciones exitosas: solo queremos brindar productos que enamoren a las personas, pero no sabemos si el producto deleitará a nuestros clientes hasta tanto no lo hayamos entregado.

Las cosas así, llevar a cabo minuciosamente algunas de estas actividades, sino todas, ayuda:

• Definir y defender la visión del producto.
• Investigar la naturaleza y probar las necesidades del mercado
• Identificar múltiples opciones de productos de alto valor.
• Decidir las fechas de lanzamiento y el contenido. Sobre todo, lanzar con calidad.
• Durante el desarrollo “a lo Scrum”, lograr que los elementos del backlog de producto estén "Preparados" para la planificación y desarrollo
• En ese mismo orden de ideas, aceptar solo trabajo "Terminado"
• Realizar demostraciones de productos y solicitar retroalimentación en vivo y en directo, tomar atenta nota e incorporar, de ser posible, las nuevas solicitudes

En mi artículo Las historias de usuario se cuentan con C de Contexto, enumeraba Algunas herramientas que nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general. Puedes leer el artículo en:

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

Ahora bien, antes de pensar en la tecnología, pensemos en el negocio. Antes de salir a vender (o a producción), pensemos en el mercado. Antes de desarrollarlo, pensemos en el cliente o usuario. Antes de considerar sus componentes internos, pensemos en cómo se verá a los ojos, a los sentidos de las personas a las que queremos llevarle el producto.

Una técnica que estamos aplicando con éxito es esta del desarrollo de productos basado en experimentos: una forma de abordar el diseño del producto y el proceso de desarrollo para que la investigación, el descubrimiento y el aprendizaje (hacer preguntas y obtener respuestas útiles y confiables) tengan prioridad sobre el diseño y luego la validación de las soluciones propuestas. Pero sobre desarrollo de productos basado en experimentos hablaremos en otra oportunidad.

Imagen tomada de Pixabay

Mientras tanto, atención Dueños de Producto, Gerentes de Producto, deleguen completamente el diseño y la construcción del producto al equipo de desarrollo, ustedes dedíquense a explorar el mercado, a aprender de él, a pensar en nuevas formas de cambiar el estilo de vida de las personas y a conocer las necesidades de estas. Es lo que finalmente los conducirá al éxito en sus tareas habituales. ¡Escucha a tu usuario!

Finalmente, es solo a través de procesos efectivos de diseño, prueba, retroalimentación e iteración, que un Dueño de Producto y su equipo pueden validar el impacto de una idea en un contexto. Súmate a un equipo grandioso, porque un equipo estupendo hace productos fantásticos.

La lista de chequeo de Scrum Roosmalen

Clic para ampliar la imagen

Ralph van Roosmalen implementó hace ya algunos años esta herramienta en Microsoft Excel, basado en la ya archifamosa Lista de Chequeo de Henrik Kniberg, de la cual tuve la oportunidad de publicar la versión en español hace ya varios años. La pueden encontrar y descargar en:

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html

Si ya la tienes, vuelve a releer el espíritu que inspiró esta lista de chequeo. No intentes encontrar todas las respuestas allí, es un buen comienzo. La he usado ampliamente de diversas formas en los últimos años y me ha funcionado bastante bien. En retrospectivas y revisiones de distintas implementaciones de Scrum y de prácticas ágiles. Como fuente de aprendizaje para futuros Scrum Master, Dueños de Producto y miembros de equipos Scrum en general. Como parte del crecimiento de las empresas hacia un pensamiento lean-ágil que soporte su cultura organizacional. En fin, las posibilidades son infinitas.

En esta ocasión contacté a Ralph y me autorizó a publicar la traducción al español de su herramienta. Muy útil para presentar información incluso a la alta gerencia, como guía del estado de una implementación Scrum típica. Está enriquecida con gráficos de los aspectos más relevantes del marco de trabajo que finalmente sirven como datos para tomar decisiones acerca de los pasos siguientes durante el cambio en la forma de hacer las cosas.

Clic para ampliar la imagen

Como siempre, el llamado es a experimentar, a cambiar la herramienta una vez que la dominemos, a sacarle el mejor provecho posible. Aquí se las presento. Al final, encuentran el enlace para descargarla. Veamos que dice Ralph en la página de Documentación.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum o para evaluar tu actual implementación de Scrum. Está basada en la Lista de Chequeo de Scrum de Henrik Kniberg[1]. Le he adicionado una sección: Scrum Distribuido.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum pero se aseguraron de que el propósito de la práctica Scrum ha sido cumplido de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la retrospectiva. Como una herramienta de discusión, no como una herramienta de evaluación.

¿Es esta una lista de chequeo oficial?  No. La lista de chequeo refleja principalmente la opinión personal y subjetiva de Henrik acerca de lo que realmente importa en Scrum. Él ha pasado años ayudando a compañías a empezar con Scrum y ha conocido a cientos de otros practicantes, instructores y entrenadores; y ha encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Clic para ampliar la imagen

Para usar la lista de chequeo correctamente, si es posible 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 allí es donde se pone interesante. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo será el comienzo de una discusión! Como se describió en el segundo párrafo, no puedes juzgar una implementación de Scrum basado solo en esta lista de chequeo. Si acaso sea posible juzgar una implementación de Scrum    ;)

Para usar el instrumento, ve a la hoja Entrada de Datos y marca tu  "calificación". Cuando todo esté diligenciado correctamente, todas las cruces rojas serán verdes. Tan simple como eso, como en Scrum. Scrum es mortalmente simple... Sin embargo, implementarlo puede ser muy desafiante ;)

Clic para ampliar la imagen

¿Pensaste que encontraste un error porque la columna "Tu número de madurez de Scrum" siempre es 42 [2]? Correcto y esto no es un error. No puedes capturar una implementación de Scrum en un número, eso es imposible. El hecho de hacer algunos cálculos y mostrar gráficos ya es cuestionable.

¿Por qué no usamos degradados rojos y verdes en las barras de colores? Porque el rojo está relacionado con lo negativo y el verde con lo positivo y no podemos decir que algo es negativo o positivo en tu organización. Así que lo mantenemos neutral, solo azul.

Clic para ampliar la imagen

Si tienes preguntas o comentarios, contáctame en ralph@agilestrides.com.

Referencias

[1] https://www.crisp.se/gratis-material-och-guider/scrum-checklist

[2] https://es.wikipedia.org/wiki/El_sentido_de_la_vida,_el_universo_y_todo_lo_dem%C3%A1s

Puedes descargar la herramienta de Ralph aquí:

No dejes de contactarme o de contarme en el foro sobre el uso que le están dando a esta herramienta que seguramente te será de mucha utilidad.

Traducción de Lucho Salazar. lucho.salazar@gmail.com. http://www.gazafatonarioit.com.

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:

• Siempre aplicamos las mismas prácticas en todas partes
• Siempre exigimos adherencia a actividades y procesos, ágiles o no
• Definimos la cadena de herramientas permitida
• Forzamos la estandarización en todas partes
• Creemos que el proceso habla por sí mismo
• Confiamos en el proceso más que en las personas y el equipo

Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:

• Definir y liderar la visión del producto.
• Investigar y probar las necesidades del cliente / mercado
• Identificar opciones de productos de alto valor.
• Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
• Aceptar solo trabajo "terminado"
• Realizar demostraciones de producto
• Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
• Explicar siempre el valor detrás de un proceso
• Observar, aprender de y analizar el mercado.
• Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
• Decidir las fechas de lanzamiento y el contenido.
• Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
• No lanzar en la fecha, lanzar en calidad (a lo Spotify).
• Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
• Saber cuándo descontinuar o sacar el producto del mercado

El equipo de desarrollo de producto debe:

• Ser pragmático en la elección de las herramientas
• No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
• Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno

Toda la organización debe:

• Concentrarse en el Valor.

¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:

The Uncomfortable Entrance

Illustrations by Katerina Kamprani

https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/

Por qué hay tanto mal practicante de la agilidad: o de cómo los agilistas experimentados le podemos poner el cascabel al gato

Advertencia: agilidad sin prácticas técnicas no es agilidad.

Corolario: agilidad sin atención continua a la excelencia técnica no es agilidad.

Quizás cuando no teníamos la experiencia que tenemos hoy y empezábamos en esto de la agilidad no fuimos los mejores instructores, los mejores maestros, los mejores acompañantes, los mejores facilitadores, los mejores Scrum Masters. Incluso quizás no tuvimos los mejores maestros. Aunque sí tengo que decir, que tanto nosotros como nuestros maestros siempre tuvimos las mejores intenciones, de eso que no le quede la menor duda a nadie.

La proliferación aleatoria, desordenada y sin medida de “versiones” tanto del pensamiento ágil, como de los marcos de trabajo y prácticas más ampliamente usados actualmente, como Scrum, historias de usuario, SAFe, Kanban, DAD o el muchas veces explotado pero pocas entendido y mal usado modelo de las tribus y los squads ("sí, ese de Spotify"). No me malentiendan, todas esas “versiones” a las que aludo son bienvenidas, es lo que exige el entorno VUCA en el que transitamos. Pero hay unas bases sólidas sobre las que quizás no nos estamos levantando. Hablo del Manifiesto Ágil, del corazón de la agilidad, de los valores y principios que promueven el pensamiento ágil y todo este movimiento del que hacemos parte.

Muchos de quienes ya tenemos experiencia dejamos de enseñar temas “básicos” o para principiantes. Además, de tanto hablar de o tratar algún tema clasificado en esas categorías, hemos llegado a creer que ya todo el mundo tiene claridad sobre ello cuando, de hecho, no es así. Al movimiento ágil sigue sumándose gente todo el tiempo, de todo tipo, tanto a nivel personal como profesional, al igual que equipos, áreas y organizaciones enteras que necesitan de la ayuda de las personas que hayamos realizado muchos experimentos y que al menos hayamos aprendido cómo reaccionar a los resultados de esos experimentos, tanto exitosos como fallidos.

En nuestras economías, los equipos se están integrando y desintegrando todo el tiempo, no permanecen en el tiempo. Todavía estamos lejos de ese ideal que significa llevar proyectos a los equipos y abandonar para siempre la práctica de llevar equipos a los proyectos. Las cosas así, los equipos están en una eterna formación a lo Tuckman. Esto, sumado al constante estado “Shu”, natural por demás, de los principiantes, hace necesario que sigamos mirando hacia ese lado de las trincheras.

No nos estamos haciendo acompañar de las personas correctas. Aclararé esto con una instancia: una de las grandes disfunciones que tenemos los seres humanos, sobre todo quienes elegimos la tecnología como objeto de trabajo, es la comunicación. Más si se trata de comunicación cara a cara. No somos buenos comunicándonos. A no ser que lo hagamos vía WhatsApp o de cualquiera de los artilugios que nos ha regalado la tecnología del siglo 21. Ahora bien, el que el manifiesto ágil señale que “el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara” no logra por sí solo que seamos capaces de conversar cara a cara. Ni siquiera porque se lo escuchemos a un gurú ágil, incluso a alguno de los mismísimos firmantes del manifiesto, no.

Si no somos “buenos” hablando cara a cara es porque en nuestra mente ocurren cosas que vienen desde hace mucho tiempo, quizás desde antes de que naciéramos, qué sé yo. De eso se trata precisamente. Quienes tenemos formación de Ingenieros, de programadores y similares, no tenemos la formación académica ni la experiencia suficiente y necesaria para tratar esos “males”. Y la mucha agilidad que transpiramos, practicamos y promovemos no va a conseguir solucionarlos. Quizás hasta estamos empeorando la situación. Así es que hagámonos acompañar de especialistas en esos temas tan ajenos a nosotros.

Y este apenas es uno de los muchos ejemplos que puedo mencionar. No es precisamente vía una o varias retrospectivas, sin el debido acompañamiento, que vamos a solucionar el problema de falta de comunicación entre miembros  del equipo. No es precisamente vía reuniones uno-a-uno, o a través de más lean cafés, más dinámicas de la confianza o más cervezas ágiles que vamos a curar algunas de las enfermedades crónicas de las personas en este milenio.

Atención a que no estoy diciendo que tenemos mala intención. Antes por el contrario. Queremos ayudar. Partimos de esa directiva. Pero no es nuestra competencia. Es definitivo. La agilidad es sobre personas, es para personas, antes que para equipos y mucho antes que para organizaciones. Y ser personas no nos hace expertos en personas. Hay otros profesionales que sí lo son. Busquémoslos, hagámoslos parte de nuestros equipos y empresas y trabajemos con ellos de la mano, aprendamos de ellos, sin querer reemplazarlos en ningún momento.

Sobre escalado y otros aspectos

Estamos escalando disfunciones. Algunas de las razones que expuse antes ocasionan esta situación. Lo que a su vez genera malos practicantes del escalado, de la agilidad en los negocios, de la agilidad en Recursos Humanos, en Operaciones, en Logística y en otras áreas fuera de las áreas de Tecnología, que es donde usualmente se inician los procesos de cambio en el enfoque ágil de hacer las cosas.

Llamado a la acción

Tomémonos un tiempo para reflexionar sobre estos asuntos de interés para nuestro tiempo. Pensemos en la inmensa responsabilidad que tenemos con los demás, estamos tratando de cambiar vidas y por una u otra razón no lo estamos haciendo bien. Promulgamos el que los demás deben hacerse acompañar (¡de nosotros!) pero nosotros no nos estamos acompañando de quienes necesitamos.

Volvamos a las bases. No tratemos de correr cuando deberíamos seguir caminando. ¡Cuántas veces he escuchado el “oye, ya llevas un año en tal empresa y como que no ha pasado nada”! En un año o más pasan muchas cosas, pero no todas las que esperamos y menos las que esperan los demás. Y un año es un período muy pequeño para que se susciten grandes cambios en organizaciones que vienen siendo conducidas por personas cuyo pensamiento tradicional les impide darse cuenta de que el ritmo de cambio afuera es mayor al de adentro.

Cumplamos la promesa y hagamos el cambio de manera orgánica. Paso a paso. Sostenible. Constante. Eso sí, no nos olvidemos de que todos los enfoques fallan, pero unos fallan más rápidos que otros.

Créditos de la imagen de la portada:
Trocadero Marbella Rugby Club, Marbella, España
Partido de rugby jugado el 14-01-2018 entre el Trocadero Marbella Rugby Club “B” y el Victoriano Rugby Club en el Bahia’s Park de Marbella. Estuvo lloviendo durante casi todo el partido formándose barro con lo que el juego se hizo dificil a la par que interesante y “atractivo”.
Foto de https://unsplash.com/photos/cK2UBBg4JI4