Scrum en la practica

Scrum Masters: El bueno, el feo y el malo

Hay una secuencia lógica que aquellos alumnos que han asistido al curso de Professional Scrum Master experimentan: Darse cuenta que Scrum no es en muchas ocasiones lo que ellos pensaban. Preguntarse qué hace el Scrum Master todo el día. Y una tercera que revelaré más adelante.

La mayoría de las organizaciones entienden al Scrum Master en un rango que va del Jefe de Proyecto latigador clásico al Psicólogo de equipo, pasando por el entretenedor y facilitador oficial. Sin embargo, esas no son sus funciones.

Lo que dice la guía de Scrum es: El Scrum Master se encarga de gestionar y mantener Scrum y de eliminar impedimentos. La primera parte está clara. Asegurarse de que Scrum funcione, bien explicando cual es el valor de cada uno de los elementos de Scrum (+10 Scrum Master) bien organizando y forzando a la organización a seguirlos (+0 Scrum Master).

La segunda está menos clara. La mayoría de las interpretaciones van por el camino de facilitarle la vida al equipo, facilitar que el equipo pueda entregar y facilitar que el producto salga adelante. Esto, que no deja de ser correcto, da lugar a ciertos problemas.

Muchos Scrum Masters con poca experiencia de verdad en Scrum optan por centrarse en el equipo. Facilitar que el equipo haga reuniones y que tenga las herramientas que necesitan a su disposición, en ocasiones encargándose personalmente del mismo.

Sin embargo, aquellos que tienen experiencia, dejarán al equipo de desarrollo autoorganizarse y se centraran en eliminar impedimentos a la agilidad organizacional: desde explicar y hacer entender el valor de Scrum hasta la interacción con la organización de desarrollo para incorporar mejores herramientas, pasando por identificar y explorar que mejoras internas se pueden hacer para que el equipo se autogestione mejor.

Si no lo has leído bien, lo repito. Los Scrum Masters más malos son aquellos que se centran en facilitarle la vida al equipo, impidiendo que sean ellos los que se auto gestionan, mientras que no promueven el cambio organizacional para que la organización mejore.

Un ejemplo: En uno de mis clientes, mientras que uno de los Scrum Masters se afanaba en ayudar al equipo a finalizar el testing para entregar al final del Sprint, otro explicaba a la organización cual es el valor de invertir en testing automatizado.

Una vez que el mensaje había calado, los equipos de desarrollo se hicieron cargo de implementar todo el proceso. El Scrum Master del primer equipo se quejaba de que ahora no tenía mucho que hacer. ¡Claro! Nunca había hecho realmente su trabajo.

Influenciar sin autoridad

En otro cliente, los Scrum Masters habían formado una especie de sindicato donde se reunían para llorar sus penas y exigir mejoras. Se llamaba el Scrum of Scrums. Al final, consiguieron que la organización los nombrara a todos Development Leads. A los pocos meses dejaron de hacer Scrum para hacer un híbrido que se inventaron. Hoy lo anuncian en twitter como la nueva revolución ágil.

El dilema del Scrum Master es precisamente ese: Cómo influenciar a la organización sin autoridad para hacerlo. Los Scrum Masters no deben de tener autoridad en la jerarquía funcional de la organización. Hacerlo supone dar un poder que no necesitan en primer lugar.

Mi día a día como Scrum Master

Cuando ejerzo de Scrum Master, generalmente no voy a los Daily Scrums ni facilitó Retrospectivas. Estas cosas bien puede hacerlas un equipo de desarrollo que se auto organiza. Cada vez que hago algo por el equipo que pueden hacer ellos, les estoy quitando una oportunidad de aprendizaje.

Así que me centro en lo que impide que el equipo de desarrollo y el producto avance. E intento evangelizar, apoyar, mentorizar y explicar cómo las cosas se pueden hacer ágilmente. Todo el tiempo libre que -deliberadamente- tiene el rol está para eso, no para arreglar teclados a los miembros del equipo de desarrollo.

Aquí llegamos a la tercera revelación de los alumnos del PSM: Eso es tremendamente difícil Jero. Ya. Lo se. Nadie dijo que fuera fácil. Fácil es tener un rol como el de Scrum Master y pintar dibujos a lo largo de toda la empresa mientras el conocimiento sobre Scrum es nulo, el pipeline de Delivery es desconocido y la empresa sigue funcionando por proyectos.

Además de fácil, es un poco irresponsable.

