SAFe o Scaled Agile Framework es uno de los principales marcos de trabajo ágiles que se están utilizando en la industria actual. Junto con Scrum, es ahora un estándar a adoptar, el cual también es buscado comúnmente tanto por clientes como por futuros empleados.
En las figuras anteriores, se observa como SAFe a nivel global, cada año sube más y más en popularidad en distintos tipos de industrias.
En Latinoamérica, insights for the future, presenta un estudio con datos similares, aunque la muestra es pequeña, comprueba que Scrum y SAFe están aquí para quedarse. La mayoría de las empresas en Latinoamérica, como BBVA, Elektra, entre otras de gobierno como SAT, quienes han implementado SAFe han observado un cambio importante en sus plataformas móviles y en línea. Han requerido de consultoría externa al igual que reorganización interna, siendo BBVA de las más exitosas.
Existen muchos mitos y mentiras de porque SAFe no es para mi empresa o porque sus principios y prácticas no funcionan. En latinoamérica y en el mundo, SAFe está ayudando a entregar alto valor de negocio a muchas empresas, al mismo tiempo, la competencia incrementa día a día. Sin embargo, no todas las implementaciones de SAFe son iguales, y de estas, la mayoría tiene desviaciones del marco de trabajo documentado en scaledagileframework.com. Entre distintas razones por la que una implementación puede llegar a ser fallida o no demostrar los resultados esperados, la causa mayor de estas, es la resistencia al cambio.
SAFe incluye un camino (roadmap) hacia la implementación, usualmente se requiere pasar por un curso de 4 días y pasar un examen de certificación para convertirse en SAFe Program Consultant, quien es el experto que ayuda a implementarlo en la empresa. Sin embargo, eso no significa que las empresas no puedan decidir comenzar a caminar hacia la transformación ágil por su cuenta. Siendo casi el mismo camino en otros marcos de trabajo, la inversión requerida para realizar esta transformación es grande, tanto en dinero como en tiempo. SAFe ofrece cursos de certificación usualmente de dos días, o día y medio, donde los estudiantes aprenden los principios del manifiesto ágil, Lean thinking, y valores de Scrum. En estos cursos, se require invertir tiempo y dinero para entender el cambio de mentalidad o mindset, al mismo tiempo que aplicando los conocimientos por medio de ejercicios prácticos tales como un Program Increment planning simulado.
Durante el curso Leading SAFe (material ya disponible en español), diseñado para ejecutivos y líderes, se podrán dar cuenta de los beneficios de aplicar este marco de trabajo dentro de su empresa inmediatamente. Sin embargo, la mayoría de las ocasiones se recomienda que este curso se personalice a la empresa o alumnos que asistirán. Algunos líderes descubren una epifanía al cursarlo durante sus dos días, otros deciden descartar los principios, no estar presentes y ocupados, y solo experimentar la simulación del PI planning. Cuando se personaliza los cursos de certificación de SAFe por medio de ejercicios relevantes a la empresa, backlogs actuales, y situaciones reales, el compromiso aumenta. El objetivo de Leading SAFe, así como otros cursos de SAFe, es motivar a los estudiantes a cambiar su forma de trabajo actual y llevar las prácticas a su área de trabajo al día siguiente. Algunos son más tediosos y complejos que otros, el más rápido y básico siendo SAFe for teams, diseñado hasta para 150 personas o para entrenar a todos en el tren ágil. Después del curso, en muchos casos, esto se traduce a realizar su primer Program Increment Planning real con todos los presentes.
Los beneficios de un PI Planning presencial con todos los equipos y stakeholders presentes durante uno o dos días completos, Big Room Planning, son inmediatos. Además de obtener un plan a largo plazo de alta confianza más el acuerdo por parte de stakeholders y business owners, es una especie de team building donde todos se comunican y conocen en urgencia.
Si bien el SAFe Implementation Roadmap menciona que Leading SAFe es uno de los cursos principales que actúa como un parteaguas para tomar la decisión de implementar o no, estas no son las unicas formas en que se puede decidir optar por SAFe. Los procesos en cascada tradicionales y en su mayoría inspirados y auditados por el Project Management Institute por medio de profesionales en project management ha sido la metodología principal en la que empresas, por ejemplo de IT, administran sus proyectos. Agile en general parece ser el enemigo número uno del PMI, sin embargo, no se necesita reñir. PMI ha estado buscando integrar agile en su método desde hace ya varios años, incluso lanzando su propio modelo híbrido ágil Disciplined Agile Delivery.
SAFe tiene distintas practicas, principios, y valores, que en su mayoría se adaptan a empresas que se impulsan principalmente por un proceso tradicional detallado y pesado para mostrar resultados. Usualmente, y con la ayuda de un consultor partner de SAFe, o un SAFe Program Consultant interno, se realiza una “traducción” del proceso actual al marco de trabajo ágil que se ha elegido. Debido a que SAFe escala sus iteraciones o sprints en Scrum, y le llama Program Increments de 8 semanas hasta 12 semanas, resulta más factible realizar releases o entregas más frecuentes, a diferencia que cada día con Kanban, o cada dos semanas como en Scrum. Claro, dependiendo de las tecnologías utilizadas, aveces será más fácil hacer entregas cada semana para plataformas en web, pero sería difícil hacer esto mismo con una plataforma de hardware para vehículos automotrices. Lo difícil será cambiar la mentalidad de proyectos y enfocarse en los productos, permitiendo así cadenas de valor producidas por equipos continuos y con larga vida. Esta adaptación puede llevar a los checklists usuales de un gate review a terminar en los distintos niveles de Definition of Done de manera incremental que SAFe recomienda.
Aquí es cuando las empresas derivan un proceso “híbrido” que no es SAFe o Ágil pero tampoco es cascada o waterfall completamente. Si esta forma híbrida se utiliza como un puente temporal hacía las entregas o releases frecuentes, de manera sustentable, por medio de retrospectivas y mejoras al proceso, siendo transparentes, ejecutando en cadencia, inspeccionando y adaptándose, entonces el manifiesto ágil está presente. En SAFe adicionalmente se busca desacoplar el proceso de entregas continuas y hacerlas a demanda por medio de su Continuous Delivery Pipeline.
Hoy en día es muy común llegar a una empresa que dice está aplicando Scrum, o SAFe, y se dicen ya ser Ágiles. Sin embargo la realidad es que están en un modelo híbrido y que sus roles ágiles tales como el Product Owner o Scrum Master en realidad siguen siendo project managers or business analysts. En SAFe, con sus roles escalados, es muy común observar como un project o program manager con experiencia termina siendo Release Train Engineer o Product Manager, y en varios casos, ambos roles recaen en la misma persona. Similar a los roles de Product Owner y Scrum Master que terminan siendo uno solo. Entre otros antipatrones como cuando el mindset en realidad no observa cambio alguno, esto sucede cuando los ejecutivos, sponsors, o business owners, deciden no involucrarse en esta transformación ágil y prefieren delegar sus responsabilidades y no invertir. En estas empresas también se dice que se castiga al mensajero, y se hace una práctica común el hacer micromanagement. Al igual, si no hay casi innovación debido a la falta de tiempo, o a los individuos se les premia más por la mentalidad de héroe en vez de trabajo en equipo, se podrá obervar como existe estancamiento. Las tareas principales del Scrum Master Product Owner será trabajar en Jira (herramienta para administración ágil) y asignar tareas o empujarlas en vez de permitir a los equipos elegirlas o jalarlas (Push vs Pull). Los líderes se excusan utilizando el dicho “hacer más con menos” (Do more with less), o como lo menciona los creadores de Scrum, “el arte de hacer doble de trabajo en la mitad del tiempo” (the art of doing twice the work in half the time). Por medio de micromanagement preguntan a los equipos porque no son más rápidos y que les está tomando tanto tiempo.
En muchas ocasiones, se invierte la mayoría del dinero y poco tiempo en los eventos de planeación, y no en la ejecución, donde las personas parecen motivadas pero existe poca confianza en sus planes. Esto se le llama el Agile Theather. Y hoy en día después de COVID, se invierte incluso cada vez menos en eventos de planeación de cara a cara ya que puede ser digitales cíen por cierto. También cada vez es más común exigir a los equipos quienes estaban trabajando remotamente con herramientas e infraestructura digital colaborativa de forma motivada, regresar a la oficina y olvidarse del incremento en productividad que el trabajo remoto había producido. Manteniendo el espíritu del manifiesto ágil, aunque las conversaciones de cara a cara son valiosas (y continúan siéndolo digitalmente), también lo son los individuos y equipos motivados.
En empresas donde se observa un cambio exitoso y motivacional, los líderes desde el nivel ejecutivo hasta los propios managers de los equipos, se involucran en la transformación entendiendo que hacen falta varios pasos para llegar a la Agilidad Empresarial, pero hacen su mejor esfuerzo para vivir los principios ágiles, de SAFe, y valores de Scrum. Invierten no solo en nuevos roles y herramientas, sino tambien invierten tiempo siendo partes de los eventos de planeacion tales como PI Planning y crean grupos de trabajo con distintos departamentos tales como Recursos Humanos, Marketing, Ventas, y Manufactura, en su esfuerzo para lograr esta Agilidad Empresarial. Confiando en los equipos y sus individuos. Si se invierte en un buen marco de trabajo de trayectoria profesional con management y recursos humanos para los nuevos roles ágiles, se comenzará a observar equipos más motivados que quieren crecer sus skills en agilidad, y ser parte de la tranformación, eventualmente ayudando a cambiar la cultura, y hasta el mindset de la empresa. Si se invierte en entrenamientos y certificaciones, para formar individuos tipo T o multifuncionales, así como en innovación y flexibilidad para los equipos, la motivación continuará creciendo. Si se evita la tiranía de lo urgente, y se decide realizar celebraciones y demostraciones del valor construido, se podrá ver crecer la motivación intrínseca de los trabajadores basados en conocimiento. Si se les dá la confianza suficiente a los equipos para tomar sus propias decisiones en cuanto al producto, y decentralizan las decisiones que tardan más, los equipos estarán en el camino a ser auto dirigidos y de alto rendimiento.
En conclusión, para comenzar con SAFe, en Latinoamérica o el resto del mundo, se necesita estar dispuesto a invertir tiempo y dinero en la transformación pero sobre todo en sus equipos, inclusive reorganizándolos alrededor del valor.
- Invertir tiempo en la implementación (2 días de entrenamiento, 2 de PI Planning, etc)
- Invertir dinero en roles ágiles, entrenamientos, herramientas, y desarrollo profesional.
Si el nivel de liderazgo está decidiendo adoptar SAFe (Top-Down Approach) debido a que otras empresas lo están haciendo y no quieren perderse el tren (Fear of missing out o FOMO), o en su experiencia observaron una tranformación algo exitosa y creen es traducible al negocio actual, es necesario primero convencer al nivel de los equipos. Para esto, es necesario los líderes apliquen el principio de Gemba, o ir directo hacia donde el trabajo se realiza, e indagar. La mayoría de las tranformaciones ágiles que se estancan o fallan (se decide revertir a un modelo en cascada), donde los equipos ágiles se encuentran desmotivados, usualmente es porque tienen un severo caso de falta de compromiso de parte de sus líderes en la agilidad. Algunas otra transformaciones exitosas invierten en sus roles agiles, incluido sus desarrolladores principalmente, para permitirles crecer, siendo flexibles, y permitirles la confianza de convertirse en equipos de alto rendimiento. Sin la inversion en los equipos y su crecimiento profesional en agilidad, el manifiesto ágil no está presente.
Otra forma de comenzar con SAFe tambien funciona cuando los equipos mismos deciden tranformarse y ser ágiles (Bottom-Up approach), y surge la necesidad de escalar la implementación. Es raro ver un tren ágil (ART) lanzarse solo sin participación de los ejecutivos o business owners, pero si se logra, se observa el beneficio inmediatamente y atrae la atención de los líderes. Después de aproximadamente año y medio a dos años, es cuando puede aparecer el estancamiento, lo dificil es no caer en el Agile Theater, mantener a los líderes comprometidos, mantener, crecer y mejorar la implementación de SAFe en toda la empresa.
Para más casos de uso reales se puede ver SAFe Customer Stories.
Leave a Reply