Esto no es Scrum.

Estaba claro: vayas donde vayas, ahora encuentras a alguien renegando de Scrum. Y es que aunque el rechazo se fue cocinando a fuego lento, el contexto de la pandemia acabó por precipitar los acontecimientos. Así pues, dejando a un lado artículos oportunistas celebrando con ello la muerte del agilismo y, asumiendo, sin dogmatismos, que ya no hacemos Scrum (hasta la vista, Scrumbut), ¿acaso no se puede ser ágil sin implementar un framework específico?

Hubo un tiempo, y hay escritos que así lo atestiguan, en que se hablaba de Scrum indistintamente como de un proceso (metaproceso) o de una metodología. Es más, los propios fundadores admitían que no era más que un marco de buenas prácticas y aludían al sentido común a la hora de implantarlas, tomando aquellas que nos sirvieran e incorporando empíricamente las que considerásemos oportunas.

Fue luego con su popularización que surgieron, de algún modo, dos corrientes, una más purista y otra más ácrata. A la purista, que velaba por un aseguramiento y blindaje del marco, se adscribió un puñado de malos profesionales que, con la carcasa de la guía por bandera, eludía su responsabilidad para con el resto de cuestiones que no fueran metodológicas. Una pésima interpretación que suscitó recelo con más frecuencia de lo deseado, incluso en el interior de los propios equipos.

Pero en esta caída en desgracia pesó más, quizá, la falta de experiencias exitosas en la realidad imperante en el mercado, la consultoría. Y es que, de alguna manera, le estábamos exigiendo a nuestros clientes un cambio que, o bien no estaban dispuestos a asumir o en el cual directamente no creían, máxime cuando no nos habían contratado para agitar los cimientos de su organización, sino para proporcionarles un (el mejor) servicio.

Por lo tanto, atrás quedaron los tiempos en que los equipos se frustraban por no estar haciendo Scrum bien del todo y a los clientes les asustaba que se quisiera hacer demasiado estricto. Y si esta excomunión en sí me resulta injusta, en tanto en cuanto Scrum sirvió como puerta de entrada a un universo mayor, más aún me lo parece la defenestración de dicho universo por la caída en desgracia del marco de trabajo que lo propiciaba, como si tras él no hubiera opción Agile posible. «No hay alternativa», que diría Margaret Tatcher.

Y es cierto que algo de realidad puede que haya en ello, pues una vez inferidas las prácticas de XP por el desarrollo pudiera parecer que tan sólo nos queda abrazar formalmente Kanban o mirar de reojo las reconversiones ágiles de los frameworks tradicionales.

Pero me gustaría que nos detuviéramos en la esencia, en examinar en detalle los valores y principios del manifiesto para ver si los cumplimos o no, pues ello es lo que realmente va a dictaminar el que dispongamos de una mentalidad ágil. No obstante, es ahí donde reside el verdadero impacto organizacional y no tanto en las prácticas, tal y como exponía Simon Powers en su conocida Agile Onion.

¿Qué dicen los cuatro valores del Manifiesto Agile?

1 Individuos e interacciones sobre herramientas y procesos

Es este un valor transversal, una filosofía de trabajo. En pocas palabras lo dice todo acerca del ecosistema y de la dignificación del equipo técnico para sacarlo de los cubículos de las viñetas de Dilbert y establecer un marco más humano. Dejar de ser meros recursos colocados aquí o allá, sin apenas relación con el cliente (las jerarquías bien delimitaditas) y favorecer una comunicación más horizontal, directa y, por ende, eficiente, ya que en el propio empoderamiento va implícito el extra de responsabilidad para con el resultado final.

Por tanto, no se trataba sólo de dignidad, sino también de productividad, calidad y eficiencia, dejando patente la necesidad de suprimir toda burocracia derivada de los sistemas de control y vigilancia fordistas en aras de la confianza hacia la persona y su propia autoexigencia.

