Blog

Cómo solucionar un Daily Scrum que no funciona

En el artículo anterior vimos cinco ejemplos de un Daily Scrum disfuncional. Para que no tengas que pinchar te los recuerdo aquí.

Es un reporte
Respondemos a las tres preguntas
Falta gente
No ocurre sin el Scrum Master
Nunca hay follow-ups

Hoy quiero centrarme en soluciones que no son obvias y los motivos por los que éstas situaciones pueden estar sucediendo.

Arranquemos.

Pedagogía de Scrum

Uno de los primeros pilares en los que tiene que centrarse un Scrum Master para poder habilitar el funcionamiento de Scrum como herramienta para ser más ágiles es que las personas que participan del proceso entiendan Scrum.

No puedes esperar que quienes participan o utilizan un proceso o herramienta para hacer su trabajo la utilicen correctamente si no entienden para qué sirve.

Una de las cosas más comunes que hago nada más llegar a una organización es preguntar: ¿Para qué estamos haciendo esto? ¿Por qué nos reunimos durante 15 minutos todos los días?

Habitualmente la respuesta esconde el problema: Para reportar que hicimos ayer, para sincronizarnos, para tener al día al Product Owner.

Es entonces, y sólo entonces, cuando podemos recordar que el Daily Scrum existe para inspeccionar el progreso hacia el Sprint Goal y adaptar nuestro plan en consecuencia.

Tras esto, la reacción que podemos esperar es descubrir el motivo de fondo que lleva a que el Daily Scrum sea inefectivo. La falta de un Sprint Goal hará que no tengamos el elemento central de este evento. Que no exista un plan que seguir durante el Sprint provocará que no tengamos nada que adaptar.

Inexistencia de un producto

Scrum es un framework magnífico para desarrollar productos que tienen que lidiar con problemas complejos.

Si no tenemos un producto, una planificación, un roadmap, una estrategia y un entendimiento compartido de cual es la visión de lo que hacemos, difícilmente podremos esperar que un equipo Scrum inspeccione un Sprint Goal para adaptar su plan de trabajo de 24 horas.

De hecho, si nuestro objetivo es utilizar Scrum para entregar algo que está cerrado en fecha, coste y funcionalidad, probablemente la disfuncionalidad del proceso con el que hemos definido el trabajo (alcance, tiempo y coste) termine trasladándose inevitablemente al trabajo que hacemos diariamente.

Es en este caso cuando lo que esperamos de nuestro equipo Scrum es que sean capaces de convertir requerimientos en código -u otro producto- a la máxima velocidad posible.

¿Es esto posible? Por supuesto.

¿Es esto útlil? Existe una duda razonable.

En primer lugar hay que tener en cuenta que en el mundo en el que vivimos realmente ya no existe el concepto proyecto, entendido como algo que tiene un principio y un fin. Por tanto, intentar gestionarlo todo con esa mentalidad sólo conlleva frustración e ineficacia a largo plazo.

En segundo lugar, un Product Owner capaz de crear, fomentar y transmitir una visión en torno a un producto es un activo increíblemente valioso para cualquier organización porque habilita la estrategia de esa misma organización y la conexión entre negocio y tecnología.

Esa batalla -la de negocio y tecnología- no existe. Son dos caras de la misma moneda. Una moneda que se acuña a través de productos. Porque los productos existen, queramos o no, y es nuestro deber sacarles partido con la máxima profesionalidad posible.

Falta de skills

Superados estos dos primeros problemas profundos puede ser que todavía nos encontremos con un Daily Scrum inefectivo. Y esto puede ser debido a que las personas que forman y hacen el mismo no tienen los skills o la motivación para hacerlo funcionar.

Sorprendentemente nunca me he encontrado con un equipo obligado a hacer Scrum en el que todos los miembros del mismo estuvieran desmotivados o se negaran a llevarlo a cabo.

Puede que una o dos personas no quieran participar del juego de Scrum y es labor de un Scrum Master facilitar que se integren o facilitarles una salida, pero sinceramente éstos no han sido los casos habituales que he encontrado.

En cualquier caso, si esta es la situación hay que valorar si realmente merece la pena hacer Scrum o intentar crear un clima de trabajo y colaboración antes de seguir adelante.

