Un mejor Scrum o cómo mejorar tu práctica ágil para entregar resultados asombrosos

 

Estoy comprometido con mejorar la práctica de Scrum en las organizaciones y comunidades que acompaño y me he convencido de que todos los equipos, sin importar su estado de desarrollo, pueden optimizar su capacidad de inspeccionar y adaptarse para hacer mejor las cosas.

En mi continuo trasegar por las organizaciones que usan Scrum o intentan hacerlo me he encontrado con manifiestos desordenes en ese ámbito: desde el uso de un Scrum fundamentalista o Scrumdamentalismo, ese que raya en lo sectario, pasando por el-mismo-Scrum-para-todo-el-mundo, sin dejar atrás el Cascrumcada o “Scrum-cascada”, el Scrum mecánico, apenas para un apocalipsis zombi, o el extremista “Scrum-solo-para-mí” porque mi organización es única en el mundo, hasta el muy común en las empresas que apenas comienzan, el Scrum-sin-terminar, con el que todavía están extendiendo el Sprint, usan el tiempo de la retrospectiva para terminar de probar y no la hacen o simplemente no hay entrega de incremento probado y funcionando la mayoría de las veces.

Al enfrentar estas alteraciones he encontrado muy útil determinar no solo el nivel de desarrollo de los equipos sino el estado general de la organización en materia de pensamiento lean-ágil, estructura y cultura organizacional, identidad de los equipos, trabajo colaborativo y qué tanto está arraigado el mejoramiento continuo en la forma de hacer las cosas de la empresa, para así tratar de curar no solo los síntomas sino las causas raíz de estas disfunciones y empezar a entregar mejores resultados, cumpliendo así con la promesa ágil.

De estos asuntos trata esta presentación que hice en el Regional Scrum Gathering México 2020.

Puedes ver y descargar la presentación aquí.

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

“La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

“Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

“¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados

Ritmo sostenido, cadencia y el ciclo lunar

Imagen de Gerd Altmann en Pixabay

Hablaba con mi amiga Claudia Toscano sobre el por qué la duración de los Sprints debería ser siempre lo mismo, el por qué no era buena idea estar cambiando de duración a las iteraciones en Scrum y lo primero que se me ocurrió es que una de las razones principales es el ritmo, precisamente ese ritmo sostenido del que hablamos ya desde el manifiesto ágil, que nos permite conocer con más precisión (o menos imprecisión) la capacidad real del equipo.

Me refería a ese principio del Manifiesto que dice:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida”.

Decíamos que ese ritmo constante tiene otros beneficios también, entre ellos mayor productividad, elimina el estar pensando precisamente eso de "este sprint de cuánto tiempo será". Esas conversaciones que son desperdicio y restan productividad desde el sprint anterior en donde las personas están sugiriendo que "el próximo sprint sea de 10 días o de 5", "qué tal si lo hacemos de 15", evita esos diálogos que generan estrés, agregan confusión a un contexto que quizás ya tiene mucha incertidumbre. En general, se reduce la complejidad, esa complejidad inherente a tener que tomar ese tipo de decisiones cada vez que va a empezar un nuevo sprint, aun desde el anterior.

Hay menos inseguridad. Hay menos gasto de energía y se genera menos estrés. Además, con el tiempo, los eventos internos del Sprint son más efectivos porque la gente ya conoce su  ritmo y eso es muy importante en la Planificación, porque el equipo ya tiene una proyección de lo que puede hacer en un Sprint. Hemos notado que al mantener un ritmo y vigilarlo continuamente ayuda a mejorar la eficiencia de las personas en el trabajo, reduce los riesgos inherentes al trabajo del conocimiento y al producto o servicio, disminuye el desperdicio que se pueda generar, sobre todo si mantenemos los elementos del backlog (historias de usuario) pequeños, y contribuye significativamente a la mejora continua.

Algo que nos pasaba con nuestra forma de trabajar anterior, en Cascada, era que lenta y casi imperceptiblemente empezábamos a caer en lo que podríamos llamar "vórtice de procrastinación". Uno en el que rápidamente estábamos perdiendo contacto con los clientes o consumidores, con los interesados, pero incluso más grave aún, con los propios compañeros del equipo. No sabíamos cuando íbamos a terminar algo, a pesar de los planes “detallados” a que éramos sometidos de manera dictatorial y el fin de una actividad pasaba de horas o días a semanas y rápidamente a meses… ¡un día a la vez!

¡Eso definitivamente no tenía nada de divertido!

