Puede una organización ser ágil… ¿por trozos? ¿Dpto Desarrollo Ágil + Dpto Pruebas Ágil + Dpto Producción Ágil = Organización Ágil?

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.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024