En Scrum lo que importa es la velocidad

La velocidad es uno de los temas de Scrum más discutidos online y offline. Sólo hace falta acercarse a la comunidad de Scrum Masters en Facebook para comprobar como muchas de las cuestiones planteadas están en la linea de la velocidad de entrega de los equipos de desarrollo de Software.

En muchas compañías, existen sofisticados métodos de estimación basados en la velocidad y yo mismo he tenido la oportunidad de usar -y odiar- hojas de excel que hacen estimaciones basadas en Puntos de Historia de usuario para intentar manejar la incertidumbre.

Es tal la obsesión que muchas organizaciones y Scrum Masters jóvenes hacen de la velocidad su arma de trabajo. Contar Story Points. Hacer proyecciones. Aleccionar al equipo a cumplir sus compromisos y a esforzarse más.

Sin embargo, leyendo la guía de Scrum, no hay ningún sitio donde se hable de velocidad. Concretamente, en Scrum se habla de estimar los PBIs (Product Backlog Items) como parte del proceso para refinarlos y que estén listos.

Es la asignación de Puntos de Historia junto con el popular planning póquer y la obsesión insana por evitar cualquier tipo de riesgo lo que lleva a las organizaciones que usan Scrum a hacer todo este trabajo de presión y previsión que es, en la mayoría de los casos, inútil.

El motivo por el que estimamos en Scrum es simple: El desarrollo de Software es complejo, e incluir a muchas personas en crear una pieza de algo complejo, añade más complejidad todavía. Las estimaciones son una herramienta para facilitar una conversación.

Uno de los miembros de mi equipo de desarrollo considera que un ítem conlleva 2 puntos y otro considera que conlleva 12. Parece claro que uno de los dos se está perdiendo algo. Quizás el primero no esté considerando todos los aspectos contenidos en la Definition of Done. O por el contrario, el segundo puede estar obviando una solución mucho más simple que la que tenía en mente. Esta estimación nos ha facilitado una conversación.

En Scrum no importa la velocidad. Lo que importa es entregar software terminado al final de cada Sprint. Y poner ese Software enfrente del cliente lo más tempranamente posible. Esos datos, junto con algunas herramientas, nos pueden dar una fiabilidad bastante buena de nuestra predicibilidad para los próximos meses. Los puntos de historia no. Las estimaciones no. Estos solamente son herramientas para tener una conversación.

Un buen punto de partida es echarle un vistazo a la guía de #NoEstimates que contiene múltiples enlaces a técnicas alternativas de previsión de entrega que están al margen de puntos de historia. En Kanban, también utilizamos herramientas estadísticas como las simulaciones de Montecarlo que nos dan un nivel de fiabilidad bastante bueno sobre la capacidad de cumplir fechas y compromisos.

Para esto hacen falta datos. Intentar estimar sin tener al menos tres o cuatro medidas (Sprints terminados) es simplemente una locura. Dependiendo del modelo estadístico que utilicemos necesitaremos entre tres y veinte medidas para poder dar una previsión con un alto nivel de fiabilidad.

Un problema nuevo

Esto nos lleva a un problema nuevo. Necesitamos datos fiables y en mi experiencia, lo que los equipos de desarrollo entregan en muchas organizaciones es simplemente cero. Nada. Desde no completar los requerimientos funcionales hasta no cumplir los requerimientos de puesta en producción.

Es por eso que antes de empezar a pensar en velocidad, tenemos que cumplir Scrum e introducir cuantas prácticas de ingeniería sean necesarias para así poder tener estimaciones fiables.

Quizás el principal problema es que cuando enfrentamos a los que toman decisiones en las organizaciones con la realidad de los datos de sus equipos, no quieren admitir que el problema no es la velocidad, sino que el Software que se desarrolla no cumple, ni ha cumplido nunca, un estándar de calidad para ponerlo en producción.

A pesar de todos nuestros Scrum Masters, Estimaciones, Project Managers y compañía, en realidad nunca hemos dejado de hacer Software como si de hacer un puente se tratase.

Es mucho más fácil hacer estimaciones a ojo y llamar a esa información velocidad. Pero eso no es Scrum. Porque en Scrum la velocidad no importa. Importa el software terminado.

#ScrumClinic: De Proyectos cerrados a Proyectos Agiles

