Buscar en Gazafatonario IT

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

miércoles, octubre 04, 2023

El TAO de la Experimentación: del caos a la evolución organizacional

 

Una de las conversaciones más extensas que sostuve en el más reciente Ágiles Latinoamérica en Lima, Perú, trató sobre experimentar en las organizaciones, a raíz de una charla de Jorge Abad sobre Liderazgo Digital, donde él preguntaba a los asistentes sobre el número de experimentos en el último mes: solo 2 o 3 personas mencionaron que 1. Un número irrisorio por demás que deja mucho que desear para empresas que están en la senda de la transformación digital. Y, sin embargo, muchísimo más que el resto de las empresas representadas en la sesión, cuyo número de experimentos simplemente es un vacío cero.

Mi crítica no se hizo esperar a la salida. Les contaba a mis amigos peruanos cómo Booking.com realiza más de 1.000 pruebas rigurosas simultáneamente y, según estimaciones, más de 25.000 pruebas al año. En cualquier momento dado, millones de miles de millones de permutaciones de páginas de destino activas, lo que hace prácticamente improbable que dos clientes en la misma ubicación vean la misma versión. Este nivel de experimentación ha ayudado a transformar la empresa de una pequeña empresa emergente holandesa a la plataforma de alojamiento en línea más grande del mundo en menos de dos décadas.

Les prometí finalmente que iba a escribir más sobre ello y aquí estoy.

Y es que experimentar, en el sentido amplio del concepto, no es solo un método. Es un estilo de vida. En mi era ágil como coach ágil, me di cuenta de que cada organización, cada equipo y cada individuo poseen un universo de potencial. Pero para aprovecharlo, debemos fomentar una cultura de experimentación.

Primero hablemos de las razones por las cuales no experimentamos:

1. Experimentación vs. Miedo al Fracaso

Durante mis primeros años como coach ágil, me encontré con equipos tan paralizados por el miedo al fracaso que dudaban en probar algo nuevo. Estaban practicando Scrum, pero sentía que estaban "haciendo ágil" en lugar de "ser ágiles". A uno de ellos, en particular, les propuse un desafío: en cada retrospectiva, llevaríamos a cabo un experimento. ¿Los resultados? Asombrosos. Cuanto más experimentaban, más aprendían. Y con cada experimento, el miedo al fracaso disminuía. Al celebrar los fracasos tanto como los éxitos, transformamos ese miedo en combustible para el crecimiento.

2. Generación y Validación de Hipótesis

Trabajando con el sector financiero siempre me encuentro con vacilaciones, dado el alto nivel de aprehensión por la seguridad, la regulación y la gestión de riesgos, que son aspectos cruciales en esta industria. En una ocasión, un equipo estaba interesado en integrar una nueva funcionalidad, pero a su vez estaba inseguro sobre su recepción. En lugar de hacer suposiciones, generamos una hipótesis: "Creemos que, al agregar la Función X, podemos aumentar la participación de los usuarios en un 15 % durante el próximo trimestre". Lanzamos un producto mínimo viable (MVP) y lo probamos. Los resultados no fueron los que esperábamos, pero las percepciones que obtuvimos fueron invaluables. Este enfoque iterativo de generar y validar hipótesis se convirtió en el corazón de su desarrollo de producto.

3. Aprendiendo del Fracaso: la esencia del crecimiento

Una vez guie a una organización a través de una transformación ágil a gran escala. Enfrentamos desafíos en cada esquina, desde la resistencia al cambio hasta malentendidos sobre ágil. En lugar de ver estos como obstáculos, vimos cada desafío como un experimento. Con cada "fracaso", recopilamos datos, adaptamos nuestro enfoque y avanzamos con una comprensión aún mayor. Fue en estos momentos de adversidad donde ocurrió el crecimiento más profundo.

La esencia de la experimentación en las organizaciones

La experimentación es ese gen de una práctica deliberada de probar nuevas ideas, procesos o productos de manera controlada para determinar su viabilidad o valor. En general implica establecer hipótesis sobre los cambios que podrían lograr y luego probar esos cambios en un entorno real, a menudo a pequeña escala inicialmente, para validar o refutar esas hipótesis.

Si fomentas una cultura de Experimentación, tienes:

1.  Innovación: la experimentación fomenta la creatividad y las nuevas ideas, impulsando la innovación dentro de la organización.

2. Gestión de Riesgos: al probar cambios a menor escala, las organizaciones pueden evaluar resultados antes de una implementación a gran escala, reduciendo pérdidas potenciales.

