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.
Blog de Daniel Brandi 
Hola Daniel.
Acerca del punto «No hacen falta managers, no hace falta gestión».
Gestión y Managers son dos cosas distintas (pero relacionadas) que las metodologías y formas de organización de empresa «tradicionales» se han encargado de mezclar. Cuando se habla de «managers» automáticamente uno piensa en jefes y estructura jerárquica, confundiendo «gestión» con «command & control». Agile en ningún momento propone dentro de sus valores la ausencia de «gestión», pero sí la ausencia de jerarquía.
La gestión agile es necesaria y ha de facilitarse mediante roles de liderazgo (tipo Scrum Master, Product Owner etc…) a través de un estilo de Liderazgo Servicial (Servant Leadership es la base del «management» en Agile en contraposición a las jerarquías «command and control» tradicionales). La suma de liderazgo servicial + autoorganización de equipos + correcta estrategia de escalado (mediante marcos como SAFe, LESS o similares) da como resultado una gestión Agile.
La gran diferencia en Agile no es la ausencia de gestión, sino la ausencia de jerarquía de poder: el líder servicial no busca atesorar poder ni crear silos funcionales,sino facilitar la labor de los equipos, unos equipos que no están bajo su «mandato» sino bajo su responsabilidad. Esto no es fácilmente entendible para ciertos profesionales que erróneamente equiparan «gestión» a «poder» y que lo primero que hacen al llegar a sus organizaciones es habilitar su rol en base a lo que precisamente agile intenta desterrar: el concepto de manager jerárquico / director «ordeno y mando» / este es mi «territorio» y aquí mando yo.
¿Gestión en Agile? Sí, sin duda. SAFe establece que los principios de cadencia y sincronización entre equipos son cruciales en entornos donde trabajan varios equipos. Pero esto no significa que los equipos deban cumplir a rajatabla con lo que se le ocurra a un «iluminado» (empleando el término utilizado en el artículo) por el simple hecho de estar «más arriba en la jerarquía». Agile se basa en el más profundo respeto por todas y cada una de las opiniones de los miembros de los equipos, sin que una opinión se anteponga a las demás por una «simple» cuestión jerárquica.
Por tanto, sí a la gestión, sí al liderazgo servicial (gestión de impedimentos, alineación con negocio, supervisión técnica, coaching y desarrollo de equipos y personas). No a los «managers» con «mando en plaza» y nombre en cajita de organigrama que luego queda bien en Linkedin.
Tras varios años de vivencias Agile, esa es la conclusión a la que, juntamente con otras muchas personas, he llegado. Lo demás, es querer nombrar a lo de «siempre» con palabras de moda, faltando a los valores y principios básicos de Agile pero usando los nombres de sus técnicas y herramientas para querer «subirse a la moda», o dicho de otra manera, cambiar de nombre a las cosas pero que realmente no cambie nada y que los jefes sigan pudiendo ser jefes en sus reinos de taifas.
La vida va de elecciones, no se puede tener todo… O se es Líder Agile servicial a los equipos, o se es jefe jerárquico con «mando en plaza y gente a cargo». No seré yo quien diga cuál de las dos opciones es la mejor (porque no tengo respuesta única a eso) pero sí me gustaría dejar claro que ambas opciones son incompatibles y una buena estrategia organizativa pasa por saber elegir cuál de las dos usar en cada momento, sabiendo que elegir una supone renunciar a la otra y que no necesariamente una es siempre mejor que la otra.
Saludos.
Hola Israel,
te agradezco tu comentario, muy extenso y bien explicado.
Tras más de una década trabajando en agile en diferentes organizaciones de diferente tamaño mi propia experiencia es que cuando sólo hay un equipo ágil y todo el mundo tiene suficiente experiencia efectivamente la ausencia de «jefes» es el mejor modelo. Pero en mi experiencia ese modelo no escala bien. Cuando tienes 5 equipos ágiles trabajando en el mismo producto (30 personas), personas con diferente nivel de experiencia y conocimiento, etc… hace falta gestión además de liderazgo.
Un saludo