Los 5 Me gusta y los 5 No me

Gusta de SAFe: Pensamientos desde

la trinchera
OCTUBRE 13, 2014 / JOHNNY ORDEZ

Desde hace un poco ms de 3 meses soy parte de una jornada de

transformacin gil en una gran compaa de desarrollo de software en
Ecuador. El proceso involucra a ms 300 personas en 3 pases y a todas las
reas de la compaa. Representa precisamente un proceso de
transformacin que toca el ADN mismo de la compaa en muchos sentidos
(estructura, procesos, tecnologa, diseo del software, cultura). Cuando me
incorpor a apoyar, el proceso ya tena unos 3 meses de haber iniciado. El
consultor que lo lideraba us el marco SAFe (Scaled Agile Framework) como
la gua metodolgica y de procesos a seguir. Haba ledo acerca de SAFe -
cuando todava no se llamaba as- hace un par de aos atrs; el libro es muy
grande, a veces me dola la cabeza leerlo y por algn motivo lo dej. Ahora,
era el momento de retomarlo y empaparme profundamente sobre el tema.

Qu es SAFe?
Antes que seguir, quisiera dar una breve introduccin acerca de SAFe, ya que
es bastante nuevo sobretodo en el entorno ecuatoriano.

Scaled Agile Framework es un marco de trabajo que busca escalar los

beneficios y principios de Agile y Lean hacia todos los niveles de una
organizacin: equipos, programas y portafolio; a travs de prcticas, roles y
herramientas aplicadas para obtener entregas frecuentes de software de
valor y calidad, maximizando el beneficio al negocio y permitiendo mayor
agilidad organizacional. Es la promesa ms grande y el propsito de SAFe.

Como yo soy muy visual, me gust este video de Inbar Oren -uno de los SAFe
Program Consultants estrellas, SAFe Coach y creador de videos oficiales del
framework- que explica SAFe en 9 minutos y con dibujitos.
Para ms informacin sobre SAFe, les dejo los siguientes artculos:
SAFe
SAFe Purpose
SAFe Foundations
41 Things You Need to Know about the SAFe

Los 5 Me gusta de SAFe

No tena mucha certeza de por dnde comenzar a describir mis puntos: los
que me parecen buenos primero o los no tanto; pero normalmente cuando
doy feedback hacia alguna persona siempre comienzo resaltando sus
aciertos y luego le describo los puntos de mejora; entonces hago lo mismo
con SAFe. Siendo as, las cosas que me gustan son:

El Agile Release Train

Posiblemente una de las propuestas ms interesantes de SAFe desde mi
punto de vista. El Agile Release Train o ART es un mecanismo a nivel de
programa para la entrega de valor en una cadencia definida y constante de
un incremento de sistema. El trmino surge de la analoga de las salidas de
los trenes de una estacin, las mismas que se definen en rangos uniformes
de tiempo y de constante consecucin. Cada ART produce un incremento de
sistema; donde se integran todas las historias o funcionalidad de todos los
equipos que se terminaron y aceptaron por los Product Owners en una
iteracin. La cadencia definida es de dos semanas, de tal forma que hay una
integracin de un Big Working Software y una revisin con los
stakeholders denominada System Demo.

Algo muy interesante de SAFe, es que la definicin de la salida al mercado de

un nmero acumulado de features que corresponde a un tren especfico es
una decisin de negocio, algo que se denomina Desarrollo en Cadencia.
Entrega en Demanda. Esto habilita a la toma de decisiones por varios roles
(Product Managers, Marketing, etc.) basados en costos de oportunidad, time-
to-market adecuado, madurez o estabilidad de la versin, etc. Tiene todo el
sentido del mundo para m. En empresas como Spotify lo manejan de forma
similar.

