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
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola Javier,
me he reído con la intro tipo «star wars», parece que en el mundo del SW y de las metodologías hay tanto guerra como gente que se autoetiqueta como «jedis», «padawans» o «ninjas». 🙂
Ahora más en serio, quería comentar un par de cosas, no tanto por tu post específicamente sino también por lo que ves en las empresas y las «comunidades ágil / pesada».
La primera es que creo que hemos de superar el frontismo. En mi caso yo estudié UML y RUP en la universidad, trabajé en IBM Rational y soy certificado tanto PMP como PSM. La agilidad ha traído cosas muy buenas y me encanta, pero quienes sólo han conocido la agilidad (los más jóvenes) o los que reniegan de todo lo introducido anteriormente (atención, Scrum es del 95 y RUP del 96!) creo que se pierden conocimientos que añadidos a su «paleta» les permitirían abordar los proyectos medios y grandes con más garantías. Pienso que hay bastante desconocimiento general de RUP y de otras metodologías que hacen que, junto a su complejidad, no hayan sido bien introducidas en la mayoría de las organizaciones. Pero al final, tanto con RUP como con Scrum, lo que cuenta es la capacidad de la organización entera (no sólo los desarrolladores) para implementarla. De todas maneras, dejo aquí el debate «pesado vs ágil» que no es el objeto del post.
La segunda es la crítica en si a SAFe (y a Leffingwell). Los puntos negativos que recoges tienen sentido, sin duda, aunque me gustaría matizarlos. Si consideramos las necesidades de una organización grande (no de 5 o 6 equipos ágiles, sino más), las propuestas de Leffingwell pueden tener bastante sentido. El hecho de que el rol de los product managers estén a un nivel más alto de abstracción y que los product owners más a nivel de equipo no tiene que ser malo, ni contravenir lo que dice Scrum. Además, son un rol y no personas, por lo que no se dice que los product owners no puedan participar también a nivel de portfolio. Además, que los arquitectos o UX sean de equipos separados tampoco tiene porqué ser ningún pecado. En empresas suficientemente grandes, estos pueden tener una parte de su dedicación en un grupo de arquitectura y otra codo a codo con los equipos. Así pues, aunque entiendo las críticas no las comparto si se generalizan.
Como resumen, creo que hay que buscar respuestas sin apriorismos a los desafíos de las organizaciones que necesitan escalar «verticalmente» agile. La mayoría de las propuestas serán rechazadas por los «core agilists» (como diría Scott Ambler, co-creador de la Disciplined Agile Delivery), pero merece el interés investigar sobre eso.
¡Saludos!
Àlex Ballarin
pd: el SAFe viene de la literatura de Leffingwell como Scaling Sw Agility (2007) y Agile Sw Requirements (2011) que, aunque tengan partes discutibles, me parecen ambos libros excelentes.
Hola Javier y Álex
Muchas gracias a ambos, a Javier por sus publicaciones ya a Álex por un comentario que creo muy profesional y sobre todo respetuoso.
Soy de una generación que hoy creo se puede considerar sin remordimientos «prehistórica». Comencé a trabajar en el uso práctico con los enfoques estructurados allá por fines de los ´80. Les pido sean «piadosos» y no saquen cuentas. Ja Ja. Posiblemente por eso es que a mi edad ya considero que no se nada pero de algo hay que vivir… Confieso no ser un experto en métodos ágiles y pido disculpas si alguno de mis conceptos puedan reflejarlo. Solo intente como decían «sacar lo mejor de los diferentes enfoques»
A lo comentado quería agregar que me parece que uno de los problemas de fondo en esto a mi modo de ver es uno que se relaciona entre la gestión de la demanda (necesidades del negocio) que no siempre pueden ser atendidas en el contexto de un equipo ágil por mas que allí se encuentre un representante del negocio. El motivo suele ser la complejidad de la solución necesaria que puede abarcar mas de un aplicativo y posiblemente varios equipos de trabajo. Aquí es donde la visión de un arquitecto que pueda definir la solución y sus posibles componentes así como el posible enfoque para la construcción e integración de sus componentes junto a otros miembros como el negocio parece ser relevante.
Claramente esa solución puede ser susceptible de ser gestionada con un plan de proyecto que preserve la visibilidad sobre los trabajos que realiza cada equipo.
Los equipos recibirán cantidad de historias de usuario proveniente de distintos proyectos y lo manejarán con un enfoque ágil pero me parece que la dimensión de la solución y el proyecto que surgieron de las necesidades del negocio es una dimensión complementaria que requiere alguna solución conceptual en los métodos y que sea compatible con estos. Creo que esto es un aporte valioso en SAFe.
Serían muy valioso para mi sus comentarios y desde ya un saludo a ambos
En muchos puntos donde miro Safe siento que no está tan alejado por ejemplo del escalamiento que le quiere dar Nexus al armar el arquetipo para escalar scrum.
A mi lo que me incomoda de scrum (y es algo que peleo todo el tiempo en mi empresa) es que al avanzar a la agilidad no nos hacemos cargo de que no necesariamente vamos a tener equipos auto-organizados-gestionados-capaces de finalizar los sprint definidos. Entonces se genera una brecha para que(vuelvo al ejemplo de mi empresa) los grandes empiecen a ver agilidad más allá de un grupo de frikis que hacen las cosas más rápido y más simple que la gerencia de desarrollo, y lo anterior genera un clima donde avanzar con agilidad se vuelve cuesta arriba.
Saludos