Ya en este primer valor rechina el hecho de que una mala interpretación de Scrum haya podido abanderar la causa del agilismo, pues un rol guardián del marco carente de responsabilidades sobre el entregable es una contradicción en sí mismo, y una búsqueda de la pureza en la ejecución supone una anomalía, empíricamente hablando.

2 Software funcionando sobre documentación exhaustiva

Estamos ante el que quizá sea el punto más capcioso del manifiesto. No cabe duda de que es preferible tener software aportando valor que disponer de documentación exhaustiva, si es que tenemos que elegir. Y tampoco hay duda de que no resulta demasiado útil manejar una documentación de dimensiones bíblicas.

Pero que el código sea legible y autoexplicativo es uno de los pilares de la artesanía del software y eso también es documentar, como también lo es mantener un censo de los servicios disponibles, un mapa de arquitectura, diagramas de infraestructura o incluso un onboarding adecuado para las nuevas incorporaciones.

Por tanto, estaríamos hablando realmente de la necesidad de documentar con pragmatismo; es decir, de manera muy diferente a como se venía haciendo cuando salió el manifiesto (2001). Huelga decir que la guía Scrum no trata en absoluto este punto y que los ejemplos esgrimidos corresponden más bien al decálogo del Agile Craftsmanship.

3 Colaboración con el cliente sobre negociación contractual, y 4. Respuesta al cambio sobre un plan preestablecido

Unifico estos dos valores, pues siempre y cuando estemos hablando de un entorno VUCA (volátil, incierto, complejo y ambiguo) o, como ahora, BANI, (neurastenia pospandémica) son deseables, incluso en proyectos con alcance cerrado, y uno es consecuencia del otro.

Dispondremos de una hoja de ruta a alto nivel, que iremos desgranando, mostrando resultados sobre lo entregado y revisando las funcionalidades venideras, simplificándolas o ampliándolas según sea necesario, alterando el plan preestablecido para adaptarse lo máximo posible a las necesidades del cliente en un modelo iterativo incremental que nos dará certezas sobre el aporte de valor.

Si, además, colaboramos estrechamente, en lugar de ser un mero proveedor, podremos asesorar en base a nuestra experiencia, participando en el proceso de co-creación.

Revisados los valores, habría que echar un vistazo a los doce principios del manifiesto. Es su cumplimiento lo que va a demostrar que se puede adoptar una postura Agile en la entrega sin la implementación de un framework específico.

¿Podemos cumplir los principios del Manifiesto Agile sin hacer Scrum?

1 Nuestra prioridad principal es la satisfacción del cliente a través de la entrega temprana y continua de software con valor

Si bien Scrum habla explícitamente del Producto Mínimo Viable, el disponer de un backlog ordenado a inspeccionar periódicamente entre ciclos iterativos es propio de cualquier metodología de desarrollo guiado por la entrega. También en Kanban nos organizamos en torno a hitos y releases y en XP se habla de ciclos trimestrales cuyo propósito es mantener un roadmap deseable de objetivos compartido entre desarrollo y negocio.

2 Los cambios en los requisitos son bienvenidos, incluso en fases tardías del desarrollo

La flexibilidad es primordial si queremos ser lo suficientemente competitivos, pero para ello se requiere un marco de colaboración que lo ampare. Ese marco no solo es de método sino también contractual y debe estar basado en la confianza. Sólo así un cambio tardío en los requisitos podrá negociarse de tal manera que ni sea inabordable hasta después de la entrega inicial prevista, ni tampoco deje de implicar un cambio de alcance sobre el resultado. Con transparencia y mecanismos apropiados de inspección y adaptación, el cómo absorbamos dichos cambios y reflejemos su impacto: alteración del Sprint, alcance de la entrega, desplazamiento de la fecha prevista, faseado de la funcionalidad, etc. no es más que un mero formalismo.

3 Hay que entregar software funcionando lo más frecuentemente posible