Ms informacin:
Agile Release Train SAFe
Release-SAFe
Develop on cadence. Release on Demand SAFe
SAFe Kanban
Mucho Lean Thinking y Kanban en varios niveles
SAFe posee tambin una base filosfica fundamentada en el pensamiento
Lean. He ledo y escuchado a algunas personas sobre la casita de SAFe, la
casita Lean, y esta casita es la siguiente:
Bsicamente es la misma casa tomada del Toyota Production System. Okay,
yo comprendo los pilares y el sentido del pensamiento Lean, lo que quera
saber es cmo se expresa el mindset Lean y Kanban dentro de SAFe. A nivel
de portafolio se aplica el pensamiento Kanban restringiendo el WIP basado
en presupuesto, el mismo que es repartido entre varias cadenas de valor
o value streams. Es decir, slo se pueden trabajar en iniciativas que
podamos pagar, hasta donde nos de el presupuesto?. En la prctica, esto
se expresa en el manejo de las picas de negocio y arquitectura a travs de
un flujo Kanban; las picas deben pasar por un funnel donde
reciben aprobacin por los miembros del Portafolio. Los dueos de la pica
deben preparar y vender su pica justificando los beneficios para el
negocio y para la compaa. Bsicamente, de la misma forma en la que un
emprendedor explica y vende su idea ante un grupo de inversionistas (o
ante un estanque de tiburones, para el caso la analoga sirve).
A nivel de Programa, se aplica Kanban restringiendo al trabajo en base a la
capacidad organizacional, traducida por la capacidad de los equipos con los
que cuenta la compaa. Esto se traduce a: cuntas features podemos
hacer con la capacidad que tenemos?. Este mindset se expresa en el
Release plan y el Roadmap de producto; cuando las lneas de potenciales
releases son fijadas por la capacidad (con la cadencia de los ARTs es posible
contar con fechas definidas y fijas) y en cada Release Planning se
van ajustando para replanificar, repriorizar y ajustar nuestras entregas bajo
criterios de negocio. Esto ya vena sucediendo en el entorno gil; as que
hace mucho sentido para m y es un aspecto que se mantiene y me gusta.
En general, en todo SAFe siempre se habla acerca de contar con una vista
econmica, un trmino que viene de los principios del Desarrollo del Flujo
de Productos, especficamente del libro de Don Reinersten, The Principles of
the Product Development Flow; de donde SAFe ha tomado muchos
conceptos de gestin de flujos aplicados al nivel de programa (algo que no
me sorprende debido a que Don Reinersten hizo un foreword en el libro del
cual naci SAFe). Tener una vista econmica significa que debemos tomar en
cuenta el costo de la demora de no sacar un producto o caracterstica al
mercado en cierto momento. La idea es, donde el costo sea ms alto, eso se
debe entregar primero. Para aquello se usa una frmula
denominada WSJF que permite priorizar picas y features. En el entorno gil
ya venamos usando algo similar de lo que denominamos el ROI de Agile:
Business Value / Story Points. WSFJ es casi lo mismo, pero agrega otras
variables en el numerador que brinda otras perspectivas al anlisis. Lo
bueno de esto, es que se discute otros aspectos vlidos para el marketing, el
cliente y operaciones; lo malo es que lleva ms tiempo estimar y priorizar las
picas/features (ms nivel de discusin, ms Planning Poker, etc.).

Ms informacin:
SAFe Way to Lean Software Development
SAFe Kanban
Business Epic Kanban
WSJF
Lean / Agile Leaders
Uno de mis likes favoritos. En la ltima versin de SAFe (la 3.0) se hace
relevancia al rol de champions que abracen al Manifiesto gil y los
principios Lean para apoyar al proceso de adopcin y tener una jornada lo
ms satisfactoria. Estos lderes son clave en el entendimiento y aplicacin de
los principios y prcticas. En SAFe tienen su propio manifiesto con cuatro
principios fundamentales:
Tener una vista sistmica: de todas las partes de la organizacin, el
proceso y del flujo de desarrollo del producto;
Abrazar el Manifiesto gil: soportar los valores y principios giles;
Implementar/Optimizar el Flujo de Desarrollo de
Productos: visualizar el trabajo, limitar el WIP, identificar cuellos de
botella, ayudar a la mejora continua;
Desbloquear la motivacin intrnseca de los trabajadores del
conocimiento: ayudar a crear el ambiente y las condiciones para
contar con personas autnticamente motivadas y fomentar el
conocimiento.
Este ltimo tiene una relevancia sper alta para mi forma de ver, es vital.
Este es un plus en SAFe, me gusta mucho que se haya dado esta importancia
a este grupo; algo que los agilistas ya conocamos.

