Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Experimentos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Experimentos. Mostrar todas las entradas

viernes, agosto 18, 2023

El poder de la experimentación: una travesía a través de Scrum e historias de usuarios

 

Luego de muchos desafíos he observado una constante: la transformación ágil es una travesía de descubrimiento. Es un camino cargado de preguntas, dudas y esa ansiedad que genera la experimentación. He recorrido este camino con personas, equipos y organizaciones, y una de esas revelaciones es que Scrum, combinado con Historias de Usuario y Desarrollo Conducido por Hipótesis (HDD), puede ser la brújula que nos guíe a través de los paisajes corporativos actuales.

La esencia de la experimentación

Hecho: la experimentación no se trata de fracaso o éxito. Se trata de aprender, adaptarse y mejorar, en el sentido de crecer. Se trata de desafiar las suposiciones y aceptar una realidad en constante cambio. En el corazón de Scrum, el proceso iterativo de inspección y adaptación es en sí mismo un experimento. Es una búsqueda de la verdad, pero también de la belleza y la excelencia.

La experimentación es un arte, pero, sobre todo, una ciencia. Es una filosofía que ha estado en el centro de mi trabajo durante más de una década. Pero ¿qué significa exactamente y por qué resuena tan profundamente en el mundo Ágil?

El proceso de descubrimiento. En el ámbito de Scrum, la experimentación no es simplemente una herramienta o un método; es una forma de pensar que impregna cada acción, decisión e interacción. Permite a los equipos navegar por esos horizontes complejos y en constante cambio de los negocios modernos.

Para experimentar, ten la voluntad de explorar. La experimentación comienza con la curiosidad. Se trata de preguntar, "¿Y si…?" ¿Y por qué no…?" Se trata de tener el valor de adentrarse en lo desconocido, desafiar el statu quo y sondear posibilidades sin un destino predeterminado.

Para experimentar, no le temas a la incertidumbre. Uno de los aspectos más viscerales y emocionales de la experimentación es su incertidumbre inherente. Hay un miedo y una sensación de asombro al no saber qué sucederá a continuación. Es esta incertidumbre la que alimenta la creatividad, la innovación y el crecimiento. Es por ello por lo que causa tanto temor hablar en voz alta de experimentos en los entornos organizacionales de hoy. Sigue siendo un tabú. Antes, era una herejía.

Experimentando, aprendes a través del fracaso. No voy a usar palabras bonitas. Que falla, que negación, que infortunio. No.  En mis años como coach, he visto equipos tropezar, flaquear y frustrarse. Pero también los he visto crecer, aprender y transformarse. La experimentación reconoce que el fracaso no es un callejón sin salida sino una encrucijada, un punto de reflexión, una lección que se debe acoger, que se debe dejar entrar en nuestra cultura organizacional. Es en estos momentos de fracaso cuando a menudo se produce el aprendizaje más profundo.

Experimentando continuamente, cimientas resiliencia. Es de esta manera que las personas y los equipos se vuelven más adaptables, más receptivos y más alineados con la naturaleza dinámica de su trabajo. Es un proceso que fomenta una cultura de confianza, colaboración y empoderamiento.

Frecuentemente me preguntan cómo fomento, cómo cultivo la experimentación. Aquí les dejo algunas notas:

  1. Colabora: involucra a todos. La diversidad de pensamiento es el caldo de cultivo de la innovación.
  2. Acepta el fracaso: este es una oportunidad de aprendizaje. Celébralo, analízalo, crece a partir de él.
  3. Haz preguntas: fomenta la curiosidad. Aviva una cultura en la que se celebre hacer preguntas.
  4. Itera: los experimentos pequeños y frecuentes permiten un aprendizaje y una adaptación rápidos.
  5. Reflexiona: Tómate el tiempo para reflexionar sobre los resultados. ¿Qué aprendiste? ¿Cómo lo aplicarás?
  6. Crea espacios seguros: permite errores. Crea un entorno en el que el fracaso se vea como una oportunidad, no como una amenaza.
  7. Celebra el aprendizaje: concéntrate en el viaje de aprendizaje, no solo en los resultados. Reconoce y recompensa el crecimiento y la comprensión.
  8. Comparte ideas: la transparencia fomenta la colaboración. Comparte hallazgos, ideas y reflexiones abiertamente dentro del equipo y la organización.

