Guillem Hernandez Sola

Últimamente, el alcance del líder del cambio, ya te consideres Scrum Master o Agile Coach ha tocado las alturas, y todas las demás personas quieren poner sus manos en esto. Este artículo te va a ayudar a obtener tu primer trabajo de Scrum Master.

¿Agile está muerto? ¿Es Agile el «arte de la felicidad»? ¿Agile cumple lo que promete? A medida que las organizaciones se acostumbran cada vez más a ser ágiles usando Scrum o otros marcos en el mercado, también comienzan a cuestionar las maneras como se hace la agiidad en las organizaciones. Últimamente, la gente parece decir que los marcos ágiles no cumplen su promesa. Si habéis estado en la industria del software durante algunos años, lo ha visto antes seguro. Yo he oido muy poca gente hablando bien de Scrum, o de Kanban o sobretodo de SAFe. Ya no quiero entrar de los comentarios que he oido de organizaciones Big 4 como McKinsey, Accenture o KMPG sobre sus estrategias para implementar agilidad en las organizaciones. No veo lo de Agile está muerto cuando estas Big 4 se gastan millones y millones para hacer negocio en las implementaciones de estrategia apostando por Agile. Estás trabajando de una manera específica pero sigues escuchando acerca de esta otra fantástica “bala de oro” que otros están usando. Cosas como qué bonico es el método Spotify o qué bien hacen agilidad en tal otra organización. Las organizaciones lo intentan durante algún tiempo, pero realmente no lel ven la grandeza, así que deciden probar otra cosa. Algo que realmente revolucionará la forma en que trabajamos. Parece sucede con la mayoría de las metodologías. Tengo una hipótesis sobre por qué sucede esto. En primer lugar. Vivimos en un mundo de cambios. Los métodos y los marcos son construcciones para el mundo tal como fueron cuando se crearon. Recordad que hay documentos donde se habla de Scrum en 1993 y el Manifiesto Ágil de Software es de 2001. Dejadme insistir aquí en el concepto de «Manifiesto Ágil de Software», no habla del «manifiesto ágil sobre como proporcionar soluciones en un mundo complejo». A medida que el mundo cambia, las premisas que construyen los fundamentos de un marco o metodología dejan de ser válidas. También evolucionan. Pero, ¿es eso cierto para la agilidad en este momento? ¿Seguimos sin avanzar hacia una sociedad y un paisaje donde las condiciones cambian rápidamente? ¿Dónde tenemos que responder a los cambios? ¿No es eso de lo que se trata Agile? Creo que eso todavía se mantiene, y probablemente seguirá siendo así durante una década más o menos. Sinó mirad al 2020 en su totalidad. Aplicar la teoría de los primeros en adoptar Entonces, si el mundo todavía necesita Agile, ¿por qué hay tantos artículos que afirman que Scrum y Agile están muertos? Mi hipótesis es que Agile sigue la curva tradicional de los primeros usuarios. Scrum es ahora la corriente principal y está en su apogeo. Ahí es cuando comienza la prensa negativa. Vea la imagen a continuación. Si aplica esta teoría a Scrum, potencialmente puede ayudarnos a comprender algunas cosas. Mi reflexión personal es que al principio, cuando los primeros usuarios comenzaron a investigar y usar Scrum y otros marcos ágiles, eran expertos. Habían llegado a «Ri» en Shu-Ha-Ri. Estas personas, que eran se consideraban con el mindset Agile, no tenían un marco estándar completamente descrito para usar. Tuvieron que fallar, reflexionar, inspeccionar y adaptarse, y trabajar duro para entender qué funcionó. A medida que aumentaba el interés y comenzaba la exageración de los medios de comunicación, estas personas sabían qué había funcionado y qué no. Las conclusiones se basaron en años de experiencia en experimentos. Gran parte de ese conocimiento probablemente fue tácito. A medida que aumentaba la demanda, surgió la necesidad de crear marcos fáciles de entender para que otros pudieran aprovechar la experiencia y ser ágiles. Estos primeros usuarios, que probaron Scrum, probablemente aún provenían de un mundo de experiencia en cascada, RUP, Prince2 y otras metodologías. Cambiar la forma de trabajar requiere mucha comprensión. Entender por qué se necesitaban cambios e ideas diferentes. Pasar de un modelo mental a otro es difícil. Eso requiere que comprenda lo que hace y por qué. Diría que los primeros en adoptar Scrum tuvieron éxito porque entendieron por qué eran necesarios los cambios. Podían ver dónde habían fallado antes y dónde tendrían sentido las nuevas ideas. Diría que estaban en la etapa Ha de Shu-Ha-Ri. A medida que alcanzamos la actividad más allá de los primeros usuarios y las nuevas generaciones que nunca han trabajado con otros métodos … Bueno, leyeron las 17 páginas de la Guía Scrum y comenzaron a realizar los eventos y crear artefactos sin tener una comprensión más profunda de por qué. Nunca tuvieron que entender el por qué. Scrum es la forma en que siempre ha trabajado des del inicio de los tiempos. Para estas personas, Scrum describe el CÓMO trabaja, no el POR QUÉ. A esto se le llama corte de carga. Este es, por supuesto, el enfoque equivocado. Piense en la metáfora clásica del iceberg. Solo ves lo que está por encima de la superficie. La mala noticia es que realmente no se puede cambiar el comportamiento hasta que se descubra que no funciona y averiguar POR QUÉ no funciona. Eso requiere experiencia y que reflexiones sobre el por qué. Aquí es donde muchos se dan por vencidos y no van más lejos. Estas personas están en la etapa «Shu». Entonces, ¿qué pasará después? Un escenario muy probable es que Agile seguirá siendo necesario y útil. Y sobretodo que vaya dando el valor que le toca. Sin embargo, lo más probable es que las empresas tengan que darse cuenta de que el solo hecho de seguir las ceremonias y crear artefactos no ayudará. Por lo tanto, necesitarán ayuda y ganarán sus propias experiencias reñidas. Esto siver para obtener una comprensión más profunda. Las empresas necesitarán ayuda para crear marcos que se adapten a la cultura, estructura, mercado, producto, regulaciones y personas específicas de sus organizaciones. Puede ser que vivan en un mundo híbrido, dónde haya partes que navegan en métodos diferentes a otras. En estos casos no pasa nada, porqué la diversidad hace el color y facilita la entrega de valor. La comprensión debe ir de «Shu» a al menos «Ha» y preferiblemente «Ri». Esto se abre para los maestros de los frameworks. Las personas “Ri” ágiles y calificadas pueden ingresar a una organización y personalizar un marco que se adapte a esa organización. SAFe ha empaquetado una solución muy bien. Creo que las organizaciones se darán cuenta de que SAFe no es útil para todos. Tiene grandes ideas y principios, pero probablemente no debería simplemente sacarlos de su zona de confort. Lo mismo sucedió cuando la gente descubrió que el modelo de Spotify era solo para Spotify. El modelo de Spotify se personalizó para Spotify. Si no lo has descubierto aún, el modelo Spotify es para un empresa casi monoproducto de cultura muy joven con una visión muy clara. Pero claro si no triunfamos siendo Spotify, Agile está muerto. Las organizaciones tendrán que encontrar expertos en los marcos que puedan ayudar a crear su propio marco ágil customizado. Habrá una necesidad de muchos marcos nuevos y sobretodo personalizados para el contexto donde se están haciendo las transformaciones ágiles. Y recuerda, no hay 2 transformaciones iguales. El objetivo de crear su propio ecosistema agile agrega el beneficio de que las personas de su organización (con suerte) ayudan a crear y decidir las reglas. Al participar en la creación de las reglas del juego, también te das cuenta de que puedes darles forma y romperlas según sea necesario. Esto te da el POR QUÉ. Solo se aplicó el clásico «Inspeccionar y adaptar» en el contexto de manera satisfactoria. Para resumir, lo que le está sucediendo a Agile y Scrum es probablemente normal y, a medida que avancemos, Scrum y Agile evolucionarán hacia algo diferente. A algo poco mejor. A algo un poco diferente, inspeccionando y adaptando lo que los propios practicantes propopen. Agile está muerto en completa evolución.

