Agile Manifesto. Lost in Translation (and Business Areas Lost in Context)

En estos más de 12 años de trabajar directamente con la agilidad y más de 20 como profesor universitario, constantemente en entrenamientos y cursos he hablado del manifiesto ágil, y cuando lo hago sigo el siguiente proceso:

• Muestro el manifiesto en inglés (no difiero mucho con la traducción) - agilemanifesto.org 
• Lo presento en español -  agilemanifesto.org/iso/es/manifesto.html 
• Lo explico y discuto.
• Explico quiénes son los que firmaron el manifiesto ágil e invito a que los busquen y sigan en redes, blogs, empresas, Twitter, Facebook, Youtube, LinkedIn (como dicen modernamente, los invito a stalkear).
• Luego paso a los principios en español - agilemanifesto.org/iso/es/principles.html y similarmente los explico y discuto en detalle.

Y aunque he brindado cursos de agilidad y de SAFe (www.scaledagileframework.com) en inglés, me ocurre como a todos, a veces pasamos por encima de las cosas sin hacernos conscientes de ellas. 

Bueno, quiero compartirles algo que me impactó luego de 20 años de explicar el manifiesto ágil a mis estudiantes (1); existe una discrepancia radicalmente importante entre el texto en inglés y español en el tercer principio del manifiesto, el cual reza:

En inglés:

• Business people and developers must work together daily throughout the project.

En español

• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Se observa que en la traducción hacia el español se pierde el must, el cual denota obligatoriedad o imposición. Considerando lo anterior, unas posibles traducciones más fieles al texto en inglés podrían ser:

• Los responsables de negocio y los desarrolladores debemos trabajar juntos diariamente durante todo el proyecto.
• Los responsables de negocio y los desarrolladores tenemos que trabajar juntos diariamente durante todo el proyecto.
• Los responsables de negocio y los desarrolladores tenemos la obligación de trabajar juntos diariamente durante todo el proyecto

Completamente diferente, ¿No es cierto? Una sola palabra genera una realidad distinta en español, como dicen en coaching “el lenguaje crea realidad”, y nos hace ver que es conditio sine qua non no funciona la agilidad que promovemos, pues partimos de la base que quienes hacemos agilidad cumplimos los 4 valores y 12 principios, y fallar en el involucramiento diario de la gente de negocio generará que fallemos en nuestro propósito de construir soluciones que coincidan con las necesidades de los clientes y usuarios.

De igual forma, cambié la palabra cotidiana (2) por diariamente, aunque significan lo mismo, quiero hacer este hecho aún más explícito.

Otra traducción un poco débil dentro del manifiesto ágil se encuentra en el segundo valor, el cual expresa: 

En inglés

• Working software over comprehensive documentation

En español

• Software funcionando sobre documentación extensiva

Según el diccionario Oxford son sinónimos de comprehensive: complete, full (3); por lo cual unas traducciones más cercanas a la intención en inglés podrían ser:

• Software funcionando sobre documentación completa
• Software funcionando sobre documentación integral

Pongamos foco en el punto de dolor

No dudo que al igual que yo, muchos instructores, agile coaches, scrum masters, practicantes ágiles, áreas de TI, áreas de negocio, etcétera, han leído y usado la traducción del manifiesto ágil en español interpretando ese trabajamos juntos sin el énfasis que le pusieron los autores en inglés, pero el hecho más preocupante es que existen muchas áreas de negocio y clientes que insisten en hacer agilidad sin estar involucradas, delegando a los equipos de software la construcción de la solución, sin entender que es un factor de éxito en escenarios de incertidumbre y de construcción incremental. 

Cabe adicionar que varios informes del caos del Standish Group  - www.standishgroup.com - a lo largo de las últimas tres décadas han demostrado que los proyectos de software más exitosos son aquellos en los que está el cliente involucrado y comprometido diariamente.

Áreas de negocio perdidas en el contexto del desarrollo de software

