Agile, leche de almendras y negocios

Hace un tiempo (unos 2 o 3 años), en el contexto de una de las Jornadas Ágiles Latinoamericanas se creo un grupo de Telegram para coordinar actividades y compartir recursos/inquietudes/etc.  En ese grupo hubo en estos días un hilo de discusión muy interesante sobre la evolución de Agile, el uso del término Agile, etc, etc. La discusión me resultó muy interesante y por ello quiero compartir algunas de las reflexiones y argumentos que vi pasar. Aclaro que voy a copiar textualmente varios mensajes incluso cuando no estoy de acuerdo con algunos de ellos.

El tema comenzó de la siguiente forma:

A: En muchas partes he visto “Agilidad Impuesta”, es decir por mandato. ¿Cómo llamarían al caso contrario?

(varias respuestas de distintas personas)

P: … Y si la llamamos “Agilidad” y listo? lo otro es “cómo intentar que equipos que no tienen ganas, usen Agilidad”. Esa Agilidad la Agilidad forzada/impuesta? … mepa que no.

A: El mercado y las mega consultoras ya ensuciaron el término

A partir de aquí la discusión transcurrió sobre el uso del término Agile/Agilidad y los usos del mismo y yo agregué mi opinión:

N: “Agile manifesto for Software Developement”, entonces si queres utilizar agilidad fuera del desarrollo del software => buscate otro nombre“.

Algunos colegas manifestaron su acuerdo con mi visión y agregaron:

U: “Si cambias el texto del manifiesto y le pones otras palabras para tu conveniencia o rama ponle otro nombre y no lo llames Agile, porque eso ya es otra cosa

Esto me resonó con una situación que he visto recientemente en otro ámbito. Resulta que en Argentina, hace un tiempo se empezó a popularizar la “leche de almendras”. La primera vez que escuché el término me llamó mucho la atención pues en mi concepción la leche sale de una teta. De hecho la definición de wikipedia indica que es una secreción nutritiva producida por las celulas secretoras de las glándulas mamarias.  Dicho esto, lo que sale de una almendra no es leche. Este mismo fenómeno se repite con “la hamburguesa de soja” y el “alfajor de arroz”. Para mi todos estos casos son claros ejemplos de publicidad engañosa, se utiliza el nombre de un producto fuerte establecido en el mercado para vender algo distinto.

Volviendo a la conversación de telegram, con el correr de los minutos/horas la charla fue pasando por distintos temas y gradualmente subiendo el énfasis de las opiniones. Se hablo de “agile coaches” y diversas interpretaciones del manifiesto ágil. Un  comentario que me resultó muy razonable y me parece puede ayudar a zanjar algunas de las diferencias del debate:

G: “…Últimamente me suma valor diferenciar “Agile” de “agility”. El primer término lo veo con mucha carga (ni buena, ni mala) de sus orígenes (software development). El segundo lo veo expresado en nuevos conceptos: organizational agility, business agility, enterprise agility.

Otro mensaje que me resonó fuerte fue:

J: “…nos (hablando de los developers) estamos alejando de todo lo que tenga Agile como título y nos acercamos más a grupos como el Socrates..

Un mensaje que me resultó muy en línea con mi realidad fue:

O: “El punto es, que como consecuencia de la expansión, hacer agilidad ya no es una manera de hacer mejor software… cada vez se comparte menos al respecto, entonces es mejor buscar otros espacios

En un momento de la discusión compartí dos artículos escritos por firmantes del manifiesto ágil que a mi parecer están muy relacionados con el tema en cuestión:

Para cerrar este artículo comparto mi parecer:

  • El origen de “agile” es El manifiesto ágil para el desarrollo de software
  • La propuesta tuvo cierto éxito, se hizo mainstream y con ello aparecieron innumerables oportunidades de negocio (empezando por certificaciones, cursos y servicios de consultoría). Con las oportunidades de negocio aparecieron personas/organizaciones más interesadas por el negocio que por el desarrollo ágil de software. Al mismo tiempo el mainstream hizo que algunos tomen “agile” y lo intenten llevar a otros contextos. (nobleza obliga: yo soy parte de este negocio también)
  • Todo bien con utilizar “agile” en N contextos distintos, pero me gustaría que utilizara otro término para evitar confusiones (¿agility?). Todo bien con la leche de almendras, pero no le llamen leche, es engañoso, mete ruido y genera falsas expectativas.
  • Como consecuencia de los negocios, aparecen servicios brindados por organizaciones/individuos que no siempre tienen la preparación suficiente.
  • Como consecuencia de estas organizaciones/individuos no suficientemente preparados y de este uso de “agile” fuera del software, la parte del manifiesto ágil que busca asegurar la excelencia técnica del software queda marginada/olvidada.
  • También como consecuencia del negocio y del “agile no software” empezamos a ver “coaches/facilitadores/consultores” hablando de agile sin mucha idea de desarrollo de software, trabajando con equipos de software y haciendo software de baja calidad.
  • Las reuniones/eventos de agile se ven invadidos por cuestiones no relacionadas al software y eso hace que quienes nos dedicamos a desarrollar software perdamos interés por esas reuniones/eventos.
    (varias de estas ideas  ya las había vertido en mi capítulo del libro Ensayos Ágiles)

Continuará…

Cuestión: Duración de la iteración

Una de las decisiones que debe tomar un equipo que decide trabajar en forma iterativa es la duración de sus iteraciones. Según nuestro estudio de prácticas ágiles en la comunidad latinoamericana, el 74% de los encuestados reportó trabajar con iteraciones de 2 semanas.

Yo personalmente me siento más cómodo trabajando con iteraciones de 1 semana, pues eso lleva a una agenda más uniforme cosa que me sienta más cómodo:  se que el mismo día todas las semanas tengo reuniones de planificación, revisión y retrospectiva.

Sin embargo, en varios de los últimos proyectos que he trabajado hemos utilizado iteraciones de 2 semanas pues tanto el cliente como la mayoría de los miembros del equipo así lo preferían. En estos casos logramos cierta uniformidad semanal estableciendo un día recurrente para las reuniones: en la semana 1 hacíamos review/retro/planning y la semana 2 usábamos ese mismo espacio horario para hacer refinamiento y mid-sprint-demo.

Materiales de Extreme Programming Moderno

El lunes pasado estuve en Santiago de Chile y participé en un meetup organizado conjuntamente por la gente de Chile Ágil y Software Crafters Chile. En ese contexto estuve hablando de Extreme Programming Moderno. Comparto aquí algunos recursos que mencioné:

Agradezco a Loreto Arriagada y David Lay por haberse encargado de la organización.

My summary of Agile 2018

In my  opinion the best part of  the conference was what happen outside the sessions: informal talks with old and new colleagues.  Beyond that, I really enjoy some of the sessions.

  • I liked the keynote session by Troy Magennis about Agile Data (video here)
  • The session “Database DevOps: Strategies to Address DevOpsLast Mile” by Scott Ambler was really interesting (slides here)
  • One of the most interesting sessions for me was  “Building evolutionary cloud infrastructure“, it presented a really useful model (slides here). Beyond the slides some of the content of the session is available in the website infrastructure-as-code.com
  • The Impact Mapping workshop delivered by John Hughes and Rachet Whitt allowed me to practice this technique for the first time and I think I will include it in software engineering course.
  • The session “Stepping Stones in Refactoring to Microservices” delivered by Amr Noaman (slides here) provided a interesting but controversial method to move to microservices

There were some other sessions that I couldn’t attend and that received very good feedback from my collegues:

  • Agile Quantified (Measuring the impact of Agility) by Larry Maccherone (no slides available)
  • The 12-factor pipeline by Juni Mukherjee (slides here)

Finally, I am very happy with the session I delivered: “Principles of Self-Service Infrastructure“, it was recorded so I will shared the video as soon as the organization publishes it.

 

 