Ms informacin:
Lean-Agile Leaders
SAFe es evolutivo
SAFe no naci tal como lo vemos ahora en su Big Picture, ha tenido varias
versiones, la actual es la 3.0. SAFe ha venido de un proceso de adaptacin y
evolucin desde los primeros blog posts de Dean Liffingwell hasta
consolidarse en la figura que vemos. Gracias al feedback de varios
consultores, las empresas que adoptan SAFe y la comunidad, el framework
se ha ido adaptando y ajustando; agregando o eliminando elementos sobre
la marcha. Pude hacer un tracking de la vida de SAFe en el tiempo y
encontr versiones desde el 2008. La primera vez que lo vi no se llamaba
SAFe y fue por la versin 2.0 all por el 2011.

Ms informacin:
What is this SAFe
El Big Picture
Otro gran plus de SAFe es su Big Picture; puedes ver SAFe en una hoja.
Aceptmoslo, es de mucha ayuda. Adems de que visualmente es agradable,
el Big Picture es como una base de conocimiento interactiva en lnea que
permite navegar rpidamente sobre los conceptos y profundizar sobre algn
tema. Creo que visito este sitio unas cinco veces al da cuando necesito
reforzar alguna cosa o encontrar algo que se me escapa. Este Big Picture,
junto con los otros recursos: presentaciones, videos, posters, referencias,
frases, cursos; son elementos de marketing claves que posiblemente le han
dado gran visibilidad a SAFe en los ltimos aos. Representan una estrategia
inteligente de difusin y ventas.

Una de las razones por las que dej de leer el libro, es que puedo encontrar
el contenido ms rpido y la informacin est actualizada
(el libro bsicamente describe la versin 2.0 y algo de la 2.5).
Yo imprim el Big Picture y me sirve mucho para el anlisis de los puntos de
mejora el contexto de la adopcin, me ayuda a identificar problemas y
priorizar, como dije; soy muy visual.
Los 5 No me gusta de SAFe
Pues ahora, permtanme enumerar los aspectos que me generan mucho
ruido y que desde la prctica veo que necesitan atencin si se est pensando
en la adopcin de Agile con este framework.

1 da = 1 story point? Qu?

Cuando escuch por primera vez al consultor que deca esto yo dije en voz
alta en medio de una reunin: Qu? y todo mundo en el saln me qued
mirando raro. Esto para los agislistas es cercano a la aberracin. Estamos
usando una medida de complejidad para medir tiempo? Es como usar
kilogramos para medir distancia. Es impensable, ya que sabemos que no hay
una relacin directa entre los story points (unidades para evaluar
complejidad) y el tiempo. Es decir, 5 story points pueden ser hechos en ms
o menos tiempo en funcin de capacidad del equipo: su destreza,
conocimientos, experiencia, etc. No hace sentido para m, as que me puse a
leer mucho sobre el tema.
En SAFe existe la necesidad de normalizacin. Normalizar significa contar
con una medida estndar para poder realizar predicciones a nivel de
programa y portafolio. Bsicamente, SAFe prescribe usar esta relacin de 1
da = 1 story point; si tenemos un equipo de 5 personas trabajando 8 das de
un sprint de dos semanas (se resta dos das: 1 Sprint Planning y otro para
Sprint Demo y Restrospectiva) tenemos que un equipo cumple 40 puntos
por sprint (5 personas x 8 das => velocidad de 40 puntos por sprint). Para
lograr eso, se le pide al equipo que imagine una tarea que pueda hacer en un
da y a esa se le pone 1 punto (ms o menos como los das ideales).
En la prctica, no funciona. Cuando Usted le pregunta al equipo que estime la
historia, en sus mentes no estn pensando en complejidad, sino automtica
existe una conversin a horas que luego traducen a puntos. Por ejemplo: Yo
me tardo haciendo esta tarea 16 horas, si 8 horas es un punto, entonces
esta historia es 2 puntos; y peor, como se est pensando en tiempo y no en
complejidad se aaden colchones o buffers para evitar equivocarse en la
estimacin: Yo me tardo haciendo esta tarea 16 horas, pero por si acaso
digamos 3 das. Si 8 horas es un punto, entonces esta historia es
3 puntos. He visto este razonamiento en muchos equipos. Cuando se est
comenzando con Agile es contraproducente, ya que brinda una manera
sencilla de expresar el mindset tradicional pero con lenguaje gil; haciendo
que no ocurra un verdadero cambio. A la final, le est preguntando lo mismo
que antes cunto te tardas en esto?cuando el cambio es qu tan
complejo (complejidad inherente, accidental y tamao) consideras
esto?.
A nivel de programa tambin hay problemas. Con un estndar de 40 puntos,
es relativamente sencillo hacer proyecciones y planificar features. Los
clculos son expresados en frmulas con esta base, por ejemplo: si tengo
1000 puntos y 2 equipos que me dan 80 puntos por sprint, entonces los
estar completando en aproximadamente 13 sprints, y otras frmulas
derivadas. Las fmulas no estn mal, lo que est mal es considerar la
premisa de que cada equipo produce 40 puntos. Es como decir que todos los
equipos piensan igual, actan igual, que son relojes perfectos que entregan
siempre lo mismo sin considerar aspectos como el aprendizaje sobre la
nueva tecnologa, si hay personas nuevas en el equipo, si alguien sale de
vacaciones, etc.
Sigo leyendo sobre el tema, pero an no hace sentido para m. Cuando se
escala Agile es verdad que se necesita normalizar para ayudar al nivel de
programa, rea de ventas, etc.; pero en mi experiencia previa de adopciones
Agile lo que hemos hecho es normalizar el concepto de complejidad a travs
de un backlog de referencia. Bsicamente, creas un backlog con muchas
historias tipo que representan varias labores que se generan dentro del
contexto de la organizacin, las estimas con Planning Poker donde se
involucran muchos roles (arquitectos, miembros de los equipos, DevOps,
Testers, etc.). Con eso, los equipos tienen un punto de referencia para iniciar
su estimacin, toman la historia de 1 punto del backlog de referencia y
contra ese comparan su backlog para ese sprint. Las estimaciones son
ajustables cada cierto periodo. Las proyecciones a nivel de programa se
realizan tomando en cuenta la velocidad histrica y se eligen escenarios:
optimista, esperado, pesimista.

