Parece razonable empezar esta reflexión hablando, primero, de qué es ser ágil. Como sabes, no hay una única definición de agilidad (esto ya lo hablamos en nadie sabe lo que significa agilidad y en las metodologías ágiles no existen, posts que te recomiendo leer en este momento) por ello, en este contexto, yo voy a entender que por agilidad estamos diciendo que en nuestra organización queremos con la mayor velocidad (evitando procesos, caminos, papeleos, etc., que no aportan valor y frenan) entregar valor a los usuarios (pasar a producción), en forma de software, de manera fiable (lo que nos lleva a tener unos mínimos de calidad, testing, etc.) y constante (lo que implica NO hacer software malo malo, porque ello valdría para la primera entrega, pero por aquello de la deuda técnica frenaría la velocidad de las siguientes), para con esas entregas frecuentes aprender qué quiere y realmente necesitan los usuarios (es decir, no tengo requisitos cerrados).
Continuando con algo de contexto, necesario antes de entrar en el tema del post, más allá del concepto “agilidad” está el framework Scrum (por cierto, te dejo la entrevista que le hice a Jeff Sutherland, co-creador de Scrum), uno de muchos, pero tomado como referencia por la mayoría de los que dicen ser, o quieren ser, ágiles. De dicho framework, te he extraído algunas frases literales de la “Guía de Scrum”, versión en español, los cuales dicen:
“Tener más de nueve miembros en el equipo requiere demasiada coordinación” (un equipo Scrum no supera las 9 personas).
“Los Equipos Scrum son autoorganizados y multifuncionales. […] Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.”
Y dicho todo esto, casi que queda poco por responder. Junta todo lo dicho en los anteriores párrafos y contesta ahora a la siguiente cuestión:
Puede una organización ser ágil… ¿por trozos? Es decir, teniendo un departamento (o contando con una empresa externa) de desarrollo, que dice ser ágil (pero sólo bajo el ámbito de desarrollo), con otro departamento separado (o contando con una empresa externa) para los temas de pruebas (que puede decir que usa técnicas ágiles) y otro departamento más, separado (o contando con una empresa externa), esta vez para los temas de producción, operaciones, máquinas y similares, este esquema… ¿Puede ser Ágil? ¿Es el todo ágil?
- Pues yo te diría que el contexto anterior puede ser fabuloso, ir como la seda, etc., cosa que pocas veces ocurre, pero podría ser, pero ágil, lo que se dice ágil, yo no lo veo, y menos trabajar bajo el marco Scrum.
- Que desde que un usuario necesita una nueva funcionalidad en el software se tenga que pasar por tres organizaciones, no lo veo muy ágil.
- El gasto en “desperdicio” de burocracia, gestores, procesos, procedimientos, etc., que supone lo anterior, no lo veo yo muy ágil.
- Que ninguno de los tres equipos tenga las competencias necesarias para llevar a cabo el trabajo, ya que cada uno depende de otras personas y departamentos que no son parte del equipo, no lo veo muy ágil.
- Que tres equipos sean dependientes unos de otros siendo caja negra unos frente a otros, no lo veo muy ágil.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Que un equipo de cinco personas se encargue de analizar, implementar, implantar, testear y formar al usuario final, es muy ágil. Yo he trabajado así y el trabajo sale y sale bien y a tiempo. También salen miembros del grupo por infartos o quemados de no tener vida. Luego está la cuestión de la personalidad de los miembros del grupo. Los hay más volcados en la causa y más volcados en ser reconocidos. Se crean rencillas y lo que empieza como EL sueño dorado de cualquier apasionado por su profesión termina en pesadilla.
¿Cuál es tu opinión y tu experiencia acerca del impacto personal de este modo de desarrollo? ¿Qué ocurre cuando alguno o varios miembros del grupo se descuelgan sabiendo que el resto de miembros es capaz de asimilar el trabajo en contra de un exceso de carga laboral perjudicial?¿Cómo se incluye a un nuevo miembro en el grupo sin una apropiada gestión documental del proyecto?¿Deben asumir los miembros que quedan la autorización del nuevo miembro?¿Cuál sería ese plan de adaptación?
Gracias.