¿Por qué? Porque somos seres rítmicos por naturaleza. Seguimos ciclos de manera casi ritual, por ejemplo, estamos despiertos y dormimos más o menos a las mismas horas, siempre. El ritmo nos ayuda a relajarnos, a calmar el estrés, nos permite determinar bloques de tiempos para actividades específicas y todo ello nos posibilita adaptarnos mejor a las circunstancias, porque podemos predecir o proyectar lo que podemos hacer y cómo hacerlo sin estrés, de manera más o menos divertida.

El Sprint en Scrum y el ciclo lunar

Imagen de Syaibatul Hamdi en Pixabay

El Sprint es el corazón de Scrum y en Scrum todo ocurre en el marco de un Sprint. El objetivo en el Sprint es crear un incremento de producto “Terminado”, utilizable y potencialmente desplegable en un ambiente donde al menos un grupo de usuarios o consumidores pueda “jugar” con él. De la guía también aprendimos que “es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo”. Ya hemos establecido ampliamente el porqué es necesaria es invariabilidad.

Una de las duraciones más ampliamente usadas por los equipos en todo el mundo es 2 semanas para sus Sprints, según indica The 2015 State of Scrum Report de la Scrum Alliance. Más sobre este reporte en:

https://www.scrumalliance.org/ScrumRedesignDEVSite/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf

Pero también es importante definir Sprints cuyo inicio y fin concuerden con los ciclos lunares. Esto se les hace más natural a las personas porque nos adaptamos mejor a esas cadencias que son habituales para nosotros. Por eso siempre estamos buscando iniciar Sprints un lunes y terminarlos un viernes. Sin embargo, en países como Colombia donde las festividades fueron modificadas de manera artificiosa hace ya varias décadas, hay que adaptar esos ciclos para acomodar tales eventos y otras pausas habituales en las culturas locales. Por ejemplo, dado que en Colombia hay muchos lunes festivos, podría ser interesante experimentar iniciando los Sprints un martes y hacerlos de nueve días en vez de diez. En el caso de que durante ese ciclo de dos semanas no haya días festivos, el décimo día se puede usar para trabajar en la mejora del equipo o en apoyo a otros equipos y áreas de la organización, o simplemente en socialización al interior de la empresa. También son útiles estos días para realizar hackatones u otras actividades que fomenten la innovación.

De esta manera, los equipos establecen una cadencia acostumbrada y fijan expectativas con base en las fechas de finalización de los Sprints. El equipo puede sincronizarse con otros equipos para entregar incrementos de producto en el que estén trabajando en conjunto o para tener un mejor manejo de las dependencias entre ellos. Esto reduce los conflictos entre esos equipos y las personas nos sentimos más a gusto y cómodas trabajando con el horizonte de los ciclos naturales a los nos que hemos habituado desde niños. Esto mejora la motivación del equipo y afianza los valores y la visión establecidos.

Conclusión

Tener este tipo de hábitos, como Sprints de duración fija, reuniones diarias a la misma hora y en el mismo lugar, y conocer con anticipación las fechas de otros eventos como la Planificación, la Revisión o la Retrospectiva, permite que los miembros del equipo se enfoquen en sus tareas principales y hagan lo que mejor saben hacer, que es manejar la incertidumbre, los cambios y la ambigüedad inherente al tipo de tareas que hacemos diariamente, es decir, esa otra cara variable del trabajo.

Referencias

Para saber más sobre patrones Scrum puedes consultar el libro:

A Scrum Book: The Spirit of the Game, de Sutherland , Coplien , den Hollander y otros.

Diez comportamientos atípicos en Ágil y Scrum

Escucha el audio de este artículo aquí:

De valores y principios

La agilidad es una capacidad de las personas, los equipos que forman esas personas y las organizaciones que cobijan esos equipos, de crear Valor y de responder eficiente y efectivamente al cambio para tener éxito en un entorno lleno de incertidumbre, pero también de ambigüedad, altamente complejo y volátil.

El pensamiento y el comportamiento ágil se funda en lo que conocemos como el Manifiesto Ágil, que enuncia cuatro valores, que conducen nuestro comportamiento de agilistas, intrínsecos a nuestra forma de pensar y de interpretar el mundo que nos rodea, de alguna manera subjetivos, emocionales y hasta debatibles. Pero valores al fin y al cabo.  Los valores ágiles son importantes para nosotros y los practicamos incluso de manera inconsciente, sin ningún esfuerzo. Estos valores se complementan con doce principios, extrínsecos o manifiestos que nos ayudan a hacer objetivos los valores, a hacerlos más concretos, incluso impersonales y a poner esos valores en evidencia. Los principios ágiles son indiscutibles. Los valores ágiles se basan en los principios.

