La CAS diez años después y el futuro del agilismo

Viajar a Barcelona siempre resulta estimulante. Si encima se tiene el pretexto de un evento como la CAS, el plan no podría intuirse más prometedor. Uno asistía a este décimo aniversario de la Conference Agile Spain con la ilusión del neófito -ya iba tocando, tras tres años ejerciendo como Scrum Mastah- y ni mucho menos querría tirar por tierra el trabajazo derivado de la organización de un evento de semejantes proporciones, logísticamente impecable y con dicho poder de convocatoria prolongado en el tiempo. Pero sí he de reconocer (como si a alguien le importara esto) que regresé a casa con un regusto agridulce, que tardó en aflorar por la ilusión de haberme reunido con compis del sector y la emoción de haber descubierto una de las mejores tortillas de patata del Puente Aéreo (la del Koska, por si alguno tiene curiosidad)*

Tras una semana de reposo, y habiendo intercambiado impresiones con mis colegas más cercanos, achaco este sentimiento no tanto a las expectativas no cumplidas y al letal combo entrada + alojamiento + desplazamiento, difícilmente justificable desde el punto de vista pecuniario, sino a la sensación de déjà vu. Y es que en la CAS no se respiraba precisamente futuro sino presente impregnado de una pátina de pasado, quizá fruto de la nostalgia por la efeméride, cuyos fastos, por otro lado, de tan discretos resultaron inexistentes hasta el punto de quedar algo deslucida.

Sea como fuere, cuando voy al Codemotion veo naves en llamas más allá de Orión, computadores cuánticos, escuadrones de cibercrimen organizado. Pero también veo compiladores más eficientes, motores de búsqueda basados en inteligencia artificial, algoritmos capciosos de adicción en los videojuegos, compromiso social, paridad… incluso palitroques con los que dar feedback inmediato al más puro estilo Black Mirror. Veo, en definitiva, al presente con voluntad de acercarse al futuro.

Sin embargo, en la CAS veo empresas dándose al autobombo, ponentes clave improvisar charlas para los cuatro colegones con los que empezaron todo este tinglado, méritos incuestionables aparte. Veo un evento completamente de espaldas a la tecnología, que es el campo de acción en donde desarrollamos nuestra actividad hoy día en un 99,9%. Y tanto la responsabilidad social, más allá de lo tangencial por lo acertadísimo del enclave dada la delicada situación política, como la paridad, brillar por su ausencia casi tanto como el café. ¿Cómo demonios es posible que en una convención no se pueda tomar café a todas horas? Adicciones aparte, todo ello conforma para mí una flagrante contradicción, dado el supuesto afán transformador del agilismo.

Por suerte y contra todo pronóstico, no hubo apenas fumata blanca ni acopio utilitarista de técnicas orientales para llenar de filosofía mal entendida un mero marco de producción, sino que imperó cierta practicidad en todo el evento. Y esto es de justicia recalcarlo y valorarlo porque aparte de que debemos luchar fuertemente contra el cliché, cada vez que se abraza un árbol para producir mejor Slavoj Žižek se muere un poquito más por dentro and so on…

Ahora bien, ¿significa esto que el agilismo no pueda ocupar un espacio en 2019 sin caer en lugares comunes y aportar algo más allá de todas esas lecturas que se remontan a 2012? No lo creo, pues ello sería afirmar que ya está todo hecho, y nada más lejos de la realidad.

Como agilista principiante me gustaría que se ahondara más en la historia para conocer en profundidad de dónde venimos, puesto que todos damos por sentado que hemos mejorado lo presente pero pocos lo hemos vivido de primera mano. Me gustaría que la mujer tuviera la voz que ya tiene en nuestro día a día, pues no olvidemos que dentro del desarrollo de software, un sector netamente masculino, es predominante en la materia. Me gustaría que en la integración con el cliente se pusieran de relieve casos de fracaso estrepitoso, en un ejercicio brutal de honestidad del que poder partir para analizar los motivos y reforzar la cultura necesaria, más allá de modas y tendencias. Que se ahondara en la adaptación a otros medios no VUCA (volátiles, inciertos, complejos y ambiguos) y sectores ajenos al ámbito del desarrollo. También que no se perdieran de vista otras metodologías más convencionales y sus propios procesos de reconversión, porque al igual que asumimos con naturalidad algunas prácticas inferidas de XP, es necesario seguir tapando las grietas aún existentes (documentación, gestión de cambios, etc.) con técnicas y herramientas válidas. Y porque, qué leches, se supone que Agile no es sólo Scrum y precisamente esta proclama fue lo más ovacionado de toda la convención, en la charla de Juanma Gómez y Edu Ferro, lo cual no deja de ser, cuando menos, sintomático.

