Me animo a escribir este post porque recientemente leí tres artículos que están causando revuelo en la comunidad agilista, en parte por sus reconocidos autores y por otra, por su contenido. Me refiero al artículo The Agile Holocracy de Allen Holub, The Corruption of Agile de Andrew Binstock y The True Corruption of Agile del Tío Bob.
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».
Gracias por sus comentarios.
Referencias
http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698
http://www.drdobbs.com/architecture-and-design/the-agile-holocracy/240166629
http://blog.8thlight.com/uncle-bob/2014/03/28/The-Corruption-of-Agile.html
http://en.wikipedia.org/wiki/William_Ouchi
http://www.thoughtworks.com/es/insights/blog/agile-liturgy
Hola Johnny, quería aprovechar un poco tu experiencia en Agile para una consulta, en mi empresa están emprendiendo con fuerza en el tema, el equipo ágil está conformado por:
Product Owner
Analistas de Negocio
Especialista de Software (como un Project Manager)
Equipo de Desarrolladores de Software
Ahora el equipo de desarrolladores de Software esta tercerizado y tiene una calidad cuestionable, la paga de ellos es muy baja para el medio.
No se realizan prácticas de pair programming ni existen QAs dentro del equipo, por lo que el principal issue que entra en duda es si este esquema es el adecuado para servicios importantes en la empresa.
Hola Jim, gracias por comentar y por la pregunta. Esto es algo que podríamos conversar con más calma por Skype (johnny.ordonezortiz) o HO (jhonnyv75@gmail.com), lo que te puedo adelantar ahora es que tanto proveedores como el equipo local trabajan juntos como un equipo siguiendo los mismos lineamientos y acuerdos. De esta forma la responsabilidad es de ambos. Si hay cosas por mejorar; hay que plantear esquemas, prácticas y roles en el equipo; ambos -proveedor y cliente- deben estar dispuestos a asumirlos y trabajar coordinadamente.
Lo hablamos con detalle por Skype! Gracias.
Pingback: ¿Cambiar Comportamientos = Cambiar Cultura? | Johnny Ordóñez
Pingback: ¿Qué es Agile? Mitos y Verdades – Andrés Salcedo
Pingback: MITOS Y VERDADES SOBRE LA AGILIDAD – Blog