Cómo ya vengo comentando últimamente, cada vez hay más hype, o como lo queráis llamar con el tema de metodologías ágiles, y más concretamente Scrum, y la verdad es que cada vez que hablo de Scrum, más hay que poner énfasis en los valores de Scrum.
La gente, en algunas ocasiones, se pierde en el tema de las prácticas de Scrum, que si, que por si solas nos ayudan, y bastante, a organizarnos y centrar el trabajo, pero Scrum es más que eso, y lo realmente importante para mi son sus valores, la esencia que podríamos decir en el plano filosófico trascendental.
Lo primero, y algo que Rodrigo Corral no se cansará de decir, es que es una metodología empírica, esto es, tenemos que estar constantemente inspeccionando y adaptando nuestras decisiones y los procesos en tiempo real, basándonos en datos actuales y respondiendo rápidamente a las condiciones cambiantes del entorno. Esto es básico en todas las metodologías ágiles, ya sabéis, responder a los cambios antes que simplemente seguir los planes a ciegas.
¿Para qué vamos a dar soluciones a problemas que no tenemos?, esto es, partiendo de lo anterior, tenemos que estar atentos a los posibles problemas que nos vayan a surgir, por supuesto, pero hemos de ser flexibles, de nada nos vale intentar dar solución aun problema que nos puede surgir dentro de 3 meses, cuando no sabemos como el entorno va a evolucionar en estos 3 meses. Esto está muy relacionado con, por ejemplo, la arquitectura de las soluciones, en las que muchas veces el Big Upfront Design nos da como resultado una arquitectur totalmente inflexible, que no da respuesta ni aa los problemas actuales, ni a los que no conocemos aún que tenemos.
Muy importante en Scrum, y algo que no me cansaré de insistir, es la auto-organización, es básico, cuando acometemos un sprint es un compromiso (otro de los valores fundamentales), que adquirimos como equipo. Por tanto es importante conceder al equippo la capacidd de auto-gestionarse, para esto contaremos con equipos multidisciplinares, que tengan la capacidad de poder tomar las decisiones necesarias para crear productos de alta calidad y gestionar sus propios procesos, ¿quién puede tomar mejor las decisiones sobre un trabajo, más que el que lo va a hacer?. Ojo, nadie dice que esto sea fácil, pero tampoco quiere decir que necesitemos obligatoriamente un equipo de, únicamente, superhombres, héroes, o como queráis llamarlos, por supuesto, para producir productos de calidad, necesitas equipos de calidad, de gente predispuesta a enseñar y aprender (sí, las dos cosas), nadie nace sabiendo, y vamos aprendiendo por el camino, apoyándonos en gente que sabe más que nosotros y en gente que sabe menos, para esto lo importante es dejar a la gente auto-organizarse, y proporcionarle los medios necesarios para ello.
El compromiso, ufff, esto suena difícil ehh, pero es importante, cuando cerramos un sprint planning meeting, estamos adquiriendo un compromiso en ambos sentidos, por un lado el equipo, que se compromete a gestionarse para cumplir el objetivo, ya que ellos mismos han sido parte importante, mediante sus estimaciones, ¿cómo puedo comprometerme si no, a algo que yo no he sido partícipe?, si el equipo, reiteradamente, no se toma en serio este compromiso, incumpliendolo, o sin tomarselo en serio, lógicamente no podemos pedir que nos dejen auto-gestionarnos, en ese caso ya hemos demostrado que no sabemos hacerlo.
Esto no quiere decir jornadas de 16 horas trabajando, fines de semana, etc., esto siginifica tomarse en serio el compromiso y ser realistas con lo que nos comprometemos, no sentar falsas expactativas ni similares. Por supuesto, como dicen los americanos shit happens, pero lo importante es tener la información de en que punto estamos, hacia dónde vamos, como nos afecta el shit happens, etc., otra de las partes fundamentales, tener la información (¿recordáis lo que son los daily scrum?)
Y también, como no, compromiso por parte del Product Owner, que se compromete a no cambiarnos el ámbito del sprint, sin este compromiso, el equipo tampoco puede comprometerme, por qué, ¿cómo puedo comprometerme a cumplir un objetivo en un plazo de tiempo si me cambian el objetivo o el mismo no está claro?
Y llegamos a otro punto, bueno otros dos puntos, la priorización y los plazos de tiempo. Si tenemos que responder al cambio ¿por dónde empezamos?, priorizando, aquí entra en juego el Product Owner, que tiene que decidir que es lo más importante en el punto actual, y empezar a acometerlo. Y claro, para esto necesitamos fijarnos plazos, en Scrum, estos son de unas cuatro semanas, durante las que nos centraremos en lo que hemos priorizado como más importante, y el equipo ha estimado que se puede comprometer a ello, pasado ese tiempo, habrá que volver a juntarse, repriorizar el siguiente trabajo a acometer.
¿Qué fácil parece todo cuando está escrito verdad?, efectivamente no es fácil acometer esto, y requiere de un cambio organizacional importante. Todo esto del compromiso, la auto-organización, el trato directo con todas las partes implicadas en el proceso es muy importante, por desgracia, estamos acostumbrados al entorno de trabajo de “yo-mando-tu-haces”, y pasar de ahí a un entorno colaborativo no es fácil.
Hay que promover el coraje del cambio, la apertura a las aportaciones de todos, y a favorecer el avance colectivo, por encima de los héroes, o las personas imprescindibles. Todo esto se resume en el respeto mutuo a todos los niveles en las organizaciones.
Pero esto del cambio organizacional, el coraje, etc, ya lo dejo para otro post ….