Cuando pienso en los motivos que relataba la semana pasada, creo que estos tres temas tocan todos de una manera u otra.

Al final, hacer Scrum es acordar trabajar bajo unas reglas de transparencia, inspección y adaptación.

Cinco señales de un Daily Scrum disfuncional

Cuando se trata de analizar por qué un evento en Scrum no funciona, frecuentemente hay que mirar más allá del formato o de la actitud de los participantes y centrarse en los motivos profundos que hay detrás del funcionamiento del evento.

Anteriormente ya hemos hablado de la efectividad de los Scrum Masters, de cómo mantener vivas las iniciativas ágiles en tu organización y de cómo trabajar activamente para destruirlas. Hoy lo haremos desde el punto de vista del Daily Scrum.

A pesar de la importancia de este evento para favorecer la transparencia, la inspección y la adaptación, son muchos equipos los que perciben este evento diario como una carga en lugar de un espacio productivo para inspeccionar y adaptar el trabajo para conseguir metas.

Veamos los cinco signos más importantes de que el Daily Scrum no funciona.

Signos de que el Daily Scrum no funciona

Es un reporte

Los miembros del equipo Scrum van, uno por uno, explicando en qué estaban trabajando ayer y en qué van a trabajar a lo largo del día de hoy.

En aquellos equipos más inmaduros, a lo largo del tiempo se reduce a: “Voy a seguir trabajando en lo que hice ayer y seguiré haciendo mañana”. En muchas organizaciones esta es la oportunidad diaria para que Product Owners, Scrum Masters, Jefes de Proyecto y otras especies de la organización realicen su control diario para comprobar que todo el mundo está trabajando.

Por otro lado, este método es cómodo para los miembros del equipo Scrum que simplemente quieren marcar la casilla de “Hacemos Scrum” y seguir trabajando en lo suyo durante el resto del Sprint.

Responder a las tres preguntas

“¿Qué hice ayer para contribuir al Sprint Goal?” “¿Qué voy a hacer hoy para contribuir al Sprint Goal?” “¿Qué impedimentos tengo para conseguir el Sprint Goal?”

Esta es una variante del anterior. Normalmente indica que existe un Scrum Master que se leyó la guía de Scrum y quiere que se haga Scrum como-lo-dice-la-guía. En realidad no deberíamos esperar mucho más que en la versión anterior, ya que cuando alguien no quiere explicar que en esta organización no hay Sprint Goals ni planificación de producto porque trabajamos en proyectos de alcance, tiempo y coste cerrado, lo que hace es marear la perdiz un poco para responder lo mismo que hemos visto anteriormente.

De hecho, en la actualización de la guía de 2020 el uso de las tres preguntas se ha eliminado porque sus efectos eran más perniciosos que beneficiosos.

Falta gente

El Daily Scrum normalmente tiene dos o tres faltas de personas todos los días. Hay miembros del equipo que reportan por otros. Hay personas que comentan por Slack lo que iban a decir en el Daily Scrum y -en su versión más visual management– otras dicen que han actualizado los Post-its en el tablero.

La sensación es que la mayoría de los miembros del equipo Scrum no están involucrados con la forma de trabajar y ven el Daily Scrum como una carga en lugar de algo que pueda ser útil para ellos.

No ocurre sin el Scrum Master

El Scrum Master motivado se asegura de que haya un Daily Scrum todos los días a la misma hora y en el mismo lugar. Sin embargo, cuando se va de vacaciones o dejar la empresa, los que quedan corren a eliminar una reunión más que no les aporta valor, lo sustituyen por un Daily Stand-up asíncrono -🤦‍♂️- o directamente la van moviendo de un lugar para otro hasta que no se hace más.

Nunca hay follow-ups

Para mi sorpresa, todavía hay Scrum Masters que, con la excusa de seguir lo-que-dice-la-guía, limitan el Daily Scrum a 15 minutos y nunca permiten seguimiento a temas importantes que han salido durante el evento.

Sin embargo, estos eventos Kaizen espontáneos son tanto o más importantes que el propio Daily Scrum, ya que permiten la adaptación necesaria para poder alinearnos en torno a un objetivo común -el Sprint Goal-.

La importancia del Daily Scrum