Las organizaciones que he visitado estaban en un estado de waterfall estructural también conocido como manera de trabajar en cascada rígida. Están lejos de la mejor implementación de Agile. Esta revelación en particular me llegó pocos años después de que comencé a trabajar con agilidad. Todas afirmaban que eran ágiles. Decían cosas como «pero hacemos reuniones diarias», «hacemos sprints» o alguna otra una cita real de la gerencia de una de ellas. También afirmaban en el momento que las apretabas un poco con preguntas algo incomodas que eran ágiles y requeteágiles pero admitian cosas como que «tenemos un largo camino por recorrer y todavía estamos aprendiendo». Por supuesto, esto no es cierto para todas las organizaciones, pero debo decir que es la mayoría de los casos en mi experiencia. Básicamente me han llamado siempre para ayudar en implementaciones de Scrum, de Agilidad de negocio o de Kanban y siempre me han preguntando «Tu qué haces aquí si ya hacemos todo lo que vienes a mostrar?». Esta pregunta no se aguanta ni 3 minutos en el momento que empiezas que lanzas la pregunta: «¿Tu sabes qué hace tu compañero de equipo? ¿Tu sabes que hace la persona que tienes sentada a tu lado en la oficina?» Por eso, la primera cosa a tener en cuenta en una impementación de Agile es hacer relucir la transparencia. Saber que hace la persona que tienes sentada al lado de tu mesa de trabajo en la oficina. ¿Por qué es así? La mejor implementación de Agile no es un estado. Esto de la agilidad es la capacidad de cambiar y responder a un entorno en el que se encuentra como organización. La capacidad de sentir y responder y la capacidad de inspeccionar y adaptar. ¿Puedes decir que has implementado métodos ágiles como Scrum o Kanban? De hecho, puedes. Si tiene todos los elementos en su lugar, entonces lo has hecho. Pero si lo has hecho bien, comenzarás a comprender que la agilidad de negocio no es la mecánica. No es una cosa de libro, sinó de reglas, valores y excelencia técnica. La colaboración por encima de las recetas precocinadas. Son los valores, principios que son mucho más difíciles de introducir. De ahí es donde viene el «largo camino por recorrer y seguir aprendiendo». Y es eso un camino, no una receta a seguir. Se tiene que huir de cualquier persona que diga que tenga el libro mágico de la agilidad y su receta vencedora. Las organizaciones ágiles son las que luchan por el buen Scrum, su buen tablero de Kanban o cualquier otro marco que entienda que solo el cambio y la mejora constante aportan un valor significativo y una ventaja competitiva. Al igual que durante la pandemia actual, los han podido adaptarse, sobrevivir o prosperar lo han hecho adaptandose al ambiente. Después de comprender la Agilidad y Scrum, verás que nunca ha terminado de cambiar ni de evolucionar. Entonces, la próxima vez que una organización os diga «sí, somos ágiles», verifica si realmente lo son. Tienes que ser escéptico si los que «todavía están aprendiendo» realmente tienen un largo camino por recorrer. Además, cuando hablamos de métodos ágiles, tienes que primar la diversidad sobre la supremacia. No es mejor SAFe que LESS, cualquiera de las 2 aporta valor en su contexto. Las simplicidad sobre la complejidad. Navegar la complejidad es eso, navegar el desconocimiento delante el conocimiento. Porqué andar el empiricismo es eso, inspeccionar y adaptarse al entorno. En resumen, en estas situaciones, yo siempre pongo el mismo ejemplo. Esto de la agilidad es como el sexo adolescente, los que lo han prácticado bien, no te lo han contado. Igual que la mejor implementación de Agile.