Hola Jerónimo,
He descubierto tu página hace poco y desde entonces soy un asiduo a ella. Es más a raíz de tus posts ya tengo en mis manos el libro de Scrum – A pocket guide de Gunther Verheyen.
Te cuento, he estado 5 años trabajando en una empresa de IT que apuesta muy fuerte por las metodologías ágiles. Hace 7 meses cambié a otro sitio y aquí me está costando mucho hacerles ver las ventajas de trabajar con Scrum frente al waterfall tradicional.
Aquí cuando entra un proyecto nuevo, en base a una estimación sobre suposiciones se elabora un plan de proyecto y una oferta económica que acaba siempre en incumplimientos de fechas de entrega y budgets.
Como ahora me toca más de cerca el tema de los presupuestos no tengo muy claro cómo hacer con Scrum para presupuestar un proyecto. Te pongo ejemplos. Si en una fase inicial donde apenas conocemos el alcance del proyecto y el cliente está pidiendo un presupuesto, o incluso si nos presentamos a un concurso, cómo podemos hacer para decirle al cliente lo que le va a costar el proyecto?
Scrum se basa en el empirismo y en la confianza entre cliente y proveedor, pero cómo le puedes decir a un cliente que de primeras no tienes ni idea de lo que le va a costar el proyecto y que hasta digamos la mitad del transcurso del proyecto no tendremos una idea aproximada de lo que puede llegar a durar (y por tanto) costar su proyecto.
Muchas gracias por adelantado!

Alberto Gómez

El mito del 100% de certidumbre

Me parece una pregunta muy interesante, y quizás la respuesta que pueda dar parezca sorprendente. Vamos allá:

Cuando te pregunten por proyectos cerrados, responde con complejidad y métricas de predictibilidad. NO discutas sobre lo indiscutible. En lugar de eso fomenta una conversación que ayude a pensar en cómo mejorar.

Una de las habilidades más importantes como Scrum Master es tener la capacidad de establecer el contexto adecuado a la hora de hablar de problemas y soluciones. Ver más allá de la cuestión e intentar establecer nuevas ideas para que las personas con las que trabajamos puedan desarrollar su propia visión de las cosas.

El caso que me comentas me lo he encontrado muchas veces a lo largo de mi carrera. A pesar de querer utilizar Scrum, las organizaciones insisten en tener fechas, alcances y precios cerrados. Lo ven como un factor de reducción de la incertidumbre y algo a lo que agarrarse en caso de que las cosas vayan mal. Y es que las cosas irán mal. Y no porque no hagamos nuestro mayor esfuerzo en ceñirnos al plan. Sino porque el plan, desde el primer momento que lo escribimos, está mal.

El desarrollo de Software como entorno complejo

Déjame presentarte a Dave Snowden. Es uno de los contribuyentes más importantes al movimiento ágil y sin embargo, despotrica de Scrum cada vez que tiene oportunidad ¿Por qué? Porque ve como Scrum se ha convertido en el palo con el que las organizaciones atizan la complejidad.

Dave es experto en complejidad. Basándose en el trabajo de Ralph Stacey, ha creado el framework Cynefin (Pronunciado Kin-fin) dentro de su compañía para explicar este concepto.

Sí, los planes funcionan en entornos simples y en parte de los complicados, pero en el momento que aumentamos la complejidad, es imposible mantener un plan y de tontos intentar ceñirte a él. En esos entornos, es mejor contar con una forma de trabajo que permita inspeccionar y adaptar.

Te daré un ejemplo. Si tengo una habitación que mantener a la misma temperatura todo el día, ¿Cuantas variables influyen?

Muchas. Muchísimas.

¿Tendría sentido hacer un plan para todo lo que hay que hacer en la habitación (poner el aire, quitar el aire, poner la calefacción, abrir las ventanas) para ejecutarlo una vez al día? ¿O tendría más sentido utilizar un climatizador, que se encarga de inspeccionar la temperatura y adaptarla? Scrum es al Software lo que el climatizador es a la habitación. Nos permite descartar variables, inspeccionar y adaptar en entornos complejos.

Para aquellos clientes que demandan predictibilidad, no hay más que utilizar herramientas que tienen en cuenta la complejidad, como son el cono de incertidumbre, No Estimates o el uso de simulaciones de Montecarlo para poder estimar basados en situaciones previas.

Ten en cuenta que el truco es tener un histórico. Si no existe un histórico de delivery de ese equipo en ese proyecto, es imposible dar ningún tipo de predictibilidad. Tampoco si el equipo ha estado en otro proyecto. Lamentablemente este es el mundo del Software. No importa cuanto le grites a un cable, no va a transmitir más bits por segundo.

