¿Porqué hay gente que dice que "odia" SAFe®?

Remove References To Scrum From SAFe!

Hay algo de revuelo últimamente en la comunidad Agile, algunos agilistas declaran con convencimiento en contra de SAFe®. Un ejemplo lo podemos encontrar en el artículo de Alex Kudinov "Extremists and the hate SAFe machine", y otro en la petición "Remove References To Scrum From SAFe!" para quitar los términos de Scrum de SAFe...

Pero ese no es el objeto de este post... como agilista y como coach ágil me preocupan las personas, aquellos que hacen el trabajo, los que forman los equipos ágiles. El Manifiesto Ágil empieza con "estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros", por tanto la Agilidad busca como mejorar las formas de trabajar, focalizándose sobre todo en personas sobre procesos.

Desde mi perspectiva y entendido esto, no importa tanto el proceso sino como este mejora la forma de trabajar y la vida de las personas. Lo que ha de preocuparnos es como las personas que hacen el trabajo y generan valor sufren implementaciones de SAFe disfuncionales, esos desarrolladores y programadores que en diversas situaciones me dicen que "odian" a SAFe. Les pregunto sobre el porqué y me cuentan sus historias completamente disfuncionales:

• Trenes de entre 300 y hasta de 600 personas con equipos de 15 y hasta 40 personas, trenes en cuyo diseño se ha ignorado absolutamente la dinámica de grupos y la sociología imposibilitando así una autoorganización adecuada.
• PI Plannings en las que se planifican las tareas de todas las personas a tres meses vista... una chica programadora me comentaba que es como hacer encaje de bolillos, el equipo crea tareas para cada miembro del equipo de manera que cuadren con la "pila del alcance fijo" y carguen a cada persona al 100% de trabajo... algo en lo que nadie cree y anula todo sentimiento de compromiso.
• Votaciones de confianza donde los managers recomiendan previamente no votar menos de 3... y si alguien vota un 2 el manager directo tiene una charla privada con la persona y a la vuelta la persona vota 3... con el resultado de que todo el tren vote 3. Otra historia cuenta que en una votación predominó el 2, los desarrolladores fueron a comer y a la vuelta los "Scrum Masters" dieron instrucciones a todos, se volvió a votar y el resultado fue 3 para arriba. La votación de confianza trata de averiguar si todos los participantes están convencidos de los planes que ellos mismos han elaborado en la PI Planning, deberían de ser 4 y 5.
• Retrospectivas en la que los managers están presentes y no emerge nada, por tanto se niega todo beneficio de la mejora continua.

Razones como estas son las que nos deben de preocupar y mover a los coaches ágiles.

En mis cursos de SAFe veo que los managers suelen tener una perspectiva muy distinta de la de los programadores, donde el manager ha adaptado SAFe y declara que va bien, los equipos hablan de verdaderas aberraciones. Hay una gran desconexion sobre todo entre mandos intermedios y equipos. A veces me pregunto ¿como empresas/managers que lidian dificultosamente con su producto en el mercado pretenden diseñar una metodología?

Una implementación correcta es responsabilidad tanto de estos managers como nuestra, los coaches ágiles. Como coaches ágiles debemos de concentrarnos en generar entornos motivantes en los que los managers lideren y apoyen a los equipos para que puedan construir adecuadamente y entregar valor de forma iterativa y sostenible... y para eso SAFe es un excelente punto de partida si aplicamos sus valores y principios.

Dean y Jeff, from Scruminc. blog

Me encanta la fotografía en la que se ve a Dean Leffingwell, el creador de SAFe, y a Jeff Sutherland juntos; creo que podemos aprender de esa foto. Esta se puede ver en un artículo de Jeff "Scaling Scrum – What People Are Not Talking About!" en el que habla como junto a Alex Brown presentaron una forma de pensar sobre el escalado que se podría aplicar a cualquier marco (o falta de él).

Lo podemos leer en su artículo "Scaling Scrum using Object Oriented Architecture" donde concluyen entre otras que: "Un marco empresarial universal debe permitir que la organización inspeccione y adapte gradualmente su propia estructura sin causar consecuencias en todo el sistema. La comunidad Agile necesita un marco de acoplamiento lento para escalar Scrum que pueda actuar como el "esqueleto" de funciones, conexiones, entradas y salidas a las que se puede conectar el "músculo" de diferentes prácticas exitosas".

Y para cerrar un poco de humor; FATE el marco de Michael Küsters para compañías condenadas. "FATE NO ES SAFe: FATE es una advertencia para cualquiera que piense que puede obtener beneficios al incorporar una nueva estructura en una organización existente sin aplicar habilidades de pensamiento crítico".

Fake Agile Transformactions for Enterprises,  thanks to Agilecartoons