El imperio contraataca. SAFe, la metodología rebelde, pesada pero disfrazada de ágil

Son tiempos adversos para la agilidad. Aunque las metodologías pesadas han sido destruidas, los viejos metodólogos tradicionales han vuelto y han hecho salir a las fuerzas ágiles de sus bases ocultas y los persiguen a través de la galaxia.
En el mundo ágil reina la inquietud. Varios miles de empresas han declarado su intención de abandonar la agilidad en su estado más puro. Este movimiento separatista, liderado por los misteriosos SEMAT o SAFe ha provocado que al “limitado” número de caballeros ágiles les resulte difícil mantener la paz y el orden en la galaxia.
—
Casi que da para hacer un corto. Si alguien con dotes cinematográficas se anima, que cuente conmigo.
La historia de la ingeniería del software siempre ha evolucionado desde dos bandos, uno proponía una cosa y otro la rebatía, un grupo de gente popular pasaba a la historia, mientras que otro se hacia famoso. Una vez terminada cada batalla, la ingeniería del software evoluciona tomando lo mejor de cada postura. Tampoco es que este comportamiento sea nuevo, ya lo contaba Kuhn en The Structure of Scientific Revolutions, que así evolucionaba la ciencia.
Hace muchos años, algunas épicas batallas fueron las de la programación estructurada y sus detractores, la orientación a objetos y sus detractores, las BBDD relacionales y sus detractores, UML y sus detractores, etc. La última… la agilidad y las metodologías predecesoras.
Aunque hoy en día la adopción de la agilidad ha sido tan amplia que ya casi nadie se acuerda de los detractores o, más que detractores, aquellos los que proponían otras ideas. Y ya apenas hay batalla.
Cada generación de propuestas metodológicas ha tenido su grupo de personajes populares que las llevaron a la fama. El grupo popular relacionado con la agilidad, hoy es bien conocido, formado principalmente por los firmantes del manifiesto ágil. Pero hubo un grupo de metodólogos previo, hoy casi olvidado.
Un grupo previo que popularizó las hoy llamadas metodologías pesadas. Los Rumbaugh, Jacobson y Booch, con su lenguaje UML y la metodología asociada, el RUP. Los que formaron la popular Rational. Etc.
Algunos de los anteriores, y otros que trabajaron con ellos, ha vuelto. Después de años de silencio, han aparecido con nuevas metodologías que combinan la agilidad con lo tradicional. Entre los retornos más populares está en SEMAT (de Jacobson) y SAFe.
Y claro, las durás, muy durás, críticas por arte de los ágiles, ahora en el poder, no se han hecho esperar, deidcandole, por ejemplo, a SAFe cariñosos textos del tipo The Horror Of The Scaled Agile Framework, unSAFe at any speed o Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

SAFe, la última metodología remake, producto de la anterior generación de metodólogos

SAFe ha recibido bastantes críticas desde su aparición. Una de las opiniones más compartidas entre los detractores de SAFe, es que aunque se supone que este framework intenta escalar lo ágil a toda la organización, en realidad parece la implantación de un modelo en cascada introduciendo algo ágil, pero sin llegar a serlo del todo.
La principal crítica viene desde uno de los 12 principios del manifiesto ágil: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto”. Si en Scrum el Product Owner tenía una visión de negocio y trabajaba codo con codo con los desarrolladores, en SAFe los roles que realmente tienen una visión de negocio se encuentran en otro nivel, en el nivel de comercial y no están en contacto con los desarrolladores.
Otro aspecto criticado de SAFe es que los arquitectos y diseñadores UI/UX están separados del equipo de desarrollo, cuando en Scrum estos roles deben estar integrados en el propio equipo. En Scrum, los equipos son responsables del diseño del software que realizan, mientras que en SAFe las decisiones de diseño y arquitectura derivan del rol de arquitecto y como ya hemos dicho, no está integrado en el equipo.
Lo ágil anima a que un equipo sea auto organizado, pero con tantos roles separados en SAFe y sin contacto diario, se hace complicado la coordinación entre los equipos. Sin embargo SAFe, lo único que incluye de los principios ágiles, son los elementos más “fáciles” de cambiar en la empresa, como por ejemplo, que los testers estén en los equipos, trabajar en iteraciones o ser conscientes de que la arquitectura del sistema va a evolucionar. Por todo esto, este framework queda un poco lejos de ser la implementación ideal de lo ágil a nivel de gran empresa.
Referencias
–        “Scaled Agile Framework”
–        41 Things You Need to Know about the Scaled Agile Framework® (SAFe)
–        Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?
–        unSAFe at any speed
–        The Horror Of The Scaled Agile Framework