La próxima vez que te veas en esta situación, en lugar de decir ¡No se puede!, intentar crear una conversación sobre complejidad y sobre la experiencia de la compañía en el pasado con estas situaciones, para dar paso a una discusión sobre métricas alternativas de predictibilidad que ayuden al cliente y a la organización a entender mejor el proceso.

Por último te recomiendo un libro: Actionable Metrics for predictability, que ahonda mucho más en este tema.

Con paciencia y perseverancia, empezarás a tener conversaciones que hagan que el rumbo de la compañía cambie.

No me llames SCRUM

Scrum cumplió 21 años en 2016. Ya tiene edad legal para comprar alcohol en la mayoría de estados americanos. Y durante este tiempo ha crecido mucho. Con muchos cambios.

Cuando en 2011, Ken Schwaber y Jeff Sutherland decidieron publicar la guía oficial de Scrum, lo hicieron atendiendo a un problema cada vez mayor: Cada profesional veía Scrum de una manera distinta y, lo que en su momento eran una serie de reglas, se convirtió en algo que quedaba a la más pura interpretación del profesional que lo implantaba.

Desde 2011 ha habido dos grandes cambios en la guía de Scrum, en 2013 y 2016. Primero, se eliminaron algunas cosas, como los diagramas de burndown. Se reforzó el énfasis en el Daily Scrum como elemento de planificación -y no solamente sincronización- y también se cambió el nombre de la reunión de grooming a refinenement.

En 2016 se añadieron los valores de Scrum, aquellos que hacen que el marco funcione en una organización, además de algunos cambios menores. Puedes consultar todos los cambios de las guía de Scrum aquí.

Una de las cuestiones importantes que trajo la guía de Scrum es que dejó de llamarse SCRUM. Hace muchos años, cuando se publicó el paper original sobre Scrum, se eligió en mayúsculas para darle más énfasis. Sin embargo, parece que muchos profesionales siguen tratándolo como si de un acrónimo se tratara.

Si quieres seguir investigando más, te recomiendo también la lectura del The New New Product Development Game, en el que se describen las reglas que dieron lugar al que hoy es el framework de desarrollo de Software ágil más usado en el mundo.

Uno de los énfasis que hacemos en Scrum.org es en el uso del lenguaje en lo que a Scrum se refiere. El Sprint Review es una reunión de negocio, no una demo. El Sprint Planning es para el equipo Scrum, no para los Stakeholders. Estas cosas marcan la diferencia en el entendimiento sobre las responsabilidades que cada una de las personas que están afectadas por Scrum, tienen. Mejoran la comunicación y reducen la fricción.

Scrum es un nombre propio, y por eso se escribe capitalizado, tanto en Castellano como en Inglés.

Cuando veo un profesional con años de experiencia escribiendo SCRUM, me pregunto: ¿Qué otros conocimientos no habrá actualizado?

6 errores evitables que cometen los equipos Scrum

El otro día alguien me preguntó cuales eran los errores típicos que veía en equipos Scrum que empezaban.
Mi respuesta fue sorprendente: ¿Los que empiezan? Los que más problemas tienen son aquellos que ya llevan mucho tiempo funcionando.

Error 1: Mucho Work in Progress

Acaba la primera parte del Sprint Planning y el equipo empieza a desgranar los PBIs en tareas, los estiman y cada uno de los miembros del equipo empieza a trabajar en un ítem distinto.

Eso provoca que luego haya problemas de integración y silos en los cuales el equipo no tiene ni idea de que está pasando. Los equipos maduros empiezan algo y no empiezan lo siguiente hasta que no lo terminan, manteniendo una o dos tareas en paralelo al mismo tiempo.

Cuando llega el final del Sprint, la mayoría de las cosas están a medio acabar y no da tiempo a integrar. Sin embargo el Product Owner aprieta para mostrar cuanto más mejor en el Sprint Review y el equipo de desarrollo añade la «deuda técnica» al backlog, para re visitarla… nunca.

Error 2: Falta de Sprint Goal

El Sprint Backlog se convierte en un cajón de sastre en el que entran decenas de cosas que no tienen nada que ver las unas con las otras, lo que hace que no haya coherencia y se pierda el desarrollo iterativo e incremental y la transparencia.

