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

Estimaciones en los tiempos de la agilidad

Presentación

Hace algunos días, mis amigas Valeria Vásquez y Alejandra García, un par de cómplices caleñas convencidas de esto de generar espacios para compartir conocimiento que nos permita cambiar, me invitaron al cierre de una iniciativa que decidieron liderar desde el día mundial de la Retrospectiva en 2019, la cual consistía en realizar reuniones virtuales abiertas sobre distintos temas seleccionados por la gente. Mi tema era precisamente este de las estimaciones. Aquí les presento algunas conclusiones, no sin antes felicitar en grande a estas dos intrépidas que se han tomado este asunto de ser líderes de una comunidad que sigue expandiéndose y creciendo y que cada día presenta nuevos retos, como lo es Ágiles Colombia.

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

Decíamos en la reunión que una Estimación es un proceso analítico e imparcial para predecir la duración o el costo de un proyecto o desarrollo de producto, de una iniciativa en general. Y hacíamos énfasis en que la estimación es una predicción, no es una planificación, ¡no es un compromiso! Además, “una estimación es buena cuando quienes estimaron consideraron toda la información que tenían a su disposición para el momento y el propósito de la estimación”, o algo así nos contaba mi gran amigo Wilmar Hincapié en una conversación anterior.

Pero ¿qué es eso de “considerar toda la información” disponible? Bien, debemos considerar el entorno VUCA en el que nos movemos hoy día, donde la volatilidad, la incertidumbre, la complejidad y la ambigüedad están a la orden del día, en donde no es posible predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo vamos a entregar y cuánto será su costo. Lo que sí podemos hacer es empezar con planes iniciales, planes cuya elaboración no tome mucho tiempo y sobre los cuales haya certeza de que van a cambiar, quizás tanto como todos los días. Después de todo, la meta es entregar el mejor producto o servicio posible, no la planificación en sí y mucho menos la estimación. Es lo que hemos dado en llamar “filosofía ágil”. Más sobre esto en mi artículo “Cultura ágil: ese oscuro objeto del deseo”.

No estimamos en el universo de lo simple ni de lo complicado, sino en el entorno de lo complejo, de lo caótico y hasta del desorden (Cynefin). Por ello es que no existen las “buenas” técnicas de estimación ágil, aunque tampoco existen las malas, son simplemente técnicas, experimentos que hacemos para tratar de calmar el ansia de todos los interesados en temas como la duración de una iniciativa o en las fechas de entrega de producto.

Debemos deshacernos de una vez por todas y para siempre de las cadenas que nos impuso el triángulo de hierro de los proyectos tradicionales, ese que establecía el éxito de un proyecto si este se encontraba dentro de los límites de tiempo, alcance y costo estimados. En este orden de ideas los invito a que consideren mi enfoque integral de gestión de personas y desarrollo de productos (resultados y restricciones) que expongo en el triángulo ágil extendido.

Técnicas de Estimación

Sobre este asunto de las técnicas o experimentos para estimar también hablamos un poco.

1. Planning Poker

La experiencia nos ha enseñado a usarla cuando tenemos un número relativamente pequeño de elementos a estimar y con un equipo pequeño de personas. Más sobre esta técnica en https://www.mountaingoatsoftware.com/agile/planning-poker.

2. Tallas de camiseta

Esta es una técnica muy buena para estimar un backlog grande de producto. Especialmente cuando tenemos varios equipos concurrentes trabajando en el mismo producto. Es una manera informal y rápida de tener una idea aproximada del esfuerzo requerido para hacer algo. Para saber más sobre la técnica, accede a http://getskillsblogs.com/agile-estimation-with-t-shirt-sizes/.

3. Puntos de votación (dot voting)

Útil cuando nos enfrentamos a un conjunto relativamente pequeño de elementos y necesitamos una técnica súper simple y efectiva para estimar. El método se originó a partir de la toma de decisiones. Funciona bien tanto para equipos pequeños como para grandes, pero tenemos que limitar el número de elementos estimados. Más sobre la técnica en http://www.informit.com/articles/article.aspx?p=2117898&seqNum=3.

4. El sistema del cubo

Mucho más rápido que el planning poker es el sistema de cubos. Este sistema es una buena alternativa al estimar un gran número de elementos con un gran grupo de participantes. Más sobre este curioso método en:

http://www.agileadvice.com/2013/07/30/referenceinformation/agile-estimation-with-the-bucket-system/