Ms informacin:
Iteration Planning
Normalized Story Points
From the Vision to the working software and back
Iteracin de Hardening
La iteracin de Hardening es aquella que ocurre despus de una iteracin de
desarrollo en la que integra y se prueba el desarrollo de todos los equipos
con el fin de lograr un incremento del Sistema. Est a cargo de un nuevo
equipo en SAFe llamado System Team. El producto de la etapa de
hardening es un incremento de sistema que se presentar en la System
Demo. Esta funcin era parte de lo que SAFe denominaba la iteracin HIP:
Hardening, Innovating and Planning; una iteracin especial que habilita a
los equipos a estabilizar su software y brinda tiempo para organizar
hackathons u otras actividades para innovar. Desde la versin 3.0, se separ
el concepto de Hardening y ahora SAFe provee una iteracin
especial IP:Innovating and Planning luego de varios sprints de desarrollo
(normalmente despus de 4 sprints) para habilitar la innovacin en la
organizacin.
En la etapa de Hardening, el equipo de System Team baja el cdigo de todos
los equipos en un ambiente separado, integra, genera un instalador de ser el
caso y somete al software a pruebas end-to-end (carga, estrs, exploracin,
algunas UATs). Cuando hay problemas, se reportan bugs que se pasan a los
equipos para que los resuelvan. Si el incremento pasa bien las pruebas y es
aprobado por los Product Managers, se pasa este incremento a la etapa de
Sustaining, entindase colocar en un ambiente de pre-produccin o
produccin en el Cliente. De esta forma, SAFe provee una secuencialidad de
fases como esta (Planning, Development, Hardening y Sustaining):

Esperen un minuto, esto es parecido a Waterfall no? son pequeas