El Sprint Goal es una dirección general que ayuda al equipo a mantener el foco en cual es el objetivo de este incremento. El Sprint Backlog puede cambiar, el Sprint Goal no. Eso permite flexibilidad para lidiar con cosas que no estaban planeadas y un mejor enfoque en las necesidades de negocio.

Cuando no tenemos un Sprint Goal que de dirección, perdemos una herramienta muy potente que promueve dos de los valores de Scrum: Coraje y Compromiso. Entonces Scrum se convierte en un proceso más dentro de la compañía, además de perder foco en el valor de negocio entregado en cada incremento.

Error 3: Asignación individual de tareas

Los miembros del equipo de desarrollo trabajan individualmente en tareas hasta que las completan y luego pasan a trabajar en otra cosa. Eso provoca, de nuevo, falta de integración y posibles problemas de dependencias.

Algunos equipos tienen normas para lidiar con esto. Por ejemplo, tiene que haber un code review por al menos dos miembros del equipo. Trabajar en pares. Muchas veces con poca efectividad, sobre todo si la carga de trabajo es alta.

La única manera de lidiar con esta situación es, lamentablemente, reducir la carga de trabajo. Paradójicamente, el ahorro de entregar más rápido se traduce en cuatro veces más para reparar la deuda técnica y de conocimiento que supone ese ahorro.

Además, cuando se maximiza la utilización, se tiende a perder valor. ¿Cómo? Aumentando el tiempo de entrega. Cuando el equipo se enfoca en entregar unas cuantas cosas bien hechas, quizás esté perdiendo eficiencia, pero se asegura de entregar, lo cual ya supone una gran diferencia con muchos equipos, que trabajan en cosas durante meses sin llegar a entregarlas… nunca.

Error 4: Falta de responsabilidad

En Scrum, el rol responsable de dar cuentas sobre el incremento es el equipo de desarrollo. Que el nombre no nos lleve a engaño. Todos los miembros del equipo de desarrollo dan cuentas sobre todo el incremento.

No existe la individualidad del desarrollador en Scrum. Desafortunadamente, eso lleva a muchos miembros del equipo de desarrollo a quejarse porque ellos sí hacen su trabajo.

La manera de actuar es la de dejar que el equipo se autoorganice y lidia con esos problemas. Y la del Scrum Master no es actuar sobre los miembros que consideramos destacados o vagos, sino mantener esa discusión dentro del equipo, sin que escale en la organización.

En el caso del Product Owner, él es el responsable de dar cuentas de la inversión que hace en el equipo de desarrollo cada Sprint. Y tiene que hacerlo con datos. Si la calidad técnica del producto falla, de rebote el Product Owner se convierte en responsable.

Error 5: Maximización de utilización o eficiencia

Este es, sin duda, uno de los peores que puede tener una organización. Enfocarse en que la gente trabaje muchas horas en lugar de generar valor.

No nos equivoquemos. Estos dos objetivos son totalmente incompatibles. El desarrollo de software, por su propia naturaleza, incurre en una variabilidad muy grande y no es posible estandarizar tareas, duraciones, problemas o buenas prácticas.

La realidad es que cada vez que hacemos algo en software, por muchas veces que creamos haberlo hecho antes, nos enfrentamos a algo totalmente nuevo, en un entorno nuevo, un sistema nuevo, que nunca habíamos hecho antes. Es ineficiente porque aprendemos sobre la marcha.

Las ineficiencias aparecen en forma de miembros que no tienen suficiente trabajo, otros que están sobrecargados y otros problemas intermedios. El temor a que la gente esté parada lleva a introducir trabajo no necesario para generar valor y que la gente esté ocupada.

El resultado es que cuando el trabajo que tienen que hacer esos miembros es necesario, están ocupados haciendo otra cosa. Están siendo eficientes. Y haciendo perder dinero a la compañía.

Error 6: El equipo de desarrollo es el equipo de desarrolladores

El último es, quizás, el más desconocido. Debido a su nombre, los profesionales en Scrum piensan que un equipo de desarrollo tiene que estar formado por gente técnica: programadores, ingenieros de operaciones o calidad.

Nada más lejos de la realidad. El equipo de desarrollo tiene todos los perfiles necesarios para poder entregar un incremento de producto. Si eso supone que tienen que incorporar a un Business Analyst, un especialista en SEO o un diseñador, también son miembros del equipo de desarrollo.

Si ves que tu equipo se está acercando a alguno de estos errores o que el proceso de Scrum no está desarrollando adecuadamente, te recomiendo el artículo Cuatro señales de que Agile no funciona en tu organización.