Scrum but famosos y sus repercusiones

Según la Scrum guide “Scrum es fácil de entender y difícil de dominar”. Los que nos hemos dedicado a implantarlo sabemos que es complicado porque requiere de un cambio de mentalidad que cuesta conseguir. Dado que hacer Scrum tal y como describe la Scrum Guide es difícil, existe el concepto de “Scrum but”, que significa: “yo hago Scrum pero…” y se añade algún defecto.

En mi experiencia acompañando a equipos o siendo Scrum Máster, he visto muchos tipos de Scrum-Buts, casi todos los he utilizado lamentablemente: algunos, por falta de formación y experiencia y otros, por dificultades en la organización o el contexto. A continuación, vamos a comentar los que más me han llamado la atención.

En la retrospectiva no viene el PO

Este error es bastante común. En muchos equipos el Product Owner no pertenece a la misma área que el resto de las personas del equipo y por ello se le ve como fuera del mismo. Uno de los síntomas es la Sprint Retrospective a la que no se invita al Product Owner. Este es un error, hay que entender que la Sprint Retrospective sirve para buscar la mejora del Scrum Team y para ello, el Product Owner es pieza clave.

Cuando el Product Owner se ausenta continuamente acaba provocando una brecha con el Development Team. Los impedimentos los tenemos que resolver como equipo y en ese equipo, el Product Owner siempre tiene mucho que decir.

Sabemos que, a veces, esto es deliberado. No queremos invitar al Product Owner porque no tenemos confianza o porque creemos que tenemos que tratar temas de ingeniería internos y que, por tanto, se va a aburrir. No juzguemos, dejemos que venga y que, al menos, entienda que hay dificultades.

La review es una demo

Este es un clásico, utilizar la Sprint Review como una demo que realiza el Development Team al Product Owner. Como vimos en este artículo, los equipos más inmaduros utilizan la Sprint Review de manera incorrecta y se parece a una demo. Los buenos equipos utilizan el evento como un ejercicio de inspección y adaptación del mercado para saber si el producto que construyen funciona. Esta es la esencia de la Sprint Review, aunque es verdad que aún existen pocos equipos que lo interioricen y lo pongan en práctica porque requiere un cambio de mentalidad en las organizaciones que está tardando en producirse.

En la planning estimamos todas las tareas y nos comprometemos a la entrega

El compromiso de las personas con respecto a las tareas que harán en el Sprint es un error bastante habitual. Si asumimos que el software no para de cambiar, no podemos comprometernos a que estarán unas tareas en un entorno complejo porque no sabremos exactamente lo que haremos. El resultado de la Sprint Planning es un objetivo (Sprint Goal), acompañado de un Plan para tratar de alcanzarlo que llamamos Sprint Backlog y una previsión (que no compromiso) de la cantidad de trabajo que creemos que vamos a completar. Por tanto, no hablamos de “puntos comprometidos” ni de “historias comprometidas” sino de previsión. El compromiso es con el objetivo, no con el plan.

Equipo multidisciplinares no es que todos hagan de todo.

Quizás este sea uno de los errores más llamativos y lo he experimentado personalmente.. Entendemos que las personas deben ser multidisciplinares y ser capaces cada una de ellas de hacer cualquier tarea. Realmente Scrum no dice eso.

Cuando hablamos de un equipo multidisciplinar, decimos que el equipo debe contar con todas las habilidades necesarias para poder desarrollar el producto. Esto es lo que hacemos siempre, ¿no? En muchas organizaciones, se tiende a optimizar los “recursos” por lo que se crean departamentos especialistas como son: QA, Sistemas, UX, Mantenimiento, Explotación u otros. Después, en vez de unir a las personas en un equipo, lo que se hace es que los trabajos se van derivando a esos equipos. Esto provoca consumo de energía de la organización en las comunicaciones entre partes,  trabajo de gestión y, muchas veces, competitividad entre diferentes. Por eso, decimos que esa forma de trabajar un equipo no es multidisciplinar. Para serlo, se tiene que producir el “end-to-end” por parte del equipo, es decir, ser capaces de hacer TODO el trabajo desde detectar la necesidad hasta entregar el software.

Por tanto, cuidado, este Scrum-but muchas veces viene marcado por la organización, aquí el Scrum Master tiene que actuar pero puede ser un cambio muy fuerte para que se quiera abordar.

En la Daily, sólo hablamos de lo que hicimos.

La Daily Scrum es quizás una de las grandes mitificadas. En otros artículos, hemos hablado de muchos de sus errores. Un consejo que siempre recomiendo en las Daily Scrum es que hay que entender que principalmente lo importante no es tanto si respondes preguntas o si usas tablero físico. La clave de una buena Daily scrum es si la mentalidad con la que las personas van es la de escuchar o es una mentalidad de hablar. Cuando las personas acuden con ánimo de escuchar, suele hacerse un evento con ánimo de resolver problemas e impedimentos, y avanzar.

Por eso, es un evento fácilmente manipulable o malentendido en el momento en el que nos lo tomamos como un lugar para contar lo que hacemos: eso no es Scrum. Contar lo que hacemos está bien, nos ayuda a inspeccionar, pero hay que hacer algo más. Si queréis un test sobre la Daily Scrum, aquí podéis ver un ejemplo que os puede ayudar a saber si la Daily Scrum se hace bien.