La esencia de la experimentación es algo rico y complejo que ha moldeado mi trabajo y la vida de aquellos a los que he acompañado. Es más que una técnica o un proceso; es una forma de ser, un camino que conduce a una comprensión más profunda de nosotros mismos, nuestro trabajo y nuestro mundo. Es el latido del corazón Ágil, y es lo que hace que nuestro trabajo no sea solo un trabajo, sino una pasión, una aventura y una celebración del potencial humano.

Puedes leer algo más sobre esto en:

http://www.gazafatonarioit.com/2022/01/no-cometas-los-mismos-errores.html

O en mi libro Cultura Ágil: ese oscuro objeto del deseo.

La técnica de desarrollo conducido por hipótesis (HDD)

Esta técnica es el núcleo de la experimentación. Con HDD, planteamos preguntas, diseñamos experimentos, analizamos resultados y tomamos decisiones.

Por ejemplo, considera un equipo que lucha con su compromiso de sprint. La hipótesis podría ser: "Al reducir la cantidad de Historias de Usuario en un 25 % en el próximo Sprint, mejoraremos la tasa de finalización en un 20 %". ¿El resultado? A veces funciona, y a veces no. Pero siempre, aprendemos. Incluso ya sabemos que, si aplicas patrones como El Clima de Ayer o Los Equipos que terminan más temprano aceleran más rápido, vas a aumentar tus probabilidades de tener éxito. Entonces dejará de ser un experimento y se convertirá en una práctica común a tu alrededor. Para saber más de estos patrones, puedes consultar el libro Scrum: epítome de experiencias o en mis blogs en:

http://www.gazafatonarioit.com/

O en:

https://luchosalazar.com/category/agilidad/

La técnica HDD no es simplemente un método, sino un enfoque filosófico para el desarrollo de productos y la resolución de problemas. He aquí un breve vistazo a sus elementos centrales y cómo ha llegado a influir en la forma en que trabajo con equipos y organizaciones.

Un enfoque científico. El corazón de HDD radica en tratar cada nueva idea, característica o cambio como un experimento. Adopta un enfoque científico en el que se formula una hipótesis y luego se diseña un experimento estructurado para probar esa hipótesis.

La hipótesis. Una hipótesis es una declaración bien elaborada que expresa una suposición que se va a probar. Por ejemplo, "Implementar la función Pagar Contra Entrega mejorará la participación del usuario en un 20 %". La belleza de este enfoque es su claridad y enfoque, que establece una meta y una métrica precisas para el éxito o el fracaso.

Diseña el Experimento. Dibujar el experimento implica planificar cómo se probará la hipótesis. Esto incluye definir las métricas, el público objetivo, las condiciones y los criterios de evaluación. Es una etapa crítica donde entran en juego la precisión, la previsión y la colaboración.

Ejecuta el experimento y aprende. Una vez que el experimento está diseñado, es hora de ejecutarlo. Esta etapa puede estar llena de anticipación, conmoción y, a veces, desasosiego. Los resultados pueden confirmar la hipótesis, refutarla o revelar ideas inesperadas. Independientemente del resultado, la atención se centra en el aprendizaje y la adaptación. Si no aprendes nada del experimento, quizás no era un experimento del todo.

Itera y adáptate. HDD no es un evento único sino un ciclo continuo. Cada experimento conduce a nuevos conocimientos, nuevas preguntas y nuevas hipótesis. Es un proceso dinámico y en evolución que se alinea perfectamente con la naturaleza iterativa y adaptativa de Ágil y Scrum.

Ahora bien, ¿por qué debería importarte HDD? Esta técnica ha sido transformadora en mi práctica. Aporta disciplina, claridad y un enfoque implacable en el aprendizaje. Alienta a las personas a pensar de manera crítica y sistémica, desafiar los supuestos y aceptar la naturaleza cambiante de su trabajo.

Historias de usuarios y la conexión humana