5. Grande / Incierto / Pequeño

Un método muy rápido de estimación aproximada es el método Grande / Incierto / Pequeño. Se le pide al equipo que coloque los artículos en una de estas categorías. El primer paso es categorizar los elementos obvios en las dos categorías extremas (Grande y Pequeño). A continuación, el equipo puede discutir los elementos más complejos. Esto es en realidad una simplificación del sistema de cubos. El sistema es especialmente bueno para usar en equipos más pequeños con elementos comparables. Como siempre, podemos asignar tamaños numéricos a estas 3 categorías.

6. Mapeo de afinidad

Funciona mejor con un grupo pequeño de personas y un número relativamente pequeño de elementos. Más información sobre la técnica en:

http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/

7. Método de ordenamiento

Este es un ejercicio donde se obtiene una imagen precisa del tamaño relativo de los elementos. Funciona mejor con un pequeño grupo de expertos. Todos los elementos se ponen en orden aleatorio en una escala que va de “pequeña” a “grande”. A cada participante se le pide que mueva un elemento en la escala. Cada movimiento es solo un punto más bajo o uno más alto en la escala (muy pequeños, pequeños, medianos, grandes, muy grandes), o simplemente el participante cede el turno. Esto continúa hasta que ningún miembro del equipo quiera mover elementos o ceda su turno.

El método funciona mejor con un grupo relativamente pequeño de personas y una gran cantidad de elementos.

Más sobre una “buena” estimación

• Siempre demos un rango, nunca demos un número. Los números son para hechos, los rangos son para estimaciones
• Siempre preguntemos para qué serán usadas nuestras estimaciones. ¿A qué nos hemos comprometido? ¿Basados en qué información?
• La estimación es diferente de un compromiso. Realizar una estimación “errónea” no hace daño.
• Primero tratemos de medir, contar y calcular. Estimemos solo cuando sea necesario.
• Por sobre todas las cosas, ¡nunca negociemos las estimaciones! Siempre preguntemos las razones y los supuestos detrás de las estimaciones.

Juegos de estimación dañinos que debes evitar

La estimación es un juego pero evita los juegos de estimación dañinos:

• ¡Adivina el número que estoy pensando!
• ¡Un equipo increíble como el de ustedes puede hacer mucho más que esto!
• Esta vez será mucho más rápido porque hemos aprendido mucho del proyecto anterior.
• ¡Este proyecto será muy diferente!
• Si trabajamos un poco más duro, aumentaremos la velocidad.
• ¡Puedo programar esto en la mitad del tiempo! O el infame arte de hacer el doble de trabajo en la mitad del tiempo.
• Si bajamos la estimación, el proyecto se hará más rápido (esto realmente funciona en algunos escenarios).

Recomendaciones finales

• Si sigues estimando como hace dos años o más seguramente no eres  ágil, es más, quizás ni estés haciendo estimaciones propiamente dichas.
• Experimenta con muchos tipos de estimación. 
• Estimas trabajo de conocimiento, trabajo creativo, no trabajo predecible y repetitivo.
• Toma la estimación como un juego, un juego serio pero juego al fin y al cabo.
• Usa técnicas de estimación relativa.
• Con cautela, hazle caso a La ley de los grandes números.
• Fija objetivos y resultados clave (OKR), no números fríos.
• No estimes, a nivel de iteraciones, si no conoces la Definición de Terminado ni los criterios de aceptación.
• Cuando se trate de productos o de características de producto, estima en iteraciones o, a lo sumo, en días. Deja las horas para las actividades diarias.
• Estima para un rango que va desde la Mínima Entrega Viable hasta la Entrega Completa. Es decir, asegúrate de que en ese rango de tiempo harás una entrega de valor.
• Evita a los “influenciadores” expertos y, en general, a quienes pueden crear distractores al momento de realizar la estimación.
• Estima valor de negocio, no puntos de historia.
• Experimenta, crea tu propio método de estimación. Por ejemplo, el método 1 – 5 – 9 es una técnica simple que consiste en establecer si el elemento se puede elaborar o no en una iteración junto a otros 5 a 9 elementos. De ser afirmativo, es porque contamos con la suficiente información para desarrollarlo a continuación. Útil para usar durante la planificación de una iteración de menos de un mes de duración.
• ¡O simplemente no estimes del todo! Enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Las historias de usuario se cuentan con C de Contexto

El Lienzo para Conversar sobre Historias de Usuario

