Individuos e interacciones sobre procesos y herramientas

2

En toda esta vorágine de agilidad que nos envuelve, mucha gente nombra los valores y los principios del manifiesto ágil. Pero la realidad es que si le preguntas a la gente, pocos sabrían decirte los 4 grupos de valores, y casi ninguno los doce principios. Pero es que lo peor de todo es que muchos los dicen, pero no acaban de ver qué hay detrás de estas frases. Por ello, me voy a ir concentrando en los distintos valores del manifiesto. Y si me quedan ganas, en los principios. ¿Me acompañáis? Pues vamos adelante…

DISCLAIMER: Esta serie se trata de artículos de opinión. Os comparto mi visión o interpretación de los valores y principios. No se deben tomar como un estudio de lo que dice el manifiesto, o como un axioma. Y de la misma manera tú lector puedes opinar diferente de mí y creer que estoy equivocado.

Individuals and interactions over processes and tools

Es el primer grupo de valores del manifiesto. Casí la tarjeta de visita del mismo, si descartamos ese preludio que indica que son un grupo descubriendo nuevas maneras de desarrollar software, es la primera frase de valor del manifiesto. Y no es gratuito que sea la primera, porque encierra dentro uno de los grandes pilares, la confianza en el equipo y no en los gestores. Esto es un gran ataque contra la línea de flotación de lo que se venía haciendo hasta el momento. Hablamos de la época en la que la gestión por procesos estaba de moda. Hablamos de las ISO 9001. Hablamos de los procesos de ITIL (servicios gestionados por procesos). Hablamos del PMBOK (proyectos gestionados por procesos). Hablamos de SPICE, de CMMI, de la 12.207 o Métrica (Desarrollo gestionado por procesos). Los procesos lo gobernaban todo. Da igual a quién pusieses, porque el proceso te evitaría el fallo humano. Las personas eran engranajes en una máquina cuyo diseño estaba gobernado por los procesos. Pero los procesos podían romperse, la gente podía no seguirlos, y ahí entraban las herramientas. Las herramientas eran la policía que obligaba a todos a cumplir la ley. ¿Quieres comprar un ratón? Pues conéctate a la herramienta de inversiones. Para ilustrar esta mentalidad podemos sacar un ejemplo: en CCMI DEV 1.3 que podéis encontrar aquí, en sus paginas 4 y 5 (saltándote las de números romanos de la introducción):

[…] las tres dimensiones criticas donde normalmente se centran las organizaciones: las personas, los métodos y procedimientos, y el equipamiento y herramientas. ¿Que mantiene todo unido? Los procesos utilizados en su organización. Éstos le permiten alinear su modo de trabajar. Le permiten abordar la escalabilidad y proporcionan una forma para incorporar el conocimiento de cómo hacer las cosas mejor. […] Esto no quiere decir que las personas y la tecnología no sean importantes.[…] Un enfoque de proceso proporciona la infraestructura y la estabilidad necesarias […]

Encontramos en este párrafo la visión clásica de que proceso es el que permite que las personas trabajen con calidad y como queremos.

Pero estos tipos del manifiesto ágil, nada más empezar te dicen que eso no sirve. Que no confíes en el proceso, que confíes en las personas. WTF!!

Mucha gente no es consciente de lo que supone esta rotura de moldes. Hay que haberse formado en toda esa cultura de hace unos años para entender cuan transgresor es este manifiesto.

¿Qué significan estos valores?

Individuos

El primer punto de este grupo de valores, y no es sencillo. Tenemos un doble sentido.

El primer sentido es en la importancia de los individuos. Gente motivada y buena te crea un equipo bueno. Gente mediocre y pasota, te crea un equipo malo. La gente, los individuos, que forman los equipos son uno de los puntos clave del éxito. Esto, como he indicado antes, choca con esa visión de que cuando algo no funciona, se intentaba cambiar el procedimiento. Seguro que este ejemplo os suena: Si los desarrollos no cumplían con las expectativas de negocio, se ponía una fase de aprobación entre la definición del requisito y el desarrollo, que asegure que ese requisito es lo que quiere negocio. El valor del individuo nos llevaría no a cambiar el procedimiento, sino a trabajar con esos desarrolladores para que entiendan qué necesita negocio y se alineen con él. No se trata de cambiar el procedimiento y añadir fases. Se trata en ver que esos individuos, si son buenos y están formados como toca, no se equivocarán.

