Creo que está bastante aceptado dentro de la industria de desarrollo de software que la forma en la que se obtienen mejores resultados es siendo ágil, aplicando metodologías ágiles que permitan obtener software lo más cercano posible a las necesidades y que el proceso de desarrollo sea lo más sostenible posible.

En muchas empresas la alta dirección acepta el concepto de agilidad pero no tienen claro lo que es ser ágil y mucho menos, lo que no es ser ágil.

Creo que todos tenemos claro que desarrollar software no es un proceso industrial, proceso tipo con el que se ha querido comparar durante varias décadas, es algo diferente. Los actores son diferentes, el resultado es diferente, la manera de obtener el resultado es diferente.

No soy la persona más adecuada para decir qué es la agilidad, para eso hay gente muy buena divulgando sobre ello como Javier Garzás al que sigo desde hace tiempo, pero si quiero listar una serie de cosas que, bajo mi punto de vista, muchas veces llevan a confusión y que mucha gente cree que tienen que ver con la agilidad y no es así. Esta confusión es mayor entre la alta dirección que no está estrechamente ligada con el desarrollo de software:

• No hay que documentar. Quizá la confusión viene porque en proyectos en cascada hay mucha documentación y en contraprestación mucha gente cree que en metodologías ágiles no se documenta. Nada más lejos de la realidad. Hay que documentar igualmente aunque otras cosas o de otra manera. Los epics deben tener una descripción suficiente, las historias de usuario necesitan estar documentadas, incluso el definition of ready o el definition of done debería estar documentado para no tener lugar a dudas. Es importante tener claro que ser ágil no es sinónimo de sentar a cuatro o cinco personas alrededor de una mesa a desarrollar lo que a uno de ellos se le acaba de ocurrir, sin estructura ni análisis previo.
• El alcance se puede cambiar en cualquier momento. Es cierto que las metodologías ágiles nos separan de un desarrollo en cascada en que el alcance no tiene que estar cerrado ni firmado a fuego antes de empezar, pretenden tener un proceso más iterativo que permita que el resultado sea lo más cercano posible a lo que necesito. Pero de ahí a cambiar el contenido de un sprint en curso, cambiar la visión del producto o símplemente dejar de hacer lo que se tenía previsto para hacer lo que a un iluminado se le ha ocurrido hoy, hay un paso muy grande. Sí a tener un proceso iterativo vivo; no a ir como pollos sin cabeza.
• No hay fechas. Es uno de los errores más comunes. Hay gente que piensa que porque esté usando metodologías ágiles no tiene que comprometer una fecha. Se puede y se debe comprometer una fecha. Lo que no está cerrado es la lista de funcionalidades que se entregará en una fecha o el detalle de cada funcionalidad. Eso está vivo y cambiarlo depende de muchos factores (daría para hablar mucho sobre esos factores) pero poner una fecha yo creo que es sano.
• No hay managers, no hace falta gestión. Este es quizá el punto más controvertido. Cuando hablamos de equipos ágiles hablamos de equipos autogestionados. Por definición son equipos que no necesitan la figura de un manager ya que todo el mundo sabe lo que tiene que hacer y el propio equipo busca el mejor resultado por si mismo, con una dinámica siempre positiva. Este modelo puede funcionar en equipos donde todo el mundo es bastante senior, ya ha trabajado con metodologías ágiles anteriormente y el tamaño del equipo no es demasiado grande (3-6 personas). El problema viene cuando no se cumplen estos puntos. Es decir, hay personas más junior que necesitan de gestión y supervisión técnica, alguien tiene que ser su mentor. También cuando el equipo trabaja en un subproducto de un producto grande. En este caso hay que mantener una estrategia y táctica tecnológica común entre todos los equipos de subproducto y por tanto hay un marco de decisión más amplio que el del propio equipo. Por último, la gestión es necesaria cuando se quiere escalar los equipos ágiles, cuando hace falta ser más rápidos y se requiere de más gente trabajando. Pasar de un equipo de 6 personas a un equipo de 40 trabajando en un producto no es nada fácil y eso se tiene que hacer de manera ordenada y bien gestionada para evitar que sea un caos. En este caso hace falta una gestión y liderazgo compartido entre todos los equipos.

Es muy posible que esté equivocado en algún punto o que alguien no comparta mi visión. Por favor, no dudéis en comentar el post y darme vuestro punto de vista al respecto.