3. Decisiones basadas en datos: la experimentación conduce a conclusiones basadas en evidencia, permitiendo una toma de decisiones más informada.

4. Adaptabilidad: las organizaciones que experimentan regularmente pueden adaptarse más rápidamente a las condiciones cambiantes del mercado o las necesidades del cliente.

5.  Mejora Continua: las pruebas y refinamientos regulares conducen a mejoras constantes en productos, servicios y procesos.

6.  Compromiso de los colaboradores: una cultura que valora la experimentación a menudo empodera a sus empleados, lo que lleva a un mayor compromiso y satisfacción.

Es un hecho, una mentalidad de "todo es una prueba" produce beneficios sorprendentemente grandes y competitivos, e incluso puede ayudar al desempeño de las acciones en el mercado. O si no preguntémosle a Google, Amazon, Nike, Amazon o al mismo Booking que ya mencioné.

Por el contrario, si no fomentas una cultura de experimentación, consigues:

1.     Estancamiento: las empresas podrían perderse ideas innovadoras o nuevos modelos de negocio que podrían impulsarlas por delante de la competencia.

2.    Oportunidades desaprovechadas: Sin experimentar, las empresas pueden pasar por alto posibles fuentes de ingresos o segmentos de clientes.

3.    Resiliencia reducida: las empresas que no experimentan y aprenden de esos experimentos podrían ser menos adaptables a interrupciones o cambios en el mercado.

4.  Dependencia de suposiciones: sin pruebas en el mundo real, las empresas basan las decisiones en suposiciones en lugar de datos, lo que puede llevar a costosos errores.

Pero, ojo, si no lo haces bien puedes caer en el lodo de:

1.  Parálisis por Análisis: demasiada experimentación sin objetivos claros puede llevar a indecisiones o retrasos en la implementación de productos/servicios.

2. Drenaje de recursos: la experimentación continua puede consumir recursos significativos, especialmente si no se hace de manera eficiente.

3.   Confusión potencial: si no se comunica bien, los cambios y pruebas frecuentes pueden confundir tanto a colaboradores como a clientes, principalmente a estos últimos.

4.   Miedo al fracaso: aunque una cultura de experimentación tiene como objetivo abrazar el fracaso como una oportunidad de aprendizaje, no todos los colaboradores o interesados pueden verlo de esa manera, lo que podría llevar a una reducción de la moral o confianza.

5.   Énfasis excesivo en resultados a corto plazo: existe el riesgo de que las empresas se concentren demasiado en los resultados de los experimentos a corto plazo en detrimento de los objetivos estratégicos a largo plazo.

Además de Booking, estas otras empresas lo hacen bien:

Google es conocido por su cultura de experimentación. Sin embargo, la tasa de éxito puede ser bastante baja. Por ejemplo, en Google y Bing, entre el 10 % y el 20 % de los experimentos controlados generan resultados positivos.

Amazon es otra empresa que depende en gran medida de la experimentación para la innovación y el crecimiento, pero no encontré una fuente confiable que me hablara de la tasa de éxito o fracaso de estos.

La unidad Bing de Microsoft ha descubierto que los experimentos en línea cambian las reglas del juego. Han ayudado a Bing a realizar docenas de mejoras mensuales, que en conjunto han aumentado los ingresos por búsqueda entre un 10 % y un 25 % al año.

Nike es otra empresa que realiza experimentos para impulsar la innovación. Tampoco pude encontrar la tasa de éxito exacta.

Para concluir,

Experimentar no se trata de acertar siempre. Se trata de crear un ambiente seguro para probar, aprender y crecer. Cuando cambiamos nuestra mentalidad de temer a los errores a valorarlos como oportunidades de aprendizaje, desbloqueamos un mundo de potencial.

La experimentación en las organizaciones es una espada de doble filo. Cuando se hace correctamente, puede llevar a la innovación, adaptabilidad y mejora continua. Pero, sin objetivos claros, comunicación y un equilibrio entre resultados a corto plazo y objetivos a largo plazo, también puede presentar desafíos. Es vital que las empresas encuentren el equilibrio adecuado y se aseguren de fomentar una cultura de experimentación que realmente las beneficie.

Y mientras preparo una segunda parte de este capítulo sobre experimentación, no dejes de contarnos en el foro cómo lo estás haciendo en tu empresa.

Algunas referencias

Building a Culture of Experimentation, by Stefan Thomke

https://hbr.org/2020/03/building-a-culture-of-experimentation

 

The Secret Behind Successful Corporate Transformations

by Paul A. Argenti, Jenifer Berman, Ryan Calsbeek, and Andrew Whitehouse