Scrum está basado en tres pilares: Transparencia -todos sabemos lo que está ocurriendo-, inspección -podemos comprobar el trabajo conforme se hace- y adaptación -podemos cambiar la dirección táctica.

El Daily Scrum juega un papel fundamental en asegurar que durante el Sprint este proceso se sigue y nos permite adaptarnos a los problemas y necesidades que vamos encontrando.

Cuando el Daily Scrum se estanca es difícil que podamos realizar ningún tipo de adaptación porque no hay transparencia sobre donde estamos ni hacia donde vamos.

Y es en este tipo de situaciones donde se dan las marchas de la muerte al final del Sprint o directamente las cosas se van desbordando hacia el siguiente Sprint, eliminando la sensación de avance.

En un próximo post hablaré de cuales son los motivos por los que se dan estas -y otras- situaciones y donde aplicar esfuerzo para que poco a poco dejen de producirse.

Las fechas de entrega son sagradas

Hace unos años la CNN estrenó un documental sobre la Cienciología, sus métodos y su historia. Reza Aslan tuvo la oportunidad de hablar con aquellos que en Cienciología se hacen llamar Free Zoners.

Son aquellos que, desencantados con las prácticas de la institución, siguen trabajando para promover las enseñanzas de L. Ron Hubbard desde fuera de la Iglesia.

En su momento, este documental me hizo pensar sobre el mundo de Agile y el mundo del Coaching.

Hace más de 10 años que estudié un master en Coaching de unos dos años de duración en una escuela de prestigio.

Aprendí muchas cosas sobre un grupo de prácticas y técnicas que a lo largo del tiempo, por un lado se han profesionalizado y por otro se han convertido en humo -cualquiera puede hacerlo-.

Hoy el coaching está más que nunca presente en nuestras vidas.

La mayoría de la gente ha escuchado hablar del mismo y muchos han hecho una cursos para aprender técnicas que, en la mayoría de las ocasiones, no tienen nada de ayuda para el acompañado y se basan más en manipulación y violencia emocional.

El Agile Coach

El título de Agile Coach se ha ido forjando con los años para denominar a aquellos que se encargan de promocionar una visión holística de los métodos ágiles más allá de una o dos metodologías.

Personas que, además del conocimiento, poseen una amplia experiencia en la aplicación de las mismas a dominios concretos, como el desarrollo de Software.

De hecho, en muchas organizaciones el Agile Coach se ve como el siguiente paso de evolución de un Scrum Master. El problema, al igual que en el coaching a secas, es que cualquier cosa vale.

En uno de antiguos clientes, tuvieron una experiencia horrible con un Agile Coach que se centró más en hacer de Psicólogo de la organización que en aportar ninguna herramienta que mejorara los procesos de la misma.

¿Por qué?

Porque es más fácil saber de algo de lo que no sabe nadie más y centrar los problemas en que los miembros del equipo de desarrollo sufren de dolor emocional y necesitan terapia de equipo.

Cuando, al cabo del tiempo, este Agile Coach se vio presionado por parte de la organización para saber de qué manera se podían mejorar los productos, la calidad y la entrega, se convirtió en el peor de los déspotas que no tuvo ningún reparo en sacar el látigo y ponerse a motivar programadores.

Hace unos años, David Bonilla decía lo mismo en su Newsletter: La fecha de entrega es sagrada, Agile o no Agile.

Fechas de entrega

No creo que David se considere de esa casta de gente que aprieta a la gente por beneficio propio.

El problema es que, cuando las cosas aprietan, nos quitamos las caretas y vemos lo que realmente es importante para nosotros.

Al fin y al cabo: Si descubrimos a nuestra esposa con otro, vemos nuestra casa en llamas y descubrimos que nos hemos sentado en un avispero, ¿De cual de los problemas nos vamos a ocupar primero?

Los métodos ágiles no tienen mucho que ver con las fechas de entrega.

Cualquier persona que, trabajando en la industria del Software da fechas -sagradas- de entrega a más de dos o tres semanas vista, no solamente es un inconsciente sino que además es poco profesional.

Este es el elefante en la habitación del mundo del desarrollo de Software. No es que nos desviemos un poco, es que en ocasiones el desvío es de órdenes de magnitud. Y esto es debido a la complejidad del mundo del software.

