Scrum y el arte de hacer las cosas

El fracaso de Scrum y la inseguridad del mundo para los programadores

Kent Beck dijo alguna vez que inventó la Programación Extrema para hacer del mundo un lugar más seguro para los programadores. Sin embargo, el mundo aún no lo es.
En 2001 reunió a dieciséis personas —entre ellas Robert C. Martin, Martin Fowler y Dave Thomas— para reflexionar sobre el desarrollo de software. De ese encuentro nació el término metodologías ágiles y, con él, el Manifiesto Ágil: un tratado sustentado en cuatro pilares que dieron origen a los doce principios del llamado software ágil.

Pero eso ya puede leerse en Wikipedia.

Hoy, casi dos décadas después, el exponente más conocido del manifiesto es Scrum, un modelo originado en los años ochenta a partir del estudio de cómo se desarrollaban nuevos productos en las grandes empresas de la época. En 1995, Ken Schwaber adaptó sus principios al desarrollo de software, marcando un hito: por primera vez, se integraban las gerencias altas y medias con la voz del cliente dentro de la organización.
Ya no se pensaba en una única entrega final, sino en iteraciones sucesivas que permitieran al cliente comenzar a operar cuanto antes, reduciendo riesgos y mejorando la calidad del software.

En teoría, el movimiento ágil vino a romper los esquemas tradicionales de la industria. En la práctica, la historia es más sombría. Sobre el papel es impecable, pero en el terreno real se ha distorsionado. El propio Schwaber lo resumió en una frase breve y triste: “Eso me pone triste.”

¿Qué falla en Scrum?

Lo primero que salta a la vista es que, muchas veces, las personas que lo aplican tienen buenas intenciones, pero lo hacen mal. Otro factor es la cultura laboral: cómo las jerarquías y las figuras de autoridad pueden abusar de la metodología, generando lo que Ron Jeffries llamó “Dark Scrum”.
Adoptar Scrum implica un cambio de mentalidad en todos los niveles de una organización. Si una empresa no está dispuesta a aceptar ese cambio, el fracaso de la implementación es inevitable. El problema no es saber hacia dónde ir, sino cómo poner en marcha lo que se sabe que debería hacerse. La clave está precisamente ahí.

Piénselo por un momento: ¿cuántas veces ha visto un puesto estratégico ocupado por alguien sin las competencias necesarias? ¿Cuántos nombramientos recaen en personas que no comprenden —ni ejercen— sus responsabilidades?
Promover a un buen técnico a un puesto que desconoce suele derivar en un mal líder. La empresa pierde a un excelente ejecutor y gana un pésimo estratega. Bossidy y Charan lo analizan en El arte de la ejecución en los negocios: la brecha entre los objetivos estratégicos y la ejecución efectiva. Su tesis es clara: la implementación es una disciplina que forma parte de la estrategia misma y debe integrarse en la cultura organizacional.

La cultura organizacional como raíz del problema

Muchas empresas pierden buenos técnicos porque promueven mal. Pero ese no es el único factor.
Hace años leí un artículo titulado “Prohibidos monos y lagartos”, de Alejandro Pérez e Iván Zaera. En él identificaban dos mentalidades tóxicas dentro de cualquier organización. La primera, la del mono: alguien que domina una herramienta pero no la comprende. Si algo cambia, su conocimiento se derrumba. La segunda, la del lagarto: quien vive para sobrevivir al día, preocupado más por la hora de salida o el próximo pago que por su desarrollo profesional.

Con este marco, es más fácil entender por qué Scrum fracasa en tantos casos. Algunos no conocen la metodología; otros la reducen a un proceso burocrático. Y, sobre todo, las jerarquías no abandonan la microgestión.
Scrum establece un vínculo entre la alta dirección y los equipos operativos, pero ese vínculo exige confianza, autonomía y visión compartida. Sin ellos, lo que debería ser un marco ágil se convierte en una cadena de control.

Entonces, ¿esto impide realmente que Scrum funcione? ¿Hace inseguro el mundo para los desarrolladores?
Sí. Lo hace peligroso para todos los involucrados.

La base técnica de Scrum

Scrum tiene fundamentos sólidos: prioriza el valor del producto por encima de lo accesorio; recomienda equipos de entre tres y nueve personas; promueve la autogestión y el logro de objetivos medibles.
Por eso insisto en la importancia de comprender los objetivos de la empresa —a corto, mediano y largo plazo— y de actuar como la conciencia técnica del cliente. No se trata de hacer lo que el cliente pide, sino lo que realmente le aporta valor. Para eso nos contratan como expertos, no como maquiladores.

El problema de la administración de proyectos

Seamos claros: Scrum proporciona un marco para el desarrollo ágil, pero no enseña a administrar proyectos.
En demasiadas empresas, los Project Managers carecen de formación técnica. A veces son vendedores, ejecutivos de cuenta o incluso personal administrativo cuya función se limita a dar fechas. No comprenden la ingeniería del software ni la complejidad del proceso que gestionan. Los cursos de Scrum tampoco los preparan para eso.

Ian Sommerville, en Ingeniería de Software, distingue entre los métodos predictivos (como cascada o espiral) y los adaptativos (como los iterativos o ágiles). Para efectos prácticos, podemos agrupar a los clásicos dentro del enfoque predictivo y a los ágiles dentro del adaptativo. Ambos comparten fundamentos: análisis de riesgos, costos, líneas base, requerimientos y control de calidad.
Por tanto, sí: es posible hacer Scrum bajo los principios de la ingeniería de software, y también bajo marcos como el Project Management Professional (PMP) o PRINCE2. Las diferencias son de enfoque, no de fondo.

Conclusión

La administración de proyectos exige que todos conozcan las reglas del juego.
Si aplicamos metodologías ágiles, debemos asumir el cambio cultural que implican. El Project Manager debe interactuar con todos los niveles —desde la dirección hasta la operación— y entender la lógica técnica detrás de cada entrega.
El desarrollador, por su parte, debe involucrarse con los objetivos estratégicos de la empresa y contribuir activamente a ellos.
Y la organización, en su conjunto, debe aprender a colocar a las personas correctas en los puestos clave. Solo así podrá aspirar a la ejecución efectiva de su estrategia.

Saludos cordiales.