O de la cuarta C de las historias de usuario

Un equipo de producto actúa  o debe actuar como un fabricante, uno que trace la estructura del producto para lograr coherencia. La coherencia supone una interacción entre partes que genera resonancia. A estas partes las llamamos “cosas no ordinarias”. La resonancia, una cualidad de una cosa no ordinaria trazada de manera coherente, incita las reacciones de las personas. Y son esas reacciones las que hacen que las personas experimenten algo extraordinario como algo especial.

Para lograr esa resonancia, es necesario conocer el entorno o contexto donde se ubica cada una de  esas piezas que forman el producto. Las historias de usuario son precisamente cada una de esas partes que componen un producto (de software) y como equipo de producto nos apasiona elaborar productos extraordinarios. Pues bien, una de las secciones del lienzo para conversar sobre historias de usuario (User Story Conversation Canvas), es el Contexto. Quiero ampliar un poco su definición.

Recordemos que una de las formas que toman las historias de usuario documentadas es la muy conocida de las 3 C o CCC, siglas de la aliteración Carta Conversación Confirmación. ¿Qué sucede si a esta forma le agregamos una C? La C de Contexto. Veamos.

Del lienzo para Conversar sobre historias de usuario

Entender el entorno en el cual transita o existe una historia de usuario en particular y un producto o servicio en general es crucial a la hora de desarrollar esa historia o producto. ¿De dónde viene la historia? ¿La necesidad? ¿Cuál es el problema que intentamos resolver? O mejor aún, el problema detrás del problema, la causa raíz. Las decisiones que tomemos a partir de este entendimiento tendrán un impacto en el futuro de muchas personas, incluso modificarán su modus vivendi.

Algunos elementos a considerar en todo contexto de una buena historia de usuario son:

• Necesidad origen
• Escenarios de uso de la historia
• Dominio del negocio, qué áreas del negocio usan o se impactan por la historia
• Reglas del negocio que afectan la historia
• Épica origen. No todas las historias provienen de una épica en particular, pero si es así, es bueno conocerla.
• Alcance de la historia
• Hipótesis, que queremos probar con la historia
• Dependencias de la historia. Para aprender a independizar historias, pueden ver el capítulo dedicado al criterio Independiente de las historias de usuario, previamente en este libro.
• Restricciones adicionales, de diseño, de instalación y puesta en marcha, de mantenimiento, de distribución, de empaquetamiento, entre otras.

Más sobre el Contexto de las historias de usuario

En la vida cotidiana, cualquier cosa existe en un contexto de relaciones con cosas fuera de sí misma. Eso aplica también a las historias de usuario. Una de esas “cosas” con las que interactúan las historias de usuario son sus consumidores. Y esta interacción ocurre vía interfaces, que a su vez operan en un entorno.

El usuario es quien valora el producto, es quien se beneficia del producto. Además, un consumidor puede ser una persona, otro producto u otro sistema que interactúa con nuestro producto. El lienzo para conversar sobre historias de usuario tiene toda una sección para hablar de personas, cuando estas son las consumidoras del producto. En esta sección de contexto bien podemos incluir a esos otros productos o sistemas que tengan interacción con el nuestro.

Así es que tenemos que pensar en las interfaces necesarias para que los usuarios interactúen con el producto, en la forma cómo el producto recibirá estímulos, por ejemplo datos, del exterior y cómo sus partes recibirán o enviarán estímulos entre ellas, las historias de usuario, y al exterior.

Una de las formas de conocer el contexto es realizar entrevistas con los usuarios o sus representantes, un Dueño de Producto, por ejemplo. Es la parte de Conversación de las historias de usuario, la cual, ya sabemos es la más importante: las historias de usuario son un instrumento para conversar, ojalá cara a cara. De esta manera entenderemos mejor los modelos de negocio, la industria, el ambiente sobre el que se “desplazará” nuestro producto durante su vida útil. Para efectuar estas entrevistas, seguimos un protocolo diseñado para comenzar a hablar de un tema en los propios términos de las personas a quienes entrevistamos, pero esto de las entrevistas será asunto de otro artículo.

Algo importante es pensar en la información compartida entre las partes del producto y de este con su entorno. También, en la trayectoria que tomarán esos datos, a dónde irán primero, y de allí hacía dónde y así, hasta finalizar su travesía. Eso nos da contexto. Al considerar este tipo de eventos, nos anticipamos a la dirección que tomará la historia de usuario y crearemos expectativas entre sus consumidores.