Las fechas de entrega no son un deseo, sino un resultado.

Solamente puedes tenerlas cuando mides la realidad de la empresa. Comprometerte a una fecha de entrega en el mercado del Software es como comprometerte a que mañana Lunes llegarás de Chamartín a Pozuelo de Alarcón en 30 minutos.

Quizás lo consigas o quizás no. Porque no depende de tí, sino de un mundo complejo en el cual tienes poca capacidad de controlar las variables que van a tener efecto en tu resultado.

Scrum no es sino un marco que nos permite eliminar las variables de promesas e inspeccionar y adaptar conforme vamos haciendo. Estoy en Chamartín, el cercanías va retrasado ¿Adapto? ¿Cambio mi plan? No tiene nada que ver con entregar, excepto en que Scrum no tiene sentido si no entregas.

Entregar no es entregar en una fecha. Es ser transparente con tu trabajo. La fecha de entrega no es sagrada. Es el deseo estúpido de un inconsciente.

Las metodologías ágiles y el Agile Coaching tienen que sufrir una reforma, al igual que le está pasando a la Cienciología. Porque si no, Agile terminará teniendo la misma percepción para el público que la Cienciología. La de una secta.

No importa si te sientes identificado con las creencias y valores que promulgan o no. Lo que hay que reformar es que cualquiera no pueda llegar a un cliente y pasar de hablar de terapia de equipo a motivar con el látigo con la excusa de las metodologías ágiles.

Soy consciente de que, al igual que los Free Zoners de los que hablaba al comienzo de la Newsletter, hay muchas personas que se sienten decepcionadas con la manera en que ciertos métodos, metodologías o librerías han tratado a sus creyentes de tal manera que se han convertido a formas de ser y de actuar alternativas.

Para terminar, te dejo un video que publiqué en Youtube aclarando el trabajo que tiene que hacer un Scrum Master.

¿Tienes datos que confirman el éxito? Probablemente estén mal

Desarrollar productos es difícil. Desarrollar productos que tienen éxito es prácticamente imposible.

Cuando mi amigo Ignacio arrancó su empresa hace casi tres lustros, se pasó varios años leyendo libros de emprendedores, asistiendo a charlas motivadoras y haciendo análisis de todos los datos de los que disponía para asegurar el éxito del producto que estaba desarrollando.

Hace unas semanas nos tomamos un café y me dijo: “¿Sabes lo que he aprendido en 15 años? Que el factor suerte es más importante que cualquier cosa que hagas”

El foco en las métricas

Durante bastante tiempo, el producto que desarrollaba su empresa tenía unas métricas envidiables. Incluso le sirvió para conseguir inversión externa durante los difíciles momentos que siguieron a la crisis del 2008.

Sin embargo, algo no terminaba de ir bien.

Como me dijo una vez, las métricas se parecían más a tapones de un barco que hacía aguas que a trampolines que impulsarle al siguiente nivel.

Cuando ponía el foco en una métrica ésta mejoraba, pero en contraste, otra empeoraba. Cuando se enfocaban en la segunda, la primera dejaba de mostrar buenas tendencias.

Aquí intervienen varios factores que hay que tener en cuenta para entender la situación.

La pérdida del valor informativo

En el libro Measuring and Managing Performance in Organizations, Robert Austin explica que una vez que convertimos una métrica en el objetivo de un incentivo -véase las comisiones por ventas- con el objetivo de mejorar su rendimiento, automáticamente pierde su capaz de informarnos de la realidad de la situación.

La agente comercial que sabe que una parte de su sueldo depende del número de ventas que haga tenderá a jugar con los números, ya sea contabilizando posibles ventas de dudoso valor o moviéndolas entre trimestres o meses naturales dependiendo del cálculo de los incentivos.

El teleoperador que sabe que necesita un número mínimo de valoraciones positivas para cobrar un incentivo que puede suponer el 10% de su salario mensual desarrollará estrategias para evitar que los clientes descontentos lleguen a realizar la valoración; por ejemplo invitándoles a terminar la llamada antes de la encuesta de satisfacción.