¡El poder de las historias de usuario!

Las historias de usuarios dan vida a nuestro trabajo. Son la voz de nuestros usuarios, el latido de nuestro producto. Pero también pueden ser un campo de juego para la experimentación. Recuerdo a un equipo que una vez tuvo el desafío de comprender las necesidades de sus clientes. Decidimos experimentar involucrando a los clientes directamente en la creación de Historias de Usuario. El compromiso, la empatía, los conocimientos que obtuvimos fueron transformadores. El producto prosperó, al igual que el equipo. De hecho, usamos Historias de Usuario Conducidas por Hipótesis para que cada nueva característica del producto, y el producto mismo, fueran considerados una hipótesis, un experimento en sí. Es de esta manera que empiezas a promover, aún sin mencionarlo, una cultura de experimentación en tu ámbito empresarial.

La belleza de las historias de usuario radica en su sencillez y humanidad. Sirven como puente entre los requisitos técnicos y las necesidades humanas reales, creando una conexión que impulsa el desarrollo significativo de productos.

El elemento humano. Las historias de usuario ponen al usuario en el foco del proceso de desarrollo de productos. No se trata de código, algoritmos o bases de datos; se trata de personas, emociones, experiencias. Infunden empatía en el desarrollo del producto, convirtiéndolo en un esfuerzo colaborativo y compasivo. Son una parte viva y palpitante del desarrollo ágil. Les ponen cara a las funciones, voz al código y corazón al producto. Al utilizar Historias de Usuario como base para los experimentos, no solo humanizamos el proceso, sino que también aportamos claridad, enfoque y empatía a nuestra búsqueda de innovación y excelencia.

En mi trabajo con diversos equipos y empresas, estas historias simples pero profundas a menudo han sido el catalizador de la creatividad, la colaboración y la conexión. Nos recuerdan que, en el centro de toda nuestra tecnología, procesos y métodos, siempre hay una persona, con necesidades, deseos y sueños. Conectar con ese elemento humano es lo que hace que nuestro trabajo no solo sea efectivo sino también significativo y satisfactorio.

No quiero extenderme más en este sentido. En mi blog puedes encontrar docenas de publicaciones sobre ello, incluyendo presentaciones, artículos y, por supuesto, el libro de la portada negra y naranja.

Pensamientos finales

Mi periplo ha sido uno de continua experimentación. Con cada fracaso, éxito y sorpresa, he aprendido, evolucionado y prosperado. Al menos, lo he intentado. Es una experiencia profundamente personal, llena de pasión, temor, alegría y resiliencia. Lo que he compartido no es solo un método o una técnica, sino una forma de vivir y trabajar. Se trata de ser humano y humanizante en un mundo de complejidad. Se trata de coraje, curiosidad y compasión. Y, sobre todo, se trata de la voluntad de experimentar, cuestionar y crecer.

Aquí tienes el próximo experimento y el siguiente paso en tu propio viaje. Auguro que será tan emocionante, esclarecedor y gratificante como todo lo anterior.

domingo, mayo 28, 2023

Inspirado: como crear productos de tecnología que tus clientes amen

Esta es la presentación de mi charla en el Lean Agile Summit, en Medellín este 27 de mayo de 2023. En ella brindé información sobre las prácticas y, sobre todo, los principios del enfoque exitoso de productos en empresas de tecnología y en otras con las que he trabajado a lo largo de mis 35 años de carrera profesional.

En particular, hablé de las Las causas fundamentales de los esfuerzos fallidos de producto, cómo nos pueden ayudar los enfoques Lean y Ágil en este proceso de Las 4D, descubrir, diseñar, desarrollar y distribuir productos que resuelvan la paradoja de las compañías que quieren tener éxito en el mundo convulsionado de hoy: quieren que sus clientes amen sus productos, pero no sabrán si esto es posible hasta tanto no pongan esos productos en manos de ellos.

