Soy un buen Scrum Master pero la empresa no está preparada

O “Soy un buen Scrum Master pero la empresa no es ágil”

Imagen de mohamed Hassan en Pixabay

Cuando eres Scrum Master, sea cual fuere tu nivel de experiencia o de madurez en el rol, nunca más se da el caso de “no soy yo, son ellos”:

• Es que apenas están implementando Scrum, ellos (la organización, los equipos, las personas) no están maduros. | ¿Es posible “implementar” Scrum?
• Es que todavía están (los equipos, las personas) atascados en los modos tradicionales de gestión y creen que soy el jefe o el gerente.
• Es que ellos necesitan entender la nueva forma ágil de trabajar que quieren adoptar. | ¿”Adoptar”, luego no era “implementar” Scrum?
• Es que están esperando que yo comande al equipo desde alguna suerte de puesto de control o cabina de mando.
• Es que yo no tengo autoridad sobre el equipo. Soy solo un líder servicial a su servicio, como dice la guía de Scrum. Y el equipo es autogestionado. Funciona por sí solo. | ¿Un equipo “funciona”?
• Y la lista de razones puede llegar a ser interminable.

Muchas organizaciones con una fuerte cultura de comando y control no te tomarán en serio como Scrum Master si no muestras habilidades para tomar el control de la situación. Las formas de hacer las cosas y mucho menos las formas de pensar actuales se cambian en pocos meses. Hacer que la empresa, los equipos y las personas maduren o siquiera estén conscientes de su nivel de agilidad es tu responsabilidad también.

Imagen de Gerd Altmann en Pixabay

No puedes simplemente ignorar la cultura actual de la organización y conducirte sobre los nuevos preceptos que te “dicta” la agilidad, el pensamiento Lean o prácticas como Scrum. “Es que ellos no entienden nada de liderazgo servicial ni de mejoramiento continuo”. No hay tal cosa como “ellos y nosotros” en el pensamiento ágil.

No te apresures. Da un paso a la vez y aprende de la reacción del entorno. Concéntrate primero en el equipo y ve escuchando al resto de la organización sin atribularte por la avalancha de ideas, solicitudes, advertencias, restricciones, desafíos, oposiciones y demás escenarios que vas a vivenciar. Para ello, viene bien hacerse acompañar de otros Scrum Masters, coaches ágiles o de cualesquiera que te proporcione ideas y que desee llevarlas a cabo contigo.

Estás allí para enseñarle a cada miembro del equipo a ser un líder, para empoderarlo y ayudarlo a aclarar su rol en este nuevo orden de las cosas, para remover algunos de los obstáculos en su camino pero más que a nada para instruirlo en cómo eliminarlos por sí mismo. Por sobre todas las cosas, no pierdas de vista que vienen de la cultura de ser recursos, así que piensa en ellos como personas y haz todo lo que esté a tu alcance para aumentar su felicidad.

Eres su entrenador pero deja que ellos también te entrenen. Aprende de la cultura y de los comportamientos imperantes. Luego, comienza a promover y a resaltar nuevos comportamientos “a lo ágil” y a desalentar, sin presión, las conductas actuales que no posibilitan el mejoramiento del equipo. Define un buen conjunto de valores que sean consistentes con el mensaje que quieres enviar y con el nuevo camino que les quieres mostrar, los valores de Scrum te ayudan, sí.

Asegura victorias tempranas. Una matriz de Esfuerzo versus Valor siempre viene bien en estos casos. Asegúrate de hacer con tu nuevo equipo lo que está en la zona de mayor Valor pero menor Esfuerzo y por ningún motivo mires la zona de mayor valor y menor esfuerzo.

Matriz de Esfuerzo versus Valor

