Etiqueta: agile

Mis notas de la conferencia Agile2023

Esta fue mi tercera participación en la conferencia Agile y al igual que en mis dos participaciones anteriores, también tuve la posibilidad de presentar una charla (ya hablé de ello en el post anterior).

Como es tendencia en todas las conferencias de Agile, la cantidad de charlas técnicas está en extinción. Mucho contenido de producto, transformaciones, chatgpt (¿¡!?) y curiosamente también muchas charlas de nivel inicial. Digo curiosamente porque a esta altura me resulta curioso que las charlas iniciales (agile essentials, como se las denominaba en la conferencia) hayan sido de las más concurridas.

De las charlas que asistí creo que las dos mejores fueron:

  • la de Jeff Patton, Shift: why it’s so hard to shift to a product mindset
  • la de Chris Edwards, Zero-Downtime Data migrations – Mastering Continuous Deployment

Otras que también me resultaron muy interesantes fueron

  • la de Nayan Hajratwala, Embrace these Three Fearsome Words: Test in Production
  • la Llewellyn Falco y Jay Bazuzi, Provable Refactoring – Safety without Tests
  • la de Jen Krieger, The developer-centric mindset will disrupt how all of us work
  • la de James Grenning y Jeff Langr, Your first test-driven development
  • la de Marisa Smith, Faster, Better, Stronger with Ephemeral Environments

En siguientes posts iré compartiendo detalles de algunas de estas charlas.

La organización como siempre, impecable, aunque me resultó raro y hasta inconveniente la duración de las charlas: en general los slots eran de 75 minutos. A mi me resultó bien (en parte porque tenia contenido para 2 horas más) pero en la mayoría de las charlas que participé sobró bastante tiempo. Una de las sesiones que participé sobraron literalmente ¡20 minutos!.

En lo personal tuve la oportunidad de compartir un par de días con colegas que no suelo ver: Hiro, Andrés y Martin que viven en Lima(Perú), Rosario(Arg) y Orlando(USA) respectivamente. Al margen de nosotros había unos cuantos colegas de Latam (al menos 15). También aproveché el viaje para hacerme de algunos libros: dos nuevos (The Joy of Agility y Wild West to Agile) y dos clásicos (Waltzing with Bears y Extreme Programming Explored).

Luego de haber participado en 3 ediciones creo que es una conferencia interesante, ofrece contenido variado y muchas oportunidades de networking. Al mismo tiempo participar puede resultar «bastante picante»: pasaje a USA, alojamiento y una entrada que ronda los $2.500. El «truco» es participar como speaker, ya que en ese caso la entrada está bonificada y alojamiento cubierto.

Cierro con una noticia: el año próximo la conferencia se realizará el Dallas, Texas.

Sobre la Guia Oficial de eXtreme Programming

En Scrum que existe una guía oficial que los autores mantienen actualizada. También existe una organización (en realidad creo que más de una pero la que conozco yo es la Scrum Alliance) que ofrece certificaciones de Scrum. En este sentido es razonable pensar que quien se acercó a Agile con Scrum, luego quiera acercarse a Extreme Programming (XP) y busque la guia oficial de XP.

Pero en XP no hay guía oficial, perdón si llegaron a este post buscando esa guía oficial. Al menos ahora saben que no existe :-). Tampoco existe una certificación oficial de XP, ni una XP Alliance.

En términos de publicaciones creo que los más cercano a una guía oficial es la serie de libros «XP Series» de la editorial Addison-Wesley publicada entre 1999 y 2005. En dicha serie se incluye el libro fundacional de XP escrito por Beck: «Extreme Programming Explained, Embrace chance» que a mi parece no es el mejor libro de la serie. No leí todos los libros de la serie en parte porque no pude conseguirlos, varios de ellos están discontinuados, de hecho algunos los conseguí usados. Dos libros que me parecieron excelentes fueron «Planning Extreme Programming» de Beck y Fowler y «Extreme Programming Installed» de Jeffries, Anderson y Hendrickson.

Por otro lado, un libro que a simple vista no parece de XP pero que definitivamente lo es, es el libro de James Shore «The Art of Agile Development«. La segunda edición, publicada en 2021, creo que es una descripción muy acertada de lo que podría considerarse un «XP Moderno».

En lo personal, creo que cada vez tiene menos sentido hablar de «métodos/marcos/metodologías» de desarrollo de software. Podemos debatir valores, principios, mindsets y luego bajar a prácticas concretas en las que materialicemos esos valores pero no necesitamos un rótulo para eso. Creo que las combinaciones pre-armadas de «valores + principios + prácticas» empaquetadas bajo un rótulo pueden agregar valor para un equipo/organización que recién empieza, pero a medida que conformamos grupos de trabajo más estables los «combos» agregan cada vez menos valor por el simple hecho de que el grupo de trabajo se convierte en un equipo y empieza a generar sus propias prácticas.

