Buscar en Gazafatonario IT

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.

viernes, enero 21, 2022

Plantilla en Mural para el User Story Conversation Canvas


Las buenas historias de usuario estimulan, en el buen sentido, la conversación entre los involucrados (por ejemplo, Dueño de Producto y miembros del equipo). Además, las historias de usuario ven, o dejan ver, la funcionalidad desde la perspectiva del negocio, específicamente desde el Valor que la historia proporciona al negocio.

Como su nombre lo indica, este User Story Conversation Canvas es un medio de comunicación, un instrumento para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. En el fondo, es una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.

Con este lienzo cualquier persona involucrada, el Dueño de Producto, el equipo en pleno o solo un miembro de este, el Scrum Master, incluso un usuario, puede encontrar la ayuda que necesita para describir adecuadamente los aspectos más relevantes de una historia de usuario, desde las personas que están o se verán involucradas durante la definición, evolución, desarrollo y puesta en marcha de la historia, hasta el resultado esperado y las métricas asociadas a la historia, pasando por el contexto de la misma. Pero, sobre todo, podrá encontrar el soporte que necesita para preparar conversaciones fantásticas sobre los elementos que componen el producto.

Las sesiones de refinamiento, la planificación y la revisión son tres de los escenarios principales donde podemos usar este Lienzo para Conversar Sobre Historias de Usuario. Pero se puede usar en muchas otras circunstancias: el dueño de producto hablando con los usuarios y otros interesados, los miembros del equipo de desarrollo, para acordar y sincronizar el trabajo a realizar, el Scrum Master y el Dueño de Producto, en conversaciones alrededor del producto, del backlog, al aplicar patrones para dividir las historias, entre otros escenarios.

¡Cuando se trata de historias de usuario, el énfasis es en la Conversación!

Para saber más sobre Historias de Usuario, los criterios INVEST de las historias y otros aspectos no menos relevantes sobre el tema, puedes visitar mi serie de artículos “Historias de usuario altamente efectivas” en mi Gazafatonariohttp://bit.ly/lashistoriasdelucho.

Descarga el lienzo y la guía completa en alta definición aquí:

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

Y para estos tiempos de trabajo virtual he desarrollado esta plantilla en Mural para que puedas trabajar de manera colaborativa con historias de usuario y con el lienzo para conversar sobre historias de usuario. Para ir a la plantilla, haz clic en el siguiente enlace o ve a la parte superior de la imagen que sigue y toca en "start from template" o en el icono de Mural.

https://app.mural.co/template/a233e5bd-6759-4c89-98bc-de1add6230b6/48d04f21-51a0-4175-bcd7-4ced17c633b8


lunes, enero 17, 2022

Cómo ayudar a tu equipo a mejorar su Daily Scrum

Imagen tomada de Pixabay
La guía de Scrum es cada vez menos prescriptiva para ser más inclusiva, es decir, para que la usen más tipos de personas, de equipos y de organizaciones. Hoy por hoy, Scrum se usa en casi cualquier rincón de la empresa y de la sociedad, entonces es aconsejable que se aleje de lo que la hacía más allegada al mundo del desarrollo de software. Con esto en mente, es importante dejar claro que si un lineamiento o una sugerencia ya no está en la guía no significa que era una mala práctica o algo equivocado. De ninguna manera.

Uno de los ejemplos más visibles de esta situación es el de las famosas y muchas veces poco entendidas “tres preguntas” de la Daily Scrum o reunión diaria. Las tres preguntas pasaron de ser una regla del juego Scrum en versiones previas de la guía, a ser “un ejemplo de lo que podría usarse” (durante la reunión) en la edición de 2017, a desaparecer por completo en la última edición de 2020.

Sin embargo, ello no quiere decir que no puedan seguirse usando para “inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario”, de acuerdo con la guía 2020. En cualquier caso, la conversación o la discusión durante la sesión diaria puede ocurrir de muchas maneras siempre que esta “se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo”.

¿Qué tipo de conversaciones podemos tener para realizar una Daily Scrum efectiva? ¿Qué otras cuestiones podemos abordar durante la sesión para asegurar que conocemos con exactitud en dónde estamos respecto al objetivo del sprint? Empecemos por mejorar el matiz de las preguntas clásicas.

“¿Que hice ayer?” es la pregunta que se harían los miembros de un equipo con una perspectiva estática de lo que hacen o de lo que quieren hacer a continuación. De alguna manera, este tipo de preguntas son estacionarias, aunque las estaciones solo sean de 24 horas.

En cambio, una persona, un equipo o una organización con una perspectiva dinámica bien puede responder a la pregunta: ¿qué hice para garantizar que aprendimos algo nuevo ayer? Esto imprime una energía distinta y más vigorosa a la sesión, a las personas, al ambiente de trabajo, y permite que el equipo practique y promueva una cultura de mejoramiento continuo.