https://hbr.org/2021/09/the-secret-behind-successful-corporate-transformations

 

A Harvard Business School professor on how companies like Google and Amazon use experimentation to innovate, grow, and improve, by Stefan H. Thomke

https://www.businessinsider.com/harvard-business-professor-on-companies-using-experimentation-2020-2

jueves, mayo 25, 2017

Generación de Valor con Scrum

El pensamiento Ágil llegó para quedarse. Se trata de un enfoque caracterizado por el trabajo colaborativo, las entregas de producto con Valor tempranas y frecuentes, el mejoramiento continuo y las continuas inspección y adaptación a los cambios que se suscitan en el entorno. 
Scrum es hoy el marco de trabajo Ágil más ampliamente usado porque es un instrumento que nos conduce hábilmente por el camino de la Agilidad, nos permite aumentar la productividad y la calidad de lo que hacemos a la vez que obtener retroalimentación sucesiva de los consumidores finales. 
En esta presentación revisaremos como con el marco de trabajo Scrum se puede generar Valor de manera temprana y frecuente durante los esfuerzos de desarrollo de nuevos productos.
Descarga la presentación a continuación y déjanos conocer tus pensamientos e inquietudes al respecto en el foro:


miércoles, marzo 29, 2017

Guía Supernumeraria para un Dueño de Producto Virtuoso


El Dueño de Producto es un nuevo rol para muchas, en realidad para la gran mayoría de las compañías. Y de estas, un gran conjunto no lo entiende o simplemente no ha tenido las mejores experiencias con sus responsabilidades. En términos generales, el Dueño de Producto es un ilustre olvidado.
Mientras que la promesa de un equipo de TI es diseñar y construir el mejor producto o servicio que el negocio necesita, una solución con Valor, dadas las restricciones de tiempo, presupuesto, tecnología, entre otras, la promesa de un Dueño de Producto es trabajar con el equipo en la priorización y negociación de características del producto, lograr no solo que el equipo de desarrollo aprenda del negocio sino de lo que significa Valor para el negocio.
La proposición de valor del Dueño de Producto también incluye mantener al equipo motivado y contribuir desde su posición a que se cumplan los compromisos con los usuarios o consumidores que él mismo representa. También, mientras la organización confía en la mentalidad Ágil del equipo y del Scrum Master para mantener la alineación con las áreas de TI, delega en el Dueño de Producto la responsabilidad de mejorar los tiempos de salida al mercado a la vez que optimizar el retorno de la inversión.
El Dueño de Producto es precisamente el dueño de la visión del producto, el plan del negocio, las ganancias, el plan de entregas y de un backlog de producto cuidadosamente refinado y priorizado con precisión para que el equipo pueda trabajar sin tropiezos. Mientras el trabajo del equipo es construir correctamente el producto, el Dueño de Producto debe entregar el producto correcto. ¡Es un juego de palabras, pero es verdad!
El Dueño de Producto es o será el encargado de devolver el encanto que muchos usuarios, socios y empleados perdieron en el pasado a raíz de las soluciones de TI disfuncionales que estábamos produciendo. Eran soluciones con muy poco o ningún sentido de la calidad, tardaban años en llegar al mercado y carecían de la innovación necesaria para resolver problemas reales del negocio. Las cosas así, la responsabilidad moral de un Dueño de Producto es una carga pesada que todos en la Organización tenemos obligación de ayudar a soportar mediante el apoyo incondicional a su trabajo.
Scrum en particular y el enfoque Ágil en general proporcionan las herramientas suficientes para que el Dueño de Producto cumpla con sus responsabilidades de manera decidida y franca, para conectar efectivamente los deseos y necesidades de los usuarios y el negocio con el equipo de desarrollo, de forma dinámica y receptiva.
En su libro “Agile Product Management with Scrum”, Roman Pichler describe ampliamente las principales actividades que un Dueño de Producto de talante realiza:
Definir y manejar la Visión del Producto

Una visión efectiva del producto responde o debería responder a las siguientes cuestiones:
  • ¿Quién comprará o usará el producto? ¿Quién es el consumidor o usuario final?
  • ¿Qué necesidades cubrirá el producto? ¿Qué valor agrega el producto al usuario o a la organización?
  • ¿Cuáles son los atributos críticos del producto para que este sea exitoso?
  • ¿Cómo y qué tantas ganancias tendrá la compañía con el producto?