cascaditas? Lo que se aprecia es que la etapa de Hardening es muy similar a
la etapa de Verificacin y la de Sustaining es muy parecida a la fase
de Despliegue. Esto indica para mi un olor en el proceso, y un olor no tan
agradable. La etapa de Hardening tiene buenas intenciones, estabilizar el
software antes de colocar en el ambiente del Cliente. Pero en la prctica,
tener un sprint de Hardening hace que se difieran acciones de calidad e
integracin a una etapa posterior, produciendo acumulacin de bugs,
dificultades en la integracin, desafos en el control de versiones, loops
grandes de asignacin y correccin de bugs y otros malestares que existen
en un desarrollo de cscada; recordemos. Hace que los equipos
piensen: hay una etapa de deteccin de bugs ms adelante, as que ellos
detectarn problemas.. Adicionalmente se refuerza el equipo de System
Team con ms Testers o personas de operaciones, volviendo al paradigma
del desarrollo tradicional. Aspectos de hardening deben ser abordados
dentro del mismo sprint de desarrollo y son responsabilidad del equipo. En
cada sprint el equipo debe definir, desarrollar, probar, integrar y desplegar
su cdigo. El sprint de hardening tiende a ser usado en ambiente donde no
existe automatizacin de pruebas o de integracin continua como un nivel
de contencin. Esto hace que esta fase sea para detectar bugs y no para
prevenir bugs, algo que va en contra del Agile Testing.
Mas informacin:
Hardening, Innovation and Planning
SAFe Hardening Iteration
Mixing Agile and Waterfall Development SAFE
PSI Release
Hardening Sprints
Innovation Planning
A new hipper Big Picture
Agile process smell: Hardening sprint
Retrospectivas en Excel? En serio?
Una de las cosas que me gener una gran incgnita en la cabeza fue el tema
de la ejecucin de las retrospectivas a nivel de equipo. Particip en una
retrospectiva y dentro de mi mente deca: qu est pasando aqu?. Para
realizar una retrospectiva a nivel de equipo (porque tambin hay una
retrospectiva a nivel de programa) SAFe provee un artefacto que permite
evaluar la salud del equipo y del sprint (SAFe ScrumXP Team Self-
Assessment). Consiste en una hoja de clculo con varias preguntas
agrupadas en diferentes secciones. El voto se hace en una escala de 0 a 5
(donde cero es No cumple Nunca y 5 significa Cumple siempre), el Scrum
Master lee una pregunta, recopila los votos de los miembros del equipo, saca
el promedio, redondea y coloca el valor resultante en el excel. Al terminar
con todas las preguntas, el Scrum Master guarda el archivo
y automticamente se dibuja un radar, lo muestra al equipo y luego se enva
el archivo para su consolidacin a nivel de programa. Al final de esa reunin
todos salieron y yo me qued sentado durante varios minutos tratando de
entender lo que sucedi: en qu momento se habla sobre los problemas?
cundo el equipo se expresa? dnde estn los post-its? y los action items?.
La retrospectivas -a mi forma de pensar- posiblemente sean la piedra
angular del agilismo mismo. Parte importante de los valores y principios, el
corazn de la mejora continua, la expresin de Hansei y Kaizen. El excel me
pareci interesante, pero no debe ser el foco de la retrospectiva. Es el
momento en el cual el equipo habla, se expresa, se siente escuchado, se
discuten los problemas, se comparten risas, es un momento para reflexionar
y proponer en equipo, es vital y no estoy de acuerdo que este momento sea
opacado por un artefacto.

Ms informacin:
ART Metrics
Reuniones de estilo Cerebro Frito
Imaginen lo siguiente: ms de 50 personas en una sala de reuniones, en una
reunin de 8 horas seguidas, con mucho calor, escuchando o tratando de
escuchar a todo lo que se dice.Resultado: Cerebro frito. As sent mi cabeza
luego de un Release Planning de ocho horas seguidas, y lo peor es que slo
era el da 1; al da siguiente sera lo mismo. Me preguntaba: un Release
Planning de dos das, en serio?. SAFe provee una agenda de dos das para el
Release Planning, en ella asisten varios roles: Product Managers, Product
Owners, Release Managers, System Team, System Architects, los equipos,
DevOps, etc. Debido a que se estn planeando todas las features e historias
de todos programas para el trabajo de todos los equipos del siguiente sprint,
la duracin de esta reunin es larga y con agenda definida. Quizs tenga
sentido para la primera ocasin, pero an as la reunin ya es pesada. A esto
smenle que no haban radiadores de informacin; bsicamente todos lean
o veamos la herramienta digital mediante una proyeccin y se planificaba
en la PC. Igual, la Sprint Demo, es una reunin que agrupa a todos los
equipos al mismo tiempo para que todos muestren a los stakeholders (POs,
Product Managers, Epic Owners, Marketing) su avance del sprint. En ese
momento los POs aprobaban o rechazaban las historias y se pasaba al
siguiente equipo. Ocho horas seguidas con 150 personas en la misma sala.
Despus de las dos primeras horas yo ya estaba divagando.