Más allá de esta pregunta, otras cuyas respuestas nos dan una idea más precisa de qué tanto hemos avanzado hacía el logro de la meta propuesta son:

  • ¿Qué hicimos ayer que mejoró nuestra eficiencia?
  • ¿Qué valor o principio de la empresa, del equipo o de alguna otra índole determinó en gran medida nuestro comportamiento de ayer para avanzar hacia el logro del objetivo del sprint?
  • ¿Qué decisiones tomamos ayer que nos permitieron avanzar hacia el logro del objetivo del sprint?
  • ¿Qué decisiones tomamos ayer que no nos permitieron avanzar hacia el logro del objetivo del sprint?
  • ¿Qué podemos aprender de esto para garantizar que mañana estaremos más cerca de lograr el objetivo del sprint? Las respuestas a esta última consulta derivan en un plan de actividades para el siguiente día hábil de trabajo.

Al hacer este tipo de preguntas todos los días, el equipo empieza gradualmente a desarrollar principios referentes a la forma cómo toma las decisiones, pero también comienza a ver un estándar en la forma cómo se acerca al objetivo del sprint, cada sprint. Las respuestas a estas preguntas guían en términos de cómo y qué elementos deberían ordenar para alcanzar el objetivo propuesto y entregar el valor planificado al negocio.

En medio de este análisis de si el equipo alcanzará el objetivo propuesto, es vital preguntarse por el impacto de las interrupciones causadas por eventos que provienen del entorno:

¿Hay algo en el entorno que está ocasionando distracciones al equipo o a algunos de sus miembros? ¿Es posible evitar esas distracciones?

Ahora bien, los objetivos no se pueden alcanzar a cualquier precio. En particular, no tiene sentido lograr una meta si en el camino dejamos una estela de desperdicio, de trabajo mal elaborado o de desgaste moral y físico de las personas. Aquí surge una pregunta clásica, pero cuyas respuestas pueden dar luz al equipo sobre el estado del avance hacia el logro del objetivo del sprint:

¿Estamos haciendo correctamente el producto correcto?

Finalmente, el objetivo del sprint se define durante la planificación de este, al principio del sprint. Sin embargo, a medida que pasan las horas y los días, el equipo Scrum aprende más sobre el alcance, sobre los elementos del product backlog que están implementando, por ejemplo, sobre las historias de usuario, sobre lo que viene a continuación en los dos siguientes sprints en sesiones de refinamiento y sobre la capacidad real de las personas, entre otras cosas.

Toda esta información puede conducir a hacer un cuestionamiento sobre si el objetivo del sprint es alcanzable o no, sobre si debiera replantearse, delimitarse o sobre si el sprint debiera cancelarse debido a que su objetivo empieza a sufrir de obsolescencia. Así que las respuestas a preguntas como “¿el objetivo del sprint sigue vigente?” dilucidan este aspecto. Otras como “¿lo que hemos aprendido hasta ahora mantienen la vigencia del objetivo del sprint?” también ayudan en este sentido.

Así que, en la práctica, tenemos una gran lista de temas para conversar en la Daily Scrum que nos ayudan a concentrarnos en el cómo vamos hacia el logro del objetivo del sprint. Cuáles preguntas abordar es algo que depende del escenario actual, de lo que esté sucediendo en el equipo y en el entorno. Un Scrum Master debe estar atento a las señales en el ambiente, pero lo mejor es que le proporcione pautas a las personas de equipo para que sean ellas quienes seleccionen la táctica o la estrategia adecuada en un día específico.

Una sola pregunta puede ser suficiente, pero a veces son necesarias dos o más. Sin embargo, si el avance hacia el logro del objetivo del sprint no está claro hacia el final de la Daily Scrum, una práctica que no deja dudas es la del voto de confianza. Esta consiste en que cada persona emite un voto, a manera de porcentaje, de 0 a 100, expresando que tanto confía en que el equipo Scrum alcance el objetivo este sprint. Si el promedio general es de menos del 90 % o de un porcentaje previamente acordado por el equipo, seguramente habrá que replantear o negociar qué se hará y que no se hará en lo que resta de la iteración.

¿Qué otras cuestiones o prácticas se te ocurren que pueden servir al equipo en una Daily Scrum? Por favor, déjamelo saber en el foro.

Más sobre la Daily Scrum

Daily Scrum Kaizen:

http://www.gazafatonarioit.com/2021/04/daily-scrum-kaizen.html

El Scrum Master y el Scrum Diario:

http://www.gazafatonarioit.com/2020/09/el-scrum-master-y-el-scrum-diario.html

Compendio sobre el Scrum Diario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html


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.