Esta entrada es la continuación, y la parte intermedia de una serie de post acerca de los doce principios del agile manifiesto, en este enlace esta la primera parte, con su introducción y los 4 primeros principios, en este otro la ultima parte y los últimos 4 principios.

 

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

En mi opinion, una de las cosas por las que más a triunfado el agilísimo es precisamente porque en vez de enfrentar a dos partes (cliente – empresa , manager – equipo, etcétera) intenta unirlas con un objetivo común, pone el foco en las personas y no en los procesos, y al final las personas necesitamos que confíen en nosotros, que se nos tenga en cuenta y que nuestra opinión tenga valor.

Si se cumplen esas cosas (y otras más materiales como salario, horarios, etcétera) es mucho más probable que las personas estén motivadas, y esa es una parte esencial de este punto, tener a las personas motivadas.

Claro que, motivar a una persona no es fácil, pues con todo un equipo esto se complica todavía más, y seamos sinceros; con los roles y los egos que suelen darse en los equipos de desarrollo de software (no siempre, pero en demasiadas ocasiones todo/as lo hemos visto) se hace complicado precisamente eso: la motivación de un equipo como conjunto de personas, complicado pero no imposible 😉

Aquí yo estoy convencido de que actitud siempre aporta más que aptitud, una parte clave los equipos agile son los soft skills de los mismos, no solo como individuos, sino como grupo , y como las super estrellas (ahora se hace viendo el numero de commits en algún proyecto de moda…) no suelen resolver problemas más allá de apagar fuegos, pues queda fuera de cualquier duda tener los equipos motivados es necesario poder hacer buen software (o prácticamente cualquier cosa).

Otro punto peliagudo en esta frase se dio por aquello de «confiarles la ejecución del trabajo», en los principios esto era directamente rechazado por casi cualquier directivo, jefe de proyecto, incluso clientes. El motivo era sencillo: existía una cultura mucho más proclive al refuerzo negativo que al positivo, además de la propia desconfianza propiciada por ciertos modelos de trabajo y de «liderazgo».

Pero el principio es simple y aplastante, al final el que saca el trabajo adelante no es el jefe de proyecto, solo cual héroe griego, es el equipo en su conjunto, la diferencia en los modelos agiles, y que hoy en día es habitual y lo damos por hecho, es que el teach leader, el product owner o llámalo rol X (si, si también el «jefe de proyecto») es parte del equipo, con lo que esa diferenciación no existe y esa es precisamente la idea, equipo = todos, y por tanto la motivación de todos en conjunto más sencilla si eliminamos esa barrera jerárquica.

Además, y por concluir con este punto, a día de hoy todo el mundo comprende que un equipo motivado, en el que se puede confiar siempre ofrecerá mejores resultados que uno que no lo este, donde existan las desconfianzas, falsedades, etcétera.

 

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

Otra vez se hace referencia a varios puntos claves: personas y NO documentar de manera gratuita junto con enriquecer la comunicación, siendo esta además cara a cara.

La comunicación se puede abordar desde muchas ópticas y diferentes puntos de vista, pero cuando desarrollamos software nos centramos en entender los requisitos y entregar software que aporta valor y además es eficiente.

Cuando también nos encontramos con que la información se usa como arma;  aquello de no basarnos en mails, words, tarjetas de jira o lo que sea para el «y tú más» o el «te lo dije» entonces no estamos aportando valor al producto, vamos, todo lo contrario.

Este es uno de los motivos por el que se hace hincapié en el cara a cara, a ver esto es sencillo de explicar= cara a cara es además de palabras, comunicación no verbal y obviamente con un gesto, una postura, o una «cara» se dice y expresa mucho más que words, powerpoints o tarjetas variadas.

 Además la idea subyacente es que seamos capaces de detectar cuando algo no va bien y lo corrijamos a tiempo, si entendemos (por poner un ejemplo) que el cliente no percibe valor en la manera en la que estamos planteando una funcionalidad, o que el equipo de desarrollo no entiende porque el cliente quiere algo de una manera concreta, entonces habremos ganado, como poco la duración de un sprint, en los modelos antiguos se podía llegar a perder un año o más de todo un equipo precisamente por estos motivos.