También hablé de los principios de Lean Product Discovery y entrega frecuente y de mi tema favorito: personas. Detrás de cada gran producto hay una gran persona y, por extrapolación, un gran equipo. Principios de equipos de producto sólidos, sobre el líder de producto y el papel del liderazgo y, finalmente sobre la cultura sólida de producto que tienen las organizaciones brillantes. Por supuesto, fue tiempo para hablar de las Organizaciones B (Brillantes) y la triple restricción: estas son las empresas que no solo buscan el necesario y “sine qua non” beneficio financiero, sino también el beneficio social y ambiental. No podemos tener empresas sanas y, por consiguiente, productos sanos, en un planeta enfermo. Perentorio.

Al final, de mi libro Cultura ágil: ese oscuro objeto del deseo, mis tres leyes de la cultura:

1.    La ley del cambio

2.    La ley del lenguaje

3.    La ley del liderazgo cultural

No faltaron los consejos sobre cómo trabajar con equipos de diseño e ingeniería.

Fue un momento de compartir con amigos y colegas y un gran público que me acompañó atento durante la sesión. ¡Muchas gracias a todos!

Puedes descargar la presentación aquí: 👇

miércoles, febrero 16, 2022

Nuestro Scrum empírico de todos los días

Imagen tomada de Pixabay

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

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

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

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

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

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

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

La realidad del Scrum que haces

Photo by Yan Krukov from Pexels
Todo el tiempo escuchas decir:

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

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

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

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

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

Te haré otras preguntas:

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

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

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

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

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

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

Algo del Scrum que deberías estar haciendo

Photo by fauxels from Pexels

¿Y por qué todo este cuestionamiento?

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

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

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

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

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

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

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

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

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

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

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

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

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

Quieres saber más

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

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

Mientras tanto:

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

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

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

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

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


viernes, enero 28, 2022

No cometas los mismos errores

Imagen tomada de Pixabay
Esta simple e inocente expresión que quisiera complementar con: “habiendo tantos nuevos por hacer” (No cometas los mismos errores habiendo tantos nuevos por hacer), es uno de mis mantras ágiles, hace parte del pensamiento ágil y lean que conduce mi comportamiento personal y profesional.

Sé que, si lo digo así, de esta manera tan escueta, es difícil de entender, así que trataré de explicarlo en las siguientes mil palabras… o menos.

Casi todos los equipos y empresas que conozco juegan a “lo seguro”. Se mueven como pez en el agua en su zona más confortable, usando técnicas de gestión y de ejecución y herramientas que no los desafían a ir más allá de lo necesario. Se pasean por los pasillos de una cultura donde no florecen ideas novedosas, así que, a lo sumo, alcanzan a equivocarse con errores ampliamente conocidos y miden su éxito de mejora con la velocidad a la que resuelven esos impases.

Me viene a la mente esta reflexión de Donald Rumsfeld, exsecretario de Defensa de Estados Unidos: Hay cosas conocidas que sabemos; son cosas que sabemos que sabemos. Hay cosas conocidas que desconocemos; se trata de cosas que no sabemos que sabemos. Pero también hay cosas desconocidas que desconocemos, cosas que ni siquiera sabemos que no sabemos.

Pues bien, estas empresas de las que hablo se agrupan en los dos primeros estados. Saben lo que saben, son hechos y son conscientes. Saben lo que no saben, saben que son cuestiones no respondidas, pero que tienen respuestas y están a su alcance. Incluso algunas no saben lo que saben, intuiciones; es lo que flota en algún limbo entre la consciencia e inconsciencia empresarial y que en algún instante se hará evidente. Todas estas organizaciones tampoco están conscientes de que la velocidad de cambio en su entorno es vertiginosa, mucho mayor que la velocidad de cambio en su interior. Y esta dolencia es sinónimo de extinción.

Entra la cultura de experimentación

Imagen tomada de Pixabay
Entonces, ¿cómo ir más allá? ¿Cómo provocar esa sacudida en el pensamiento de los líderes actuales? ¿Cómo ir a ese terreno inexplorado que supone lo que no sabemos que no sabemos? Los practicantes ágiles hemos encontrado una respuesta a estas preguntas: interiorizar, practicar y promover una cultura de experimentación.