Entre otras no menos importantes. En resumen, la visión debería comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que conduzca la creación del producto pero que sea lo suficientemente amplio como para facilitar la creatividad del equipo que lo desarrollará.
Un aspecto importante a considerar aquí es el conocido como el Mínimo Producto Viable (MVP) o, a veces, el Mínimo Producto Mercadeable. Este es un producto con la mínima funcionalidad que cubra algunas de las necesidades básicas de los usuarios y genere valor a la organización. Un Dueño de Producto hábil sabe que el producto debe estar en funcionamiento muy pronto y que este debe entregarse en pequeños incrementos en cortos lapsos de tiempo. Esto reduce la incertidumbre y aumenta el aprendizaje no solo sobre el producto sino sobre los hábitos de consumo de sus usuarios finales.
Para saber más sobre cómo crear la Visión del Producto, pueden ver este Webinar sobre Inception Ágil que facilité con mi gran amigo Jorge Abad:
Es prácticamente imposible, por no decir menos, establecer una visión del producto apropiada sin tener en cuenta el factor humano. En otras palabras, definir una correcta visión del producto es un acto puramente humano.
Trabajar con el backlog de Producto

Este artefacto hermosamente simple sufre muchas veces de la falta de atención apropiada tanto por parte del Dueño de Producto como del mismo equipo de desarrollo.
Para quienes no están familiarizados con la herramienta, es una lista priorizada de los elementos necesarios para darle vida al producto. Estos elementos incluyen la exploración de las necesidades de los usuarios, pero también puede incluir una descripción de opciones técnicas y de requisitos funcionales y no funcionales, así como el trabajo necesario para poner a punto los distintos ambientes de trabajo.
Uno de los aspectos más importantes que debe estar en el radar del Dueño de Producto es este del Valor de cada uno de los elementos del backlog. El valor es un factor común de priorización de sus elementos. El Dueño de Producto sabe que debe entregar primero los elementos de mayor valor. Al agregar nuevos elementos, el Dueño de Producto no solo revisa o establece el valor de estos nuevos elementos sino que reexamina el valor de los existentes.
También hemos aprendido que un Dueño de Producto experimentado va adelante del equipo en cuanto al conocimiento detallado que tiene de los elementos del producto. Quizás uno o dos sprints más allá del actual y está continuamente practicando refinamiento al producto.
Para profundizar más en estos asuntos pueden leer mis artículos:
Sobre gestión del producto en general, en el que abordo cuáles son los atributos (DEEP) de un buen backlog de producto:
Sobre refinamiento del producto en particular:
Planear las entregas

En su libro Agile Estimating and Planning, el gran Mike Cohn escribió que “Planificar... es una búsqueda de valor”. Otra vez emerge el Valor como factor determinante a la hora de planear las entregas de un producto. También hemos aprendido que este plan de entregas no puede ir encadenado a las aristas de tiempo, costo y alcance de manera fija e inquebrantable. Es posible adherirse a una de ellas, quizás a dos, pero no a las tres en simultáneo.
Otra vez: la meta principal de todo Dueño de Producto es entregar el producto correcto. De allí que la planificación de esta entrega de producto, en pequeñas entregas incrementales es una tarea fundamental de todo Dueño de Producto hábil. Sobre este asunto en particular pueden leer mi artículo:
En donde agrego el atributo de Valor a las ya ampliamente difundidas bases de Ágil y propongo El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor.
Colaborar con las Reuniones del Sprint

¡Scrum!

Las reuniones son oportunidades de Conversación cara a cara y, en el caso específico de Scrum, son momentos propicios para la inspección y adaptación, pilares fundamentales de la mentalidad Ágil. Y el Dueño de Producto hace parte del equipo Scrum, así que bienvenido su aporte estratégico y táctico al equipo durante estas conversaciones.
Para saber más sobre los distintos eventos en Scrum pueden ir a mi Gazafatonario:

En conclusión, el Dueño de Producto es uno de los ejes fundamentales sobre los cuales avanzan los equipos Scrum como un todo hacia la búsqueda de un objetivo común: la generación de valor a la vez que responder al cambio de manera eficiente. En particular, el Dueño de Producto se constituye en una arista esencial para la correcta gestión ágil del producto pero sobre todo para entregar productos cuyos componentes generen resonancia entre ellos e impacten el modus vivendi de sus consumidores, nosotros la humanidad.

Puedes descargar la presentación complementaria del siguiente enlace:

lunes, noviembre 28, 2016

Las historias de usuario como instrumentos de negociación