Este punto redunda en el primero en cuanto a su propósito. Solamente teniendo agilidad en la entrega podremos ofrecer ventaja competitiva, por tanto, para ello es fundamental tener la maquinaria engrasada, por todo lo que una entrega supone en cuanto a preparativos y responsabilidades.

La cadencia de entrega dependerá de la naturaleza del proyecto y se tendrá que encontrar un equilibrio entre tamaño y frecuencia. Si bien una release grande tiene más posibilidades de que encalle, una excesiva frecuencia puede conllevar un desperdicio en los preparativos si no se dispone de un flujo de despliegues ideal. Pero no hay que perder de vista que es hacia donde deberíamos ir y que ello es más una virtud técnica que metodológica.

4 Negocio y desarrollo han de trabajar juntos a diario a lo largo del proyecto

Únicamente con propósito es posible alcanzar un cierto grado de implicación, y solo con implicación es posible alcanzar cierto grado de distinción. Para mantener el propósito sobre el trabajo desarrollado es necesario conocer las motivaciones de algunas de las decisiones de negocio, así como unas pinceladas a alto nivel de sus estrategias competitivas. De la misma manera, es preciso que negocio disponga de indicadores que irradien información acerca del estado de salud del proyecto (y esto incluye a equipo y producto) para que sea conocedor de las posibles dificultades por las que atraviesa, más allá de su time to market.

A través de una comunicación fluida entre negocio y desarrollo se reforzarán los lazos de confianza necesarios para entender los tiempos que demanda uno y requiere otro, y que así se produzca un acuerdo fructífero entre ambas partes.

5 Construir proyectos en torno a individuos motivados. Propiciar un entorno que satisfaga sus necesidades y que confíe en su profesionalidad

Si bien es fundamental gozar de un “ambiente preparado” a lo Montessori, que elimine impedimentos y alivie frustraciones, este es tan solo un escalón preliminar de la pirámide de Maslow. En equipos que aspiren a resultados excelentes, el reto ha de ser indispensable, así como la autonomía y el crecimiento profesional de los distintos perfiles del equipo.

Ninguno de esos peldaños de la pirámide quedan intrínsecamente cubiertos por el mero hecho de adoptar un marco de trabajo, pero lógicamente unos ecosistemas dispondrán de mayor sensibilidad al respecto que otros.

6 La forma más eficiente y efectiva de transmitir información hacia y desde el equipo de desarrollo es cara a cara

O… sin intermediarios, en los tiempos del remoto. Aquí sobre todo lo que se pone de relieve es la necesidad imperiosa de acortar distancias entre negocio y desarrollo para cumplir los objetivos. Cuantas más capas de interlocución, mayor probabilidad de distorsión.

7 Software funcionando es la principal medida de progreso

Si por progreso se entiende, tal y como la RAE recoge en sus dos acepciones, no sólo ir hacia adelante, sino ir mejorando por el camino, aceptamos barco. En todo caso, este punto es muy deudor de su tiempo, donde las gráficas de un Excel medían el avance de un proyecto a medio - largo plazo.

Superado ese momento, lo que se espera del agilismo no es simplemente entregar valor, sino impacto en negocio, una determinada capacidad de respuesta, mantener la cohesión del equipo, etc.

8 Los procesos Agile promueven el desarrollo sostenible. Negocio, desarrollo y usuarios han de poder mantener un ritmo constante e indefinido

Manejar plazos exigentes no es incompatible con manejar un flujo racional del trabajo, ordenado y con trazabilidad, en el que haya un equilibrio que nos permita invertir en mejoras.

Dicho esto, no pasa nada por no estar petado todo el rato. Tener cierta pausa puede ser el resquicio idóneo para que una idea genial aflore. De hecho, la sobreexcitación perenne conduce ineludiblemente al descuido y, por tanto, a la mediocridad.

9 Atención continua a la excelencia técnica

La gestión Agile depende, en gran medida, de un desarrollo artesanal y viceversa. Puesto que entregar valor implica entregar calidad, para ello es preciso que al proceso de inspección y adaptación se incorporen técnicas y herramientas que lo cuantifiquen, en una más que natural convergencia técnica y metodológica.