En enero de 2020, tuve una entrevista telefónica para un proyecto de transformación ágil con un líder de una empresa con sede en Barcelona que estaba interesado en agile coaching.

Una de las bases clave para ayudar a que tu organización se vuelva ágil es el uso del empirismo. Agile es cambio constante y nos tenemos que adaptar.

Cuando siempre me ha tocado ser un scrum master en una organización, el departamento de recursos humanos está configurando algún tipo de cuadrícula con criterios para acceder al progreso individual.

Los Story Points y la velocidad se han utilizado durante muchos años en la comunidad Scrum y Agile.

Seamos realistas, Agile ha tenido un éxito notable en la transformación de la forma en que las organizaciones piensan sobre que fabrican y cómo entregan productos y servicios. Lo que comenzó como una forma para que los ingenieros de software entregaran software de mayor calidad de manera más predecible, ahora se ha convertido en el sistema operativo predeterminado para la mayoría de las organizaciones. En su manera de trabajar. Las "transformaciones" ágiles que estas organizaciones han emprendido normalmente comienzan con los equipos de ingeniería de software (supongo que no es una gran sorpresa para nadie) y luego se extienden para incluir otros equipos de productos digitales, diseño y UX, marketing, recursos humanos y, en algunos casos, incluso legales y finanzas. El manifiesto Agile originalmente se escribió para el desarrollo de software. La guía Scrum original se escribió pensando en los desarrolladores de software. El 100% de los autores originales del manifiesto eran ingenieros de software o estaban relacionados con la indústria del software. A medida que el alcance de la agilidad organizacional y, quizás más importante, crece más allá de los equipos de tecnología, otros departamentos se están asimilando en un proceso que nunca fue diseñado para incluirlos. Y evidentemente tiene muchas lagunas y problemas. Se ven obligados a pensar de manera diferente, a replantear su trabajo y sus formas de trabajar en formas alienas que no se alinean naturalmente con la forma en que siempre han hecho las cosas. No es de extrañar entonces que muchos equipos no tecnológicos hayan comenzado a sentir que se les está imponiendo "hacer agilidad", en muchos casos en contra de su voluntad o de su manera de trabajar. Esos equipos se resienten. Lo rechazan. En algunos casos incluso lo odian. Empieza a tomar forma una mentalidad de víctima. "No pedí esto. Todo estaba bien de la forma en que trabajábamos antes". Y se acaban planteando "Por qué cambiamos?" El resentimiento crece y pronto hay una clara mentalidad de nosotros contra ellos en el lugar donde "ellos" están "haciendo esto" a "nosotros". Eso es lo que nos impide hacer el mejor trabajo que podemos. Esto nos hace quedar mal y no mejorar. Mi consejo genuino y profundo, detente. No hay víctimas en una transformación ágil. Ni buenos ni malos. ¿Es Agile la solución mágica para todo lo que aflige al mundo empresarial? No. Ni mucho menos. ¿Puede una aplicación de principios ágiles diseñados para fomentar el aprendizaje, la mejora continua y un enfoque en el cliente ayudar a todos en la empresa a ofrecer más valor a sus clientes? Absolutamente sí. No hay discusión aquí. En primer lugar, usted, sus colegas de ingeniería, su jefe y su director ejecutivo están interesados ​​en hacer que sus clientes tengan éxito. ¿Podemos estar de acuerdo en eso? (Eso espero, de lo contrario, tiene peces más grandes para freír y problemas más complejos que atender.). En segundo lugar, una comprensión más profunda de su cliente, una mejor gestión del riesgo, una mayor flexibilidad (también conocida como agilidad de negocio) en lo que está trabajando y cuándo cambiar de rumbo. Todo esto contribuye en la entrega de valor más rápida, ¿no? (Nuevamente, supongo que estamos de acuerdo aquí). Ahora, soy consciente de que la forma en que se implementan Agile, Scrum, Kanban y SAFe no siempre refleja estos valores. Sin embargo, aquí es exactamente donde se encuentra su oportunidad de colaborar con sus colegas para construir un proceso ágil mejor y más inclusivo dentro de su organización. En lugar de cruzar los brazos, pisar fuerte y decir: "No es así como trabajamos y yo me niego a participar en esto", considere este enfoque: "El trabajo que hacemos normalmente lleva más de dos semanas." En cada sprint creemos que podemos entregar el 30% de nuestra contribución total, pero a medida que la retroalimentación llega de un sprint a otro, podemos ajustar continuamente el 30% posterior que contribuimos al producto / proyecto / servicio que estamos construyendo ". Lo que está haciendo allí es reconocer que el proceso, tal como está diseñado actualmente, no es compatible con su forma de trabajar actual explicando lo que puede hacer dentro del marco existente y cómo lo usaría en el futuro para ajustar las contribuciones futuras. Más importante aún, ha iniciado un diálogo con sus colegas sobre la mejor forma de colaborar en este nuevo mundo de la agilidad de negocio. No eres una víctima. Eres un socio. Los socios negocian. Experimentan. Miran retrospectivamente y ajustan el curso basándose en los aprendizajes. Y sobre forman parte del mundo, no son un mundo aparte. Encuentro que los equipos a menudo pasan por alto la aplicación del mantra scrum, "inspeccionar y adaptar" al proceso en sí. ¿Algún proceso es 100% correcto la primera vez que un equipo lo prueba? No. La versión de ágil de su empresa (o equipo) será diferente a la de otras empresas. Si no le gusta la forma en que está funcionando, lleve esas preocupaciones a sus retrospectivas. La transformación ágil siempre es contextual. Rechazar una nueva forma de trabajar con una mentalidad de víctima conduce con negatividad, una pared que sus colegas ahora tienen que escalar para superarla. Liderar con positividad, objetividad y la voluntad de aprender juntos sienta las bases para la colaboración continua y la salud del equipo. Si no es así como se está acercando a tu departamento, no responda de la misma manera. En tu lugar, ofrece tus inquietudes, posibles impactos y sugerencias para experimentos de proceso. Si mi suposición anterior aún se mantiene, todos ustedes tienen el mismo objetivo en mente: lograr que el cliente tenga éxito. Y si ese es el caso, nadie es una víctima. Todos somos colegas buscando continuamente una mejor manera de trabajar juntos.