Aunado a lo anterior, existe desde las áreas de negocio (y aun desde algunas vicepresidencias, direcciones o gerencias de TI) una ingenuidad sana pero que a la vez trae consecuencias negativas en los procesos de construcción de soluciones de software, y es creer que hacer software es un proceso predictivo, estable y que puede ser delegado sí existe una buena documentación.

Existen varios factores, que compiten en contra de la predictibilidad y la estabilidad de los procesos de software:

1. El proceso de desarrollo software es un proceso de adquisición de conocimiento (4), entre más se interactúa con el cliente, mejor se entiende su necesidad y lo solución es moldeada de acuerdo con el entendimiento de esta. 
2. Como lo afirmaba Watts S. Humphrey (conocido como padre de la calidad del software) "Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después que los usuarios hayan usado el sistema", por lo tanto, implica una validación de la constante del software para descubrir la solución deseada (5).
3. La complejidad creciente del software, la cantidad de conexiones de este y las posibles interacciones y comportamientos requiere de un proceso de acompañamiento de quien lo solicita.
4. De una solución de software solo el 20% es usado frecuentemente, 30% usado algunas veces, 50% poco o nunca usadas (6). Por lo tanto, si queremos llegar a construir software más rápido debemos evitar a toda costa construir software que no será usado y esto solo se logrará con un ejercicio constante de priorización y validación por parte del cliente del área usuaria.
5. Los requisitos de software son inestables en un mundo cambiante o VUCA (7). Actualmente los requisitos tienen una vida útil de seis meses o menos (8). Ver imagen continuación

En conclusión, el proceso moderno de hacer software, es decir, como se hace hoy en el Siglo XXI, se podría resumir en:

Define un poco* de software a ser construido

↪ Construye lo poco anteriormente definido

↪ Entrega a los usuarios lo construido lo antes posible para validar si es lo requerido o no

*Entiéndase poco como la cantidad de requisitos suficientes para un mes de trabajo (o menos) de un equipo de desarrollo de software.

Cerrando

Si eres cliente o del área de negocio, cuando se están creando soluciones de alto valor para la organización que cuestan varios cientos de miles de dólares y que van a generar un impacto en la satisfacción, en la eficiencia o en el entorno, se requiere no solo involucramiento, sino compromiso.

Imagen generada con Dall-e (9)

Algunos consejos para ti, sí eres de negocio o Product Owner:

• Participa activamente en las sesiones del marco de trabajo
• Prioriza por valor el trabajo a realizar o Product Backlog
• Proporciona retroalimentación sobre el software funcionando
• Interactúa diariamente con el equipo
• Interactúa con tus usuarios y conócelos, valida sus expectativas y valida el uso de la aplicación una vez la comiencen a usar
• Si careces de tiempo para estar con el equipo solucionador, y quieres entregar los requerimientos y que otros lo construyan sin tu compromiso; la agilidad y el construir soluciones de software de alto valor y retorno no es lo que tu o tu organizacion están buscando; y con seguridad construirás software de desperdicio.

Si eres del equipo solucionador, de TI o desarrollador:

• Involucra y compromete al cliente
• Muéstrale el valor de participar con el equipo
• Enséñale a priorizar
• Garantiza a que comprenda el valor de las entregas tempranas
• Compártele experiencias de otras personas en la industria acerca de usar marcos ágiles
• Instrúyele como puede generar valor más rápido con menos alcance
• Convéncelo que en escenarios de incertidumbre su interacción diaria y continua es garantía de éxito.
• Demuestra progreso con software de valor funcionando en periodos de un mes o menos, con preferencia al periodo más corto.

Ahora, respecto a las traducciones del tercer principio del manifiesto, usa la que mejor se adapte a tu entorno.

Saludos ágiles,

Jorge Abad.

Nota de agradecimiento