A su vez, marcos de trabajo como Scrum nos señalan el camino de cómo poner en práctica esos valores y principios. Por ejemplo: “hemos aprendido a valorar la respuesta ante el cambio sobre el seguir un plan”. Un principio ágil nos dice que “Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. Otro nos dice que “A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia”. Más adelante, Scrum nos enseña a trabajar en períodos cortos de tiempo, llamados Sprints, y a tener un backlog de producto que está cambiando todo el tiempo. Y además nos proporciona distintas oportunidades de hacer inspección y adaptación, al producto, al proceso y a las personas, en los distintos eventos que propone el marco de trabajo.

Incluso el mismo Scrum no está desprovisto de espíritu. Los cinco valores de Scrum no son solo un complemento a los valores ágiles, como que “los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes”, que es más de “personas e  interacciones”, sino que también nos sirven de guía de comportamiento Sprint tras Sprint.

Los comportamientos atípicos

Sin embargo, es muy común encontrar personas y equipos cuyo comportamiento ágil deja mucho que desear. No solo dentro de las empresas, sino también en las comunidades ágiles, al menos por este lado del planeta. Por ejemplo, en los foros de las comunidades, cuando se trata de preguntas o de solicitudes de ayuda de personas, he notado algunos patrones, algunos comportamientos sobre los que invito a reflexionar y, de ser necesario o de efectivamente encontrarlos hostiles, a mejorar. He encontrado:

1.    Respuestas que denotan intolerancia. Intemperancia con quien no conoce de algo en particular. Esto malogra el efecto de la comunicación. De hecho, con este mensaje corro el riesgo de que me tachen de intolerante.

2.    Respuestas "automáticas", de esas que se repiten en muchos de los foros de los grupos, la misma respuesta a muchas preguntas, sin considerar el contexto de cada una. Como si se tratara de una receta única y prescriptiva a “todos los males” de la humanidad.

3.    Respuestas “a la ligera”, sin detenerse a revisar el paradigma actual del solicitante. No porque estemos en una o cual comunidad ágil, ya tenemos claro lo que significa el pensamiento ágil, ser ágil o la agilidad.

4.    Respuestas escuetas o cortantes que muchas veces no brindan ninguna solución a la cuestión. Al menos, no una solución proclive a responder la inmediata necesidad de quien pregunta.

5.    Respuestas erróneas o, al menos, inexactas o carentes de precisión.

Imagen de Gerd Altmann en Pixabay

En este sentido, siempre que tengo la oportunidad, sugiero a los participantes de los foros:

·       Leer nuevamente la pregunta o solicitud.

·       Detenerse un poco a pensar en la respuesta antes de enviarla.

·       Solicitar contexto a quien pregunta. Estamos actuando como si hubiera una receta prescriptiva para todo y nos olvidamos de que los escenarios son distintos, los de ellos, los de aquellos, los nuestros y los tuyos. Estamos en un mundo VICA (VUCA). “Tu escenario es diferente al mío”.

·       Ser más respetuosos no solo con quien nos interpela, sino con el resto de tertulios.

·       Liderar con el ejemplo.

·       Finalmente, hagamos de nuestras comunidades unas a las que sea un privilegio pertenecer. Los valores Scrum nos ayudan mucho a ello. Acordemos estar abiertos a todo y a los desafíos que se nos presenten al participar en los grupos y comunidades ágiles.

“Malos” comportamientos Scrum

Imagen de Kate Baucherel en Pixabay

En particular, cuando se trata de usar Scrum para sacar adelante proyectos o esfuerzos de desarrollo de productos o servicios, he encontrado:

6.    Las ganas de hacer la Planificación del Sprint rápida o muy rápida. Con la excusa de que hacen un buen refinamiento. ¿Seguros? ¿Cuántos Sprints adelante? Son infinitas las planificaciones Scrum que terminan sin un trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint, descompuesto en unidades de un día o menos, y sin “una proyección de lo que (el equipo) cree que puede completar en el Sprint que comienza”. Tampoco incluyen una Meta de Sprint que les de visión y les motive a autoorganizarse y les proporcione una razón de reflexión diaria sobre si se están acercando o no a esa meta. Recordemos además que “Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”. Sobre todos estos asuntos escribí hace ya algún tiempo: Planificación del Sprint: el primer paso para producir el máximo efecto. Clic aquí.

