A medida que se avanza en los procesos de transformación hacia Agile en organizaciones de cualquier tamaño o giro de negocio, se hace cada vez más evidente que precisamente el obstáculo más fuerte al que se enfrenta el equipo de transformación y el proceso como tal, no tiene que ver tanto con el entendimiento del método o framework seleccionado, y más bien este posee aproximaciones hacia índoles humana y sistémica; el tema es cultural. Ya lo decían las encuestas: la habilidad de cambiar la cultura organizacional es la barrera más grande en la Adopción Ágil.
«A nivel de iniciativa ágil, los encuestados citaron a la cultura organizacional o una resistencia general al cambio como las barreras más grandes hacia una adopción ágil, seguido de no contar con el conjunto de habilidades correctas.»
– 9th Annual State of Agile Survey, VersionOne
De aquí que el verdadero desafío consiste en trabajar en influenciar-más que «cambiar»- la cultura organizacional vigente del grupo (equipo, área u organización). Por lo tanto, los miembros del equipo de transformación son Agentes de Cambio inherentemente, y es necesario enfocar iniciativas para lograr figurar una nueva cultura donde la Agilidad florezca en múltiples niveles; una cultura de transparencia, confianza, colaboración y preocupación auténtica por las personas. Y esto por cierto, no es nada fácil.
Y entonces te pones a leer, a comprender y aprender cómo hacerlo. Y en este aprendizaje me he encontrado con un pensamiento compartido por algunos excelentes coaches y amigos que dice: Comportamientos = Cultura. Cambiar comportamientos = cambiar Cultura. Suena coherente en verdad, pero tras mi experiencia y profundizando sobre el asunto, comienzan a aparecer mis conflictos. No creo que esto sea tan simple ni que funcione de esta forma, y pretendo explicarlo a continuación.
El comportamiento es sólo el aspecto visible de la Cultura
En varios procesos de adopción en compañías donde he tenido la oportunidad de participar, comienzan aplicando las reglas del método o framework seleccionado para traer agilidad. Algunos me dicen: «Sí, somos ágiles…aplicamos Scrum y todas las ceremonias y roles». Entonces pienso, «Okay, veamos más de cerca.» Al principio cada persona del equipo comienza a ejecutar su rol muy proactivamente, se levantan, responden sus preguntas, una buena ejecución y cumplimiento del método; pero se siguen percibiendo rastros del esquema de pensamiento y actitudes anteriores; ciertas disfunciones y algunas muy sutiles de detectar: el reporte al jefe (que ahora es Scrum Master o Product Owner), personas algo tímidas en comentar los problemas, justificaciones por el no cumplimiento del trabajo, mediciones de desempeño ahora de la forma ágil (Velocity u horas) pero con el tinte tradicional, ejecución mecánica de las ceremonias o prácticas sin la verdadera comprensión del beneficio, entre otras «reglas no escritas».
Uno de los gráficos que uso con frecuencia para explicar qué entendemos como cultura es la siguiente pirámide basada en el enfoque de William Ouichi, -el mayor precursor de la Teoría Z-:
Es como un iceberg, lo único que vemos -los comportamientos- es sólo la punta; lo de abajo es más interesante. A pesar de la aparente buena ejecución del framework, los cimientos culturales anteriores se mantienen o se modificaron muy poco. Claro, quizás sólo sea el principio, pero no deja de ser una «agilidad cosmética», poco profunda. Sin embargo, si se aleja y observa el conjunto, podría apreciar un comportamiento homogéneo en función de lo establecido.
Pensando detenidamente, considere que el comportamiento del grupo -algunas de las disfunciones descritas arriba- son el reflejo de la verdadera cultura imperante; es como el aire alrededor; difícil de señalar pero saben que está allí. Significa que la cultura está lejos de cambiar con sólo la ejecución de prácticas o reglas.
El comportamiento es un resultado
Son nuestras creencias, nuestra formación, nuestros modelos mentales, nuestras experiencias, la sociedad…y en sí, nuestro mindset los que dibujan nuestro comportamiento, y no al revés. Pero no es lo único, dentro del contexto organizacional la forma en cómo se llevan las cosas dentro de la organización, la naturaleza de las tareas, los flujos de información, la estructura y procesos influencian la forma en la que actuamos.
Cambiar Cultura es trabajar sobre el mindset: Incepción u Origen
Estaba en una de las primeras reuniones con el staff ejecutivo de una compañía para inducción sobre Agile y el framework en específico que seleccionamos. Entre los asistentes, unos de los VPs, el más fuerte de carácter y quien veía con mayor escepticismo el tema de Agile. Todos habían leído al respecto, pero el taller era más que necesario para profundizar.
Queríamos explicar el concepto del Costo de la Demora (Cost of Delay) y realizamos uno de aquellos ejercicios lúdicos con todos los presentes en la mesa, ya saben…comenzamos simulando el flujo tradicional y luego lo enfocamos como flujo de valor y tomamos los tiempos, las variaciones y todo lo demás…y este Ejecutivo tuvo un momento ¡A Ha!, se detuvo a explicarlo porque creo que sentía las ganas de exteriorizarlo y dijo algo como: «es increíble la cantidad de desperdicio que estamos generando». Al siguiente día, reunió a su equipo de Managers y propuso cambios interesantes. Él comprendió que la forma con la que estaba acostumbrado a trabajar estaba lejos de ser eficiente y que su presión -en el buen sentido de sacar las cosas- estaba generando frustración en los equipos, y lo más importante; el impacto que esto tiene en la economía de la organización. Él cambió su comportamiento y argumentos.
«No es lo mismo conocer algo que comprender algo.»
Okay, ¿recuerdan a Leo Dicaprio en la película Inception / Origen? Acá pasó algo similar, la comprensión de la idea, de los principios detrás de la práctica generaron un nuevo comportamiento. No hubiera ocurrido lo mismo si sólo le decíamos al gerente que establezca WIP contraints en su tablero Kanban o que reduzca el tamaño de los lotes (por ejemplo). El cambio se generó de adentro y se externalizó en un nuevo comportamiento. Lo mismo a nivel de proyecto, hacemos una Inception como una actividad de entendimiento compartido, de identificar y comprender la problemática a resolver, de estar todos alineados, de que salgamos con la misma imagen en la mente de todos.
¿Cómo ser como Leo Dicarpio? Utilice herramientas: SAGAs, StoryTelling, experiencias lúdicas, practique con el ejemplo, module su lenguaje, haga inceptions.
Cambiar Cultura es trabajar sobre el sistema: el qué y el cómo
Una parte del cambio se genera a nivel individual, pero es necesario reconocer que mucho de la cultura en una organización se dibuja a partir del sistema de gestión existente. A grandes rasgos el sistema de gestión está formado por el cómo se hacen las cosas y qué cosas hay que realizar. Los procedimientos, las métricas, procesos de evaluaciones y recompensas, planes, organigramas, estructuras y otros, dibujan la cultura organizacional. No es de sorprenderse que cuando una persona llega a una compañía, poco a poco la cultura de la organización dibuja su comportamiento, la cultura se contagia.
Para tomar un ejemplo, imagine a las personas de mesas de servicios o atención de tickets de una empresa de servicios a internet; si el esquema de medición está basado en cuántos ticktes pueden cerrar, la persona se enfocará en cerrar la mayor cantidad de tickets como medida de buen desempeño de su trabajo, entre más tickets cerrados y con el menor tiempo de vida es mejor; lo que hace perder el foco de que el verdadero servicio es entregar soluciones a los clientes. Me ha pasado centenares de veces con los proveedores de internet en Ecuador, te piden que llames y generes otro ticket para quejarte; y hablan muy rápido porque quieren despacharte rápido para tomar otro ticket. Observe, sólo la forma en la que se mide el «desempeño» de una persona, generará un comportamiento determinado en aquella persona.
«Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. Our idea of the culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system.»
– David Mann, Creating a Lean Culture
Si realmente se desea crear una nueva cultura organizacional, es necesario cambiar el sistema de gestión. Por lo tanto el enfoque debe ser sistémico, evitar la optimización de una parte y pensar que lo más importantes es la interacción de las partes y cómo fluye la información a través del mismo.
Cambiar Cultura es duro, ésta se defiende
La cultura organizacional es un memeplex. Una linda y acertada analogía que plantea el gran FlowSensei (Bob Marshall). ¿Qué significa? Cada elemento de la cultura organizacional anteriormente mencionado es un meme (y no me estoy refiriendo a las imágenes con textos alusivos del Facebook). Un meme es una idea que se refuerza a sí misma. De los elementos de la cultura organizacional, la idea del correcto Liderazgo, de los roles y estructura existentes, políticas y demás…están allí porque se consideran respuestas correctas a varios problemas. Por ejemplo, he escuchado cosas como: «colocamos managers porque sino los developers no hacen su trabajo», «generamos actas porque sabemos que no van a cumplir» y cosas similares. Cada argumento justifica su razón de existencia y se refuerza así mismo, generando nuevos paradigmas.
Un memeplex es un sistema de memes que actúan en coordinación (cultura), y se comporta como un sistema inmune hacia elementos foráneos que pretenden cambiar la estabilidad del sistema. El sistema repele los cambios como una forma natural de defensa.
“La Cultura es el sistema inmune de la organización.” – Michael Watkins
Nuevamente, el enfoque es sistémico. Si el equipo de Agentes de cambio se enfoca en sólo un aspecto o sólo en desarrollo de software, la misma cultura se encargará de desayunarse sus iniciativas de cambio haciendo que todo el proceso se deteriore, minando la confianza de la organización y frustrando al equipo. Es vital trabajar con las capas de liderazgo.
Si la Cultura cambia se reflejará en nuevos comportamientos: de mindset a comportamientos, no al revés
Como los comportamientos son un resultado, a medida que el equipo de cambio trabaje sobre el mindset de las personas y sobre el sistema de gestión de la organización en múltiples niveles, los comportamientos cambiarán como consecuencia. Probablemente, cuando vea a los equipos podrá apreciar adherencia al método y cumplimiento de prácticas, pero si se acerca más apreciará que la dinámica del equipo, su lenguaje y comportamientos actúan en coherencia; incluso los equipos pueden cuestionar una práctica en particular y modificarla, porque comprenden los principios detrás, y esto puede que rompa la homogeneidad, pero está perfectamente bien; ya que todos están enfocados en la entrega de valor. Algunos harán StandUps diarias, y otros StandUps emergentes, algunos usarán, Scrum y otros Kanban; no hay problema siempre y cuando todos estén alineados al propósito del proyecto y la organización. El entendimiento e interiorización de valores y principios dibujan las prácticas y el comportamiento; que consecuentemente dibuja una cultura acorde.
No sé si soy yo, pero siento que en Latinoamérica existe un creciente interés acerca de algo que yo denomino, los «movimientos #No»: #NoEstimates, #NoBacklogs, #NoManagers; que ya tienen un rato dentro de la jerga agilista (yo me encontré con ellos hace unos años). En realidad pienso que es esto es bueno porque demuestra mayor exploración y, en términos generales, mejor entendimiento del pensamiento Lean; y quizás de una transición de enfoques de desarrollo iterativos incrementales (como Scrum) hacia otros donde se habla flujo de entrega de valor (como el método Kanban). Buenísimo!
Pero -desde mi punto de vista- hay que tener cuidado en no caer en enfoques puristas que pueden alejarnos de los beneficios que estos movimientos pueden brindarnos. Mi opinión a continuación:
#NoEstimates
“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art
Las estimaciones son inútiles, pero el proceso de estimación es valorable. El proceso de estimación es un proceso de conocimiento compartido, muy valioso para los equipos; no por el valor de estimación obtenido, sino por la discusión alrededor. Si las estimaciones y la dinámica aporta valor para su organización y a sus Clientes, úselos; recuerde también que tiene áreas Comerciales, maneja contratos y departamentos legales; estas cosas siguen existiendo en el mundo real. Si las estimaciones no le aportan valor, deséchelas; pero independientemente, revise su contexto y manténgase enfocado en la entrega de valor: hacia el Cliente y hacia la organización.
#NoBacklogs
«No hay nada derrochador sobre el concepto del backlog. Un backlog en sí mismo no es un desperdicio. Lo que importa es cómo las personas lo usan. Los trabajadores creativos necesitan herramientas para almacenar sus ideas y recordar sus opciones. Sólo de trabajadores de manufactura se debería esperar mantener su inventario bajo y sus máquinas limpias.» – Jurgen Appelo, Backlogs Are Not Waste
No a los backlogs estáticos, esos sí son desperdicio. No a backlogs de cientos de requerimientos que se levantan «up-front» y que cuyo valor se pudre en el tiempo. Si su backlog es un inventario entonces es un despercicio. Pero si su backlog está continuamente cambiando gracias al feedback de sus Clientes o del mercado, adaptándose a las necesidades, mutando continuamente para maximizar la entrega de valor, generando discusión y experimentos; esto es aprendizaje, respuesta al cambio. Sí a estos backlogs. Crear software no es igual al trabajo de manufactura.
#NoManagers
«Cuando la cultura de una organización es mala, no sólo es culpa de los managers. El Management de una organización es responsabilidad de todos. Un mejor management significa «enganchar» a la gente, mejorar el sistema entero e incrementar el valor hacia nuestros Clientes.» – Jurgen Appelo, Management 3.0 Workout
Managers no es igual a Management. El management en una organización -bueno o malo- no es sólo responsabilidad de los managers, es responsabilidad de todos. Es un sistema complejo donde se conjugan principios, comportamientos, reglas «no escritas», sistemas de recompensas, cultura, diseño organizacional y más. Ver a los managers como la causa de todo mal es sólo ver los árboles, no el bosque; no es sistémico. Sí a la descentralización de decisiones y a la autonomía en los equipos, pero esto no es igual a no tener managers.
Un nuevo movimiento #No
Por favor no interprete que trato de decir que estos movimientos son malos. Lo contrario, mi invitación es a explorarlos, comprenderlos y analizar su aplicabilidad en su contexto; si le aporta valor y le funciona, adelante! Al mismo tiempo, le invito también a no establecerse en una postura purista al respecto; lo que le funcionó a Usted para su contexto, puede que no aplique en otro.
Yo me atrevo a proponer un nuevo movimiento: #NoDogmas. Podemos sentarnos a discutir por horas sobre cuáles enfoques son conceptualmente mejores y cuáles no. En realidad no importa, todos pueden estar equivocados y algunos pueden servir para un contexto determinado; sólo se sabrá cuando se aplique; pero independientemente de todo, siento que encerrarse en enfoques puristas no es recomendable para las organizaciones y equipos en los que tratamos de llevar agilidad. Agilidad sobre debates metodológicos.
Desde hace un poco más de 3 meses soy parte de una jornada de transformación ágil en una gran compañía de desarrollo de software en Ecuador. El proceso involucra a más 300 personas en 3 países y a todas las áreas de la compañía. Representa precisamente un proceso de transformación que toca el ADN mismo de la compañía en muchos sentidos (estructura, procesos, tecnología, diseño del software, cultura). Cuando me incorporé a apoyar, el proceso ya tenía unos 3 meses de haber iniciado. El consultor que lo lideraba usó el marco SAFe (Scaled Agile Framework) como la guía metodológica y de procesos a seguir. Había leído acerca de SAFe -cuando todavía no se llamaba así- hace un par de años atrás; el libro es muy grande, a veces me dolía la cabeza leerlo y por algún 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 introducción 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 organización: equipos, programas y portafolio; a través de prácticas, 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 más grande y el propósito 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.
No tenía mucha certeza de por dónde 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 más 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 término surge de la analogía de las salidas de los trenes de una estación, las mismas que se definen en rangos uniformes de tiempo y de constante consecución. 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 iteración. La cadencia definida es de dos semanas, de tal forma que hay una integración de un «Big Working Software» y una revisión con los stakeholders denominada «System Demo».
Algo muy interesante de SAFe, es que la definición de la salida al mercado de un número acumulado de features que corresponde a un tren específico es una decisión 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 versión, etc. Tiene todo el sentido del mundo para mí. En empresas como Spotify lo manejan de forma similar.
SAFe posee también una base filosófica fundamentada en el pensamiento Lean. He leído y escuchado a algunas personas sobre la «casita de SAFe», «la casita Lean», y esta casita es la siguiente:
Básicamente es la misma casa tomada del Toyota Production System. Okay, yo comprendo los pilares y el sentido del pensamiento Lean, lo que quería saber es cómo 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, sólo se pueden trabajar en iniciativas que podamos pagar, «hasta donde nos de el presupuesto?». En la práctica, esto se expresa en el manejo de las épicas de negocio y arquitectura a través de un flujo Kanban; las épicas deben pasar por un funnel donde reciben aprobación por los miembros del Portafolio. Los dueños de la épica deben preparar y «vender» su épica justificando los beneficios para el negocio y para la compañía. Básicamente, 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 analogía 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 compañía. Esto se traduce a: «cuántas features podemos hacer con la capacidad que tenemos?». Este mindset se expresa en el Release plan y el Roadmap de producto; cuando las líneas 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 venía 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 económica», un término que viene de los principios del Desarrollo del Flujo de Productos, específicamente del libro de Don Reinersten, The Principles of the Product Development Flow; de donde SAFe ha tomado muchos conceptos de gestión 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 económica significa que debemos tomar en cuenta el «costo de la demora» de no sacar un producto o característica al mercado en cierto momento. La idea es, donde el costo sea más alto, eso se debe entregar primero. Para aquello se usa una fórmula denominada WSJF que permite priorizar épicas y features. En el entorno ágil ya veníamos 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 análisis. Lo bueno de esto, es que se discute otros aspectos válidos para el marketing, el cliente y operaciones; lo malo es que lleva más tiempo estimar y priorizar las épicas/features (más nivel de discusión, más Planning Poker, etc.).
Uno de mis «likes» favoritos. En la última versión 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 adopción y tener una jornada lo más satisfactoria. Estos líderes son clave en el entendimiento y aplicación de los principios y prácticas. En SAFe tienen su propio manifiesto con cuatro principios fundamentales:
Tener una vista sistémica: de todas las partes de la organización, 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 motivación intrínseca de los trabajadores del conocimiento: ayudar a crear el ambiente y las condiciones para contar con personas auténticamente motivadas y fomentar el conocimiento.
Este último tiene una relevancia súper 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 conocíamos.
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 adaptación y evolución 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 versión 2.0 allá por el 2011.
Otro gran plus de SAFe es su Big Picture; puedes ver SAFe en una hoja. Aceptémoslo, es de mucha ayuda. Además de que visualmente es agradable, el Big Picture es como una base de conocimiento interactiva en línea que permite navegar rápidamente sobre los conceptos y profundizar sobre algún tema. Creo que visito este sitio unas cinco veces al día 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 años. Representan una estrategia inteligente de difusión y ventas.
Una de las razones por las que dejé de leer el libro, es que puedo encontrar el contenido más rápido y la información está actualizada (el libro básicamente describe la versión 2.0 y algo de la 2.5).
Yo imprimí el Big Picture y me sirve mucho para el análisis de los puntos de mejora el contexto de la adopción, me ayuda a identificar problemas y priorizar, como dije; soy muy visual.
Los 5 «No me gusta» de SAFe
Pues ahora, permítanme enumerar los aspectos que me generan mucho ruido y que desde la práctica veo que necesitan atención si se está pensando en la adopción de Agile con este framework.
1 día = 1 story point? Qué?
Cuando escuché por primera vez al consultor que decía esto yo dije en voz alta en medio de una reunión: «Qué?» y todo mundo en el salón me quedó mirando raro. Esto para los agislistas es cercano a la aberración. 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 relación directa entre los story points (unidades para evaluar complejidad) y el tiempo. Es decir, 5 story points pueden ser hechos en más o menos tiempo en función 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 «normalización». Normalizar significa contar con una medida estándar para poder realizar predicciones a nivel de programa y portafolio. Básicamente, SAFe prescribe usar esta relación de 1 día = 1 story point; si tenemos un equipo de 5 personas trabajando 8 días de un sprint de dos semanas (se resta dos días: 1 Sprint Planning y otro para Sprint Demo y Restrospectiva) tenemos que un equipo cumple 40 puntos por sprint (5 personas x 8 días => velocidad de 40 puntos por sprint). Para lograr eso, se le pide al equipo que imagine una tarea que pueda hacer en un día y a esa se le pone 1 punto (más o menos como los días ideales).
En la práctica, no funciona. Cuando Usted le pregunta al equipo que estime la historia, en sus mentes no están pensando en complejidad, sino automática existe una conversión 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 añaden colchones o buffers para evitar equivocarse en la estimación: «Yo me tardo haciendo esta tarea 16 horas, pero por si acaso digamos 3 días. 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 «cuánto te tardas en esto?» cuando el cambio es «qué tan complejo (complejidad inherente, accidental y tamaño) consideras esto?».
A nivel de programa también hay problemas. Con un estándar de 40 puntos, es relativamente sencillo hacer proyecciones y planificar features. Los cálculos son expresados en fórmulas 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 fórmulas derivadas. Las fómulas no están 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, actúan igual, que son relojes perfectos que entregan siempre lo mismo sin considerar aspectos como el aprendizaje sobre la nueva tecnología, si hay personas nuevas en el equipo, si alguien sale de vacaciones, etc.
Sigo leyendo sobre el tema, pero aún 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 través de un backlog de referencia. Básicamente, creas un backlog con muchas historias tipo que representan varias labores que se generan dentro del contexto de la organización, 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 estimación, 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 histórica y se eligen escenarios: optimista, esperado, pesimista.
La iteración de Hardening es aquella que ocurre después de una iteración 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 función era parte de lo que SAFe denominaba la iteración HIP: Hardening, Innovating and Planning; una iteración especial que habilita a los equipos a estabilizar su software y brinda tiempo para organizar hackathons u otras actividades para innovar. Desde la versión 3.0, se separó el concepto de Hardening y ahora SAFe provee una iteración especial IP:Innovating and Planning luego de varios sprints de desarrollo (normalmente después de 4 sprints) para habilitar la innovación en la organización.
En la etapa de Hardening, el equipo de System Team baja el código 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, estrés, exploración, 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, entiéndase colocar en un ambiente de pre-producción o producción 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 pequeñas cascaditas? Lo que se aprecia es que la etapa de Hardening es muy similar a la etapa de Verificación 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 práctica, tener un sprint de Hardening hace que se difieran acciones de calidad e integración a una etapa posterior, produciendo acumulación de bugs, dificultades en la integración, desafíos en el control de versiones, loops grandes de asignación y corrección de bugs y otros malestares que existen en un desarrollo de cáscada; recordemos. Hace que los equipos piensen: «hay una etapa de detección de bugs más adelante, así que ellos detectarán problemas.». Adicionalmente se refuerza el equipo de System Team con más 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 código. El sprint de hardening tiende a ser usado en ambiente donde no existe automatización de pruebas o de integración continua como un nivel de contención. Esto hace que esta fase sea para detectar bugs y no para prevenir bugs, algo que va en contra del Agile Testing.
Una de las cosas que me generó una gran incógnita en la cabeza fue el tema de la ejecución de las retrospectivas a nivel de equipo. Participé en una retrospectiva y dentro de mi mente decía: «qué está pasando aquí?». Para realizar una retrospectiva a nivel de equipo (porque también 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 cálculo 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 automáticamente se dibuja un radar, lo muestra al equipo y luego se envía el archivo para su consolidación a nivel de programa. Al final de esa reunión todos salieron y yo me quedé sentado durante varios minutos tratando de entender lo que sucedió: en qué momento se habla sobre los problemas? cuándo el equipo se expresa? dónde están 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 corazón de la mejora continua, la expresión 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.
Imaginen lo siguiente: más de 50 personas en una sala de reuniones, en una reunión 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 sólo era el día 1; al día siguiente sería lo mismo. Me preguntaba: un Release Planning de dos días, en serio?. SAFe provee una agenda de dos días 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 están planeando todas las features e historias de todos programas para el trabajo de todos los equipos del siguiente sprint, la duración de esta reunión es larga y con agenda definida. Quizás tenga sentido para la primera ocasión, pero aún así la reunión ya es pesada. A esto súmenle que no habían radiadores de información; básicamente todos leían o veíamos la herramienta digital mediante una proyección y se planificaba en la PC. Igual, la Sprint Demo, es una reunión 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. Después de las dos primeras horas yo ya estaba divagando.
Agile, Scrum y los demás métodos ágiles en general sugieren una comunicación 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, más 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 proyección durante más de 8 horas, es algo que no clasifico como comunicación 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 reunión 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. Después de una discusión sobre el uso de post-its y elementos visuales, creamos un Release Plan en la pared y la reunión de planificación se redujo a 4 horas.
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 están diseñados 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 comunicación y el apoyo del management es necesario para una proceso de adopción o transformación ágil. Muchos coaches recomiendan manejar el lenguaje apropiado para los niveles y grupos apropiados.
Lo malo de SAFe es que al ver su estructura rápidamente se presta a interpretación y se puede hacer una correlación con las jerarquías y posiciones existentes dentro de la compañía. Cómo 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 quién reporta el developer, al Development Manager? y así por el estilo. Incluso la discusión llega a nivel de áreas.
Las jerarquías existen en una organización y entre más grandes son las organizaciones, más grandes y sólidas las estructuras. Lo que me parece que hay que manejar es la percepción de que «tal rol es jefe de otro rol» o que un rol es una posición. Un rol pueden formarlo varias personas dentro de la organización, o quizás no; cada organización es diferente. Este es uno de los desafíos 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 difícil 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 sólo un framework, una herramienta que provee un enfoque referencial sobre cómo llevar prácticas del entorno ágil hacia una organización. Mi respuesta es, depende de cómo la uses. Yo soy muy crítico sobre SAFe, hay que cosas que me generan mucho ruido (y que seguiré publicando); pero en este proceso de adopción estamos tratando de tomar lo mejor, adaptar al contexto y fomentar agilismo verdadero a través de conceptos, principios y prácticas.
Johnny Ordóñez 