Quisiera agradecer a mi gran amigo Lucho Salazar, pues al momento de  hacer traducciones me ha hecho mucho énfasis en la rigurosidad de la traducción y respetar la intención del autor, por ejemplo, en la actual Guía de Scrum 2020, en la cual soy uno de los colaboradores bajo la guía de Lucho, y allí hemos puesto mucho esfuerzo en que las palabras en inglés sean lo mismo que en español, al igual que las frases e intención de los autores, algunos de los retos interesantes estuvieron con:

• Openess, traducido como apertura normalmente, pero una traducción más fiel sería Franqueza
• Accountability: que significa responsable de que algo se haga, aunque no sea el ejecutor, pero en español no tiene traducción directa y quedó con la palabra de responsabilidad que significa lo mismo, sea que se delegue o no.

Comentarios, referencias y aclaraciones

1. Sí, es cierto, si estás haciendo cuentas, luego de firmado el manifiesto en el 2001 comencé a compartirlo en las clases de ingeniería de software y taller de ingeniería de software en la Universidad Eafit en Medellín www.eafit.edu.co 
2. Cotidiano, na: diario - dle.rae.es/cotidiano 
3. Comprehensive - https://www.oxfordlearnersdictionaries.com/definition/english/comprehensive_1?q=comprehensive
4. Esta frase se la escuché a mi gran amigo y agilista Hernán Wilkinson y resueno bastante con ella.
5. 
6. http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf  
7. https://es.wikipedia.org/wiki/VUCA
8. https://www.infoq.com/articles/contract-model-failure
9. Imagen generada con Dell-e https://labs.openai.com/s/ml4XX2e8frHQ8yc2sRidpG9u
10. Algunas imágenes de referencia

---

Desarrollo Ágil sin Frameworks (sin Scrum, ni XP)

Mi viaje como Agile Coach

Hola a todos,

Hace poco cuando compartía con un equipo de Scrum Masters, hablando sobre prácticas y métodos revisábamos la famosa imagen (1) en la cual se presentan los valores, principios, prácticas y frameworks,

Imagen adaptada de Ahamed Sidky

y que si la giras un poco, vas a ver los elementos visibles e invisibles de la cultura,

aquellos que consisten en "Hacer" y "Ser", y en nuestro contexto "Hacer Ágil" y "Ser Ágil".

En donde, todo viaje de transformación parte desde los elementos visibles hacia los invisibles, transformándonos de afuera hacia adentro,

o ¿Quién cambia por arte de magia? La verdad, desde mi punto de vista y experiencia, no creo en los cambios repentinos, creo en los procesos, todo cambio requiere un esfuerzo, un delta que me permita pasar de un estado A a un estado B, y parte de algo afuera que te lleva a mover cosas adentro.

Pero bueno, el punto acá es como ha sido mi jornada de cambio, recuerdo mucho a mis inicios en el mundo ágil me reencontré con un gran estudiante que tuve en la clase de Taller de Ingeniería de Software en Eafit, Jorge Luis Valderrama, recuerdo que estaba por Colombia, pues vivía en Londres, y en varias charlas suyas y conversaciones a la que asistí, hablaba siempre desde el Manifiesto Ágil - http://agilemanifesto.org/-, y recitaba sin titubear sus valores y principios, y ante cualquier duda buscaba que principios promovía o violaba aquello sobre lo que era cuestionado. Debido a esto, me animé a imprimir y pegar en frente mío, en mi escritorio de oficina los valores y principios del manifiesto ágil, y ante cualquier duda me remitía al manifiesto ágil, frase que repite constantemente mi gran amigo Juan Andrés Ochoa:

"Ante una duda en cómo actuar, remítase al Manifiesto Ágil" -Juan Andrés Ochoa

 

De esa manera, emprendí mi viaje desde los principios y valores, luego aprendí en orden Scrum, Nexus, el Modelo Spotify, Kanban, SAFe, LeSS, Scrum at Scale, Discipline Agile. No fue fácil esa jornada, recuerdo que me tomó al menos 6 meses dejar el micromanagement y hacer gestión de horas, para comenzar a confiar en los puntos de historia.