Meetup: Recorrida de Prácticas Técnicas para Gente no Técnica

La semana próxima, miércoles 19 a las 8:15 AM, estaré dando esta charla gratuita orientada a aquellas personas que trabajan con equipos de desarrollo de software pero que no tienen un perfil técnico. En la charla repasaremos la terminología y prácticas técnicas de uso habitual en equipos de desarrollo en la actualidad al mismo tiempo que haré una demostración en vivo del desarrollo y despliegue en la nube de una funcionalidad.

Los interesadxs en participar pueden registrase en el Meetup de Agiles Argentina para recibir el link de acceso.

Esta charla es la versión en castellano de la que estaré dando a fin de mes en la conferencia Agile 2023.

Charla Aceptada: Recorrida de prácticas técnicas para gente no téncnica

Desde el año pasado vengo trabajando en intentar transmitir la importancia de ciertas prácticas técnicas fundamentales para la entrega continua a aquellos que se encuentran trabajando con equipos de desarrollo de software y que no tienen un background técnico. En este sentido el año pasado diseñe un curso que ya he dictado dos veces y del cual ya tengo agendada una tercera edición.

En la misma línea del curso, envié una propuesta de charla a la conferencia internacional de Agile de la Agile Alliance. La propuesta fue aceptada y mi charla «Technical Practices Walkthrough for Non-technical People» está agendada para el jueves 27 de Julio a las 15:45. Para aquellos que asistan al evento nos vemos en Orlando y para los que no, tengo pensado hacer un Meet-up online en castellano para la comunidad hispano-parlante. Aún no tengo definida fecha ni plataforma, pero en cuanto la tenga lo publicaré aquí.

Resultado de la segunda edición del curso de Prácticas Técnicas para Scrum Masters

Hace un par de semanas completé el dictado de la segunda edición de este curso. Quedé muy conforme con los ajustes realizados luego de la primera edición y considero que el formato utilizado será el mismo en la siguiente edición: 5 encuentros de 2 horas cada uno.

En esta segundo edición, además de agregar un quinto encuentro, también agregué varias actividades para sumar así un total de 20 actividades extra clase. Según reportaron los mismos participantes, la dedicación promedio semanal fue de 3 horas lo cual hace que la dedicación total del curso ascienda a 25 horas (10 horas de encuentros online y 15 horas de actividades extra clase).

La evaluación del taller por parte de los participantes fue muy positiva.

Sin duda que hay algunas cuestiones que mejorar pero en términos generales estoy muy conforme y contento con el resultado. Comparto algunas frases que los participantes dejaron en el formulario de feedback:

«Me encantó el curso, me fue de mucha utilidad para comprender conceptos de los cuales no tenía conocimiento y que me permiten comunicarme mejor con los equipos a los que acompaño«

«Me gusto mucho el curso, la parte de devops fue la más esclarecedora junto con el mapa de las formas de quebrar o realizar slicing de una Historia de Usuario, fue excelente.«

Para aquellos interesad@s en participar de la próxima, ya tenemos fecha y está abierta la inscripción, pueden ver más info aquí.

Recomendaciones para el mapeo de ejemplos

La semana pasada publiqué una traducción del artículo original de Example Mapping. Hoy quiero ir un paso más allá y compartir algunas recomendaciones surgidas de mi experiencia utilizando esta técnica.

Escenarios multi-regla

Cada historia de usuario tiene típicamente varias reglas asociadas que deben cumplirse simultáneamente. Sin embargo la técnica de mapeo de ejemplos propone que cada ejemplo esté centrado en una regla en particular, «ignorando» el resto de las reglas. La idea de esto es enfocarnos en entender cada una de las reglas y tener ejemplos bien concretos. En lo personal, me ha pasado de trabajar en aplicaciones con cierto grado de complejidad donde puede resultar muy útil generar ejemplos adicionales para ejemplificar la combinación de reglas. No siempre genero estos «escenarios de combinación» pero cuando lo hago procuro hacerlo en segunda instancia, o sea: comienzo trabajando en escenarios «de una regla» y luego recién después de terminar con ellos, trabajo los escenarios «multi-regla».

Escenarios encubiertos