Hablemos un poco de ese continuum que significa diseñar y construir soluciones de valor para una organización. Las organizaciones hoy día están hechas de software, el software está en todas partes y si de construir software se trata, los equipos ágiles tenemos algo que decir.
De los incontables utensilios que contamos en nuestra mesa de trabajo las historias de usuario están siempre a la vista de quienes transitamos por los senderos de los problemas complejos y las soluciones para ellos. Para nosotros, trabajar en soluciones mejora la comprensión de los problemas. Esta es posiblemente la razón principal por la cual los enfoques iterativo e incremental son mejores que cualquier otro en la actualidad. Y si los combinamos, mucho mejor. Los Agilistas fantásticos:
1.     Construimos de manera iterativa para minimizar el riesgo
2.    Construimos de manera incremental para maximizar el retorno de la inversión (ROI)
3.    ¡Repetimos  1 y 2 hasta la saciedad! O hasta que se esté generando el suficiente valor como para detener nuestro esfuerzo de desarrollo.
En ese camino hemos aprendido que los problemas no son subjetivos. Lo subjetivo es la percepción que tengamos de esos problemas. En general estos se basan en la realidad. Además, los enfoques de pensamiento, nuestro mindset, pueden llegar a redefinir esos problemas por completo.
Ya sabemos que una historia de usuario no es un contrato firmado en piedra, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. También son cartas de negociación entre unos y otros, pero solo habrá una negociación fluida si el usuario está realmente interesado en el éxito del esfuerzo de desarrollo, si está dispuesto a comunicarse de manera efectiva y a trabajar con y como parte del equipo.
Los ingredientes clave de una historia de usuario son: quién es el usuario, qué quiere hacer el usuario y por qué lo necesita. Contrario a lo que mucha gente cree, las personas (usuarios o consumidores finales, expertos con el conocimiento, interesados, patrocinadores y otras personas impactadas por la historia), constituyen lo más importante de una historia de usuario. Esto permite o posibilita la comunicación para que hagamos las cosas correctas y nos ayuda a identificar el valor para priorizar lo que haremos primero y lo que haremos más adelante.
La parte “conversación” de una historia de usuario idealmente es una colaboración entre el usuario y el equipo que construye la solución, es una asociación para entender el problema y trabajar precisamente en una solución que resuelva ese problema y también permite confirmar más adelante que esa solución de hecho resuelve el problema adecuadamente.
Las historias de usuario proporcionan un entorno, un medio para adaptarnos, para buscar oportunidades. Si encontramos un obstáculo que no es posible sortear, siempre podemos buscar otra historia relacionada que nos permita avanzar. Es posible que, al hacerlo, encontremos la solución a la historia que no nos permitía progresar en principio y podemos volver a ella.
Ahora bien, si esa carta de intención, esa necesidad que tiene el usuario, es muy específica, la tarea del equipo es preguntar “¿por qué?” ¿Por qué y para qué se necesita esa historia?; en cambio, si es muy abstracta, preguntaremos “¿cómo?” ¿Cómo lo hace? ¿Cómo quiere o quisiera la solución? Las historias de usuario siempre son sobre “negociación” si queremos un buen balance entre costo y valor.
En general, las historias de usuario nos permiten a los Agilistas fantásticos:
1.     Lograr este balance en pequeños alcances,
2.    Construir la solución, o los incrementos de esta, de tal manera que podamos obtener una efectiva retroalimentación anticipada.
3.    Trabajar en los aspectos de más valor primero para que sean entregados y empiecen a generar ROI lo más pronto posible.
Finalmente, ninguna discusión o exposición sobre historias de usuario estaría completa si no incluimos la palabra “confianza”. Si la confianza es poca en un equipo Scrum, las historias de usuario se convertirán muy pronto en piezas muy concretas de descripciones de problemas que el Dueño de Producto le entregará al equipo de desarrollo y que quizás nadie querrá resolver. Si esto ocurre, seguramente el equipo de desarrollo también va a solicitar, con grado de exigencia, unos criterios de aceptación muy concretos. El resultado: el muy pesado, extenso y falto de humanidad documento de especificación de requisitos funcionales y no funcionales del pasado, el mismo que cargaba consigo el sinsabor de la frustración y la derrota.
Entonces, para que positivamente las historias de usuario sean una herramienta auténtica de negociación entre las áreas de TI y las del negocio y para que sean una representación de los problemas de este último y de las soluciones que puedan proporcionar los primeros, es necesario que en el ambiente haya un alto grado de confianza. El Equipo Scrum en pleno, e incluso los interesados del entorno, tienen que conformar un equipo propiamente dicho, donde el trabajo colaborativo, la adaptación, el mejoramiento continuo y la entrega continua de valor sirvan de pilares y de integradores entre sus miembros para que todo lo anterior sea posible.