Y en ese viaje de ida, siempre la mentalidad ágil me ha acompañado, permitiéndome ser crítico y ver valor en prácticas tradicionales y flexibilizar mi mente y prácticas en procesos de transición organizacional que acompaño (les recomiendo leer Empático mas no Complaciente). Pero al toparme con SAFe y Kanban, observé que me faltaba algo, y era Lean (o el Modelo de Producción de Toyota escrito en términos occidentales). Comprendí que en mi jornada había olvidado las bases del mindset ágil, y comencé mi recorrido de regreso, centrándome en dos preguntas fundamentales: 

¿qué es el mindset ágil?

 ¿y qué rayos es lean?

En ese viaje de regreso, he tenido bastantes libros, charlas y conversaciones como compañeros, y recomiendo revisar detalladamente:

• El corazón de la agilidad, promovido por Alistair Cockburn (2)
• La Agilidad Moderna, promovido por Joshua Kerievsky (3)
• Lean (4)

 

El Corazón de la Agilidad (2)

Agilidad Moderna (3)

A este punto de la historia, he logrado sintetizar lo que es para mí el mindset Lean-Agile, la clave que desencadena la productividad, la felicidad y alto desempeño:

• Flujo
• Entrega de Valor
• Reflexión (Inspección y Adaptación)
• Colaboración
• Mejora Continua
• Eliminación de desperdicios

Pilares de la mentalidad Lean-Agile. Elaboración propia.

Al tuétano, al núcleo de este asunto que me apasiona y por el cual llegaste hasta este punto del artículo, lo comparto constantemente, lo considero fundamental, para poder desenvolverse en este mundo disruptivo y exigente; mis entrenamientos y conversaciones tienen un énfasis en el mindset lean-agile y cómo este funciona independiente del framework, marco, metodología o proceso y con esta perspectiva acompaño a equipos y organizaciones en su jornada de transformación.

Sé que no hay que dejar de hacer una cosa sin descuidar la otra, es decir, avanzar en el conocimiento de nuevas aproximaciones y marcos, pues hace parte de "estamos descubriendo formas mejores de"(5),  sin dejar el corazón, el corazón te permite moverte con propósito y libertad entre las diferentes interpretaciones, implementaciones o, más aún, desarrollar tu propia versión de la agilidad y de lean.

Yo no sé cómo será tu viaje, te he compartido el mío, con seguridad en tantos ires y venires nos terminaremos encontrando. Solo te quiero hacer tres preguntas:

¿En dónde estás en tu viaje hacia la agilidad, como Scrum Master, como Agile Coach, o como líder en tu organización?

¿Qué tanto conoces y dominas Lean?

¿Ves útil o inútiles artículos sobre mindset o atraen más los marcos complejos e hiperconectados con flechas?

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Imagen de Ahamed Sidky
2. Corazón de la Agilidad - https://heartofagile.com/
3. Agilidad Moderna (Modern Agile) - https://modernagile.org/
4. Lecturas recomendadas sobre lean
• Esto es Lean - https://www.amazon.com/-/es/Niklas-Modig-ebook/dp/B019E91600
• 2 second Lean - https://paulakers.net/books/2-second-lean
• Las claves del éxito de Toyota: 14 principios de gestión del fabricante más grande del mundo - https://www.amazon.com/-/es/Jeffrey-K-Liker-ebook/dp/B07XLFGTQB
5. Agile Manifesto - http://agilemanifesto.org/iso/es/manifesto.html

De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg

What’s the difference between Scrum and Agile?

Jeff Sutherland, Inventor and Co-Creator of Scrum

Answered March 30, 2020 · Author has 96 answers and 468.8k answer views

At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.

There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.

The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.

So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.

An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.

Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.

---

Traducción