Por supuesto que hubo destellos en esta línea, aparte del caso ya mencionado. Sin ir más lejos y con poca sospecha de proselitismo, mi compañero Gabriel Salafranca compartió sus logros y pequeñas miserias en su labor transformadora en una gran corporación. También percibí un punto de laboratorio más que interesante en los Sprints de un sólo día de Rafael Sabbagh. Se me saltaron las lágrimas con el coraje y apertura de miras de Gemma Albaladejo en las aulas de su instituto. Y, obviamente, no pude asistir a todas las charlas, por lo que seguro que estoy siendo injusto dejándome algo.

Miremos hacia adelante, por lo menos otros diez años más. Pero hagámoslo sin dar tregua a la autocomplacencia, valorando nuestros logros pero sin dar cabida a la hagiografía, ya que lo contrario significa firmar nuestro propio certificado de defunción. En definitiva, envolvamos de futuro aquello en lo que creemos.

Inspiraciones:

* Tortillaffinity especial Barcelona: Es la del Koska una tortilla sincrética, con relato. De hechuras sinuosas que bien celebraría el mismísimo Gaudí, correría el riesgo de perderse en sus distintas mutaciones pero su gnosis en la materia es tal que su esencia reside intacta. Una truita per la reconciliació.

Cómo tu Scrum Master puede remediar las 5 disfunciones de un equipo

A estas alturas de la película prácticamente todos estamos familiarizados con la figura del Scrum Master en los equipos. Sin embargo, tengo la sensación de que cuanto más se asume su presencia, menos claras se tienen sus competencias, los cometidos tangibles por los que poder evaluar o medir su trabajo, más allá de los resultados. Y ello, tirando un poco de autocrítica, quizá sea debido, entre otros factores, a que de un tiempo a estar parte parece que hemos puesto más énfasis en recordar lo que no hacemos que en exponer claramente lo que podríamos -o deberíamos poder- ofrecer.

En este post intento establecer una correlación de técnicas y valores que, dentro del agilismo, pueden aplicarse y fomentarse para intentar paliar “Las 5 disfunciones de un equipo” (2002), diagnóstico certero de Patrick Lencioni de algunas de las causas por las que un equipo puede no saber o querer funcionar como tal, rindiendo por ende por debajo de lo esperado. Disfunciones, por lo común, tan intrincadas con los sentimientos y emociones personales que exigen un espacio de reflexión interna, por lo que invito al lector a identificarse y reconocerse en su propio equipo, sea Scrum Master o no. De ahí el título del post, clickbaits aparte.

DISFUNCIÓN 1: La ausencia de confianza

Que la confianza es la base de todo equipo parece casi una obviedad. Sin embargo, son muchos los equipos cuyos miembros no tienen la confianza suficiente para decir lo que piensan. Además, cuando uno no tiene confianza con alguien es más probable que tomemos como un ataque cualquier apreciación.

Lo ideal es que los integrantes de un equipo adquieran confianza a través de rutinas que, generalmente, suelen surgir de manera natural, como pueden ser desayunar y/o comer juntos o unas cañas tras el curro. Estos hábitos saludables encuentran leve obstáculo en equipos en remoto y mayor en casos aislados de misantropía, pero igualmente no viene mal un refuerzo inducido en según qué situaciones, aunque con cuidado. Porque probablemente no haya nada que genere mayor incomodidad y desconfianza que sentirnos obligados a abrirnos frente a un grupo.

