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.
En SAFe a nivel de programa existe un equipo denominado el Release Management Team. Este equipo tiene la responsabilidad principal lograr un incremento de sistema «decente» en cada iteración de la cadencia a nivel de programa, es decir; es encargado de subir funcionalidad en los vagones del Tren de Entrega Ágil (o Agile Release Train o ART) en cada salida. Un Agile Release Train tiene un significado dual en SAFe. Primero, un ART es para el nivel de programa lo que una iteración es para un equipo. Es una iteración para el programa. La analogía proviene de las cadencias de 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 que componen las Features planificadas de todos los equipos que trabajan en el proyecto o proyectos que se terminaron y aceptaron por los Product Owners en la iteración que acaba de terminar. Al igual que a nivel de equipos, existe una “System Demo” donde los stakeholders, expertos de negocio, ejecutivos y Clientes entregan feedback sobre el producto; y lo más importante, determinan si este incremento de Programa o PI se convierte en un entregable hacia el mercado o hacia el Cliente, cumpliendo así con el concepto Desarrollo en Cadencia – Entrega en Demanda. El segundo significado es, el ART es un grupo de personas (típicamente de entre 50 a 125) trabajando de forma coordinada y alineada a los objetivos de negocio en un flujo constante de entrega de valor para un Value Streamdefinido para la organización. Significa, que un ART es un equipo de proyecto formado de varios equipos ágiles, equipos de operaciones y especialistas (por ejemplo UX y Arquitectura) y un equipo coordinador a nivel de programa llamado el Release Management Team (RTM) que mencionaba inicialmente.
Típicamente, los integrantes del RTM son: El Release Train Engineer, el conductor del tren (o cariñosamente llamado: «el chofer»); la persona que lleva a los demás hacia cumplir los objetivos del release, o en palabras SAFe, encargado de llevar el tren a la siguiente estación a tiempo. Funge como el Chief Scrum Master (por lo que coordina estrechamente con todos los Scrum Masters del Tren), eliminando los impedimentos a nivel de programa, escalando y trasladando los impedimentos de los equipos hacia las áreas o roles de la organización, facilitando la sesión de Inspect & Adapt (o Retrospectiva a nivel de Programa). Coordinando, escuchando, guiando, facilitando; es el Scrum Master a nivel de Programa, pero tiene mucha responsabilidad en la ejecución. El Product Manager (o Product Managers, dependerá de cada tren), la persona o equipo quien sabe qué cosas van en los vagones; conocido también como el Chief Product Owner. Esta persona junto con los Product Owners, personas de negocio, Subject Matter Experts, Marketing o UX, conforman el Product Management Team. Al igual que un Product Owner, tiene la responsabilidad de destilar las Features, organizar al equipo para lograr estimaciones, priorizarlas, identificar dependencias y establecer el contenido de cada incremento de Programa o release. Naturalmente, trabaja estrechamente con los POs y posee una visión y conocimiento del negocio, más no técnico necesariamente. El Development Manager (últimamente un rol muy polémico en varias conversaciones vía Twitter que he tenido). Lejos de ser el Jefe de los desarrolladores como el nombre del rol podría intuitivamente sugerir, es la persona que se preocupa por el desarrollo personal y profesional de las personas en el tren. En el Big Picture de SAFe no aparece a simple vista este rol, pero ingresando por Lean & Agile Leaders podremos encontrar literatura sobre el rol. Alguna vez envíe un mensaje a las personas de Scaled Agile Inc. sugiriendo cambiar el nombre (algo como People Development Lead, People Lead o algo parecido), en verdad que se presta a mal interpretación y automáticamente puede calzar con roles existentes en una organización como Jefe de Desarrollo, Gerente de Operaciones o algo así. Independiente de esto, el Development Manager es un Agile Champion. Es una persona que conoce, vive y transpira los valores y principios del manifiesto ágil y del pensamiento Lean, pero con un enfoque muy fuerte hacia las personas, preocupado por su bienestar, porque tengan lo que requieren para realizar su trabajo, que el entorno sea favorable, que se sientan bien. Es quien se preocupa por el desarrollo personal, de carrera y profesional. Además, SAFe le da responsabilidad de velar por el desempeño de los equipos, manejar relaciones con personal externo involucrado en el proyecto, ayudar al RTE a eliminar impedimentos, eliminar distracciones y apoyar en el proceso de adopción ágil en la organización. El Business Owner, él o los responsables fiduciarios de los resultados de negocio (normalmente financieros) del valor entregado por el tren. Normalmente es un grupo formado por ejecutivos de áreas de negocio, marketing u otros. Son responsables del ROI de la operación y del aporte de valor al Value Stream y a la organización. Junto con el Product Manager establecen los objetivos del programa a cual se anclan las Features, para que posteriormente se descompongan objetivos de iteración para los equipos, a los cuales se anclarán las historias más adelante. Parte del RTM son también el System Architect, encargado(s) de proveer lineamiento sobre la visión técnica, tecnológica y arquitectónica de la solución, guiando a los equipos en el diseño e implementación del producto, ayudando a construir (o construyendo ellos mismos como un equipo ágil) la Pista arquitectónica o los «rieles» por donde circula el tren, etc.; UX Designers, que brindan guías y lineamientos para crear y mejorar la experiencia de los usuarios y del uso de buenas prácticas para el diseño de UI, dando feedback e investigando sobre el comportamiento de los usuarios; el System Team, el grupo que apoya a los equipos en tareas de operaciones, infraestructura, pruebas de sistema. El System Team tiene la responsabilidad de habilitar a los equipos que integren sus incrementos de producto, realizar pruebas de sistema end-to-end (Performance, Carga, Seguridad, Disponibilidad, etc.) y prepara el ambiente para la System Demo. Y otros miembros que cada tren decida integrar para ayudar a la ejecución y a la entrega de valor.
Este equipo es y debe comportarse como un equipo ágil. Vivir los principios de colaboración, transparencia y mejora continua. No necesariamente significa que debe contar con un tablero con sus actividades de cada iteración (aunque no es mala idea), deben contar con reuniones de coordinación frecuentes, monitorear constantemente el estado del release y del tren, ver si se está alineado con los objetivos de negocio y del Value Stream, comunicación cara a cara, sesiones de feedback, transparentar los problemas, analizarlos y atenderlos, alzar la mano cuando se identifican riesgos, coraje, respeto, colaboración.
La Tríada en el corazón de la colaboración ágil a nivel de programa
Al ser un equipo ágil, el RTM realmente no tiene la necesidad de contar con líderes o jefes; pero tiene el compromiso de trabajar colaborativa y proactivamente para lograr que unos de los valores de SAFe se cumpla: Ejecución del Programa; y mas allá, lograr una cultura de entrega de valor constante. De mi experiencia con SAFe a través de varios equipos y programas, he visto que -si bien es cierto la responsabilidad es de todo el tren y de la organización- existen tres roles a los que veo correr activamente, entendiendo los objetivos del negocio, priorizando el alcance, estableciendo las fechas de entregables en base al contrato, analizando los problemas, pegando el papelógrafo en la pared para la ejecución del Release Planning, agendando sesiones con los Stakeholders, pendiente de los equipos, etc. Los 3 amigos: Release Train Engineer, Product Manager y Development Manager. Tomen en cuenta que no necesariamente cada rol corresponde a una persona (pueden ser dos o más ejerciendo el mismo rol, en función del tamaño del ART) pero estos roles en mi punto de vista son vitales y complementarios entre sí.
Piensen un momento en que el propósito de SAFe es escalar los beneficios de Agile a través de principios, prácticas y roles. Si está escalando con sólo con Scrum, por ejemplo; con varios equipos y varios Product backlogs; podría contar con una configuración de Chief Product Owner como lo propone Roman Pichler. Podría contar también con un rol que está ayudando a escalar problemas hacia la organización y brindando guía sobre el proceso Scrum, un puente con el management y la organización; por ejemplo un Chief Scrum Master, quien asistiría y facilitaría la S2 (Scrum de Scrums) o incluso la S3 (Scrum of Scrums of Scrums). Y al tener muchos equipos trabajando juntos sobre la misma iniciativa, posiblemente requiera un rol que deba estar pendiente de proveerles lo que necesitan (organizacionalmente), de su moral para su día a día, de su expectivas, de su crecimiento personal y profesional. Independientemente de los nombres de los roles, yo identifico este patrón en SAFe. Básicamente, una configuración de escalamiento de las que ya hemos leído, y que podemos adaptar a cada contexto.
Pensamientos finales
Aunque SAFe proponer temas muy interesantes, en realidad es la recopilación de muchas de las estrategias, enfoques y prácticas exitosas para la aplicación de los principios del desarrollo ágil a escala organizacional. Nuevamente, SAFe es un framework (al igual de Scrum por ejemplo); lo que quiere decir que NO HAY RECETAS!; y que su aplicación será exitosa en función de su apropiada adaptación al contexto, al negocio y la organización, y sobretodo de los resultados de negocio que habilite; pero fundamentalmente, este o cualquier framework será exitoso en la medida en la que conserve, promulge y potencie los valores y principios del Agilismo.
Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie
Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de «Hecho» (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra «Hecha» para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.
Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y «Done Done» o «Accepted» cuando ha sido revisada y “firmada” por el Product Owner.
Varios agilistas sugieren lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la «Definición de Listo».
La Definición de «Ready» o DoR
Análoga a la Definición de «Hecho», la definición de «Listo» es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.
¿Por qué es importante?
Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior, el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.
Bob Galen habla mucho del «Readiness Criteria» en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):
Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.
Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su «olfato» para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):
Sprint plannings más rápidos;
Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente sprint;
Gestión colaborativa del backlog;
Feedback temprano;
Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.
Pensamientos finales
Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.
Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.
Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.
Son las 9:15 am y siento el batuquear del avión que me lleva a Medellín para asistir a una nueva edición del evento más grande de Agilismo en Latinoamérica, Ágiles 2014. Mientras el avión se estabiliza, normalmente comienzo a ojear las revistas de las aerolíneas hasta que pueda sacar mi libro o la laptop (me mareo con facilidad). Con un bostezo, comienzo a revisar las páginas de publicidad que no se terminaban, hasta que llegué a la sección de lecturas interesantes; entre aquellas, un titular que me llamó la atención: “James Cameron: Visionario en Ciencia y Entretenimiento”.
Siento un gran apego por James Cameron, no sólo porque me gustan sus películas, pienso que es un gran Director (sentí que le robaron el Oscar hace un par de años), también porque considero que ha aportado a la industria cinematográfica con su trabajo y además porque uso el ejemplo de la película Titanic en mis presentaciones para ilustrar la diferencia entre el éxito de un producto frente al éxito de un proyecto (comparándolo con el Maglev Chino, un fantástico ejemplo que me enseñó mi amigo Heitor Roriz); siempre es útil.
Comencé a leer sobre la entrevista que le hicieron a James acerca del nuevo documental que está dirigiendo y produciendo: James Cameron’s DeepSea Challenge 3D; sobre los desafíos de construir una máquina que pueda sumergirse más, de la tecnología y de su equipo; y de a poco me fui topando con frases que enseguida despertaron mi “sentido ágil” (algo así como el “sentido arácnido”); la primera:
“La única manera de construir este vehículo, dentro de un tiempo y presupuesto razonable, era hacerlo con un equipo pequeño de personas dedicadas y multifuncionales.”
Dije entre mí: “Suena como un equipo Scrum. Chévere!”. Continuaba la lectura y apareció una joya que enseguida me dibujó una sonrisa:
“El método que utilicé se llamó: Total Transparencia Radical. Todos los que estaban trabajando en el vehículo tenían que sentarse alrededor de una mesa, cada mañana a las 8h15 –no 8h14 ni 8h16– y ahí aireábamos nuestros problemas. Las conversaciones sobre lo que iba mal en el proyecto debían ser públicas. Tú llevabas tus problemas al grupo y nosotros, como grupo, los resolvíamos.”
Pensé: “Hey!, estos son valores y prácticas de agilismo.”. Y no podía parar de leer:
“La gente pensaba que estaba loco, pero después de unas dos semanas, empezamos a trabajar realmente como equipo. Ellos empezaron a entender que uno no oculta sus problemas, uno los comparte con el grupo.”
“Dos semanas…un Sprint!?; mucha coincidencia!”. Luego el periodista pregunta:
“¿Qué nueva tecnología estás utilizando en las tres secuelas que estás haciendo de Avatar las cuales se presentarán a partir del 2016?”
Y James responde:
“Unos dos meses después de haber terminado Avatar, volvimos a reunirnos para hacer un gran análisis postpartido. Le pedí a cada departamento que elaborara un libro sobre lo que hicimos bien, lo que hicimos mal y lo que podríamos hacer mejor la próxima vez. Y de ahí surgieron las directrices para el desarrollo de un nuevo software y las mejoras del sistema.”
“Una retrospectiva post-mórtem!.” dije.
Agile no es «sólo» desarrollo de Software
Okay, analicemos esto. Tenemos valores, principios y prácticas aquí:
Disciplina
Transparencia Radical
Reuniones Diarias
Equipos pequeños multidisciplinarios
Retrospectivas
Visión
Liderazgo
Son elementos esenciales para realizar cualquier trabajo de forma colaborativa. Una de las percepciones más comunes que se dan cuando se habla o se lee sobre Agile es pensar que es exclusivamente para el desarrollo de software. Nunca me cansaré de decir o escribir esto: comprendamos qué es Agile y qué significa:
Agile es un mindset basado en valores, guidado por principios y expresado en prácticas.
En mi experiencia, he visto e incorporado principios y prácticas de agilismo más allá del software: Marketing, Ventas, Tesis de Maestrías, en la casa. Agile es algo que trasciende; son simplemente elementos necesarios para realizar un trabajo de forma colaborativa y bien hecha.
Sin duda, la fuerza Agile es fuerte en James; podría sin duda ser un gran Agile Coach; y esto hace que tenga ganas de ver el documental.
Reportando desde el aeropuerto El Dorado de Bogotá, haciendo escala hasta Medellín.
“Es importante la constancia, el compromiso, la colaboración y la interacción entre individuos pues es lo que genera la máxima productividad.”
– Norberto Gaona
Algo que siempre decimos y percibimos los agilistas es ”que los equipos ágiles son muy disciplinados”. Disciplina, acuerdos y compromiso son -desde mi punto de vista- pilares para la ejecución y adopción ágil (y de cualquier trabajo, sea ágil o no). Son clave para que el proceso ágil fluya, mejore y se entregue el valor en un ritmo constante en periodos cortos. Las prácticas ágiles fueron diseñadas a propósito para elevar el sentido de disciplina; por esta razón los timeboxes son fijos (pase lo que pase), los sprint plannings se basan en compromisos, las reuniones son llamadas ceremonias, el código se sube todos los días, la definición de Done y los criterios de aceptación se cumplen, si hay que hacer documentación, se hace; y se respetan los acuerdos organizacionales y del equipo. Cuando un equipo ágil es disciplinado, incluso el trabajo remoto se lleva mejor.
“Agilidad requiere una dosis extra de disciplina, porque cada miembro del equipo es indispensable. El valor, el peso y la responsabilidad de cada uno es por lo tanto mayor.”
– Giancarlo Girardi
En mi experiencia, la moral del equipo se incrementa al ver software funcionando creado en un sprint luego de haber trabajado en una jornada dura, pero donde se demostró disciplina, ahínco, profesionalismo y compañerismo. Los equipos ágiles tienden a convertirse en equipos de alto desempeño, los miembros de un equipo son como atletas; para llegar a ser un gran atleta y competir en alto nivel, existe mucha disciplina en los entrenamientos, en su plan de nutrición, en su disciplina mental y física. Skills, Disciplina, Entrenamiento.Es lo mismo para los equipos ágiles.
“Disciplina para hacer lo que sabes que es correcto e importante, aunque difícil, es el camino real para el orgullo, la autoestima y la satisfacción personal.”
– Margaret Thatcher
Todos somos llamados a fomentar la disciplina a través de nuestro trabajo del día a día. Disciplina no es miedo, disciplina no es micromanagement, disciplina no es autoritarismo. Disciplina es un valor que expresa diariamente; es el puente entre las metas y los logros. El Agilismo está lejos de la anarquía de las que temen muchos managers, sobretodo en organizaciones grandes. Disciplina es un valor requerido en el Agilismo. A practicarlo!
(Buscando imágenes para este post me encontré con estas fotos sobre la Belleza de la Disciplina en el entrenamiento de monjes Shaolín; me encantó).
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.
El tema en discusión: comprender Agile como un conjunto de valores y principios más allá de un conjunto de prácticas; interpretar si Agile es una cultura o no.
El punto de Allen y Andrew: «Agile es un cultura, no un conjunto de prácticas»
Allen y Andrew explican en sus artículos que un gran grupo de consultores ágiles se enfocan rápidamente en la aplicación y socialización de prácticas o frameworks olvidando lo que en esencia se menciona en el Agile Manifesto. Agile es un conjunto de valores y principios, más que prácticas de desarrollo de software.
El punto del Tío Bob: «Agile es una cultura expresada a través de un conjunto de prácticas»
En respuesta, el Tío Bob explica que la verdadera corrupción de Agile es pensar que las prácticas están separadas de la cultura. Es a través de las prácticas que podemos reconocer una cultura y por lo tanto son inherentes a ella, nos identifican. En tal virtud, Agile es también un conjunto de prácticas.
Esperen un minuto, resolvamos esto primero: ¿Qué entendemos por cultura?
Okay, antes de comentar mi punto de vista al respecto deseo detenerme un momento a comprender lo que es cultura. Hay muchas definiciones (si no me creen vean esta discusión en LinkedIn). Para mí, cultura es como el par de lentes adquiridos a través de los cuales vemos y comprendemos el mundo. Es parte de nuestra memoria colectiva y de la comprensión de nosotros mismos. Cultura es algo que nos une.
Algo que me ha ayudado a comprender mejor lo que es cultura es el trabajo de William Ouchi quien llevó conceptos de antropología a la organización y básicamente define la cultura como una pirámide en cuya base se ubican las creencias y valores, más arriba los modelos mentales y por último el comportamiento:
Esta pirámide es como un iceberg, lo único que podemos percibir inicialmente es el comportamiento de las personas e intuir lo que hay por debajo.
Si hago una relación de Agile con el iceberg tendríamos algo así:
Para mí, Agile es una cultura basada en valores, guiada por principios y expresada en prácticas. La base del iceberg es lo que llamaríamos «Ser Agile», mientras que la parte visible es lo que consideraríamos «Hacer Agile».
Okay, una cultura posee ambos: valores y prácticas; cuál es el problema?
En los procesos de adopción de Agile muchos consultores comienzan profundizando las prácticas: «hagamos TDD, tengamos Dailys Standups, usemos Scrum», etc. El problema de comenzar por la parte superior del iceberg es que las prácticas se deterioran si no son practicadas teniendo una conciencia sobre el principio o valor que las sustenta. No hacemos TDD o Dailys porque decimos que somos ágiles, hacemos TDD porque construimos software de valor, de alta calidad, de forma colaborativa y con feedback temprano; es porque creemos en la transparencia y en el trabajo en equipo. Agile es más que pegar post-its en la pared y reunirse todos los días. Del otro lado, existe una alta probabilidad de que si te reúnes como equipo, trabajan colaborativamente, usas buenas técnicas de desarrollo de software, la calidad mejore y entregues mayor valor; pero normalmente no hay una correspondencia bidireccional entre el «ser» y el «hacer».
Mi punto: Agile es cultura, pero debe ser una cultura viva
Seguramente han visto muchas empresas con sus valores pintados en las paredes, o con grandes pósters diciendo: «somos ágiles, trabajamos en equipo, trabajamos con pasión, transparencia», etc; pero en el día a día pasa precisamente lo contrario: micromanagement, competencia, individualismo. De igual forma, me he encontrado con numerosos equipos teniendo «zombie standups» todos reunidos contando los minutos para terminar y sentarse nuevamente a trabajar, siguiendo la Liturgia Ágil (como le diría mi amigo Juame Cardona) de forma automática, sin ninguna reflexión acerca del valor de la práctica.
En ambos casos existe una brecha entre los valores y el comportamiento. Es una cultura vacía, una cultura zombie.
Una cultura viva es aquella en donde se respira, practica y vive lo que se predica. Es aquella en donde las prácticas reflejan el verdadero acuerdo del equipo, los valores con los cuales se comprometieron, el lente a través del cual miran todos. En una cultura viva existe una comunión auténtica entre valores y prácticas, de tal forma que las prácticas pueden cambiar o evolucionar en busca de respetar los valores; es muy difícil que las prácticas por sí solas modifiquen los valores core del individuo, equipo u organización; son sus valores core quienes modifican las prácticas.
Adoptar Agile implica un cambio profundamente humano
«Tu cultura se come a tu estrategia por desayuno». – Henrik Kniberg
Ya lo dicen las encuestas: «el principal obstáculo para adoptar Agile es la falta de habilidad de cambiar la cultura organizacional» (State of Agile, 8th Version One Survey). Tiene sentido, no podemos ayudar a una organización sin conocerla, sin conocer los drivers y los valores en la parte baja de la pirámide más allá del comportamiento visible. Es la razón por la que estoy convencido que un Agile Coach/Consultant debe ser un antropólogo organizacional y descubrir la pirámide de cada organización. En mi opinión, más allá de las prácticas o frameworks de moda para escalar Agile; el cambio es profundamente humano. A partir del primer valor del Agile Manifesto:
Individuos e interacciones sobre procesos y herramientas.
se derivaría algo como:
Valores y principios sobre frameworks y prácticas.
No quiere decir que las prácticas o los frameworks no sean necesarios, son herramientas muy útiles; pero sin una interiorización de los valores que representan, estas se diluirán con el tiempo perdiendo aquellos valores. Una cultura Agile es la comunión auténtica bidireccional entre «Ser Agile» y «Hacer Agile», comenzando por comprender «Ser Agile» para luego «Hacer Agile».
El mes anterior tuve la fantástica oportunidad de participar en el evento Ágiles 2013: la 6ta Jornada Latinoamericana de Metodologías Ágiles; el evento más importante sobre Agilismo en la región, que reúne a agilistas de toda Latinoamérica e invitados especiales de todas partes del mundo.
Fue una experiencia muy especial para mí y que disfruté plenamente por varias razones. Por fin conocería en persona a muchos amigos agilistas con quienes compartimos artículos, discusiones y conversaciones a través de Twitter; esta ocasión podría hacerlo en persona y conversar con ellos más allá de la frontera de 140 caracteres. Fue bastante divertido la forma en la que nos reconocíamos uno a otro a través del nombre de tu cuenta de Twitter anotada en tu pecho.
Sin lugar a dudas, los invitados especiales fueron la sensación. Estaba muy emocionado porque escucharía en vivo -al fin- a Jurgen Appelo hablando de su Management 3.0 y de Cómo cambiar al mundo; después de seguir su trabajo por más de 2 años me sentí como un fan de Justin Bieber en primera fila antes de su concierto. Su keynote de inauguración del evento, hablando sobre Champfrogs fue realmente memorable y que abrió la perspectiva muchos asistentes acerca de la dinámica de un equipo ágil y cómo ser un agente de cambio o«organizational transformer» como él lo llamó. Después de mucho luchar con mi nerviosismo y superando mi temor por hablar en inglés; pude acercarme y hacerle las preguntas que quería hacerle desde hace mucho. La lista en mi mente superaba las 20 preguntas, pero sólo pude hacerle dos. Supongo que estar ante una de tus estrellas del agilismo y management intimida. No me despedí sin antes invitarlo a Ecuador a algunas charlas para difundir estos temas. Se mostró muy a gusto con la idea, así que tengo la esperanza de un concierto en Ecuador.
Pronunciar el apellido Poppendieck en el mundo Agile y Lean, es hablar de temas mayores. Mary y Tom estuvieron en el evento, y curiosamente en todas las charlas que elegí participar, Mary Poppendieck estaba allí. Fui muy afortunado de participar de sus comentarios sobre los temas de las charlas. Sus argumentos fueron directos, inteligentes, sinceros y divertidos también. Una perspectiva muy clara sobre la realidad del desarrollo de software y las personas. Una persona muy amigable pero firme en defender sus ideas. Siempre estaba sonriendo, y accedió muy gentilmente a tomarse una foto conmigo.
Otra de las razones por la cual este evento fue especial para mí, fue que tuve la oportunidad de conocer y escuchar a varios ThoughtWorkers -de las oficinas de Brasil y EEUU- compartiendo sus experiencia acerca de procesos, prácticas y técnicas para construir mejor software. Estoy muy contento de contar con compañeros que proponen ideas disruptivas y que han hecho cosas maravillosas dentro de ThoughtWorks.
Finalmente, tuve la oportunidad de reunirme con más agilistas ecuatorianos para fortalecer y promover la Comunidad Ágil en Ecuador. Acordamos en crear y promover un manifiesto ágil y organizar charlas, talleres, dojos, etc.; para promover la cultura ágil en nuestro país.
Ágiles 2013 fue un gran espacio aprender, compartir y disfrutar; fortaleciendo las relaciones entre los agilistas de la región. Fomentando y compartiendo el espíritu ágil y las ganas de ayudar; haciendo más amigos. Un gran espacio para unir a las personas.
La semana anterior conversaba acerca del tema a través de twitter con un amigo agilista de Ecuador. Cuando él propuso esto, lo debatí fuertemente; ya que para este momento no concebía que un arquitecto de software pueda llevar la gran responsabilidad del PO. Mi temor estaba orientado a que podría dársele más énfasis a aspectos técnicos y tecnológicos que a satisfacer las necesidades funcionales y expectativas de negocio de nuestro cliente. Al final del día, no importa mucho si lo haces con .NET o Java, 3 capas o cliente-servidor, si el producto no es de calidad (según mi visión de calidad basado en el modelo Kano), sino representa utilidad para el negocio y las funciones diarias del cliente; sino deleita.
Durante esta semana (y mientras escribo este post) tuve la oportunidad de participar en un curso de arquitectura basado en la visión del IASA. He descubierto que estaba muy sesgado acerca del rol de un buen arquitecto de TI y un buen arquitecto de software, comprendiendo que un buen arquitecto buscar solucionar problemas de negocio apalancado en tecnología, algo fácil de decir pero muy complicado
«Nunca dudes que un pequeño grupo de personas comprometidas puedan cambiar el mundo. En efecto, es lo único que lo ha logrado» – Margaret Mead
Hoy en la tarde participé de una experiencia fantástica.
Agilistas de Venezuela, Chile, Colombia, Perú y Ecuador participando con sus tweets en el primer ConversaAgil; una simple pero poderosa iniciativa diseñada para compartir experiencias acerca de Agile y conversar sobre un tema específico propuesto; en esta ocasión «Técnicas ágiles aplicadas a proyectos que no son de software».
#ConversaAgil se asemeja a un OpenSpace habilitado sobre Twitter (algo como un TOS: Twitter Open Space) en el cual todos los participantes compartieron sus tweets llenos de valiosos aportes, links y consejos. Es un espacio para conocer y exponer puntos de vista sobre una problemática ágil y al mismo tiempo fortalecer las relaciones entre amigos agilistas de la región, que aunque no nos conocemos personalmente, compartimos este gran espíritu ágil y las ganas de ayudar.
Todavía hay cosas por mejorar, pero para ser el primer intento, salió genial!! Pronto llevaremos a cabo otro #ConversaAgil.
Gracias Gustavo Bonalde e Irwin José Franco por hacerme parte de esta maravillosa idea; un gusto colaborar con Ustedes.
Johnny Ordóñez 