Agile, Scrum y los dems mtodos giles en general sugieren una

comunicacin continua, clara, cara a cara. Reunirse para tener estas
conversaciones entre los miembros del equipo, con los stakeholders, con el
Cliente, etc.; es muy bueno, mucho feedback. Cuando hablamos de un equipo
gil y sus stakeholders, esto no es muy complicado, nos reunimos,
conversamos, planificamos y seguimos. Pero cuando hablamos de 20
equipos, ms de 100 Devs, 12 Scrum Masters, 12 POs, 5 PMs, 5 RMs, etc.; la
cosa se complica y mucho. Desde mi punto de vista esto est lejos de la
efectividad. Mucho tiempo de muchas personas todas sentadas viendo una
proyeccin durante ms de 8 horas, es algo que no clasifico como
comunicacin cara a cara. Esto no quiere decir que estoy en contra de las
reuniones, todo lo contrario. Pero la reuniones en Agile son facilitadas, con
artefactos visuales, muy ligeras pero bien enfocadas, con los interesados
correctos. La idea es dosificar; hacer las Sprint Demos con cada equipo y su
PO y crear otra reunin entre POs y PMs (algo parecido a Scrum de Scrum
pero de Producto), un Release Planning efectivo con un Visual Story Map y
los pocos interesados, reuniones de trabajo de los equipos de Producto y
otros para llevar el trabajo de Features e historias listas al planning, entre
otras. Despus de una discusin sobre el uso de post-its y elementos
visuales, creamos un Release Plan en la pared y la reunin de planificacin
se redujo a 4 horas.

Ms informacin:
Release Planning
Hace match con las jerarquas organizacionales
Uno de los aspectos de SAFe que posiblemente sea parte de su creciente
popularidad en la comunidad y empresas, es que su lenguaje y estructura
estn diseados para el mundo empresarial. Hablar a la gente de las
corporaciones y el management sobre portafolio y programas pero con un
enfoque Agile y Lean es apropiado, hablar el mismo lenguaje ayuda a la
comunicacin y el apoyo del management es necesario para una proceso de
adopcin o transformacin gil. Muchos coaches recomiendan manejar el
lenguaje apropiado para los niveles y grupos apropiados.

Lo malo de SAFe es que al ver su estructura rpidamente se presta

a interpretacin y se puede hacer una correlacin con las jerarquas y
posiciones existentes dentro de la compaa. Cmo se llama ahora al BA?
PM, y el PM es el jefe de los POs; el Release Manager o RTE es el jefe de los
Scrum Masters; a quin reporta el developer, al Development Manager? y
as por el estilo. Incluso la discusin llega a nivel de reas.
Las jerarquas existen en una organizacin y entre ms grandes son las
organizaciones, ms grandes y slidas las estructuras. Lo que me parece que
hay que manejar es la percepcin de que tal rol es jefe de otro rol o que
un rol es una posicin. Un rol pueden formarlo varias personas dentro de la
organizacin, o quizs no; cada organizacin es diferente. Este es uno de los
desafos al que nos enfrentamos los consultores y coaches y hay que tener
criterio para abordarlo.

Pensamientos finales
Un amigo agilista de Ecuador me pregunt hace poco tiempo: y esta vaina
de SAFe funciona o qu?. Es una pregunta algo capciosa y difcil de
responder de forma de S o No; similar a si se preguntara qu funciona:
Toyoya o Mazda? o una cuchara o un cuchillo?. SAFe es slo un framework,
una herramienta que provee un enfoque referencial sobre cmo llevar
prcticas del entorno gil hacia una organizacin. Mi respuesta es, depende
de cmo la uses. Yo soy muy crtico sobre SAFe, hay que cosas que me
generan mucho ruido (y que seguir publicando); pero en este proceso de
adopcin estamos tratando de tomar lo mejor, adaptar al contexto y
fomentar agilismo verdadero a travs de conceptos, principios y prcticas.
Gracias por su feedback. Un abrazo!