7.    Mantener al Dueño de Producto alejado del resto del equipo Scrum. ¿Dónde quedó aquello de que “los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto”? En particular, sobre la ausencia del Dueño de Producto en la retrospectiva, escribí: Dueño de Producto, usted ha sido invitado a la Retrospectiva. Clic aquí. Tenemos que ayudar a que el Dueño de Producto se enamore de su rol, todos, Scrum Masters, coaches ágiles y similares y Equipo de Desarrollo.

8.    El síndrome del bravucón. Los seres humanos tenemos la naturaleza de “ir por más”, de querer hacer más. Con buenas intenciones. O, al menos, partimos de ahí. Y si tenemos autoestima elevada, nos fijamos metas cada vez más elevadas. Pasa, por ejemplo, con las estimaciones. Durante la planificación del Sprint. El problema radica en que muchas veces no hemos cumplido la promesa o lo que planificamos en los últimos tres o cuatro Sprints y en el que comienza no solo queremos seguir insistiendo en que esta vez sí lo lograremos sino que prometemos hacer más, mucho más. A veces esto da resultado en el plazo inmediato. Pero a la larga, es algo insostenible. Y cuando de nuestro trabajo depende mucha gente, incluso una organización entera o más, miles o millones de consumidores, no es bueno incumplir. Eso desanima no solo al propio equipo, a la empresa sino también a los usuarios finales del producto o servicio. Para la solución a este síndrome escribí sobre el muy conocido patrón de Scrum “El clima de ayer” en: El clima de ayer, o el arte de prever lo que sucederá hoy. Clic aquí.

9.    La adicción a las herramientas. Cuando venimos del paradigma tradicional no tiene nada de malo si nos aferramos a lo que conocemos. Pero cuando el tiempo pasa y seguimos anclados a esa antigua formula de trabajo, es que nos falta incorporar parte o toda esa nueva forma de pensar y de hacer las cosas: nos hace falta agilidad. Esa búsqueda continua de instrumentos automatizados para hacer esto y aquello. Ese deseo incontrolable de tener control sobre el proceso, sobre el producto y sobre las personas mediante el registro de su trabajo en herramientas de todo tipo. Las conversaciones se vuelven discusiones eternas sobre evaluación de proveedores, precio de licencias, RFP ininteligibles, licitaciones y presentaciones sin valor para la empresa. ¿Y de aquello? Sí, de aquello, del producto probado y funcionando, útil, de valor para la organización y para sus clientes. De eso nada. Allí es cuando necesitamos trabajar más en formas de interacción entre personas y valorar más esto que a esas herramientas y a los procesos. Scrum, por su parte, nos provee de ricos momentos para interactuar, cinco eventos más uno, sí, el refinamiento. Literalmente, todos los días podemos tener conversaciones cara a cara, que se han convertido en “el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros”. Escribí sobre este asunto en: La Conversación Cara a Cara en Tiempos de la Comunicación Digital. Clic aquí.

10. La falta de espíritu. En la introducción a este artículo les dije que Scrum no carece de espíritu. De hecho el Espíritu del Juego es el patrón Scrum que nos proporciona el contexto, el entorno que necesitamos para ejecutar cualquier otro patrón: se trata del marco de trabajo mismo, Scrum. A veces es útil pensar en Scrum como un juego. Cuando usemos Scrum, el equipo de desarrollo de producto, no solo el Scrum Master ni mucho menos el Dueño de Producto, debe enfocarse en crear una cultura donde la personas conozcan, interioricen, practiquen y promuevan el espíritu de Scrum. Todos en el equipo Scrum y quienes trabajamos con ellos debemos ayudar a instanciar esa cultura y a que esta evolucione liderando con el ejemplo. Sobre esto, hemos aprendido a promover y a premiar comportamientos que consideremos apropiados o “correctos” para la cultura que queremos, y a desanimar y castigar otros comportamientos que creemos inapropiados o “erróneos”. En el largo plazo, esto da como resultado que una nueva cultura emerja: la cultura Scrum, la cultura ágil. Sobre esto último escribí hace muchos años: Cultura Ágil, ese oscuro objeto del deseo. Clic aquí. Además de muchos otros artículos en este mismo Gazafatonario. Y sobre Scrum, con mi gran amigo Jorge Abad estamos en el proceso final de edición de nuestro libro Scrum: epítome de una década de experiencias, que reúne mucha de nuestra propia experiencia lidiando con estos comportamientos atípicos y con muchos otros. Clic aquí.

La lista de comportamientos extraños o irregulares puede ser infinita. Pero es definitivo, “para crear la cultura debes ser la cultura”. Déjame saber en el foro qué piensas de todo esto y qué otros comportamientos insólitos o anómalos has encontrado en tu camino ágil.

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.