Los equipos Scrum que ponen el foco en las mecánicas del framework probablemente terminen siendo poco efectivos, tal y como comentaba en un artículo previo y sus iniciativas ágiles es posible que terminen muriendo.

Un caso interesante de este tipo de situaciones se puede ver en el episodio dedicado al banco Wells Fargo de Dirty Money en Netflix. Durante varios años, los ejecutivos del banco ligaron el rendimiento de sus empleados exclusivamente a su capacidad de vender productos financieros. Esto desemboco en una cultura tóxica en la que los empleados del otrora banco familiar y confianza de las diligencias del oeste americano, terminaron estafando a su clientes, empleados y familiares con el único objetivo de cumplir con los objetivos impuestos por la empresa.

Cuanto más notable sea un dato, más probabilidad de que sea erróneo

El motivo es que los errores y la manipulación de datos son más comunes que los resultados genuinos. Cualquier investigador sabe que tras cientos o miles de horas de preparación de hipótesis, toma de datos y análisis lo más probable es que obtengamos conclusiones aburridas.

Esto se conoce como la ley de Twyman y es una de las leyes más importantes en análisis de datos.

Los descubrimientos disruptivos o Breakthoughs son poco comunes. Menos de lo que podamos imaginar. Por tanto, según Twyman, cuando observemos datos extremadamente notables, lo primero que deberíamos de hacer es dudar de ellos.

Es por esto que en ciencia se recurre constantemente a la revisión por pares y a la refutación de hipótesis replicando estudios.

El objetivo es asegurar que aquellas cosas que damos por sentadas son realmente correctas.

El pasado año un caso sobre posible fraude en la toma de datos puso al investigador Dan Ariely, conocido por sus estudios sobre la honestidad, al pie del cañon.

Ariely, una conocida estrella mediática, condujo una serie de estudios sobre honestidad en los que intentaba descubrir por qué las personas mentimos. A raiz del estreno del documental (Dis)Honesty: The truth about lies, algunos investigadores intentaron replicar sus resultados sin éxito.

Esto desembocó en una acusación de que el autor habría fabricado los datos de sus investigaciones para que arrojaran los datos que él esperaba sobre las mismas.

El caso sigue en investigación por la Universidad de Duke y no deja de ser paradójico que el autor de una investigación sobre deshonestidad termine siendo acusado de fraude.

El sesgo de confirmación

Por último, existe el sesgo de confirmación, por el cual tendemos a prestar más atención a aquellas cosas que esperamos confirmen nuestras propias creencias.

Cuando uno pasa horas escuchando que es posible tener éxito y conoce historias de emprendedores de éxito, cualquier dato que confirme la creencia de que va por el camino correcto será, por definición, un dato importante.

Nunca conoceremos a aquellos que han fracasado por el camino. Solo a los supervivientes.

Si trabajamos desarrollando productos o prestando un servicio susceptible de ser medido, es importante que tengamos en cuenta que los datos son datos, y que las historias que contamos sobre ellos son interpretaciones de los mismos.

En la medida que estos datos son revisable, accesibles y verificables, podemos estar seguro de que al menos estamos sacando conclusiones sobre algo que -en principio- es correcto, nunca que nuestras conclusiones sean correctas.

Cómo trabajar como Scrum Master externo y tener éxito

Es común encontrarnos con organizaciones que deciden adoptar una estrategia de contratar externos para ayudar a introducir Agilidad.

También es frecuente encontrar profesionales que han sufrido malas experiencias realizando esta labor.

En este artículo vamos a analizar qué problemas podemos encontrarnos al intentar adoptar una estrategia de Professional Scrum y cuales son los pushbacks más comunes.

Professional Scrum ¿Qué es?

Ken Schwaber fundó Scrum.org hace 15 años tras su paso por la Scrum Alliance.

Hay diferentes teorías y versiones sobre los motivos de su salida de ésta organización, creada tras la Agile Alliance y que compartía varios miembros fundadores.

Lamentablemente el artículo inicial con las motivaciones que le animaron a crear una nueva organización ya no se encuentra online; sin embargo, algo que ha mencionado muchas veces a lo largo de los años es que quería formar parte de una organización que se esforzara por hacer Scrum de manera profesional.

En realidad, Professional Scrum no es distinto, a nivel mecánico, del Scrum descrito en la guía oficial.