En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.

El Manifiesto Ágil está pensado para todo el Ecosistema Software

Tomada de (1)

Hola a todos

Hace poco luego del Evento del Ágiles 2019  - http://agiles2019.agiles.org/ en Rosario Argentina, espectacular por cierto (felicitaciones a los organizadores, nos hizo falta más evento, más Rosario y más Argentina), reflexionaba sobre que aspectos contemplaba el "Manifiesto por el Desarrollo Ágil de Software", el cual es la base del movimiento ágil y los marcos ágiles que han transformado al mundo.

Luego de este evento surgieron críticas  sobre la cantidad de charlas que fueron técnicas y la cantidad de charlas que no lo fueron (cosa buena la crítica  nos cuestiona y nos hace evaluar otros puntos de vista), yo estuve allí y en efecto vi que se dieron charlas de un sabor y del otro, adicional que ninguna charla se prohíbe y existe total apertura que se hable sobre lo que es importante.

Se habló de todo lo que los asistentes quisieron hablar, adicionando que no todo hace parte de la agenda, hubo muchas conversaciones en las mesas, cenas, almuerzos, grupos de a pie, en fin.

Desde mi punto de vista se cumplió el lema “MUCHAS TRIBUS, UNA MISMA AGILIDAD”

Volvamos al Manifiesto

Pero veamos que dice el manifiesto y que pistas nos da para la comunidad ágil:

Tomado de: https://agilemanifesto.org/iso/es/manifesto.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Algunas palabras claves agrupadas del manifiesto, son las siguientes

• Conceptos claves
• Desarrollo de software
• Conversación cara a cara
• Cambio
• Ventaja Competitiva
• Trabajamos juntos
• Entorno
• Ritmo constante
• Excelencia técnica
• Buen diseño
• Simplicidad

• Artefactos
• Procesos
• Procesos ágiles
• Herramientas
• Software funcionando
• Documentación (extensiva)
• Plan
• Software de valor
• Negociación contractual
• Requisitos
• Proyecto
• Arquitecturas
• Diseños

• Roles
• Terceros
• Cliente
• Responsables de negocio
• Desarrolladores
• Equipo de desarrollo
• Promotores
• Equipos auto-organizados

De forma similar, según las referencias de como se firmó el manifiesto ágil publicadas por Alistar Cockburn .https://twitter.com/TotherAlistair, (ver imágenes a continuación), se observa que:

• Los principios 1 al 4, están inclinados a los clientes
• Los principios 5 al 8, están inclinados a los gerentes
• Los principios 9 al 12, están inclinados al equipo

Tomado de (2)

Tomado de (3)

Por lo tanto, el manifiesto se encuentra pensado en todo el ecosistema en el cual esta inmerso el desarrollo de software, no excluye a uno o a otros, invita a que trabajemos juntos de forma continua y sostenible y generemos software de valor.

No existe una preferencia, por unos y otros, se requiere de la mejor voluntad de todos los involucrados para generar resultados grandiosos.

Clientes-Gerentes-Desarrolladores nos necesitamos entre sí, y aunque existan aproximaciones Clientes-Desarrollaores, la gran cantidad de productos y proyectos del mundo requieren de gerentes, promotores para garantizar que unos y otros interactuen de forma coordinada.

Cerrando

Bienvenidos los eventos de agilidad, bienvenidas todas las personas y roles del ecosistema software, bienvenida la excelencia técnica, bienvenidos los desarrolladores, promotores, lideres, scrum masters, agile coaches, y hablemos sobre todo lo que nos interesa, duele y queremos mover y promover en el ecosistema


Nos vemos en Uruguay Agiles2020

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Más fotos e información de referencia en https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b
2. https://www.facebook.com/photo.php?fbid=10156214339079035&set=a.496846469034&type=3&theater
3. https://www.facebook.com/photo.php?fbid=10156214339084035&set=a.496846469034&type=3&theater