En 1990 Jeff Sutherland dio los primeros pasos de lo que años más tarde se conocería con el nombre de Scrum, una metodología para el desarrollo de software en los departamentos de IT.

Quien haya trabajado con informáticos o en contacto con un departamento informático sabe que la planificación es difícil y el futuro incierto. No hay plan más allá de unas pocas semanas y el futuro escapa a toda previsión porque los programas informáticos no son complicados, sino complejos. Es una diferencia sutil, pero muy importante. En un sistema complicado hay muchos elementos diferentes que interaccionan entre sí de distintas formas. El ejemplo típico es un reloj mecánico, cuyo funcionamiento es complicado, pero previsible. Wikipedia explica que «un sistema complicado […] está formado por varias partes, pero las relaciones entre estas no añaden información adicional. Nos basta con saber cómo funciona cada una de ellas para entender el sistema».

En cambio, en un sistema complejo «existen variables ocultas cuyo desconocimiento nos impide analizar el sistema con precisión», dice Wikipedia. La predicción es imposible, porque al hacer algo no sabemos cómo afectará eso al conjunto del sistema. A menudo los programas informáticos de las empresas responden a este patrón de los sistemas complejos y no permiten hacer predicciones a largo plazo.

Lo que sucedía en las empresas es que desde la dirección se pedía a los informáticos una planificación clara y que cumplieran con los plazos, pero los informáticos a menudo no conseguían ni una cosa ni la otra. Un desastre para ambos lados de la mesa. Ante tal fracaso, pero con la vigente necesidad de tener objetivos concretos en los departamentos informáticos, nació Scrum. Hoy es la metodología que adoptan prácticamente todos los informáticos del mundo. Se trabaja en paquetes de pequeños objetivos a corto plazo, con el objetivo a largo plazo en el horizonte. Se traduce lo complejo en complicado. Se fija un objetivo a largo plazo, pero con una planificación en detalle solo a corto plazo, en una ventana de tiempo que permite hablar de tareas complicadas (previsibles), no complejas (imprevisibles).

Veamos cómo funciona. Un departamento informático tiene como objetivo a largo plazo (a cuatro meses vista) instalar un nuevo CRM (Customer Relationship Management), un programa que permita centralizar en una única base de datos todas las interacciones entre la empresa y sus clientes. Entonces fija una lista dinámica de tareas necesarias a corto plazo (a dos semanas vista). Una lista dinámica porque, a medida que se avance en el trabajo (en el sistema complejo), irán surgiendo nuevas tareas que se añadirán a la lista que se denomina Backlog. No se planifica el trabajo a cuatro meses, sino a dos semanas. Ese corto lapso de tiempo se llama Sprint. Cada miembro del equipo escoge las tareas en las que va a trabajar durante ese tiempo de forma autónoma. Puede surgir alguna discusión o diferencia, pero al finalizar la reunión cada persona ha asumido la parte de responsabilidad que le toca: Acabar en el Sprint las tareas de la lista a las que se ha comprometido. Manos a la obra y todos a trabajar. A esa planificación corta se le añade una breve reunión diaria para desbloquear posibles problemas y tomar el pulso de cómo avanza el trabajo. Al finalizar el sprint el equipo se vuelve a reunir para analizar cómo ha ido, qué han aprendido y cómo planificar el siguiente. De esta forma se fija un ciclo de trabajo eficiente de dos semanas: planificar, trabajar y supervisar, revisarlo todo y vuelta a comenzar.

De forma gráfica, la metodología Scrum funciona así:

Fuente: https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_ process.svg

Cuando Ken Schwaber publicó en 2001 Agile Software Development with Scrum (Desarrollo ágil de software con Scrum), su libro cayó como una bomba en el mundo informático, transformándolo por completo a nivel mundial. En la actualidad el sistema Scrum es la metodología estándar para gestionar las tareas y las prioridades de cualquier departamento informático.

Ahora bien, la metodología Scrum se basa en una simple premisa: todo se hace visible para todos. Y todo quiere decir todo: el proceso, el flujo de trabajo, el progreso, etcétera. Para que funcione se requiere confianza, transparencia y honestidad, entre otras cosas. Sin estos cinco valores Scrum no funciona:

• Compromiso. Los miembros del equipo se comprometen individualmente a lograr los objetivos en cada sprint.
• Coraje. Los miembros del equipo tienen el coraje necesario para superar los conflictos y los desafíos a fin de alcanzar los objetivos.
• Enfoque. Los miembros del equipo se centran exclusivamente en las tareas del sprint, no tienen otras prioridades más allá de estas.
• Transparencia. Los miembros del equipo están dispuestos a ser transparentes sobre el trabajo y sus posibles desafíos.
• Respeto. Los miembros del equipo se respetan mutuamente en cuanto a sus capacidades e intenciones.

Pues bien, eso es Scrum: una ética y una metodología de trabajo para mejorar los resultados de los equipos informáticos. ¿Quién no desearía que toda la empresa fuera gestionada igual, con la misma metodología y valores subyacentes? ¿A qué CEO, gerente o manager no le gustaría tener tan claras las prioridades de cada miembro de su equipo y poder tomar el pulso del trabajo a diario? Por otro lado, estoy seguro de que a todo empleado le gustaría disfrutar de esa autonomía para decidir de qué tareas se va a ocupar. Y se sentiría a gusto con una gestión tan eficaz, en la que todo el equipo va a una (uno para todos y todos para uno) en pos de alcanzar un objetivo común. Pues de eso trata este capítulo, de cómo fortalecer el pilar de la autonomía y al mismo tiempo conseguir un mayor enfoque y mejores resultados.

Muchas veces me he preguntado por qué (casi) todos los departamentos informáticos del mundo cuentan con esta metodología de trabajo tan eficiente y universal, mientras otros equipos, en primer lugar los equipos directivos, van a salto de mata. Cada uno a su manera, algunos peores que otros. He encontrado cuatro razones (si crees que me he dejado otras, me encantaría conocerlas: jorg@igostrategy.com):

• Los equipos de IT suelen estar formados por personas metódicas de por sí, y por eso se lo han planteado antes con mayor éxito.
• Los salarios en IT suelen ser más elevados, y por eso los informáticos han tenido una mayor presión por resultar eficientes y rentables.
• Al tratar con sistemas complejos, los informáticos tienen la necesidad de traducir lo complejo en complicado.
• Es muy fácil exigir a los informáticos, pero es muy difícil cumplir con las exigencias. Eso siempre ha provocado tensiones.

— Sigue leyendo