Professional Scrum es, más bien, una manera de entender y de usar Scrum. A grandes rasgos sus características pueden ser resumidas de la siguiente manera:

Unos valores sólidos en los que apoyarse a la hora de introducir Scrum y utilizarlo como el marco de referencia para construir productos.
Un enfoque en la generación de valor, a través de la construcción de productos que sean usables.
Una alta ética profesional, fomentando y mimando organizaciones que se miden a sí mismas bajo altos estándares éticos.
Un entorno de profesionalidad, donde todos los miembros de los equipos Scrum y de la organización buscan la excelencia y llegar más lejos.
Por último, una entrega constante de valor, a través de la puesta en manos de los usuarios de Incrementos de alto valor.

Como podemos intuir, Scrum en organizaciones que se limitan a aplicarlo de manera mecánica tiende a ofrecer beneficios reducidos. Es solamente cuando vamos más allá cuando podemos desatar todo el potencial de la organización.

Motivaciones para perseguir Agilidad

Cada organización tiene distintas motivaciones para poner en marcha iniciativas de Agilidad de negocio. Sin embargo, solemos encontrar dos problemas principales:

Los sponsors que deciden adoptar Agilidad lo hacen como una herramienta que solucione todos (o parte) de sus problemas
No hay una comunicación explícita de los motivos subyacentes a lo largo y ancho de la organización, lo que impide entender pero también medir como de efectiva está siendo nuestra iniciativa.

Estos dos problemas, que en mi experiencia afectan a todas las organizaciones con las que he trabajado en cierta medida, chocan de manera frontal con la manera de hacer Scrum profesional que he mencionado anteriormente.

¿A todas? A todas.

En otro artículo hablaba de la disciplina para evitar que las iniciativas de adopción de Agilidad murieran o fueran engullidas por la cultura organizacional. Hacía una analogía con el entrenamiento deportivo que es muy válida en este contexto.

No importa cuánto gastemos en implantar herramientas que si somos incapaces de entender las nuevas maneras de hacer de las mismas, toda nuestra inversión será inútil.

No hablo exclusivamente de herramientas tecnológicas. En este saco entra también Scrum.

Conflicto de agendas

Aparentemente esto es un problema de la propia organización que no tiene por qué afectar al desarrollo del trabajo de un Scrum Master externo. Es más, precisamente por ser externo probablemente tenga una capacidad de abstraerse y poner distancia con los problemas y cultura existente y plantear otro tipo de soluciones.

Terrible error.

Precisamente las empresas más afectadas por los problemas que mencionábamos anteriormente son aquellas que contratan Scrum Masters externos. ¿Para qué?

Para culparlos si las cosas salen mal.

Es muy sencillo. Cuando empezamos a trabajar en una organización nueva, es muy posible que nuestro sponsor esté motivado y nos proporcione todo el apoyo necesario para desarrollar los cambios que necesitamos para crear un entorno de Scrum profesional.

E incluso aunque esto sea así al comienzo, las personas cambian y lo que era cierto en un momento puede no serlo en otro. Incluso puede que terminemos siendo minions al servicio de la política interna.

Cómo lidiar con éstas situaciones

Para mi la única forma de lidiar con estas situaciones es siendo brutalmente transparente tanto acerca de nuestras intenciones -el tipo de enfoque que queremos darle a nuestro trabajo-, como del trabajo que estamos realizando -siendo muy organizados y comunicando qué y cómo estamos haciendo en cada momento- tanto como con los objetivos que queremos conseguir con el primer y el segundo punto.

Si no hay alineamiento es el momento de cambiar o dejar de empujar hasta que se facilite el alineamiento.

Para ello, y especialmente al comienzo, nuestra labor va a ser casi totalmente pedagógica. Hemos de mostrar el estado futuro y asegurar que quienes tienen que facilitar ese camino entienden no a donde tenemos que llegar, sino como remar todos juntos en esa dirección.

Esto, a corto plazo, puede parecer incluso dañino para vuestra carrera como Scrum Masters; sin embargo, a la larga os facilitará acceso a mejores oportunidades profesionales y os mantendrá alejados de aquellas que directamente evitarán vuestro enfoque.