Las dinámicas que inciden en este punto suelen ser o bien de autodefinición (desde un Personal Mapping a una Matriz de Habilidades, si nos queremos poner más técnicos) o bien de descubrimiento del otro mediante preguntas y respuestas o Team Buildings varios. Ojo con esto: un Team Building quizá sea la manera más intrusiva de intentar estrechar lazos, suelen acogerse con recelo y es complicado que satisfagan a todos. Aunque se puede recurrir a ellos como refuerzo positivo, a modo de celebración, siempre de manera voluntaria y en horario laboral a ser posible. Particularmente, pienso que la manera más sutil es la revelación de sentimientos a partir de la abstracción (Cartas Dixit) y la representación (Lego) de situaciones: una imagen o una figura que simboliza nuestro estado anímico como punto de partida para ahondar en ello.

En cualquier caso, la responsabilidad del Scrum Master en este campo es la de propiciar un entorno que ayude a romper estas corazas, donde no tengan cabida las actitudes coartantes e intransigentes, se eviten las culpas individuales a toda costa e impere la humildad para preguntar todo aquello que no se sepa. Fomentar la vulnerabilidad, lo llaman.

DISFUNCIÓN 2: Miedo al conflicto

Los equipos cohesionados y realmente productivos discuten. Discuten mucho. O, al menos, deberían. Un equipo que no tiene una discusión encendida sobre alguna cuestión técnica u organizativa es un equipo pasivo, alienado, que raramente va a marcar una diferencia sustancial.

Pero para discutir bien, lo primero de todo sería aprender que el conflicto es muy diferente de la agresión. Y no me refiero explícitamente a caer en el insulto o la descalificación. Esto que suena tan trivial, no todo el mundo es capaz de hacerlo. Por ello, es necesario establecer unas reglas de equipo que respeten sus propios códigos internos y fijen unos límites para que, un supuesto moderador pudiera levantar la bandera roja una vez se franquearan.

El segundo punto a aprender es que un conflicto resulta generalmente doloroso, sobre todo si hemos reforzado la confianza mutua. Dos personas que no se importan discutirán en modo agresión más fácilmente que dos que se estiman y respetan. Pero también nos veremos más afectados. Hay técnicas para identificar cómo se discute (Thomas-Kilmann Conflict Mode Instrument), porque a veces uno no es consciente del todo de cómo lo hace o quizá quisiera discutir de otra manera. De todos modos, con confianza uno podrá manifestar al otro sin problema si se ha sentido herido.

Por otro lado, el foro para tratar los problemas del equipo es la Retrospectiva. De un tiempo a esta parte la Retrospectiva se ha convertido en el espacio de lucimiento personal del Scrum Master, el momento en el que pareciera ha de justificar su trabajo haciendo gala de un derroche de fantasía e imaginación… Y no. Las retrospectivas no tienen por qué ser ni imaginativas, ni divertidas, tienen que ser, ante todo, efectivas. Y para que una Retrospectiva sea efectiva, tiene que haber conflicto, dolor y, por ende, cohesión. Salir cabreados, exhaustos o motivados… Y con tarea a cuestas, objetivos SMART (Specific, Measurable, Attainable, Relevant, Time bound) a implementar.

La premisa es romper esa falsa armonía llena de tensiones internas que acaba por explotar justo cuando menos se necesita: ante la adversidad.

DISFUNCIÓN 3: Falta de compromiso

El mercenario del código, que diría mi colega Héctor López: tiro mis líneas, me exijo lo mínimo posible y cumplo con el expediente. Sería muy aventurado decir que la falta de compromiso viene únicamente motivada por el hecho de no sentirse implicado, pero desde luego que puede ser un factor que lo incentive. Y esa falta de implicación a menudo viene propiciada por la toma de decisiones.