Esfuerzo y Valor son relativos. Asume que todo lo que haces genera Valor y requiere de cierto esfuerzo. Pero incluye las variables que necesites para garantizar que algunas tareas, de tres a cinco de ellas, generan más valor que otras y requieren menos esfuerzo que otras. Y así, hasta completar la matriz. Distintos ejercicios te pueden llevar a lograr esto en pocos minutos, aun si tu equipo no es el mejor comunicándose.

Ve a lo seguro, sin dejar de experimentar. Después de todo, de eso se trata, de aprender mediante experimentos rápidos y baratos. Sigue la línea Shu-Ha-Ri como en esta infografía que preparé con mi gran amigo, compañero de batallas ágiles, Jorge Abad (@Jorge_Abad):

Scrum Master Shu-Ha-Ri

En esta etapa inicial, como Scrum Master, sigue la guía de Scrum con cierta precisión. Concéntrate en cómo organizar y llevar a cabo los eventos con el equipo, que se tengan los artefactos y que cada miembro del equipo Scrum se desempeñe como lo plantea la guía, sin preocuparte demasiado por la teoría subyacente; por ejemplo, en cómo planificar en un entorno empírico. Si hay múltiples variaciones sobre cómo hacer algo, solo decídete por la forma en que la guía lo establece o en como lo aprendiste. Tengo que decirlo, en este último caso, quizás estés equivocado, así que igual, hazte acompañar de alguien más experimentado, incluso de miembros de tu nuevo equipo. Ellos ahora son tu familia.

Más adelante pasarás a los demás estados. Recuerda que si ingresaste al equipo y a la organización, hay una alta probabilidad de que la madurez en materia de desempeño de todos quizás se reinicie “a lo Tuckman”, en donde los miembros del equipo tengan miedo (otra vez) de pedir ayuda unos a otros y a ti, no confiarán completamente en ti y te monitorean de cerca cuando estés trabajando en una tarea específica, con o sin ellos; muchos de ellos tendrán sus propias ideas sobre el proceso y las agendas personales serán rampantes; quizás te encuentres con roles específicos dentro del equipo, como líder técnico, facilitador, diseñador, documentador, incluso gerente; volverán las discusiones abstractas (si alguna vez se fueron) sobre distintos conceptos y temas y algunos miembros estarán impacientes con estos debates. Entre otros comportamientos típicos de la etapa de Formación de un equipo tradicional.

Incluso parecerá que estás logrando poco hacia la consecución de los objetivos del proyecto (sí, todavía se llamará “proyecto) y recibirás toda la carga de la culpa cuando te señalen a ti y a la nueva forma ágil de hacer las cosas que intentas poner de manifiesto en el ambiente. No te preocupes mucho por ello, aunque no estén completamente seguros de las metas y problemas del proyecto, algunos, quizás todos, estarán entusiasmados y orgullosos de estar en el equipo y a la expectativa de lo que pueda venir.

Las cosas así, quizás no puedas ir más allá del estado Shu, así te sientas con la fuerza, la experiencia y el coraje para empezar con el estado Ri. Lo leí de Melina Jajamovich (@latodoterreno) recientemente, “No hay seniority que valga cuando se trata de #agilidad | El mindset es un desafío de cada día”. Eres un eterno aprendiz, inculca eso en tu equipo, estás allí para acompañarlos a ser mejores.

Finalmente, empieza a pensar en el futuro del equipo. De hecho, esto se convertirá en lo más común y en lo mejor que podrás hacer en tu nuevo rol. Con el tiempo aprenderás que para un Scrum Master extraordinario no hay tal cosa como “no puedo hacer esto o aquello porque surgió algo urgente”. Debes adelantarte en el tiempo y visionar cómo llevarás al equipo al siguiente nivel de crecimiento, sin dejar de vivir en el presente para estar al frente de las tareas menos mundanas de protección y liderazgo del equipo.

Ya eres Scrum Master, no lo eches a perder solo porque el resto de la organización no te entiende. Asume tu responsabilidad, toma el control y muéstrales las cosas fantásticas que pueden lograr con agilidad. Es tiempo de cambiar.

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/