×
×

Scrum es un marco de trabajo, no una metodología

 

 ¿Por qué este artículo?

Scrum se usa en la mayoría de los casos como "simplemente" una metodología para la entrega de software, olvidando que Scrum impulsa la autonomía de los equipos no solo para decidir cómo gestionar el trabajo, sino también para poseer, definir y mejorar continuamente sus procesos y prácticas de desarrollo. Enfocar Scrum como una metodología produce efectos negativos como falta de implicación en los equipos y de reducir la mejora continua, derivando en un Scrum "mecánico" o "Zombie". En este artículo analizamos porqué Scrum es una herramienta para ayudar a optimizar el trabajo de los equipos y no un corsé en el que importa más el formalismo que el valor entregado.

 

 

 Definición Guide, marco de trabajo y metodología

Comencemos viendo las definiciones de Scrum y de los términos "marco de trabajo" y "metodología".

Según la Scrum Guide 2017, Scrum es:

Scrum (n): Un marco de trabajo dentro del cual las personas pueden afrontar problemas adaptativos y complejos, a la vez que entregan productos del máximo valor posible de manera creativa y productiva.

Según la Wikipedia en castellano (la RAE no define este término), un Marco de trabajo es:

Marco de trabajo: un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.

El término Metodología se usa de manera incorrecta, pues la Wikipedia lo define como "estudio o elección de un método pertinente o adecuadamente aplicable a determinado objeto". El término más parecido al significado que se le da en el ámbito empresarial y tecnológico es el de "Proceso de negocio", que la Wikipedia define como: 

Un proceso de negocio o un método de negocio es una colección de actividades o tareas relacionadas y estructuradas que en una secuencia específica produce un servicio o producto (cumple un objetivo de negocio en particular) para un cliente o clientes concretos

 

Si comparamos estas tres definiciones podemos sacar una primera conclusión: mayoría de organizaciones y equipos entienden Scrum como un método o proceso de trabajo, donde el protagonismo lo adquiere entender su ciclo de vida, ceremonias, roles y artefactos. Este error de concepto, más allá de las restricciones organizativas que existan, es importante pues determina las expectativas de qué se puede obtener de Scrum y de como utilizarlo.

Me gusta plantear esta alternativa para asentar la diferencia entre ambos enfoques:

Una metodología la definen unos, y se sigue sin cuestionarla. Un marco de trabajo te obliga a pensar y a definir tu manera de trabajar.

 

 Scrum y la complejidad

La definición de Scrum hace referencia explícita a su utilidad para afrontar problemas complejos, como son frecuentemente la realización de proyectos tecnológicos innovadores. En otros artículos como Contextless Scrum: ¿marco orientado a principios o a reglas? hemos detallado las razones por la que Scrum da mejores resultados que los métodos tradicionales, que analizan el problema y prescriben una solución detallada, destacando un plan de trabajo definido y poco flexible.

 

Matriz de Stacey

 

Otros tipos de actividad dentro de las empresas se han gestionado con éxito usando procesos definidos, como p.e.:

  • el soporte a usuarios (peticiones y solución a incidencias)
  • operaciones tecnológicas (gestión de servidores y redes)
  • gestión de la demanda (de nuevos servicios o aplicaciones)

Esta inercia ha hecho pensar a las organizaciones durante décadas que un proceso definido ("metodología"), diseñado y controlado frecuentemente por departamentos centralizados de Arquitectura y Métodos, y no por los equipos de trabajo, era la manera òptima de obtener buenos resultados en los proyectos de desarrollo de producto.

 

 Diseño organizativo y gobierno IT

 

Jerarquia tradicional en organizaciones

Fuente: https://twitter.com/JimmyJanlen

 

El modelo organizativo tradicional es el jerárquico y funcional:

  • Jerárquico: los managers controlan la calidad y eficiencia del trabajo de las personas y equipos a través de la inspección directa, pero especialmente a través de indicadores para escalar este control y evaluarlo de una manera más cuantitativa. Este control necesita de la definición de procesos detallados para comparar como de diseña y ejecuta el trabajo.
  • Funcional: especializamos y agrupamos a los trabajadores por tipo de trabajo y conocimientos. Estas personas, frecuentemente en grupos y departamentos diferentes, se coordinan principalmente según los procesos definidos y no según su criterio.

 

De esta manera, la cultura tradicional de las organizaciones está orientada a procesos, y por tanto es natural que busquen la estandarización viendo a Scrum como un proceso (o metodología).

 

 ¡Agile va más de cultura que de procesos!

 

El iceberg organizativo de la agilidad - visión operativa vs visión cultural

Scrum Strives for Deep Organizational Change - Alex Ballarin

 

Otro factor, alineado con los anteriores, que facilita la confusión de Scrum con un proceso o metodología es la visión de una organización como un sistema basado en estructura, procesos y operaciones. Simplificando se puede resumir en "si la gestión de proyecto era planificar con un cronograma de tareas (Gantt), Scrum es planificar con Sprints". Así, al buscar la "implantación" de esta "metodología" aquello que se identifica como sujeto a cambiar es la parte operacional:

  • Procesos: se debe cambiar de un ciclo de vida en cascada, sino sprints.
  • Herramientas: se debe cambiar de una herramienta ofimática (p.e. MS Project) a una web y colabortiva (p.e. Jira).
  • Diseño organizativo: se debe cambiar los roles de jefe de proyecto a Product Owner, etc. (lo de los equipos autosuficientes y "cross-funcionales" suele olvidarse).

Todo esto puede gestionarse porque puede planificarsemedirse. Pero estas organizaciones se olvidan de algo mucho más difícil de identificar y cambiar (por eso la metáfora del iceberg):

  • Valores: creemos en la transparencia, admitir la incertidumbre y los errores, en el beneficio del equipo en vez del propio, etc.?
  • Principios: ¿pensamos que la mejor manera de obtener el éxito es planificarlo y documentarlo todo exhaustivamente? ¿cada tarea la tiene que hacer únicamente la persona más experta en este dominio? Etc.
  • Cultura organizativa: ¿Cuál es la manera en la que las cosas se hacen en la organización? ¿Qué se tolera y que no? ¿Qué se recompensa y que se penaliza?

Los cambios en aspectos operacionales pueden planificarse de manera centralizada (el enfoque de "implantar Scrum"), pero los cambios culturales nunca pueden implantarse, sino liderarse en grupos pequeños donde se puede establecer una confianza suficiente entre personas. 

En la mayoría de organizaciones que conozco que han adoptado Agile y Scrum, se han fijado más en la parte operacional que en la cultural. Y eso nos conduce al tipo de Scrum obtenido, mecánico, fláccido o zombie, como veremos en el siguiente apartado.

 

 Scrum Zombie o Mecánico

 

p51_zombie_scrum.jpeg

Fuente: Zombie Scrum - The Liberators

 

Muchas organizaciones están descontentas con el valor que obtienen de Scrum. Se puede haber reducido el riesgo de los proyectos y haber mejorado el valor entregado a los usuarios, pero los miembros de los equipos Scrum suelen estar frustrados por limitaciones heredadas de la cultura y metodología heredades de la organización en la que trabajan, p.e.:

  • Proyectos cerrados e inflexibles, con dificultad para optimizar la visión y alcance del producto tal y como se aprende más de éste.
  • Equipos de desarrollo externalizados y con difícil comunicación con los usuarios, por motivos ajenos al desarrollo de software (p.e. que no denuncien a la organización cliente por "cesión ilegal de trabajadores").
  • Rigidez en los estándares de desarrollo por estándares definidos por otros y que no pueden alterar.
  • Desconocimiento de los objetivos de los eventos de Scrum, que se realizan mecánicamente y donde se emplea más esfuerzo en seguir una ceremonia e inspeccionar (analizar) que adaptar (tomar decisiones basadas en el aprendizaje).

Por estos y otros motivos, que se entienden bien después de lo expuesto en los apartados anteriores, en la industria se habla de Scrum mecanicista o Zombie, enfocado en el formalismo y que no empodera a los equipos para aprender y utilizar estos conocimientos para optimizar continuamente el trabajo hecho, que es el objetivo último de Scrum. En el enlace del pie de la foto superior, se encuentra un estudio de The Liberators con más de 700 equipos que explican el grado de "infección zombie" que sufren. Es muy recomendable leerlo.

 

 Conclusiones

El objetivo del artículo era entender porqué se concibe en las organizaciones frecuentemente Scrum como una metodología y no como un marco de trabajo que empodera a los equipos para aprender continuamente y utilizar este aprendizaje con el fin de mejorar y maximizar el valor. Espero que este análisis pueda ayudaros a argumentar mejor porqué Scrum es un framework (marco de trabajo) y no una metodología, una distinción que no es un simple matiz sino que tiene profundas implicaciones.