Las historias de usuario son (deben ser) independientes unas de otras, pero deben integrarse acorde en el producto final para que este tenga coherencia. Esta coherencia describe qué tan bien las historias de usuario de un producto encajan entre sí. Algunas herramientas visuales nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general:

• Un mapa de producto, como un mapa de historias de usuario (user story map)
• Un lienzo de producto, como un product vision board o el mismo business model canvas
• Una caja de producto (product box)
• Un modelo de dominio (del negocio)
• Una matriz de trazabilidad (la podemos seguir usando con pensamiento ágil)
• El lienzo para conversar sobre historias de usuario (user story conversation canvas). De hecho, todas las secciones del lienzo nos permiten visualizar distintos aspectos del entorno en el que transita una historia de usuario y el producto del cual es componente.

Que quién es el responsable de trazar el contexto, entenderlo, asegurarse de que sea una parte de la conversación cuando de desarrollar historias de usuario se trata: ¡el equipo de producto en pleno! Eventualmente tendremos que recurrir a otras personas, conocedores del negocio, usuarios finales o consumidores, expertos del dominio, etcétera.

Así es que, equipo, al considerar tu próxima historia de usuario, preguntémonos cuál es su contexto.

Referencias

The User Story Conversation Canvas

En español:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

En inglés:

http://www.gazafatonarioit.com/2017/09/the-user-story-conversation-canvas.html

El libro Historias de Usuario: una visión pragmática:

http://www.gazafatonarioit.com/2018/10/historias-de-usuario-una-vision.html

Apuntes sobre historias de usuario:

bit.ly/lashistoriasdelucho

The Soul of Design

Austin, Robert. The Soul of Design: Harnessing the Power of Plot to Create Extraordinary Products. Stanford University Press. ©2012 by the Board of Trustees of the Leland Stanford Junior University.

La caducidad del Scrum Master… y por extrapolación del coach ágil

El 10 de abril de 2019 un grupo de contactos de la comunidad Ágiles Colombia revivió este debate en el que yo no participaba quizás en los últimos cinco años. Hablamos de la “fecha de vencimiento del Scrum Master”, de la madurez del equipo, de si el Scrum Master agrega valor o no. Varios y distintos puntos de vista, una discusión con respeto y apertura, tengo que decirlo, lo que muestra que, de alguna manera, hemos madurado y que estamos aprendiendo a soportarnos, que hay apertura, y que ya no somos tan políticamente correctos. ¡Eso es bueno, creo!

Esta es mi opinión, ni más faltaba, soportada en mi experiencia:

Quiero empezar por dejarlos con la siguiente reflexión: llegar a considerar esto (que en algún momento no se requiere el Scrum Master) quiere decir que el desarrollo del equipo tiene un “techo”, es decir, un nivel máximo (de madurez). Algunos dirán que el equipo (de producto) y el Dueño de Producto pueden seguir evolucionando por sí solos; quizás sea posible, ¿pero hasta qué nivel? El equipo tiene una tarea principal y es precisamente el producto, la entrega de valor.

Al considerar este escenario, estamos diciendo que el así llamado mejoramiento continuo tiene un límite. Que en algún momento del tiempo no necesitaremos mejorar más, que llegamos a un nivel de madurez “non plus ultra”, que somos los más más, los que todo lo pueden y no hay nada ni nadie más allá.

Yo estoy hablando del rol, pero no veo al equipo “distribuyéndose” este rol de Scrum Master, en principio “as per Scrum guide”, entre sus miembros. El equipo tiene sus propios retos, inherentes a su papel, hablo de todo eso en lo que confluye la excelencia técnica y, sobre todo, en la entrega continua de producto con valor.

Quizás son dos cosas muy distintas, pero no veo un equipo de fútbol, aun uno de Rugby, o a una orquesta sinfónica, todos conformados por grandes estrellas en sus respectivos campos, jugando o interpretando sin el entrenador adecuado.

Lo escuché por primera vez de Ángel Medinilla: el Scrum Master vive en el futuro del equipo. Le compré la idea. Bueno, ¡en realidad, la tomé prestada! La promuevo en mis equipos y en las organizaciones con la que colaboro habitualmente. Me ha dado buenos resultados. Vivir en el futuro quiere decir que está pensando en cómo llevar a su equipo al siguiente nivel y en cómo preparar a la organización para ese “nuevo” y mejorado equipo. Mejoramiento continuo.