Esencialmente, una cultura de experimentación implica implementar nuevas ideas o soluciones en la empresa, sin restringirlo solo a ciertas áreas.  Hago énfasis en lo de “restringirlo” porque hoy por hoy, los así llamados y recién instaurados laboratorios de innovación o centros de experimentación se están convirtiendo en una isla más en la organización. Un lugar, físico o virtual, al que solo ingresan algunos “privilegiados” de la empresa en tiempos de cambio.

La experimentación debe adoptarse en toda la empresa y los líderes junto con la alta dirección deben tener una mentalidad que promulgue e incentive la búsqueda de ideas en todas las personas que hacen parte del entorno corporativo. Es un hecho, las buenas organizaciones tienen personas y equipos con una fuerte convicción sobre el logro de objetivos y ejecutan iniciativas de una manera equilibrada; pero una organización virtuosa agrega la dimensión de una cultura de experimentación consistente.

Como siempre, la falla es un imperativo, es una condición sine qua non una cultura de experimentación se establece y arraiga en la empresa. Sin experimentar y errar en algunas acciones, iniciativas, incluso proyectos, no será posible encontrar las mejores ideas que posibiliten dar nuevos, grandes y concretos saltos a la organización, para entrar otra vez en el mercado ampliamente volátil y competitivo actual.

Una cultura de experimentación reta el statu quo organizacional y, a no ser que las empresas aprendan a desafiar sus formas actuales de pensar, no podrán sobrevivir. Perentorio.

La experimentación es dolorosa al comienzo. Saber que la mitad o más de nuestras hipótesis fallarán, no es algo que aliente a muchos en la empresa, mucho menos a la alta dirección. Pero es un paso necesario en la evolución corporativa hacia dejar una huella más profunda en los clientes y consumidores y hacia el logro de ese propósito superior que toda organización virtuosa ambiciona hoy. Aumentar el número de experimentos por unidad de tiempo, a lo Jeff Bezos, es una manera de salirle al paso a este dolor. Y es que las empresas exitosas prueban muchas ideas cada día, cada semana.

Cómo empezar a adoptar una cultura de experimentación

Imagen tomada de Pixabay
Estamos hablado de cultura. No cambiamos la cultura de un equipo, mucho menos de una organización en poco tiempo. Es una tarea titánica. De hecho, intentar cambiar la cultura organizacional es algo que raya en lo imposible. Lo que hacemos es apropiarnos de, empezar a practicar y a incentivar comportamientos inéditos, originales, que a la postre den como resultado el cambio cultural que queremos. De manera paralela, desincentivamos poco a poco comportamientos que nos hagan arraigar en la cultura actual.

Para este caso en particular, algunos comportamientos siembran la semilla de la experimentación en la empresa:

Invita a todos en la organización, incluso en el ecosistema empresarial. La experimentación la hacemos las personas y es para las personas. La gran mayoría de laboratorios de innovación que he visto son un ejemplo de lo que no debe ocurrir. Apenas si alcanzan a ser una bodega más en las selvas corporativas de la actualidad. La inteligencia colectiva y la diversidad de perspectivas son algunas de las mejores formas de enfrentar los escenarios complejos inherentes al trabajo que hacemos día a día; y se constituyen en pilares esenciales de la generación de nuevas ideas a probar.

Fomenta nuevas iniciativas por doquier. Grita a los cuatros vientos, hasta los extramuros de la empresa, que estamos bajo un manto seguro para fallar. Algo así como el manto de la invisibilidad de Harry Potter, una reliquia de la experimentación y la alquimia. Incentiva el nacimiento de hipótesis, premia los experimentos realizados, sin importar el resultado, siempre que haya aprendizaje para el equipo y la organización.

Motiva a las personas a mantenerse hambrientas, al menor estilo de Steve Jobs y su ya muy famoso y recordado “Mantente hambriento, mantente alocado”. Si empiezas a institucionalizar muy rápido estarás erigiendo paredes infranqueables para una cultura de experimentación. Es una vía rápida a la cultura del “siempre lo hemos hecho así”. Y de allí, al estancamiento solo hay unos pequeños pasos. Es definitivo, erradica todos los “talla única” de tu empresa; es decir, un único proceso para todo, una única forma de hacer las cosas, una sola práctica para todo, etcétera.

