domingo, noviembre 27, 2022

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. https://es.wikipedia.org/wiki/VUCA
  6. https://www.infoq.com/articles/contract-model-failure
  7. Imagen generada con Dell-e https://labs.openai.com/s/ml4XX2e8frHQ8yc2sRidpG9u
  8. Algunas imágenes de referencia
---

sábado, noviembre 05, 2022

Manual para Remar en Arequipe (Dulce de Leche) o Cómo ser Agile Coach (o Scrum Master) en Entornos Adversos a la Agilidad

 

Hombre remando en Arequipe -Creada con DALL-E (1)
Hola a todos,

Con frecuencia al hablar con Agile Coaches y Scrum Masters les digo que muchas veces nos encontramos en una organización en la que estamos 

¡Remando en arequipe! (2)

 o 

¡Remando en dulce de leche! (2)

haciendo referencia a que no es fácil el entorno en el que nos encontramos, y buscando generar cambios. Lo cierto, es que no es una buena noticia, pero ¡Para eso estamos!¡Para eso nos contrataron! Si fuera sencillo no estaríamos allí. para ayudar a las personas, equipos y organizaciones a reformular sus paradigmas y a encontrar formas mejores de interactuar y generar valor.

La resistencia al cambio es natural, no nos gusta cambiar, preferimos la inercia del estado en el que nos encontremos, la zona de confort o el statu quo; y si se quiere generar un cambio habrá que vencer dos fuerzas:

  • hacer un Δ (delta) de esfuerzo para cambiar de estado, es decir, salir de la zona de confort y
  • vencer el miedo a la incertidumbre de si ese nuevo estado es mejor que el actual o no.
Adicionalmente, está apareciendo otra fuerza para aquellos que estamos trabajando con la agilidad:
  • ya hemos estado ahí y no nos gustó (3)
Esta última se puede leer como: no supimos cómo avanzar o no nos acompañaron bien. Todo lo anterior se puede ver ilustrado en el siguiente análisis de campo de fuerzas de Kurt Lewin:

Cómo entonces generar el cambio

No hay una fórmula secreta para lograrlo, al leer sobre gestión del cambio y experimentar muchos modelos, voy a compartirte algunas estrategias que han servido:
  1. Identifica si existe alguna métrica, indicador, OKR, KPI, evaluación de desempeño en la que se puede incluir el propósito que quieres lograr. Es una de las más efectivas pues, hay una máxima de la gestión "Cómo me midas me comporto" (4) y esto ayudará en el propósito buscado. Bajo esta premisa, encuentra una buena métrica que ayude a generar los comportamientos adecuados, lo contrario, es peligroso.
  2. Usa el Método Kanban (5), pues este tiene un lema: "EMPIEZA CON LO QUE HACES AHORA" (el cual es cierto) y poco a poco introduce el método - te sugiero revisar con calma la referencia (5) en la zona de recursos y la 6)-.


  3. Aplica Agilidad Orgánica o Scrum Orgánico, es decir, invita a hacer retrospectivas máximo cada mes y ve introduciendo prácticas que el equipo vaya necesitando - ver referencia (7)-.
  4. Use el lenguaje tradicional para fuera del equipo, pero al interior use la agilidad - ver referencia (8) - 


  5. Logra que tu proyecto reporte resultados a quienes te contrataron, de forma que puedas informar avance, impedimentos o riesgos según se vayan presentando.
  6. Un último consejo, ponte en los zapatos de ellos, se Empático mas no Complaciente(9), y pregúntate:
    • ¿Por qué actúan de esa manera? ¿Qué les impide ayudar?
    • ¿Cómo son medidos?
    • ¿Qué sucede si acontece el cambio con los cargos de ellos?
    • ¿Tienen el conocimiento necesario?
    • ¿Cómo puedo ayudar desde mi experiencia aumentar el grado de consciencia respecto a la agilidad?
    • entre muchas otras.
  7. Declarar experimentos y buscar como implementarlos en la organización por tiempo corto. Lean Change Management es una buena opción para hacerlo:





Lo cierto, es que no hay una sola estrategia para motivar el cambio o generarlo. Es valioso que como agente de cambio estés monitoreando el entorno, tomando métricas, comparando versus líneas base e identificando efectivamente si la organización desea avanzar hacia la dirección deseada, en caso de que sí, persevera, en caso de que por un tiempo prudente (y ese solo lo sabes tu) observas que efectivamente no desea el cambio, entonces busca otra oportunidad en otra organización o equipo., 


Saludos ágiles,

Jorge Abad.


Referencias 

  1. Imagen creada en DALL-E https://labs.openai.com/s/MFYbemXGsB7HnPDnQfuZSZvD
  2. En Colombia el dulce de leche es conocido como arequipe.
  3. La Agilidad ha Muerto, ¡Larga Vida a la Agilidad!  http://www.lecciones-aprendidas.info/2022/05/la-agilidad-ha-muerto-larga-vida-a-la-agilidad.html
  4. Cómo me midas me comporto:  http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
  5. Método Kanban - https://kanban.university/
  6. Infográfico del método kanban:
  7. Unas notas sobre Scrum Orgánico / Agilidad Orgánica - http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html
  8. Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales - http://www.lecciones-aprendidas.info/2019/09/como-evitar-la-ingenuidad-agil.html
  9. Reflexión: Empático mas no complaciente - http://www.lecciones-aprendidas.info/2020/03/reflexion-empatico-mas-no-complaciente.html

jueves, noviembre 03, 2022

Video: Agilidad en las organizaciones y en HR (talento humano)

Hola a todos,

Les comparto esta interesante conversación con Juan David Botero CEO de Talento Cloud, sobre agilidad organizacional y agilidad en las áreas de talento humano conocida también como Agile HR.

Pueden acceder al video en el siguiente enlace: https://youtu.be/yDnvgryvBtc