Si al identificar los escenarios tenemos uno con un «o», puede ser un indicio de que en realidad tenemos 2 escenarios distintos. Por ejemplo si en una funcionalidad de pago con tarjeta de crédito tengo un escenario «aquel donde mi tarjeta está bloqueada o sin saldo», es posible que resulte más conveniente tener un escenario para tarjeta bloqueado y otro aparte para tarjeta sin saldo.

Plantilla online

Si bien ante la posibilidad de elegir prefiero que las sesiones de mapeo de ejemplos sean presenciales, en muchas ocasiones me encuentro haciéndolas online y para esos casos suelo usar esta planilla de Google Docs.

Alternativas a la tarjetas de colores

Al hacer las sesiones presenciales en ocasiones he tenido dificultades para conseguir tarjetas bibliográficas de colores y he tenido que buscar alternativas.

Una alternativa es hacer la sesión en forma presencial pero digital, o sea, tomamos la una computadora, la conectamos a un proyector y trabajamos con la plantilla que mencioné previamente. Pero en lo personal, si estamos físicamente juntos prefiero utilizar papel.

Una alternativa obvia es usar post-its, pero me he encontrado que el pegamento me genera cierta incomodidad pues me gusta poder ir reacomodando los escenarios a medida que los vamos trabajando. Por esto es que prefiero utilizar simplemente papeles de colores, tipo post-its pero sin pegamento. Esto va muy bien pues los puedo mover con total libertar, aunque al ser más livianos que las tarjetas y no tener pegamento, son mucho más volátiles y cualquier brisa leve los hace volar.

Sobre el curso de Prácticas Técnicas para Scrum Masters

La semana pasada completé la primera edición de este curso que pensamos junto @martinalaimo. Estoy muy contento con cómo salió considerando que fue la primera edición.

Fueron 4 encuentros online y sincrónicos a todo ritmo con un grupo de 20 participantes muy motivados. Si bien los encuentros tuvieron bastante interacción, me quedó gusto a poco con las interacción offline, me hubiera gustado ver más participación en los foros :-(.

Hablamos de facilitación de estimaciones, modelos de branching, integración continua, test automation y devops.

El feedback de los participantes fue muy positivo y todos coincidieron en que el curso debería haber tenido más encuentros para poder profundizar mas en algunas cuestiones, cosa con la que estoy completamente de acuerdo. Agradezco a todos los participantes por haberse sumado al curso y haber sido en cierto modo «conejillos de india» de este nuevo curso.

Ya tengo en mente varias mejoras para la siguiente edición incluyendo el hecho de extender la duración (posiblemente sean 5 o 6 encuentros) y agregar algunas demostraciones «ejecutables» de pipelines y pruebas automatizadas. Aún no hemos puesto fecha para la siguiente edición pero seguramente tengamos una fecha para el primer trimestre de 2023.

Finalmente quiero agradecer a Martin Alaimo por haberme alentado en esta iniciativa y al equipo de AlaimoLabs por el soporte y la logística del curso.

Prácticas técnicas para Scrum Masters

Desde 2006 vengo trabajando con equipos desarrollo que intentan trabajar en una dinámica «tipo Scrum». Sin embargo son contadas con los dedos de una mano las ocasiones que he trabajado con un Scrum Master que aporte valor al equipo desarrollo más allá de los rituales estrictos de Scrum. Lo que ocurre es que a medida que el equipo va ganando experiencia en Scrum el aporte del Scrum Master se va diluyendo si el Scrum Master se limita a aportar estrictamente desde Scrum.

Sin embargo, los equipos de desarrollo afrontan diversos desafíos que van más allá de las reglas de Scrum y de las cuestiones de programación. Muchos de esos desafíos representan oportunidades para que un Scrum Master agregue valor al equipo. Pero para eso es necesario que el Scrum Master se familiarice con algunas cuestiones de indole técnica que típicamente no forman parte del camino de formación de un Scrum Master. A esto se suma una situación cada vez más habitual: gente desempeñándose en rol de Scrum Master que no viene del mundo IT. No resulta extraño hoy en día encontrarse con equipos de desarrollo cuyo rol de Scrum Master es ocupado por una persona con formación en psicología, arte, marketing o ciencias sociales.

Es por esto que hace un tiempo, junto a Martín Alaimo, comencé a trabajar en el diseño de un entrenamiento para Scrum Masters de cara a ayudarlos adquirir conocimientos y habilidades para poder sumar valor a sus equipos de desarrollo más allá de lo que propone Scrum.

El curso está pensado para personas en el rol de Scrum Master (o facilitador de equipo en términos más generales). No es necesario tener formación el IT/programación pero sí es necesario tener experiencia de campo trabajando con un equipo de desarrollo.

El curso será en modalidad online, con 4 encuentros en vivo (uno por semana) y varias actividades semanales a lo largo de las 4 semanas del curso. Pueden encontrar más información aquí.

A tale of Slicing and Imagination

Este es el título de la charla que voy a estar dando en el contexto de la conferencia XP 2021 el 17 de Junio a las 14:00 (GMT-3). La charla está basada en un artículo que escribí a modo de reporte de experiencia con la colaboración de Rebecca Wirfs-Brock y que será publicado en el sitio de la Agile Alliance.

El punto central de la experiencia que voy a contar pasa por la estrategia de slicing que utilizamos en un proyecto en el que participé el año pasado. Dicha estrategia fue central para poder entregar incrementos de valor de forma continua. Al mismo tiempo la estrategia de slicing requirió del uso conjunto de otras técnicas como continuous delivery, feature toggles y una arquitectura de «micro-apps».

Esta conferencia es una de las conferencias que más me gusta porque tiene la particularidad de combinar trabajos formales/académicos con experiencias de industria. Los interesados en participar pueden aprovechar la registración temprana que está habilitada hasta el 31 de mayo.

Actualización: ya está publicado en el sitio de la Agile Alliance el artículo que dio origen a la charla.

Todos son ágiles, pero no todos son felices

Los métodos ágiles surgieron en los 90′ y su «nacimiento formal» se ubica usualmente en 2001 con la firma del manifiesto.

Hacia 2010 Forrester ya decretaba Agile como mainstream.

Hoy, 2021, creo que «todos son ágiles» o al menos dicen serlo. Claro está que del dicho al hecho hay un gran trecho.

En los años que llevo trabajando como facilitador he visto situaciones de las más variadas respecto de la adopción de Agile a nivel equipos de desarrollo pero que en términos muy simplificados podrían clasificarse en dos grandes grupos: 1) Equipos que llegan a agile desde «el desorden» y 2) Equipos que llegan a agile desde un proceso definido, no-agile, generalmente controlado, secuencial o «iterativo «laxoo»(iteraciones de duración variable, típicamente no time-boxes, etc.)