El segundo sentido es que se debe descargar la responsabilidad (o Accountability en inglés) en las personas. Las personas deben tener el poder de tomar decisiones, y se debe confiar en ellas. Cuando no se confía en las personas es cuando vienen los procesos. Si estás en esa situación te deberías plantear, ¿Tengo las personas adecuadas? ¿Puedo conseguir transformar a este equipo en las personas en las que podría confiar? Intentar tapar los defectos de los individuos con procesos o con herramientas, sólo será un parche. La solución está en transformar a esos individuos.

Interacciones

En los procesos las interacciones se suelen describir con flechas que unen cajas. Y muchas veces se basan en herramientas, como aplicaciones o formularios. Se trata de estandarizar estas interacciones, y muchas veces limitarlas, para que queden bajo el control del procedimiento. ¿Por qué va a hablar un programador con el usuario cuando un analista funcional ya ha descrito exactamente lo que hay que hacer? ¿Por que va a preguntar un programador a sus compañeros si necesitan ayuda, cuando tiene un cuaderno de carga que le describe exactamente lo que debe hacer?

Pero es lógico que se llegase a pensar. Las interacciones son la base del caos. El número de interacciones posible en un equipo crece de forma cuadrática con el tamaño del equipo.

Con un equipo de tamaño dos tenemos 1 interacción. Con tres personas 3 interacciones. Con cuatro personas 6 interacciones. Con 10, 55 interacciones posibles. Con 20, hay más de 200 posibles interacciones. Esto lo hace incontrolable. ¿o no?

Si dejamos de confiar en los procesos y empezamos a confiar en los individuos, las interacciones son generadores de valor, no de caos. Son generadores de caos, cuando no confiamos en el criterio de las personas, pero si nos fiamos, ese caos desaparece, teóricamente.

Cuando se habla de interacciones entre personas, como valor, también hay dos puntos de vista.

El primero es que cuantas más interacciones mejor. Se trata de permitir y potenciar la comunicación. Se trata de hablar y no de escribir. Se trata de verse las caras y de empatizar. No hablamos de hacer muchas reuniones, sino de permitir que las personas del equipo puedan hablar entre ellas y trabajar juntas. Ellas solas se definiran sus procesos.

El segundo es que las interacciones deben ser de calidad. Deben aportar valor. Pero, ¿Qué significa de calidad? Pues muchas cosas:

  • Comunicaciones con sentido, veraces y útiles. Hablamos de no perder el tiempo en las interacciones, sino conseguir que sean de utilidad. No hablamos de reuniones eternas con todo el equipo.
  • Hablamos de respeto. De no ir criticando a los demás libremente y sin ánimo constructivo.
  • Hablamos de confianza, la cual se transmite en las interacciones de cada día.
  • Hablamos de transparencia, y de poder decir las cosas como son.
  • Hablamos de trabajar en grupo, de pair programming, de compartir objetivos.

Siempre digo que la mejor manera de mejorar es apuntar a lo que se hace mal. Y eso debe ser un elemento de comunicación. Transmitirse qué hacemos mal, genera esa crítica constructiva. Hablamos de generar un conflicto positivo, como lo acuñan algunos autores.

Por lo tanto y como resumen, hablamos de que un valor que debe existir es el de la capacidad de que las personas del equipo se puedan comunicar la información libremente y de forma fluida, que la información fluya. Individuos comprometidos, más comunicación fluida, nos lleva a equipos y organizaciones comprometidas.

Los otros valores

Al otro lado de la frase hay otros dos valores que se ponen en segundo plano. Y esto es lo importante: No se dice que sean malas prácticas, sino que deben estar en segundo plano. Esto ya os lo comente en el artículo sobre “Ignorando completamente la derecha“. Así, esto no quedaría completo si no los repasásemos también.

Procesos

Los procesos son las grandes tareas que realizamos. Los procedimientos son las reglas de juego bajo las que las personas se coordinarán para hacer estas tareas. Cuando se habla de dar un enfoque de proceso o ponerse a considerar los procesos, hablamos de procedimentarlos, de darles reglas. Si los pones en primer plano, como gestores deberíamos volcarnos en definirlos e intentar llegar a los mejores. Pero cuando los pones en segundo plano lo que sucede es que dejas que los equipo se definan sus procesos. Y esa es la clave en esta primera frase, definir procesos, pero dejar que los equipos se los definan ellos solos. Hacer las cosas sobre la marcha no suele ser buena idea porque requiere mucha comunicación para coordinarse cada vez y mucho esfuerzo decidiendo cada vez como lo haremos. Además perdemos la capacidad de aprender de nuestros errores y plasmar los cambios en el nuevo procedimiento. Así que tener un par de procedimientos, es bueno. Pero no impuestos, sino que surjan del equipo. Así las personas están siempre por delante.