También sabemos que cuando una persona entra o sale del equipo, el resultado no es el mismo equipo, se trata de un nuevo equipo. Aun para equipos de alto desempeño, equipos maduros, equipos en el nivel desempeño del modelo Tuckman, aun para esta clase de equipos, el esfuerzo de “volver” a integrarse los hará regresar de nuevo a la etapa de formación. Y este impulso seguramente seguirá requiriendo de un gran Scrum Master cuyo foco sea llevar nuevamente al equipo a su estado de madurez más alto conseguido.

Voy a ir más allá. Hemos establecido ampliamente que el Scrum Master, al menos uno extraordinario, juega en distintas posiciones:

1.    Coach

2.    Maestro

3.    Líder servicial

4.    Gestor

5.    Agente de cambio

6.    Mentor

7.    Facilitador

Entre otras no menos importantes. Distribuir cada una de estas funciones en el equipo no es algo de poca monta y puede llegar a ser algo perturbador para los miembros de ese equipo. ¿Una por cada miembro del equipo? ¿Y qué pasa si es un equipo de menos de siete personas?

¿Y las tareas mundanas?

Veamos otro contexto:

En algún momento, abstraerse de las complejidades propias de un producto y dedicarse a preparar una retrospectiva puede ser un aliciente, una “pausa activa” para uno o dos miembros del equipo de producto. Pero no veo a largo plazo los beneficios de implementar tal práctica. Necesitamos a los miembros del equipo concentrando todo su esfuerzo en la generación de valor de manera frecuente para la organización.

Sí, ya sé, algunos van a decir que estoy tratando a la retrospectiva como algo frívolo, “terrenal”. ¿Y no es de eso de lo que estamos hablando cuando hablamos de jubilar al Scrum Master? Mirémoslo desde otro ángulo: a la luz de un equipo maduro, que seguramente estará enfrentando problemas de alta complejidad y de mucha incertidumbre, preparar y realizar un evento de Planificación o una Retrospectiva parecerá algo profano y hasta superfluo.

Pero no se equivoquen: no, los eventos Scrum no son para nada momentos vanos, ni siquiera para un equipo realmente “avanzado”. Mucho menos lo son la gran cantidad de otros eventos, sesiones, ceremonias, reuniones, actividades y prácticas que emergen alrededor del desarrollo de productos con Scrum y, por extensión, con pensamiento ágil o lean.

Sobre VUCA y Cynefin

Ah, y ya que toco este no menos peliagudo asunto de la complejidad y la incertidumbre, ¿qué hay acerca del mundo VUCA que habitamos hoy? ¿Qué hay acerca del caos que nos consume? Es en estos ambientes de altísima volatilidad y ambigüedad en los que se necesitan soluciones expeditas, prácticas y categóricas. Un equipo, aun uno con un alto grado de madurez, quizás no sea capaz de reaccionar por sí solo a esos escenarios que emergen de repente y mucho menos en iteraciones cortas de una o dos semanas. Es allí donde un Scrum Master, de esos que he dado en llamar “Extraordinarios” es útil. Incluso si el Scrum Master está parcialmente en el equipo, como plantean algunos, sus respuestas pueden llegar tardías o simplemente no llegar.

Y el Coach Ágil

Un Scrum Master extraordinario sabe que necesita un mentor, alguien que lo acompañe en el camino mientras se forma, mientras madura. Tanto uno como el otro no deben entorpecer las labores del equipo, tampoco deben generar dependencia. En ese sentido deben ser “invisibles”, pero esto no quiere decir que no sean indispensables para ayudar en la mejora de las personas del equipo.

Mi Conclusión

En mi opinión, sí es necesario el Scrum Master. La persona. ¡Y el rol que juega! Quizás sea posible un modelo donde no esté. Ni el coach ágil. Pero en mi experiencia, la evolución de este equipo se va a detener o se va a hacer excesivamente lenta.

¿Qué piensas de todo esto? Déjamelo saber en el foro.

Sobre el Scrum Master Extraordinario

Los invito a leer algunas de mis contribuciones al respecto:

http://www.gazafatonarioit.com/2015/05/de-scrum-master-bueno-scrum-master.html

http://www.gazafatonarioit.com/2016/11/mas-de-como-ser-un-scrum-master.html

http://www.gazafatonarioit.com/2013/10/de-jedi-master-scrum-master.html

http://www.gazafatonarioit.com/2016/12/el-scrum-master-extraordinario.html