En el caso de los equipos que provienen del desorden, generalmente optan por agile (y particulamente por Scrum) sin mayor cuestionamiento. Como que simplemente siguen al rebaño. Esto obviamente trae sus riesgos ya que en más de un caso los equipos no cuentan con los requisitos mínimos para aplicar agile de forma eficaz (usuario/PO muy involucrado, developers capaces de auto-organizarse, etc). Según he visto, en muchos casos esto resulta en equipos que dicen practicar agile pero que en la práctica terminando haciendo ScrumBut y/o Flaccid Scrum. Obviamente esto les impide alcanzar todos los beneficios que generalmente se esperan de un equipo usando agile, pero a pesar de eso puede que el equipo termine trabajando de una forma mejor que lo era su situación previa trabajando en el total desorden.

El caso de los equipos que llegan a agile desde un proceso no-agile pero definido, controlado y generalmente secuencial es menos frecuente en mi experiencia. En los casos de este tipo con los que me he cruzado mi sensación es que logran una implementación más sólida de agile, ya que generalmente cuentan con cierto orden y capacidades que les permiten gradualmente incorporar distintas prácticas de agile.

Esta situación de que «todos son ágiles» me ha llevado personalmente a intentar evitar el término agile para definir una forma de trabajo. En general prefiero hablar en términos de prácticas pues me parece que resulta mucho más concretro que hablar de «Agile en abstracto» o «Scrum by the book».

Desde hace ya un par de años me hace más sentido hablar de prácticas y performance de delivery que de Agile o Scrum. En este sentido me resulta mucho más significativo que un equipo me diga que su lead time es de 1 semana a que me diga que hace Scrum.

En fin, resumiendo: hoy en día todos dicen ser Agiles, pero en la práctica no todos lo son en verdad. Muchos practican agile con un grado tal de ineficacia que su «agilidad» bien podría debatirse. Esto me lleva a reforzar el fondo de la cuestión (al menos desde mi perspectiva): la cuestión no es si agile o no, la cuestión es cuan buenos(y felices) somos entregando valor independientemente de la forma en que lo hagamos. Personalmente hoy creo que para muchos contextos tiene más sentido analizar la entrega de valor desde un perspectiva Lean que desde una perspectiva Agile.

Nota: Lean y Agile no son lo mismo, son dos marcos diferentes, con mucha afinidad, pero distintos. Diferencias y similitudes de estos marcos serán tema de otro artículo.