¿Qué prácticas técnicas podemos habilitar como Scrum Master?
Porque ya sabemos que Scrum no alcanza. Y porque hay muchas otras prácticas además de TDD — Test Driven Development
Hace años que me pregunto ‘¿Qué hacen los equipos que dicen hacer desarrollo de software ágil? ¿Cómo lo hacen? ¿Qué significa ‘desarrollo ágil?‘
Con esa curiosidad a flor de piel llegué a Grupo Esfera hace casi cinco años. Y descubrí muchas cosas:
- hacemos Scrum a nivel Dios (ahre),
- hablamos mucho con nuestros clientes y entre nosotros, de varias cosas, pero sobretodo de qué es lo deseado y qué es lo posible en el lugar donde estamos,
- somos transparentes hacia adentro y hacia afuera,
- buscamos la excelencia técnica,
- usando las prácticas de Extreme Programming…
‘Ah ok, entonces la agilidad técnica tiene que ver con Extreme Programming’, le dije a alguien en Grupo Esfera.
‘Si, esas prácticas son parte de un marco para desarrollar software… entre otros métodos que surgieron previos a la firma del Manifiesto Ágil y que luego le darán sustento, pero hay más, muchas más…”
Entonces acá, ya no se si hablamos de ‘prácticas técnicas ágiles’ o si hablamos de prácticas de ingeniería de software que hacen que tu software sea adaptable, flexible y llegue a tiempo a los usuarios. Porque en el fondo, eso queremos del software ágil:
- que pueda modificarse cuando cambian las prioridades,
- y cuando cambian los usos que le da el usuario,
- que llegue a tiempo, es decir que llegue al usuario cuándo el usuario lo quiere usar, cuando lo necesita.
En el Ágiles 2021, con Mariano, Seba, Code y Javi, hicimos una charla que se llamó ‘Prácticas técnicas for dummies: todo lo que siempre quisiste entender sobre las mil siglas, TDD, BDD, CI, DC…’ que intenta ser un compilado sencillo de las prácticas que valoramos en Grupo Esfera. Valoramos = usamos, practicamos, enseñamos, reflexionamos. Creo pertinente hacer la aclaración de que no las usamos siempre ni en todos los clientes porque ‘la herramienta depende del objetivo y del contexto en el que estamos’.
En el Ágiles 2022, sin mis compañeros técnicos, invité en el open space a una conversación sobre ‘¿Qué prácticas técnicas usan los equipos que hacen desarrollo de software ágil?’ Tuve el honor de que me acompañaran en la sesión Fede Zuppa y Carlos Peix, amigos y maestros de la comunidad ágil de Argentina.
Me llevé la grata sorpresa de que las personas que estaban en la sesión conocían la mayoría de las prácticas y qué hay entendimiento compartido sobre para qué se usan, en qué nos pueden ayudar.
Aquí les comparto el compilado que arme luego de esa conversación. Me tomé el atrevimiento de agregar otras prácticas que no salieron de esa charla y que tal vez no son técnicas 100% pero que conozco y ayudan a que nuestro software sea ágil:
Siguiendo con la sección, la pregunta que no pensaba hacer pero que espontáneamente me surgió fue: Si las conocemos, ¿por qué no las usamos? ¿No nos ayudarían a entregar software funcionando con más frecuencia?
Y acá voy a decir qué pienso yo porque el tiempo en la sesión no nos dió para más…si estás leyendo este artículo y te dan ganas de contribuir con tu opinión y hacer crecer esta lista, adelante! Hacelo en los comentarios.
¿Por qué no las aprendemos/implementamos en todos los equipos?
Falta tiempo: en general no hay tiempo para aprender ni para hacer las cosas con calidad y eso nos lleva al punto 2.
La tiranía del ‘entregar valor’: a veces pienso que en la agilidad cometimos un grave error al hablar de ‘entregar valor’. Nada más difuso que esta expresión que hay que definir en cada contexto: ¿qué es valioso para este cliente? ¿Y para aquel otro? En esas conversaciones, aprender, que hagamos software para aprender del contexto, para ‘ver qué pasa’ no está permitido. La importancia de algunas de estas prácticas sobretodo las que están más cerca del código o lejos del negocio, no es evidente, entonces es difícil sostenerlas, negociarlas frente a la tiranía de ‘entregar valor’
El requerimiento invisible, ‘… y todo lo demás sigue funcionando’: cito a Jessica Kerr en “Velocity defeats itself. Get acceleration instead”:
Hay un requerimiento invisible en toda nueva funcionalidad: ‘…y que todo siga funcionando.’ Cuantas más cosas nuestro software pueda hacer, más difícil es agregar o cambiar esas capacidades.
Que todo siga funcionando cuando cambiamos o agregamos cosas a lo que ya funciona, es el requerimiento invisible, del que no hablamos y a veces no tenemos en cuenta al estimar.
Requieren disciplina: no son las formas habituales en las que los equipos hacen software. Entonces, además de aprender a hacerlas, se requiere cierta disciplina y conciencia para sostenerlas hasta que se conviertan en ‘las formas habituales de hacer software’.
Algunas requieren acuerdos fuertes en los equipos. Esto quiere decir que todas las personas de ese equipo comparte la idea de que hacer de esta forma es mejor. Como creemos que, por ejemplo, es mejor hacer slicing que no hacerlo, nos comprometemos como equipo a dedicar tiempo y esfuerzo a practicar el slicing, aún las personas de negocio (en este caso específico del slicing que es una práctica técnica y funcional).
Las últimas dos, en contextos donde se hace uso de las ‘software factory’ como generadora de recursos no son posibles de sostenerse ni de proponerse siquiera por los niveles de rotación y de desapego hacia las personas y el producto.
¿Por qué estoy escribiendo y hablando de estas cosas si ni siquiera soy técnica?
Porque como Scrum Master veo los límites que tiene Scrum como marco de trabajo. Para hacer desarrollo ágil, software adaptable y que llegue a tiempo, no alcanza Scrum. Hay que meterse en la forma en la que los desarrolladores y desarrolladoras hacen, diseñan, piensan. Entonces, aprendí con el tiempo a matchear los problemas habituales que veo, con prácticas que completen a Scrum. No enseño todas estas prácticas porque no las hago, las recomiendo, las sugiero, las nombro… a veces ni siquiera puedo darme cuenta si en el contexto del equipo son fáciles o difíciles de hacer. Simplemente, las alumbro, entendiendo el problema frente al cual nos enfrentamos e invito a pensar por fuera de lo que les es habitual.
¿Cuáles de estas prácticas técnicas considero que debemos impulsar como Scrum Master?
- Test Automation por sobre cualquier otra práctica, como la más básica.
- Pair Programming por sobre Code Review. Inclusive Mob Programming.
- Slicing: divide y reinarás. Software suficiente por sobre el software ideal.
Entonces, Scrum Master del mundo, amigues, colegas, ¿qué necesitan ustedes para habilitar el desarrollo ágil en sus equipos?
¿Qué leer sobre estos temas?
- Blog de Jessica Kerr
- Blog de Nico Paez
- Construcción de software: una mirada ágil de Diego Fontdevila
- Desarrollo de software ágil en 10Pines de Fede Zuppa, específicamente el capítulo de prácticas técnicas escrito con la colaboración de Nico Paez.
- Artfull Making de Rob Austin y Lee Devin
- The art of agile development de James Shore
¿Cómo aprender de estos temas?
- Conversar con personas referentes
- El curso de Grupo Esfera sobre Prácticas Técnicas Ágiles que armamos con conocimiento, experiencia y amor, porque el amor mejora todas las cosas 🙂
Agradecimiento especial a las personas que me dieron feedback de este artículo y me ayudaron a mejorarlo: Rox Muñoz, Ettiane Salamanca, Hernán Paredes, Paz López, Code Raguet, Naty Lehmann, Fede Zuppa, Pablo Salvado, Maca Gonzalez, María Thompson, Martín Salías.