Agile Disciplinado, ¿curioso u obvio?

Agile Disciplinado (Disciplined Agile) es el nombre del enfoque/marco ágil propuesto por Scott Ambler. La primera vez que escuche este nombre me hizo reflexionar:

  • Por un lado me gustó, porque me gusta el trabajo disciplinado y al mismo tiempo porque creo que si bien en general los métodos ágiles tienen pocas reglas, seguirlas suele requerir de bastante disciplina*.
  • Por otro lado me pareció muy apropiado, ya que en ciertos ambientes hay una percepción de que los métodos ágiles son “medio hippies” o “poco serios” (para algunos armar un plan de proyecto pegando post-it en una pared resulta nada serio).  Dado este contexto, decir “Agile Disciplinado” suena a decir “esto es agile, pero de verdad, no somos hippies”.

Esta sensación inicial me llevó a indagar un poco más sobre este enfoque y para ello decidí leer el libro de referencia. El enfoque está planteado en forma integral desde una perspectiva general de la organización (en este sentido el enfoque de Agile Disciplinado se presenta como una alternativa más en el contexto de los métodos de transformación agile).  El enfoque hace mención explícita a temas organizacionales y técnicos incluyendo: diseño de arquitectura, control de configuración y calidad entre otros, todo con una visión Lean/DevOps.

*comparados con métodos orientados al plan como UP, la cantidad de reglas propuestas por los métodos ágiles es muy menor

Gestión de ambientes y Diseño de Infraestructura para DevOps

EL próximo Jueves 26 estaré dando una charla abierta sobre esta temática:

El manejo de ambientes de desarrollo y tests es un tema relevante a la hora de intentar optimizar el flujo de valor de todo proyecto de desarrollo de software. En este contexto la práctica de Self-Service Infrastructure puede ayudar a una organización a simplificar el manejo de estos ambientes, dando más libertad a sus equipos de desarrollo sin sacrificar estabilidad. En esta charla veremos los principios, beneficios y desafíos de esta práctica, junto con algunos patrones y herramientas para su implementación. Entre otras cuestiones hablaremos de modelos de infraestructura, continuous delivery, infraestructura como código y chatops.

La cita es este Jueves 26 a las 19.00 hs en Facultad de Ingeniería de la UBA (Paseo Colón 850), aula 319. Interesados por favor registrarse en este Meetup.

Agile por Kilo

El año pasado me contactó un directivo de una empresa multinacional que estaba interesado en empezar a trabajar con métodos ágiles. Me reuní con él para entender su necesidad. Una vez comenzada la reunión le pregunté sobre la motivación que lo llevaba a los métodos ágiles, o sea, yo quería entender qué problema se esperaba resolver o que situación se esperaba mejorar a partir del uso de métodos ágiles. La respuesta fue muy concreta: a nivel global la organización había decidido adoptar una “forma de trabajo ágil combinada con DevOps” y por ello este directivo quería contratar a la brevedad 5 coaches/scrum masters para generar un “shock de agilidad” que se tradujera en una mejora notable de productividad. De esta forma esperaba contagiar al resto de los equipos de la subsidiaria local para que se subieran “al tren ágil”. Esta estrategia distaba mucho de lo que yo hubiera hecho y en un punto hasta podría considerársela “anti-ágil”. En enfoque ágil implicaría crecimiento orgánico y sustentable lo cual es muy distinto a “un shock”. En vano intenté convencerlo de utilizar un enfoque distinto y la cuestión no pasó de esa reunión.

Estos son los tiempos que vivimos. Del mismo modo que hay organizaciones que desde hace años pretenden “comprar programador por kilo” hoy en día, con agile siendo mainstream, hay organizaciones que pretenden “comprar agile coaches por kilo”.

Pero en cierto modo creo que lo más triste no es la intención de los que quieren comprar, sino que hay organizaciones dispuestas a satisfacer esos pedidos :-(.

Ya lo decía mi abuela: la culpa no es del chancho sino de quien le da de comer 😦