Agilidad ¿responsabilidad de todos?

Si, por aquí de nuevo, luego de unas semanas muy ajetreadas, donde pudimos organizar el Global DevOps Bootcamp, renové mi participación en el programa Microsoft MVP (gracias por la confianza!) y se organizo el Ágiles Perú 2018 con motivo del décimo aniversario de nuestra comunidad.

El evento se realizo en la UTEC, y pese a todo lo acelerado que pasamos como comité organizador fue todo un éxito, mucho interés del publico por las charlas de los asistentes y varias propuestas interesantes en el Open Space.

 

En todo caso la jornada me dejo algunas anécdotas que están derivando en reflexiones, que comparto con uds.

En uno de los días tuve que conversar con la representación de una empresa sponsor, y lo que se me dijo fue mas o menos “estamos muy contentos de estar aquí, apoyando la agilidad, estamos contratando muchos coaches”.

Luego, en una de esas conversaciones de pasillo nos llegamos a juntar varios asistentes incluyendo algunos internacionales, y como consecuencia de un comentario que hice sobre la arquitectura e infraestructura de la universidad, alguien dijo algo como “siempre se aprende algo, es lo bueno de conversar con coaches”, supongo que lo hizo para alagar pero tuve que aclarar rápidamente “disculpa, yo no soy coach”.

Para cerrar en la retrospectiva aprecie esta imagen que reclamaba por mas presencia de Scrum Masters:

Esto me lleva a concluir que la idea de que la agilidad es campo de scrum masters y agile coaches, ha penetrado muy fuertemente, acaparando los temas de conversación y difusión, se valora mucho el incorporar facilitadores de todo nivel, y con eso se cree que ya se hace agilidad, sin tomar en cuenta que el compromiso con el Manifiesto Ágil es algo transversal, que también esto trata de equipos y su día a día resolviendo impedimentos, algo que estamos dejando de lado lamentablemente.

Parte de eso lo vi en mi sesión “¿Historias técnicas? si, gracias” donde conversamos los temas relacionado al rol de las historias técnicas en el ciclo de vida de desarrollo, resultando que si bien había un cierto consenso a su importancia, el principal problema que afloraba era la “lucha” de los equipos por lograr su visibilidad, de cual era la mejor estrategia para plantear su pertinencia; llegando a la conclusión de que los equipos deben de sacar coraje para plantear lo que haga falta para lograr estas mejoras, y que se debe contar con el apoyo y entendimiento de los Scrum Masters, los cuales curiosamente brillaron por su ausencia en esta sesión.

Nota aparte es la consecuencia que ha traído esta cultura de malinterpretación de la agilidad, es que pareciera que es mas importante un selfie luego del PI o tener un bonito tablero, mientras se busca la felicidad (*), que ir construyendo y entregando software de calidad (no olvidemos que “La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.“), pero claro si nos enteramos que en ciertas organizaciones se define el perfil de un potencial SM como alguien que no debe ver temas técnicos, o como mínimo tener entendimiento de las complejidades del desarrollo de software, vemos que solo se ha dado un nuevo ropaje (mas amigable y colorido, eso si) a la clásica división cerrada de las consultorías de rama de gestión y técnica. Esto lleva a situaciones tristes como las que contó la pluma invitada hace poco, donde prima mas el postureo, la agilidad de colorea y pinta, todo para tapar las falencias en la base técnica que nos están llevando al escenario que ya nos dijo Hernan Wilkinson hace un tiempo “si solo hacemos scrum y no mejoramos en la parte técnica vamos a seguir haciendo la misma porquería, pero vamos a estar todos mas felices”, todo por mor del impacto visual o por “adaptarnos” al cliente sin procurar el cambio.

Consecuencia de este fenómeno es que la comunidad de desarrolladores ha empezado a alejarse de la “escena ágil”, y ha empezado a rechazar la liturgia lúdica que esta tan de moda últimamente porque termina siendo una terapia de evasión, generando un circulo vicioso en que lo que priman son discusiones sobre el rol del coach y/o scrum master pero poco sobre como sacar adelante el trabajo de nuestros equipos.

O como comenta Israel López: “Y el Fake Agile tiene efecto llamada: al calor de la moda, y dado que los que llevan tiempo en esto y saben de qué hablan admiten las violaciones al Manifesto de sus clientes (haciendo gala del antivalor contract negotiation over collaboration), y ante la evidencia de que si muchos (no todos) de los que saben no van más allá del post-it, del dibujito, del tablero, los eventos mecanizados y los Legos, pero que en realidad todo sigue igual con una capa de chapa y pintura reluciente (mientras nadie se atreve a tocar el motor no sea que alguien se enfade), esto es un reclamo perfecto para que muchos, sin mucho esfuerzo, se armen de PPTs, post-its, elementos gráficos y discurso “optimista” e invadan el mercado a través de la enorme brecha del Fake Agile que han creado y alimentado“, el detalle es que es justo este despliegue escénico el que vende…

Aun soy un convencido de que la agilidad es una mejor forma de trabajo que la que teníamos con los JP y cascada, pero si esta tendencia (tanto en la empresa como en las comunidades) no se revierte, volviendo a involucrar a todos los actores, podremos estar asistiendo al regreso de los JP de toda la vida, o… ¿es que ya regresaron?

¿Es un fenómeno inevitable? ¿es tan solo una consecuencia de las preferencias del publico? ¿Nos ponemos en la tarea para lograr el cambio? Luego nos quejemos de que los CIOs estén perdiendo su confianza en la agilidad. Espero tus comentarios.

(*)Que es lo que hemos empezado a denominar la “cultura unicornio”.

2 thoughts on “Agilidad ¿responsabilidad de todos?

  1. Tus palabras me hacen sentir que no estamos solos o por lomenos es un problema común, nos llenamos de seremonias pero no logramos una autentica agilidad, el cambio de cultura para algunas corporaciones es un tema me atreveria a decir generacional, va más allá de capacitaciones, creo que deberia de adoptarse sólo con las personas que tirnen la disposición esperando en Dios que en el tiempo se de un efecto viral.

  2. Y por eso considero que un buen equipo de desarrollo de software va a entregar un buen producto sin importar la metodología/framework/filosofía que sigan.
    Cuando la agilidad solo hace que cualquier equipo de programadores sea más “feliz” y entregue un MVP incompleto y que no da valor al cliente; esto solo hace que el Agile se convierta en el visual basic de las metodologías, cualquier hijo de vecino la puede usar pero rara vez en algo que sirva.

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Time limit is exhausted. Please reload the CAPTCHA.