Pre asignar tareas

Este Scrum-but es bastante típico en equipos poco maduros. Nos ha pasado a muchos porque veníamos de entornos tradicionales donde asignar tareas previamente nos ayudaba a planificar.

En Scrum, las tareas y los elementos del Product Backlog no se asignan. En primer lugar, , porque no hay etiquetas, por lo que no se puede decir que sean de nadie en concreto. En segundo lugar, porque asignar una tarea a alguien hace pensar que esa persona es responsable de lo asignado cuando los responsables somos todos. Y por último, porque asignar puede restar en la autoorganización del equipo.

En Scrum, buscamos la experiencia como mecanismo, por lo que asignar no nos ayuda a descubrir lo que ocurrirá. Dejemos que el propio Development Team decida cómo abordar el trabajo, lancemos el reto y dejemos que trabajen. Una puntualización: si usamos un software, como puede ser Jira, en el que aparezca la carita de un compañer@ no quiere decir que sea suya, solo quiere decir que nos organizamos, la responsabilidad es de tod@s.

Existen técnicas que ayudan a fomentar la responsabilidad compartida. Por un lado, tenemos el pair programming que permite generar código entre dos personas que se turnan para programar. Esta técnica no solo reduce la cantidad de errores, sino que permite asumir que lo que desarrollamos es de todos. Otra técnica es utilizar mob-programming que se basa en que un compañero programa y muchos observan; esta técnica está muy recomendada para desarrollar las partes complicadas del software o aquellas en las que queremos llegar a un acuerdo de grupo. Una vez más, esto nos proporcionar una interiorización de que el código y la responsabilidad del mismo es compartida.

No hay entrega, Sprint de subida.

Otro de los errores comunes es no hacer subidas hasta el final, generalmente dejando un Sprint para ello. Este error es muy típico y los que lo hemos cometido hemos visto las consecuencias finales. Si no abordas en cada Sprint todas las tareas necesarias para subir a “producción” entonces estás acumulando incertidumbre. Cuando llega el momento de la subida y vas a resolver esa incertidumbre, empiezan a aparecer muchos problemas que provocan tener que “matarnos” para poder llegar. ¿Qué hemos mejorado con Scrum si seguimos echando horas para llegar a la fecha?

Realmente, Scrum intenta que dejes el incremento listo para ser liberable y puesto delante de los usuarios. Scrum no dices que subas siempre, eso lo decide el Product Owner (en función de muchas factores como una posible campaña, necesidades del mercado, etc), pero esas tareas que aplazas se deben abordar como si la subida fuera a ser ahora mismo. El motivo es evitar sorpresas, ser realista sobre el avance del software. Como leí en Por un Scrum Popular, es mejor tener diez tareas done que treinta tareas doing.

Sprints variables

Este Scrum-but es bastante habitual. Dado que en cada Sprint nos marcamos una meta u objetivo (o a veces compromiso que es otro Scrum-but), hay equipos que alargan el Sprint para cumplir. Esto es un problema porque nos resta predicción. Queremos saber lo que seremos capaces de hacer en un periodo de tiempo concreto y cerrado, si no somos capaces de hacer más…

Otro motivo para que el tiempo sea cerrado (lo que llamamos time-box) es que queremos averiguar cuánto seremos capaces de hacer en ese tiempo. Es una manera de no bloquearnos analizando demasiado tiempo, en vez de eso, queremos trabajar y averiguar lo que somos capaces de hacer. Si en ese periodo no alcanzamos nuestro objetivo, es que no somos capaces de hacer más y  tenemos que estudiar caminos de mejora

Pensar que Scrum es para hacer proyectos

Este es mi Scrum-But favorito porque lo he cometido reiteradamente hasta hace poco. Tuve una conversación con una jefa mía hace años cuando ambos nos iniciábamosmos en esto de Scrum, y  ella me decía: “Scrum está muy bien pero para proyectos cerrados no lo veo”. Ahora que he ganado algo de perspectiva, creo que tenía razón.

Por un lado, Scrum no está pensado para hacer proyectos cerrados (realmente todos los proyectos son cerrados porque tienen fecha de finalización según la definición del Project Management Institute). Por otro lado, en la última revisión de la Scrum Guide añadieron “propósito de Scrum” y casualmente la palabra “producto” es la que predomina. Scrum es para hacer producto y no para proyecto; no es para garantizar una fecha ni para construir rápido algo grande. Scrum es para abordar problemas complejos, para averiguar lo que el usuario necesita y no para hacer software sin valor que no lo quiera nadie.

¿Por qué ocurre esto?

Si miramos el modelo Cynefin lo entenderemos perfectamente. En entornos simples o complicados, podemos utilizar una estrategia predictiva por lo que un proyecto que se basa en calcular el alcance-coste-tiempo y ejecución puede funcionar. El problema es que el software es complejo y de ahí que haya que usar otra aproximación. El modelo de “producto” precisamente se basa en hacer iteraciones e incrementos en los que vamos descubriendo la solución.

Esto son algunos ejemplos de Scrum-buts. Creo que he cometido todos en mi trayectoría, y, por suerte, creo que he podido aprender a superarlos y a ayudar a los equipos a no cometerlos. ¿Qué Scrum-But estaré cometiendo ahora y no seré consciente?