¿Te has preguntado cómo puedes medir el impacto de tus Scrum Masters? ¿Y cómo estos Scrum Masters o Agile coaches pueden ayudar realmente con el resultado final?

Hace tiempo que no damos Story Points en las capacitaciones que Agile611 proporciona. Lo hacemos porqué nos parece perpetrar la inmadurez en los equipos que acompañamos. Os voy a justificar porqué hacemos esto en las siguientes lineas. Todo se reduce a comprender la naturaleza de la complejidad y no a intentar utilizar enfoques lineales para desafíos no lineales. Estamos trabajo en entornos complejos, donde tenemos que fomentar prácticas emergentes para solucionar esos problemas que tenemos todos los días. Agile es bueno en lo que es bueno: manejar problemas complejos (como proyectos de software y otros entornos similares). Agile comienza a apestar cuando más introduces mecánicas que vienen del cuadrante complicado donde impera el reino de la resolución de problemas. Es decir, mecanicista, determinista y reduccionista. Esos conceptos se remontan una manera de trabajar en cascada, el taylorismo y la era de la producción en masa. Para ayudar a comprender Cynefin aquí en referencia a los dominios de los tipos de problemas. Profundizo en el video que os adjunto que otras opciones hay para superar a los story points y la velocity. Más bien te justifico el porqué que hay detrás de porqué no deberías usar puntos de la historia. Además del inventor original de la idea inicial, Ron Jeffries, te está diciendo que no los uses de manera abierta. {"preview_thumbnail":"/drupal/s3fs-public/styles/video_embed_wysiwyg_preview/public/video_thumbnails/h964sT9uQgE.jpg?itok=WE6u-DQx","video_url":"https://www.youtube.com/watch?v=h964sT9uQgE","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} ¡Adiós, velocity! Métricas Kanban como alternativa a los puntos de historia y la velocity del equipo La adicción de un pronóstico a la manera de trabajar en cascada exigía algún mecanismo de pronóstico ágil. La ruta reduccionista popular de trabajar en cascada es romper todo en sus piezas constituyentes. Una vez que tenemos todas las partes descompuestas, las dimensionamos, las sumamos y miramos la totalidad. Aquí se aterriza el sueño de cualquier director de proyecto. Luego viene el determinismo. La suma del trabajo dividida por la velocidad del equipo determinará cuándo se realiza el trabajo. Totalmente lineal y falso. Todo es un pensamiento muy lineal y podría funcionar si el trabajo no fuera complejo. Pero, por desgracia, los problemas de hoy suelen ser un problema complejo con muchas más incógnitas que partes conocidas. En un dominio complejo, no intentemos utilizar el reduccionismo y el determinismo, por ejemplo los puntos de la historia y la velocity. Cuatro alternativas para evolucionar de los story points Mencionaré algunas otras opciones para señalar historias, pero no describiré en profundidad cuáles son aquí. Eso están las capacitaciones. A continuación, se describen brevemente cuatro alternativas de estimación de Wisdom of Crowds, simulación de Monte Carlo y probabilidad bayesiana. Hay un gran video donde Dave Snowden (el padre del modelo Cynefin) dice (algo así como): cuando estás en el dominio complejo, la estimación de Wisdom of Crowds es la forma correcta de estimar. Estoy bastante seguro de que estaba en este video sobre cómo aplicar Cynefin a Kanban. Creo que Snowden está en algo aquí, y Wisdom of Crowds (también conocido como Blink Estimation) sería mi primera sugerencia para comenzar a realizar algunos experimentos. Hice algunos experimentos en esta área poniendo la estimación relativa a prueba. Me encantaría ver más experimentación en esta área y aprovecharía la oportunidad para hacerlo. Si tienes alguna experiencia, por favor compartéla. Rendimiento o recuento de historias Otra opción es el rendimiento (también conocido como recuento de historias). Esto se aleja un poco del determinismo, pero aún se basa en el reduccionismo. Idea similar a la velocity, pero la diferencia clave es que ya no necesitamos estimar el tamaño de cada elemento de trabajo. Una vez que se ha determinado que un elemento es lo suficientemente pequeño como para ser viable, ingresa al sistema de flujo y los elementos se cuentan durante un período de tiempo para obtener un rendimiento. Sin duda, es una mejora, ya que se elimina el tedio de la talla. Este método ganó especial popularidad gracias al movimiento #NoEstimates. Simulación de Montecarlo La simulación de Monte Carlo es otro mecanismo. Por lo que (creo que) entendí, todavía necesitas algo de reduccionismo. La simulación de Montecarlo muestra las probabilidades de que los elementos realizados se completen a lo largo del tiempo basándose en datos anteriores. Joseph Pelrine siente que Monte Carlo puede tener fallas en la estimación ágil. Es más inteligente que yo y aquí hay algunos trabajos que ha realizado sobre la mejora de la calidad de las estimaciones con psicología y psicometría. Todavía estoy indeciso porque no he hecho una investigación profunda, experimentación o investigación al respecto en muchos equipos, pero creo que esto va en la buena linea. Probabilidad bayesiana La última de la que también sé muy poco, pero me interesa mucho saber más, es la probabilidad bayesiana. Uno de mis intereses secundarios son los submarinos y las naves militares en general. En el libro Blind Man’s Bluff: The Untold Story of American Submarine Espionage de Sherry Sontag, Christopher Drew, Annette Lawrence Drew, comparten al menos dos historias sobre el uso de la probabilidad bayesiana para localizar submarinos hundidos. ¡Me explotó la cabeza! Necesito saber más sobre este método y si y cómo podría usarse para pronosticar en el dominio complejo. Seguiremos trabajando y investigando esta parte porqué me interesa mucho seguir. El señalamiento de historias de usuario está anticuado y el creador de los Story Points hoy lamenta haber presentado el concepto. Para resumir, los Story Points y la velocity son enfoques lineales basados en el reduccionismo y el determinismo. Como tales, no se ajustan bien a los problemas en el dominio complejo no lineal, como el software o los problemas del mundo de hoy día.