De entre los distintos modelos de toma de decisiones está claro que (¿casi?) todo el mundo diría que el autocrático no es el bueno y que lo mejor sería el consenso, pero todo tiene su lugar. La votación, tanto por mayoría absoluta como por mayoría simple es la forma más extendida y no necesariamente la más acertada, puesto que suele crear bandos y a menudo se emplea de manera que no contempla argumentación posible para la parte perdedora. La forma idílica sería el consenso, sí: todos de manera madura llegamos a un acuerdo. Sin embargo, puede dilatarse demasiado en el tiempo y generalmente no disponemos de tanto margen de maniobra (recordemos que el Agilismo permite tomar decisiones rápidas, puesto que permite fallar en el proceso). Una forma menos conocida y más apta para según qué decisiones sería el consentimiento: un acuerdo de mínimos. O lo que es lo mismo, estando en desacuerdo, qué no nos rasga las vestiduras, hasta dónde podríamos ceder.

Independientemente del modelo de toma de decisiones empleado, lo importante para evitar la falta de compromiso es contemplar las opiniones de cada uno. Si sentimos que algo nos ha venido impuesto, raramente nos vamos a comprometer con ello. Especialmente si estamos en desacuerdo, que es de lo que se trata.

DISFUNCIÓN 4: Exención de responsabilidad

Fruto de la falta de compromiso surge la exención de responsabilidad, algo que juega en dos direcciones: En que si algo con lo que no estábamos de acuerdo falla, no aceptamos responsabilidad alguna sobre ello. Pero también en que no nos inmiscuimos en lo que el otro está haciendo y nos centramos únicamente en nuestra parcela, que es la que nos parece bien. Es más, es probable que ni siquiera sintamos que el plan ha fallado, porque muy probablemente no consideremos el plan como algo nuestro.

Para ello hay que elaborar estándares que apliquen al equipo, de tal manera que uno no pueda tener éxito sin el éxito común. Esto pasa por hábitos ya asumidos de XP tales como la revisión de código activa, el CI/CD o el establecimiento de estándares de calidad y rendimiento. Pero más importante aún son las métricas colectivas, que son las que van a marcar el éxito o fracaso de la iniciativa. Para ello, es preciso sentarse con el PO y elaborar una serie de áreas y puntos a medir recurrentemente para contemplar su evolución.

La clave, en definitiva, es establecer una exigencia común que permita definir éxitos o fracasos colectivos en detrimento de los individuales.

DISFUNCIÓN 5: Pérdida de foco

La quinta disfunción no es más que la mera conclusión de todo lo demás, la ausencia de foco. Vamos como pollos sin cabeza. Ante la no existencia de un objetivo común, cada uno hace la guerra por su lado, y al entregar su parte considera que el trabajo ya está hecho.

Es básico tener bien a la vista un roadmap del producto. Pero, y esto a muchos les va a sorprender, sobre todo cuando hablamos de un entorno Agile, es beneficioso, necesario y realista disponer de fechas que marquen el ritmo y las expectativas. Estas fechas han de ser obviamente lo suficientemente amplias y consensuadas, pero han de existir y forzar nuestro umbral. Lo contrario es tan irreal como desmotivante.

Resumiendo: la ausencia de confianza propicia el miedo al conflicto, que a su vez se traduce en falta de compromiso. Esta falta de compromiso tiende a favorecer que se eludan responsabilidades, por lo que se pierde el foco, el objetivo común. Como vemos, realmente hay una correlación clara de valores como pueden ser los de Scrum en este caso y las disfunciones que queremos evitar. En general, serían aplicables a cualquier entorno de trabajo que pretenda ser mínimamente funcional, en el que la gente trabaje en equipo y sus opiniones sean consideradas y no se frustre por lo contrario y esté motivada y comprometida y produzca más y mejor, que es lo que realmente importa en este Humans of Late Capitalism Agile.

Y, un poco relacionado con todo esto, como colofón, están los sentimientos, las emociones propias. Os invito a que cada vez que sintáis uno de los mal llamados sentimientos negativos, como puede ser la ira, la tristeza o el miedo… Os paréis a reflexionar qué es aquello que lo ha provocado. Pero no el hecho concreto en sí, sino lo que subyace detrás. Si me he sentido despreciado, amenazado, decepcionado… el porqué. Para así, con esta reflexión, poder acudir al compañero en este caso y abordar la cuestión con coraje y respeto hacia uno mismo y los demás.

PD: Aquí una formación que impartí en Paradigma con este contenido.

Economizando esfuerzos

Inspiraciones: