¿Cuál es el mayor problema con el proceso de desarrollo SAFe?

No he trabajado personalmente en una empresa SAFe, pero lo leí y hablé con la gente al respecto. Así que tengo una opinión pero tómalo con un grano de sal.

Mi problema con él (y el problema que mucha gente tiene con él) es que es un sistema grande y complejo con procesos, roles y procedimientos cuidadosamente definidos. A diferencia de Scrum, que es un sistema muy liviano con muy pocos procesos, roles y procedimientos. “¡Pero Scrum no escala!”, Dice la gente de SAFe. Claro, es por eso que tenemos LeSS (Scrum de gran escala), que toma los bits buenos de Scrum y los escala (sin dejar de ser ligero y simple).

También tiene muchas capas de gobierno y control, y muchos procesos que no solo involucran el desarrollo de software, sino también en torno a la arquitectura, la planificación, la gestión de la cartera, etc. Todo esto es parte integral de la gestión tradicional de comando y control empresarial. Es por eso que SAFe es muy popular entre las grandes empresas de control y control. Realmente no quieren volverse ágiles, quieren “rápido y barato”. (¿Sabía que es un mito que Ágil significa “rápido y barato”? Escribí sobre eso aquí si está interesado: Mitos de Ágil: Ágil significa rápido y barato – Incertidumbre extrema)

Estas grandes compañías quieren un gran proceso de lanzamiento (SAFe lo llama el “tren de lanzamiento”), quieren grandes lanzamientos (SAFe lo llama el “incremento del producto”). En lugar de ser realmente ágil a escala, lo que más involucra lo que hacen personas como Google y Amazon y Facebook, que son pequeños equipos autónomos centrados en productos, entrega continua, microservicios, miles de lanzamientos por día, etc. Muy diferente a lo que son las personas SAFe hablando sobre.

Personalmente, creo que el mejor sistema escalado no es LeSS (aunque es bastante bueno, mucho mejor que SAFe, creo) sino XSCALE, un sistema nuevo y poco conocido pero sorprendente diseñado por el veterano de software australiano Peter Merel. En realidad, es un sistema “ágil desescalado”, que intenta reducir la organización a Agile, en lugar de escalar Agile a la organización. Ahora mismo estoy aprendiendo mucho sobre XSCALE y me encanta. Puedes leer sobre esto aquí: XSCALE Alliance

Hay muchos más beneficios que problemas de SAFe, por lo que esta lista seleccionada de los desafíos menores no debe tomarse aisladamente. La mayoría de los entornos de trabajo enfrentarán beneficios mucho más significativos de la adopción del marco SAFe (no un proceso) y, sin embargo, si tuviera que encontrar algún fallo en alguna parte, comenzaría con estos 5;

  1. Granularidad del desarrollo impulsado por el valor: SWJF, como lo defiende Reinertsen, es un golpe de genio y la adopción de SAFe de esto es una fortaleza. Sin embargo, la aplicación de SWJF en el nivel de Incremento del programa puede significar que los equipos se pierdan una de las mayores fortalezas de Agile para entregar un valor más alto antes de User Stories porque SAFe sugiere que trabajemos en el nivel EPIC, capacidad o conjunto de características durante PI.
  2. Asunción de SCRUM a nivel de equipo y Kanban a nivel de Portafolio y Programa: Si eres Kanban o Scrumban, no retrocedas a SCRUM. Si me preguntas, SAFe tiene estos enfoques de límite de WIP de atrás hacia adelante. Kanban en el nivel de trabajo y usar SCRUM en los niveles superiores de gestión ayuda a lograr la alineación entre los grupos intradependientes.
  3. El cambio cultural se deja para durar. Si la cultura laboral surge en la forma en que trabajan los equipos, entonces, al dejar que la cultura dure como lo sugiere SAFe, corre el riesgo de renunciar a SAFe a la irrelevancia. Los practicantes y entrenadores ágiles experimentados apreciarán la dificultad y el desafío en la gestión del cambio cultural y serán más sabios de apreciar esa cultura como un complejo y emergente.
  4. SAFe no incluye el sentido de Cynefin Framework en la complejidad
  5. Lean Enterprise, también conocido como Continuous Delivery, tiene una ventaja significativa sobre SAFe, pero estoy de acuerdo con lo que funcione en el contexto, por lo que si el liderazgo adopta SAFe, abordaré ese tren y desarrollaré las ganancias mientras inserto el pensamiento de Lean Enterprise a medida que avanzamos.

SAFe es mucho más que un “proceso de desarrollo”: es un marco de trabajo empresarial bastante completo para una empresa ágil. Es un modelo muy sofisticado y bien pensado, pero definitivamente no es para los débiles de corazón porque requiere un compromiso bastante significativo para una transformación ágil completa a nivel empresarial.

Mi mayor crítica de SAFe es que, como muchas cosas asociadas con Agile, se ha comercializado en exceso como una solución a casi cualquier problema que pueda tener y no creo que ese sea el caso. También se ha vendido como una solución de “libro de cocina” y no creo que ese sea el caso tampoco. Se necesita mucha sofisticación para implementar una transformación ágil a nivel empresarial y debe adaptarla a la naturaleza del negocio de la compañía. No debe considerarse como una solución de “libro de cocina”.

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo: Capacitación ágil de gestión de proyectos en línea para gerentes de proyectos

Recientemente realicé una encuesta sobre este tema, consulte: Resultados de la encuesta: El Net Promoter Score® de SAFe® como marco de escala es – 52.

También encontrará 13 citas de detractores, pasivos y promotores de SAFe® en la publicación.

Es un marco pesado y con eso elimina automáticamente la agilidad (al menos en parte). Puede ser que para las organizaciones de bits no haya otra forma que usar un marco como este, aunque creo que si los principios ágiles y la guía de scrum, por ejemplo, se implementan, esto también podría escalarse con LeSS.

Autor de The Agile Manifesto Unfolds y The Scrum Guide Unfolds

Blog Consultores Perdidos