---

¡Superar la falta de compromiso, la gestión del cambio y el trabajo en equipo! ¡Puede que te sorprenda!

La mayor debilidad de los marcos de mejora de procesos utilizados antes de Scrum era que: Se centraban principalmente en las exigencias organizativas de una dirección que velaba por sus propios intereses.

Entre estas exigencias estaban la supervisión, el cumplimiento y la previsibilidad. No se prestaba ninguna atención a atender bien a los clientes ni a mejorar la motivación de los empleados.

Así, los equipos directivos de software y otras partes interesadas internas y externas intentaban fijar plazos inamovibles para los proyectos y supervisar fácilmente el progreso de las fases de ingeniería de software.

Penalizaban a las personas cuando algo se desviaba del plan y esperaban resolver los problemas emergentes antes de la fecha prevista de finalización.

Además, silos independientes realizaban fases de ingeniería de software totalmente separadas. Por ejemplo, el equipo de desarrollo era completamente independiente del equipo de pruebas o verificación. La mayoría de quienes supuestamente trabajaban por la misma misión empresarial ni siquiera se conocían por su nombre.

¿Imaginas por qué nuestras organizaciones tenían esta mentalidad de silos en vez de centrarse en la misión empresarial y la madurez profesional de los empleados?

La razón es simplemente la gestión matricial . La gestión matricial es una estructura de organización y gestión de empleados presente en las empresas desde la década de 1970. A primera vista, la idea que distingue a una organización matricial parece inteligente.

La dirección crea una estructura organizativa agrupando a empleados con habilidades funcionales y técnicas similares en el mismo silo o, en el mejor de los casos, en silos vecinos.

El modelo de entrega de proyectos en cascada en una organización matricial

En aquella época eran muy habituales los llamados «centros de competencias», cada uno de los cuales constituía un silo independiente y autónomo.

Un silo para desarrolladores de C++, otro para administradores de bases de datos, otro totalmente separado para aseguramiento de la calidad en otro país, y así sucesivamente. ¡Imagínatelo!

El mayor reto de la estructura matricial era que, para entregar un proyecto de software sin el marco Scrum ni Scrum Masters, los directores de proyecto tenían que tomar prestados temporalmente empleados de los silos.

Estos empleados ni siquiera se ubicaban físicamente con sus equipos de proyecto: permanecían en las salas de sus respectivos centros de competencias.

Al terminar los proyectos, los equipos temporales se disolvían y sus participantes pasaban a sus siguientes tareas en otros proyectos.

Por tanto, el valor empresarial que buscaban esos proyectos de software nunca era la máxima prioridad de los silos independientes.

Solían ver su trabajo como casillas que marcaban en un proyecto y en otro.

La dirección y el modelo matricial no les enseñaban cómo comprometer su trabajo profesional con la mejora de los resultados del negocio, incluidas las ventas, los ingresos y los beneficios.

Un artículo de McKinsey Quarterly, escrito por McKinsey & Company, también ilustró claramente esta ilusión de optimización de costes más allá de la organización matricial .

Gartner estimó que las organizaciones de todo el mundo estaban gastando anualmente 600 mil millones de USD en recuperar sus sistemas de TI tras trabajos de mantenimiento no programados y defectos.

Ahora dediquemos un momento a imaginar cómo se desarrollaban la gestión del cambio y la resolución de impedimentos en los proyectos de software. Cómo se desarrollaban en un proyecto con el modelo en cascada, una organización matricial y sin el proceso Scrum.

Sí. Tienes razón.

La dirección y los empleados trataban la gestión del cambio, los impedimentos y la resolución de errores como excepciones indeseables que nunca deberían haberse producido.

Por tanto, los cambios en un proyecto de software se habían convertido en sinónimo de retrasos. Solían provocar un efecto dominó de retrasos en cadena. Los equipos buscaban a alguien a quien culpar por los defectos y los impedimentos.

Por último, como los silos carecían de un mecanismo para procesar, corregir y aprender de sus errores, seguían repitiéndolos.

Además, seguían aumentando la cantidad de deuda técnica mientras intentaban afrontar pasivamente sus problemas.