Estimaciones en los tiempos de la agilidad

Presentación

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

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

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

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

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

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

Técnicas de Estimación

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

1. Planning Poker

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

2. Tallas de camiseta

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

3. Puntos de votación (dot voting)

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

4. El sistema del cubo

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

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

5. Grande / Incierto / Pequeño

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

6. Mapeo de afinidad

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

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

7. Método de ordenamiento

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

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

Más sobre una “buena” estimación

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

Juegos de estimación dañinos que debes evitar

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

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

Recomendaciones finales

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

Algunos errores comunes que están haciendo tu transformación ágil más difícil y frustrante

http://www.freepik.com Designed by macrovector / Freepik

Iba a escribir algo sobre las fallas con las que me he encontrado estos años en mi viaje, acompañando y liderando cambios culturales ágiles, entrenando y sirviendo a personas y equipos con algunos de mis colegas y mejores amigos en el terreno.

Como siempre, respiré hondo mientras volvía a leer (¡otra vez!) el tan ampliamente aclamado pero en su mayoría malentendido manifiesto ágil para el desarrollo de software y de repente me llegó esta destornillada idea de escribirlo al “estilo del manifiesto ágil”.

Y así es como surgió este nuevo Manifiesto por la Transformación de Mentalidad FrÁgil, de ahora en adelante llamado aquí “Manifiesto por la Transformación Frágil”.

Esta es solo una forma de expresarme sobre las faltas en las cuales están cayendo los coaches ágiles, líderes ágiles y gerentes de todos los niveles, haciéndole más difícil a las personas entender, aceptar y participar más activa y apasionadamente en las transformaciones ágiles de las organizaciones en este mundo VUCA.

Manifiesto por la Transformación FrÁgile

Estamos descubriendo formas peores de realizar transformaciones ágiles tanto por nuestra cuenta como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Marcos de trabajo, prácticas y herramientas sobre Mejoramiento Continuo

Muchos equipos Scrum sobre Entregar Valor

Silos basados en habilidades y personal en proyectos múltiples sobre Verdadera Colaboración

Medir lo que satisfaga a los gerentes sobre Inspeccionar y adaptar

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Principios detrás del Manifiesto de Transformación FrÁgil

Seguimos estos principios a cualquier costo:

Nuestra mayor prioridad es satisfacer la gerencia tradicional a través de la creación temprana y continua de equipos Scrum

Aceptamos más prácticas, marcos de trabajo y herramientas ágiles, incluso en etapas tempranas de la transformación. Las transformaciones ágiles complacen el ego de los patrocinadores y de su personal.

Creamos escuadrones, tribus y células frecuentemente, desde un par de equipos por semana hasta docenas de ellos por mes, con preferencia a la meta más alta posible.

Los responsables del negocio y los desarrolladores no deben infundir la experimentación y la iteración en el ADN de la organización.

Pensamos que todos los individuos en la organización tienen la misma alta motivación acerca del proceso de transformación. Los tratamos como si todos tuvieran la misma energía, confianza y visión en el cambio.

El método más eficiente y efectivo de informar sobre la transformación en curso es la falta de comunicación a través de toda la organización.

Las herramientas, marcos de trabajo, prácticas instaladas y el número de escuadrones son la medida principal del progreso.

Muchas palabras diferentes flotando sobre la esfera ágil promueven la transformación sostenible. Los patrocinadores, gerentes y responsables de la transformación deben poder pronunciarlas bien, aun si no las entienden en absoluto.

La atención continua a hacer reuniones diarias y retrospectivas sin sentido desmejora la agilidad.

La complexidad, o el arte de usar marcos de escalamiento y contratar expertos en Cynefin, es esencial para presumir.

Los mejores cambios culturales, prácticas ágiles y retroalimentación emergen de equipos internos, sin un acompañamiento y entrenamiento sólidos.

Muy temprano en el proceso, la organización reflexiona sobre cómo ser más ágil para a continuación implantar marcos de escalamiento en consecuencia.

La lista de errores puede ser bastante extensa, así que incluye los tuyos apropiadamente. ¿Y estás preparado para no ser un signatario de este manifiesto? Déjamelo saber en el foro.

Nota:

Publiqué originalmente este artículo en inglés en Pulse de LinkedIn (I originally published this article in English on Pulse from LinkedIn):

https://www.linkedin.com/pulse/some-common-mistakes-make-your-agile-transformation-luis-antonio/