Por supuesto no hablamos de documentar procedimientos. Hablamos de tener claros los procedimientos. Vamos a poner un par de ejemplos. ¿Cómo se hace una release? Tener claro a quién se involucra, a quien se avisa, cuando se pueden hacer y demás aspectos, es en el fondo definir el procedimiento.

Resumen: Apostemos por los procesos, pero los generados por los equipos.

Herramientas

Estoy cansado de escuchar frases como “Quitemos JIRA que es sólo documentar, proceso y herramienta, todo anti-Agile”. Las herramientas son buenas. Pero volvemos al concepto de ponerlas en segundo plano detrás de las personas y las interacciones. Cuando quedan detrás, implícitamente estamos prohibiendo dos cosas:

  • No pueden gobernar o forzar a las personas. No es un elemento de imposición de procesos.
  • No pueden sustituir a la comunicación de las personas.

Vamos a desgranar esto un poco. Por un lado, la herramienta no puede sustituir el criterio o la flexibilidad de los equipos. No podemos darle un JIRA al equipo en el que prohibimos añadir elementos al sprint y que tienen que hablar con el responsable de desarrollo para ello. Eso es forzar el procedimiento. Si el equipo, para asegurarse, quiere auto forzarse, entonces está bien. Un ejemplo sería forzar un WIP máximo. Lo que no está bien es que el jefe de desarrollo coja y meta la limitación y les prohiba tener un WIP más alto de un número.

Entendiendo mal estos valores

Hay grandes grupos de incomprensión (siempre IMHO) de esta frase que voy a desgranar a continuación:

Procedimentar la interacción

El valor de la interacción no es que la gente hable y que haya muchas reuniones. Es que haya una comunicación real, veraz, constructiva y de confianza. Es más sobre llevarse bien y remar juntos, que sobre hablar mucho. Pero hay gente que cree que esto va sobre montar reuniones diarias. ¿Nunca te has planteado que imponer al equipo las stand-up meetings, las retros, las review, no deja de ser procedimentar?

Individuos e interacciones no significa hacer muchas reuniones y encuestas. Es mucho más que eso.

Muerte a los procesos y las buenas prácticas

Siempre he dicho que hay muchísimo valor en las buenas prácticas. Creo que la norma 12207, aunque huele a rancia por todos los costados, encierra mucha sabiduría. Y lo mismo con PMBOK, ITIL, Prince2, COBIT5 o el nuevo VeriSM. Creo que hay que estudiarlas conocerlas y sacarles el jugo bueno que tienen dentro.

Pero hay gente que coge esta línea y dice: Eso son procesos, y los procesos no tienen cabida en el mundo del desarrollo ágil. A esa gente les digo algo: ¿Te has leído la guía de Scrum? Porque es un paquete de procesos y buenas prácticas mucho más estricto que el PMBOK. El PMBOK por ejemplo, te dice que tendrías que hacer un acta de constitución de proyecto. Pero no te dice como. la guía de SCRUM te dice como tiene que ser de grande un equipo. O te dice con qué frecuencia deben hacerse los sprints (de 1 a 4 semanas). ¿Y si quiero de 5 semanas, ya no es Scrum?.

A lo que voy es que esta frase no te da derecho a cargarte de un plumazo todo el saber que habíamos aunado hasta hace unos años. No te da derecho a renegar del pasado.

Conclusiones

Resumiendo: el mensaje es que necesitas personas buenas, y que conformen un equipo que se relacione bien. Dales libertad y poder de decisión y ellos solos (o solas) se definiran sus procesos y decidiran qué herramientas utilizar. Él éxito de tu equipo depende mucho más de su capacidad, de como se lleven y de que nadie les ponga barreras. No depende de los procedimientos de la empresa o de las costosas herramientas de gestión que hayamos implantado.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

2 comments

  1. Jose Antonio Quesada 30 noviembre, 2018 at 10:28 Responder

    Muy buena reflexión. Totalmente de acuerdo. Hace tiempo que tengo un borrador de artículo titulado “La falsa agilidad” donde tenía pensado replicar muchas de tus frases
    Los últimos años se demoniza todo lo anterior como si Agile fuera algo moderno, cuando hace décadas que sus prácticas están inventadas.
    Una vez más, enhorabuena

Post a new comment