Tenga cuidado con SAFe (el marco ágil escalado para empresas), una encarnación impía de la oscuridad
… o tal vez no.
Si prefiere que SAFe hable por sí mismo, puede usar el enlace de arriba. Hay cientos de páginas de documentación, horas de videos, 15 cursos de capacitación diferentes y más. Si eso suena un poco exagerado, haré todo lo posible para brindar una explicación de cómo funciona SAFe a medida que avance en cada punto.
En el nivel más alto, llamado «Portafolio», SAFe defiende Financiación de «flujos de valor» indefinidos, que generalmente representan un producto, una línea de productos o un tipo de cliente. Sin embargo, la función Lean Portfolio Management (LPM) que controla la financiación (probablemente las mismas personas anteriormente responsables de los presupuestos de proyectos en cascada), tiene la autoridad exclusiva para aprobar qué Portfolio Epics (grandes iniciativas) se mueven en cada flujo. Las epopeyas no son explicaciones sobre un problema que debe resolverse. Son ideas preformadas sobre la mejor manera de resolver esos problemas.
De inmediato podemos ver signos de la mentalidad de la vieja escuela de ver a los equipos como una función de «entrega» en lugar de una función estratégica. los pensadores de nivel tienen ideas y los de bajo nivel ejecutan esas ideas. Se ignora la posibilidad de que los más cercanos al trabajo estén mejor equipados para tomar decisiones al respecto. Escapar de esta mentalidad equivocada es un objetivo central del pensamiento ágil que SAFe no logra realizar de forma remota.
Un problema similar vuelve a aparecer cuando miramos a un nivel un poco más bajo.
SAFe agrupa a los equipos de productos pequeños (a menudo equipos Scrum) en «Agile Release Trains ”: Grupos de equipos con una capa adicional de funciones de gestión que abarcan cada grupo en lo que se denomina el» nivel de programa «.
Por lo general, estas funciones impiden la autonomía de los equipos. Añaden gastos generales de proceso y comunicación desproporcionados con el valor que brindan.
Estos roles incluyen un Gerente de Producto (PM), un S stem Architect (SA), y un Release Train Engineer (RTE).
El SA y PM definen y dividen piezas de trabajo más grandes (a menudo heredadas del proceso de cartera anterior) y luego pasan las piezas al equipos.
Teóricamente, el propietario del producto y el equipo podrían priorizar otros trabajos más pequeños frente al trabajo que se les impone, pero estos esfuerzos tienen una visibilidad limitada y una aceptación desde arriba. Habrá una presión natural para tratar el trabajo que viene del punto más alto como el más importante, incluso si cada miembro del equipo cree que otros elementos serían más valiosos. Debido a esto, el rol del propietario del producto se reduce a escribir historias y verificar los criterios de aceptación, en lugar de ser el único punto de responsabilidad para el liderazgo del producto que era la intención original del cargo.
El arquitecto del sistema no está en condiciones de estar cerca de la obra de ingeniería real, por lo que el plan arquitectónico que transmiten puede desconectarse de la realidad de la obra. Este tipo de roles fueron un sello distintivo de los proyectos en cascada de gran diseño inicial y están bien conservados en SAFe.
Los ingenieros de Release Train definen el proceso y la cadencia consistentes entre equipos y manejan muchas tareas operativas. En última instancia, esto deja menos espacio para que los equipos individuales modifiquen, mejoren o experimenten con sus propias prácticas de cualquier manera que se desvíe de los estándares establecidos.
A veces, todos estos problemas se repiten nuevamente con la adición de un «Large Nivel de solución ”: grupos de grupos de equipos con roles análogos a los del nivel de programa, pero que abarcan trenes de lanzamiento. Cuando esto ocurre, es probable que se repitan los mismos problemas, pero el Nivel de solución parece establecerse con menos frecuencia.
SAFe (a menudo) viene incluido con Rally – LIMITANDO ADEMÁS la autonomía del equipo
SAFe es a menudo un paquete con el software de gestión de proyectos Rally. Rally es el tipo de software que esperaría una empresa que usa SAFe para hacer: está sobrecargada de funciones, desenfocada, confusa, inestable y, en consecuencia, difícil de aprender y usar.
La propuesta de valor de adoptar Rally para el liderazgo es que podrán ver informes que les dan una imagen simple y unificada de la El progreso y los problemas en toda la empresa.
Por supuesto, esto significa que todos en la empresa no solo deben usar Rally, sino que también deben usarlo de manera coherente. Nuevamente, esto solo se puede lograr mediante un dictado de arriba hacia abajo. El rally y la forma en que piensa sobre el trabajo se imponen a todos los equipos, independientemente de su preferencia, contexto o aceptación. Para que toda la información se acumule requiere una sobrecarga increíble en la estimación y el seguimiento, lo que ralentiza todo y puede ser extremadamente perjudicial para realizar el trabajo.
Además, los informes de nivel superior ni siquiera son particularmente útiles. Se centra en las cosas que Rally rastrea: métricas como el volumen de puntos de la historia entregados (literalmente inventados) o la cantidad de errores abordados (una medida terrible para la «calidad del producto»).Si la administración ignora estas estadísticas, los gastos generales que agreguen serán en vano. Si logran las métricas, las estadísticas se modificarán para que los equipos se vean bien y se queden solos. Las estimaciones se sobrecargarán, los pequeños trabajos se exagerarán y esto puede conducir fácilmente a una ruptura de la confianza.
SAFe adopta el peor enfoque posible para administrar las dependencias
A La dependencia es una instancia en la que un equipo debe esperar a que se haga algo en otro lugar antes de poder completar su propio trabajo. SAFe se estructura en torno a una actitud al revés de que las dependencias son un hecho inmutable de la vida que debe aceptarse y gestionarse. Incluso a veces se refiere a ellos como una ventaja estratégica. En realidad, cuando piensa en las dependencias como algo malo, que debe minimizarse en cada oportunidad, puede encontrar que esas oportunidades son abundantes y que aprovecharlas resulta principalmente en beneficios. Aquí hay algunas sugerencias que SAFe subestima o ignora por completo:
- Fomente una cultura de fuentes internas donde un equipo puede enviar el trabajo al código base de otro equipo sin tener que depender de ellos más allá aceptar la fusión
- Facilitar a los miembros del equipo el intercambio temporal o permanente de equipos cuando tenga sentido hacerlo
- Enfóquese en contratar, estructurar y capacitar equipos para manejar sus propias necesidades sin ayuda externa
La forma en que SAFe realmente elige administrar las dependencias es aumentando el enfoque en la planificación, el proceso, la jerarquía y la estandarización. Como era de esperar, esto da como resultado muchas reuniones que interfieren con la capacidad de realizar el trabajo. Impone este enfoque a través de un despliegue universal que afecta a toda la organización a la vez. No se tiene en cuenta qué áreas podrían haber sido autosuficientes sin la estructura onerosa adicional.
SAFe está excesivamente orientado a la planificación
Una característica central de SAFe es la idea de ~ 10 semanas Incrementos de programa (PI). Puede pensar en estos como grandes sprints que contienen todos sus sprints normales.
Cada PI comienza con un evento de planificación de PI que dura aproximadamente dos días. La planificación de PI también requiere actividades de planificación previa y posterior a nivel del Programa.
Definitivamente, es valioso que las personas se reúnan en persona para establecer relaciones, compartir información y orientarse en torno a las metas. Por otro lado, usar esa ventana de tiempo limitada para hacer planes de 10 semanas de historias de usuario específicas basadas en características predefinidas, y luego requerir compromiso con esos planes es mucho menos valioso.
Tan pronto como finalice la planificación de PI, los planes creados en función de la comprensión y numerosas suposiciones se volverán obsoletas tan pronto como se aprenda algo nuevo. Los equipos estarán continuamente divididos entre ceñirse al plan que han aprendido que no tiene sentido y reorientar las expectativas por razones que los que están por encima de ellos pueden no estar en condiciones de entender.
SAFe se orienta en torno al volumen, no valor
En todo este enfoque en las métricas de volumen, la estimación y el trabajo dinámico a través de la tubería, el concepto de lo que realmente es valioso o exitoso se pierde fácilmente. A menudo se asume que más trabajo enviado por la puerta debe ser «valioso», incluso si la experiencia del producto realmente está sufriendo y los usuarios no se benefician de las funciones adicionales.
SAFe es consciente de las críticas que no está enfocado en el valor y recientemente ha agregado «pensamiento de diseño», «enfoque en el cliente» y otros conceptos a su documentación para compensar. Hasta ahora no estoy convencido de que haga cambios significativos en su proceso que realmente hagan espacio para esas cosas y, en primer lugar, se esfuerza por comprenderlos.
Por ejemplo, la definición de SAFe de «clientes» deja la puerta abierta para definir a las partes interesadas del negocio o aquellos que financian las corrientes de valor como «clientes». es muy diferente de reorientar a todos (incluidos los que proporcionan los fondos) para que se centren en las necesidades de los usuarios finales que realmente utilizan el software, un elemento central del pensamiento de diseño.
SAFe es innecesariamente complejo
SAFe tiene una ventaja natural que protege es de la crítica; Es tan complicado que es difícil de comprender por completo. A pesar del tiempo adicional que he dedicado a investigar el marco, es probable que todavía me equivoque en algunas cosas o me pierda algunos puntos importantes. Sin embargo, la abundancia de complejidad es en sí misma una preocupación legítima. SAFe tiene tantas reuniones, puntos de control, valores y métodos que es básicamente imposible que todos estén en la misma página.
SAFe limita las retrospectivas y la mejora continua
Roles a nivel de programa y no puede asistir a todas las retrospectivas del equipo.Esto significa que las personas que realmente pueden cambiar muchas de las cosas que se están discutiendo no escucharán directamente las retrospectivas.
La forma en que SAFe intenta compensar esto no es suficiente.
Planificación de PI es el único momento en el que se garantiza que todos en un tren de liberación estarán juntos en persona. Lamentablemente, contiene una breve retrospectiva relacionada únicamente con el éxito del evento de planificación en sí.
SAFe incluye un evento «Inspeccionar y adaptar» hacia el final de cada PI, pero parece casi diseñado para omitirse. sobre lo difícil que es coordinar el RTE. Cuando se lleva a cabo, el evento se prepara revisando, por supuesto, las métricas de volumen del último PI. Además, solo se asignan 30 minutos del evento para una retrospectiva real en la que los problemas surgen y se acuerdan Si este tiempo se divide en partes iguales entre todos los miembros de un Tren de Liberación de 100 personas, cada participante tendrá aproximadamente 18 segundos cada ~ 10 semanas para plantear problemas en un contexto en el que realmente se puedan escuchar.
SAFe también tiene algunos otros elementos como «gráficos de evaluación» donde los equipos son encuestados de manera más amplia, pero estos se inclinan en gran medida a confirmar que se están siguiendo las prácticas SAFe, no si son efectivas o no.
SAFe degrada los conceptos que agrega
Una clave parte de SAFe que aún no he mencionado es la agregación de conceptos existentes como Scrum, Kanban, Lean Product, Lean UX y DevOPs.
Si no está familiarizado, le sugiero que explore cada concepto independientemente a lo largo del tiempo en lugar de todos a la vez. Muchos son valiosos en sí mismos, pero SAFe no hace un gran trabajo al sintetizarlos y a veces puede agregar confusión. Caso en cuestión:
SAFe defiende habitualmente cómo sus prácticas siguen los principios «Lean-Agile». El truco es que «Lean-Agile» en realidad no se refiere a los principios «Lean» o «Agile».
En cambio, los «Principios Lean-Agile» son una creación del propio diseño de SAFe. Este nuevo conjunto de «principios» deforma los conceptos que asimila. Por ejemplo, la página sobre la descentralización de decisiones (clasificada como la más baja de todos los principios) se subvierte sutilmente al enfatizar la importancia de centralizar la toma de decisiones para muchos casos de uso. Otros principios enumerados tienen problemas similares. Para una persona a la que se le presenta toda esta información a la vez, el significado real de los conceptos originales puede perderse.
SAFe no es ágil
A estas alturas, muchas de las formas en que SAFe es inconsistente con una mentalidad ágil debería ser bastante claro. Está centrado en el plan, es burocrático, complicado, incluye muchos procesos a menudo innecesarios, desautoriza la autonomía del equipo y más.
Pero, ¿importa si SAFe es Agile o no cuando lo que realmente nos importa es la eficacia? ?
Sí. Lo hace.
Los principios ágiles son solo principios ágiles porque generalmente fueron reconocidos y acordados como efectivos. Ese pensamiento resonó en una comunidad más amplia de practicantes, razón por la cual el movimiento despegó originalmente. Si cree que la agilidad es un predictor de la eficacia (una creencia presumiblemente detrás del interés en SAFe), entonces importa bastante si SAFe es coherente con el pensamiento ágil. Engañar a las personas acerca de lo que están comprando es algo malo y no es incorrecto mencionarlo.
¿Qué pasa con todos los estudios de casos en los que se ha demostrado que SAFe ha funcionado?
Hay alrededor de 40 estudios de casos sobre la adopción exitosa de SAFe en scaledagileframework.com. Los estudios de caso de fallas están notablemente ausentes. Contrariamente al acrónimo, SAFe implica cambios simultáneos en un nuevo proceso enorme en un ecosistema enorme: un riesgo enorme. A menos que cada una de esas 40 empresas exitosas tuviera 11 250 profesionales certificados en SAFe, hay bastantes empresas de las que no tenemos noticias.
Además, no pongo demasiada importancia en los estudios de caso que sí lo hacen. existe. Incluso si las métricas de volumen en las que se enfocan fueran realmente valiosas, es fácil elegir algunas estadísticas que hacen que parezca que las cosas salieron bien.
Para enfocarnos en un ejemplo específico, echemos un vistazo a un extracto del caso de estudio sobre la implementación de SAFe en Fitbit:
En 2016, la empresa de tecnología de consumo, Fitbit, lanzó cuatro nuevos productos al mercado que fueron recibidos positivamente por consumidores y envió más de 22 millones de dispositivos. La entrega de la mayor cantidad de productos en un año se debe en parte al compromiso de la compañía y al éxito en la adopción de SAFe® (Scaled Agile Framework®) como una forma de escalar el equipo para cumplir con las fechas objetivo.
© Scaled Agile, Inc.
Aquí está el precio de las acciones de Fitbit durante los últimos cinco años:
Sí … 2016 parece un gran año para Fitbit.
Ahora, no podemos atribuir la caída de Fitbit a SAFe adopción con la cantidad de información que tenemos.Pero si una empresa puede luchar tanto y aun así aclamar que la adopción de SAFe mejora la capacidad de respuesta de sus decisiones de productos, estrecharé los ojos un poco más cuando revise el resto de los estudios de caso.
Sin embargo, está bien como paso de transición, ¿verdad?
Si usted es alguien que haría este argumento, entonces debe pensar que SAFe necesita ser eliminado. ¡En este punto estamos de acuerdo!
Para hacer esa transición, por supuesto, tendremos que dedicar un tiempo a señalar las partes que no funcionan bien.
¿Es eso algo que ¿Ha estado pasando mucho tiempo en?
Incluso si lo está, SAFe está configurado de una manera que le impide realizar la transición. La autoridad que pone en manos de la dirección actúa como una legitimación de la mentalidad de control de arriba hacia abajo. Esto combina mal con los métodos que faltan para la mejora de procesos que ya hemos cubierto. La autoridad para «personalizar» SAFe en el contexto apropiado no está disponible en su mayoría para los equipos reales mejor posicionados para reconocer lo que no está funcionando.
En ninguna parte de la hoja de ruta de SAFe se refiere realmente a ninguno de sus prácticas básicas como de transición. Si se trata de un marco de transición, entonces no proporciona ningún tipo de plan de transición.
El enfoque excesivo en las certificaciones también perjudica la flexibilidad del marco . Si pasa horas y horas trabajando para obtener la certificación, la certificación se convierte en parte de su propio valor. Una transición a algo que se parezca menos a SAFe puede parecer que amenaza ese valor. No puedo culpar a nadie por obtener la certificación en un mercado de trabajo donde las certificaciones importan. Pero esas personas tienen la responsabilidad particular de prestar atención a las desventajas de SAFe y las posibles formas de mejorarlo o desviarse de él.
Estos problemas tienen una amplia experiencia
No estoy solo en expresando muchas de estas críticas, aunque espero haber ido un poco más lejos al conectarlas con las prácticas específicas en el marco. Si está buscando testimonios que corroboren, aquí hay algunos:
Ken Schwaber, co-desarrollador de Scrum, expresó serias preocupaciones sobre SAFe ya en 2013.
Nicholas M. Chaillan , Director de software de la Fuerza Aérea de EE. UU., Desaconseja «utilizar marcos rígidos y prescriptivos como Scaled Agile Framework (SAFe)».
El colaborador de Forbes, Steve Denning, señala a SAFe por ser «particularmente preocupante» en su artículo sobre cómo detectar ágiles falsos.
Marty Cagan del Grupo de Productos de Silicon Valley explica cómo SAFe es la antítesis de la mentalidad de las empresas de Silicon Valley.
Manténgase a salvo (no SAFe)
Si bien SAFe ciertamente ha recibido una gran cantidad de críticas , mi sensación personal es que esta crítica puede no haber llegado a una gran audiencia más allá de ciertos círculos en línea. Esto es especialmente probable cuando se considera junto con el número cada vez mayor de empresas que adoptan el marco todos los días.
Para muchas personas, la idea de que SAFe tiene algún problema, o que entra en conflicto con los principios ágiles, puede ser completamente novedoso.
Una mayor discusión dirigida a una audiencia más amplia probablemente pueda ayudar. Espero tocar más este tema en el futuro y detallar qué otras alternativas existen.
Por ahora, incluso si no está trabajando en un entorno SAFe, esa no es una excusa para volverse complaciente . Las inquietudes que he presentado aquí deben tomarse como una advertencia más amplia: incluso las ideas más sensatas pueden ser fácilmente aceptadas, corrompidas y confundidas si no prestas mucha atención.