7. El software funcionando es la medida principal de progreso.

Más claro es difícil, si el software no aporta valor, no funciona, de nada sirve todo lo demás, es una realidad que puede «picar» a más de uno/a pero es una realidad, los clientes no quieren saber nada de integración continua, de calidad, de arquitecturas , de herencia, de contratos de interfaces ni de nada de esto que tanto nos preocupa (y nos gusta), el cliente quiere valor y software funcional que cumpla con sus expectativas y que le ayude a resolver problemas.

El como nos lo «montamos nosotros» es otro asunto, en este punto hay una parte que siempre, siempre, se le complica al rol de product owner; como conseguir soluciones más rápidas, sencillas y funcionales sin que se planteen los típicos problemas desde el area técnica sobre la idoneidad de una solución más o menos compleja en la capa a nivel de código, arquitectura, etcétera. Encontrar el equilibrio no siempre es sencillo (de hecho, casi nunca lo es).

Pero la idea es muy simple: la manera de medir que estamos haciendo, y si lo estamos haciendo bien, es bastante sencilla: el software o funciona o no funciona, no hay mucho más.

Desde luego que por ejemplo el definition of done  puede dar lugar a ciertas interpretaciones, pero siendo honestos, medir en base a diagramas, métricas y todo lo que se quiera, pero sin software funcional, entregado y que el cliente quiere y usa.. mal.

Por ultimo dejar claro que quiero a sonarqube (por poner un ejemplo entre muchos, pero este es claro a más no poder) y otros sistemas que miden «progresos» y calidades en mis ciclos de desarrollo, pero bajo mi punto de vista dichas herramientas se han convertido en auxiliares, en refuerzos, en compañeros/as técnicos, ya no son el único modelo con el que medir el progreso de un producto, se ha centrado mucho mas entorno a los usuarios y a las funcionalidades.

 

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

En este punto hay varios aspectos que también son claves, por un lado se habla de mantener un ritmo constante ¿en qué? en entrega de valor, en incremento de calidad, en ser más rápidos y más eficientes a la hora de escribir código, en detectar bugs, etcétera.

Y por otro se habla de desarrollo sostenible, esto es de nuevo referente a las personas, a todas las personas, a no quemarlas, a tener un ritmo de trabajo que se pueda mantener de manera normal, a no estar siempre en sobreesfuerzo (XP al ataque de nuevo 😉 ), de que apagar fuegos no es un buen negocio a medio-largo plazo, la sostenibilidad en este punto va precisamente de eso.

Esto hoy en día se entiende, se entiende hasta el punto de que es una de las cosas que suelen valorar, y mucho, por las personas implicadas en desarrollo, a la hora de cambiar, abandonar o empezar un nuevo proyecto laboral, vamos que si no se es capaz de ser atractivo como empresa/proyecto en este punto difícilmente tendremos personas que aporten al proyecto.

Y por ultimo, esto no solo se refiere a los desarrolladores, sino también (en la propia frase lo pone claramente…) a los usuarios.

Vamos que testeen los usuarios una aplicación sin haberlo pedido no es una buena idea, quemarlos con bugs, con procesos en modo acrobático para realizar tareas que deberían ser sencillas y demás sufrimientos a los que se veían sometidos, y por otro a los «managers» que también tiene sus desgastes y su problemas de sostenibilidad, cargar con toda la responsabilidad a un product owner, o pensar que a un cargo de responsable «le va en el sueldo» determinadas cosas son buenos ejemplos de cosas que no deberían suceder.

 

Como comentaba al principio de esta entrada, esta es únicamente la segunda parte de tres entradas – primera partedonde reflexiono sobre los doce principios del manifiesto ágil, a continuación el enlace con la ultima entrada donde están los últimos 4 principios y mis conclusiones personales.

Etiquetas:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.