Es fundamental apoyarnos en alguna herramienta que nos permita mantener censado y priorizado todo lo que consideremos relevante: deuda técnica, mejoras, cuestiones de seguridad, pruebas de concepto, acciones post mortem… y ofrecer trazabilidad sobre todo este posible caos, así como visibilizar sus consecuencias. Eso quiere decir: reducir a su mínima expresión el número de incidencias en producción, vulnerabilidades, bugs con prioridad alta…

10 La simplicidad es esencial

También debiera ser extensible al marco, cualquiera que sea.

11 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados

Los equipos se auto-organizan en base a las prioridades marcadas por negocio. Pero no solo la autonomía es algo que se promueve, sino que debe haber un responsable de la maximización de la entrega que establezca objetivos y límites.

Precisamente, uno de los objetivos deseables será alcanzar un contexto favorable de equipo en aras del individualismo, tomando decisiones adecuadas para que el conocimiento fluya y no se generen silos, algo a lo que por naturaleza se tiende, a la especialización.

Así, promulgar el aprendizaje mediante el error requiere de un liderazgo no implícito en un método concreto.

12 En intervalos regulares, el equipo reflexiona sobre cómo ser más efectivos y se reajusta consecuentemente

La mejora continua no se limita a hacer una retrospectiva de manera rutinaria, sino que se ha de contar con datos que midan los puntos de mejora, y que el equipo haya sido llevado hacia un estadio donde la vulnerabilidad propicie un sano conflicto y debate.

Conclusiones

Trabajar de manera Agile consiste en establecer un marco de trabajo que cumpla los valores y principios recogidos en el manifiesto. Hay marcos cuya implantación hace que dicho cumplimiento sea más sencillo, pero que no lo garantizan por sí mismos sin un profundo entendimiento, tal es el caso de Scrum.

Ahora bien, ¿cómo afronta el otrora Scrum Master esta nueva realidad? ¿Qué puede hacer un ex-Scrum Master sin hacer Scrum? En Paradigma lo tenemos claro, dar un paso adelante y convertirse en un Agile Delivery Leader, esto es, el responsable explícito del servicio.

Una necesaria reordenación del rol que ha exigido una revisión exhaustiva de sus competencias, pues al renegarse del management clásico, asociado al ‘ordena y mando’, sus jerarquías, sus planes quinquenales y su vasta documentación, estas se habían diluido hasta quedarse en un estado de arbitraria interpretación.

Y es que, tras haber jugado al Scrum durante un tiempo (lo mejor que hemos podido y nos han dejado), entramos de lleno en una etapa de perfeccionamiento (¿fase Ri?) en la que nos despojamos, con pragmatismo, de lo superfluo y nos quedamos con las lecciones aprendidas por el camino en base a nuestra experiencia real, a la que hemos dado forma como Polaris:

Bibliografía recomendada

Observación: Nótese la selección deliberada de pasajes antiguos. Me gusta encontrar en el pasado respuestas a problemas supuestamente nuevos y desde luego vigentes.

• Elogio a la ociosidad (Bertrand Russell, 1932)
• Scrum Development Process - Advanced Development Methods (Ken Schwaber, 1995)
• 12 Principles Behind The Agile Manifesto (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert C. Martin, Steve Mellor, Dave Thomas, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Ken Schwaber y Jeff Sutherland, 2001)
• Realismo Capitalista (Mark Fisher, 2009)
• Scrum Master - A Manager (Gunther Verheyen, 2014)
• The 8 Stances of a Scrum Master (Barry Overeem, 2016)
• Explaining the role of a Delivery Manager (Emily Webber, 2016)
• Los 7 pecados capitales de Agile (José Ignacio Herranz, 2021)
• Artesanos del Agilismo (Raúl Alonso, 2021)
• Lo confesamos, no somos Scrum Masters (Esther Peinado, 2021)
• Los 9 elementos Polaris (Paradigma, 2022)