¿Ves que todavía hay mucho espacio para cometer errores? El trabajo es cuesta arriba, pero vale la pena escalar la montaña. Casi siempre la vista desde arriba es fantástica.

¿Y tú, qué estás haciendo para impregnar una cultura de experimentación en tu equipo y en tu empresa? Por favor, déjamelo saber en el foro.

martes, enero 11, 2022

Cinco formas de mejorar tu desempeño con historias de usuario

 

Imagen tomada de Pixabay

Las historias de usuario no son para escribirlas

La pregunta que debes hacer no es “¿cómo escribir mejores historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las historias de usuario son un instrumento de comunicación social y sabemos que la forma más efectiva de comunicar información es la conversación, ojalá cara a cara. La forma más efectiva de evolucionar las historias de usuario es vía conversaciones, primero entre los usuarios e interesados y el Product Owner y luego, entre este y los miembros del equipo.

Puedes leer mi artículo Las historias de usuario como instrumentos de negociación para saber más sobre este tema. Clic aquí para leerlo.

Las historias de usuario te ayudan a encontrar tu por qué

Las historias de usuario son una herramienta para iniciar el descubrimiento del producto con el usuario, consumidor o cliente, no es para finalizarlo. De esta manera, tanto el Product Owner, como los desarrolladores (quienes hacen el trabajo finalmente) deberían ver las historias de usuario como algo que describe el por qué están haciendo lo que hacen, no precisamente qué están haciendo. Como siempre, si un usuario no estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario, estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras imaginadas”.

Conoce a los usuarios

Por eso, mi primerísima recomendación, concisa, si eres responsable de las historias de usuario, es: habla con las personas que tienen la necesidad, el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un conocimiento profundo y empático del usuario o consumidor: quién es, qué hace, con quién lo hace, qué información intercambia y cómo lo hace, son algunas de las cuestiones a escudriñar si quieres tener éxito con historias de usuario.

En mi artículo Qué hay de "usuario" en las historias de usuario profundizo sobre este asunto. Clic aquí para leerlo.

Las historias de usuario y el product backlog

Una historia de usuario no está sola, aislada del resto del producto. Así que es importante pensar sobre ella como un componente de primer orden del product backlog. Y en este punto, es de mucha importancia considerar la transparencia del backlog. Recordemos que transparencia significa que todos los interesados, usuarios y equipo comparten el mismo significado de las cosas, por ejemplo, qué significa que algo está terminado.

Las cosas así, las historias de usuario deben ser transparentes y estar disponibles para todos los interesados, para que estos tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué. En particular, resuelve preguntas como:

- ¿Los interesados saben cómo acceder a las historias de usuario?

- Cuando acceden a las historias de usuario, ¿el contenido los ilustrará o los confundirá?

En mi artículo El extraño caso de las historias de usuario técnicas pongo de manifiesto que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí para leer el artículo. Este otro artículo también te puede dar ideas al respecto: Buenas y “malas” historias de usuario. Clic aquí para leerlo.

Desarrollo de producto dirigido por hipótesis y experimentos

Las historias de usuario son hipótesis. Trátalas como tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente: supuestos o conjeturas. En este apartado entran en escena las entregas tempranas y frecuentes y, sobre todo, la retroalimentación directa que logres de los clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que solo tienes algunas horas para implementarlas o construirlas, hasta unos muy pocos días, dos o tres a lo sumo.

En este apartado, una anotación especial para desarrolladores de software: si todavía te encuentras con el escenario de “mini cascadas”, es decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo” prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas. No te imaginas cómo sufren los analistas de prueba mientras esperan a que desarrollo les entregue las historias para empezar a probar cuando el final del sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización, entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo. Por eso hago toda esta recomendación especial.

Quieres saber más

Estos y otros temas de interés hacen parte de mi curso de historias de usuario. En febrero estaré facilitando una nueva edición del curso. Toda la información en https://bit.ly/cursohu.


domingo, febrero 02, 2020

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.

miércoles, julio 17, 2019

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:

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:

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.