Los retos de la agilidad en el Perú para el 2018

Pues si, se acaba el año y aunque no soy muy fan de estas revisiones y mirada hacia adelante que rodean estas fiestas, creo que en esta ocasión corresponde hacerlo a fin de reflexionar por donde estamos yendo como comunidad agilista, así que tratare de repasar lo que he visto en base a las interacciones en diversos entornos y encuentros… vamos a ello.

  • Interés creciente, ya ser ágil no esta siendo una curiosidad, sino una tendencia cada vez mas visible lo que ha hecho que las personas estén buscando cursos, las empresas buscando Scrum Masters y coaches..
  • Mucha conversación acerca de implementar/adoptar/etc la agilidad en grandes organizaciones, lo cual ha derivado en atención hacia los frameworks de escalamiento
  • La búsqueda externa de la piedra filosofal o como dice mi amigo Uzi “las empresas quieren un coach mágico y divertido” en lugar de promover el crecimiento interno
  • DevOps se ha vuelto la palabra de moda, debido a un legitimo interés en automatizar los despliegues, pero olvidando el factor cultural y de colaboración que involucra
  • Ganas por retomar la excelencia técnica como pilar de la agilidad
  • Mas dudas sobre los problemas en el día a día que sobre como implementar por primera vez
  • Profesionales que antes veían la agilidad como otra opción mas (equiparándola a cascada a veces) empiezan a preguntarse sobre ella
  • Grandes organizaciones están haciendo sus experimentos de innovación basándose en la agilidad y volviéndose referentes en el camino

Entonces, puede que Perú este llegando un poco tarde a la fiesta del crecimiento (si nos comparamos con nuestros amigos de Colombia, por ejemplo), por lo que toca plantearnos como comunidad como podemos contribuir hacia los cambios propuestos de la agilidad de la mejor manera, así que planteo unas ideas sueltas.

  • Tener siempre en mente que no hay recetas únicas, a algunos les puede ir mejor arrancando con Kanban a otros con Scrum o algún hibrido, pero debemos estar atentos a que lo que funciono en una organización u equipo puede no funcionar en otra, asíi que lo que toca es ir generando los contextos para que vaya surgiendo y recordar que “You can do better than the Spotify Model”.
  • Estar alertas con las implementaciones top-down impuestas que no involucren a los equipos y tomar todo con pinzas a pesar de la popularidad del framework propuesto, pues esta no es indicativo de calidad sino que puede ser resultado de búsqueda de algo que mantenga lo existente sin procurar realmente el cambio necesario.
  • Enfatizar la necesidad de una base técnica solida como pilar de la agilidad, se nos ha recordado mucho a los desarrolladores acerca del desarrollo de las habilidades blandas, pero por otro lado poco se hace para recordar a los Scrum Masters y coaches sobre la importancia del entendimiento del rol que juegan las decisiones técnicas en la buena marcha de un proceso de desarrollo de software, ya que como decía Hernan Wilkinson en el pasado Agiles 2017 “si solo hacemos Scrum y no mejoramos en la parte técnica vamos a seguir haciendo la misma porquería pero vamos a estar todos más felices“.
  • Estar alertas ante los vendedores de humo, y discernir entre quienes solo venden horas de consultoría y certificaciones, pero no se aplican el cuento a si mismos y quienes si efectivamente se involucran en lograr mejores resultados.
  • Recordar que DevOps va mas allá de automatizar y entregar de manera continua, que involucra mucho lo que es colaboración y cierto cambio cultural, a estar atentos cuando alguien empiece a hablar de DevOps vinculándolo a nube o a procesos de despliegue y no se mencione sobre la necesidad de colaboración dentro y entre los equipos. Personalmente siempre he creído que los profesionales de la tecnología vivimos permanentemente en un contexto de “Todos somos genios. Pero si juzgas a un pez por su habilidad de trepar árboles, vivirá toda su vida pensando que es un inútil” ya que se nos ha enfatizado en las mediciones basadas en nuestras habilidades blandas y hasta cierto punto en una extroversión que no tenemos, lo cual impide la valoración adecuada de muchos de nosotros; pero, dicho esto, creo firmemente que en el apoyo a enfoques DevOps se requiere tratar de tener el pie en ambos lados.
  • Ser más proactivos para entender y apoyar los contextos complicados, muchas de las reflexiones y propuestas que se vienen dando últimamente parten del marco supuesto en que toda la organización esta involucrada en una transformación técnica y cultural, pero poco se habla por ejemplo de como lograr hacer la transición hacia la agilidad (y mejorar el desempeño) en equipos que mantienen (y lo seguirán haciendo por un tiempo) aplicaciones legadas pues la respuesta no puede ser simplemente que se limpiara esa tecnología (ahí nos olvidamos del factor humano) sino procurar la forma de que estos equipos sumen al resultado final, o como trabajar lo más ágil posible con equipos en los cuales la permanencia de sus miembros está supeditada a contratos de tres o seis meses (renovables o no), o como ayudar a esa pequeña consultora que depende de entregar un presupuesto cerrado para un potencial contrato del cual depende su continuidad, ya que es muy fácil y cómodo desde una posición consolidada que se debe optar por otro tipo de clientes.
  • Evitar caer en el cargo-cult, si en un pasado se vio el dejar la línea técnica para irse a gestión (y llegar a ser Project Manager o similar) como una mejora de carrera profesional, ahora corremos el riesgo de caer en una variante de lo mismo al dar mucho énfasis en cómo ser o efectuar el rol de coaches y su importancia (o considerar que un Agile Coach es un Scrum Master junior), olvidándonos que lo realmente importa es el cambio y evolución de todos los integrantes de un equipo u organización.
  • Estar seguros de si lo que se está efectuando es efectivamente innovación o no.
  • Empezar a pasar de un enfoque basado en proyectos (y por ende en costos fijos) a uno basado en equipos que van construyendo productos que generan valor a la organización, esto tomara mas tiempo, pero es algo que debemos tener siempre presente.

Retos y alertas que hay que tener en mente para seguir en el camino emprendido… a estar en ello en este 2018 que esta por empezar.

 

 

“El reto del DevOps ágil” en el Ágiles 2014 de Medellín

Del 23 al 25 de Octubre tuve la oportunidad de estar en Medellin para el Ágiles 2014, fueron unos días bastante intensos, de reencuentro con amigos y sobre todo de aprendizaje, especialmente con keynotes de la talla de Tobias Mayer, Martin Alaimo y en particular Angel Medinilla que al fin (luego del intento frustrado de Lima) hemos podido tenerlo en el Ágiles con su charla “Unicornios, Krakens, equipos autoorganizados y otras bestias mitologicas“.

IMG_0728-2

Este Ágiles también me permitió presentar una charla que tenia planeada hace tiempo, “El reto del DevOps ágil”, tema que a pesar de estar de “moda” en realidad ha sido una necesidad dentro de las empresas, por lo que me alegro mucho el debate y feedback que se genero en la sesión, un aliciente para seguir impulsando el tema y romper las barreras tradicionalmente existentes entre Desarrollo y Operaciones.

IMG_1755

Mención especial merece la visita de Javier Garzas y su charla Verdades incomodas y mentiras reconfortantes… Que aprendí después de trabajar para 80 empresas software en la que nos recordo que sin calidad (y otros elementos que estamos olvidando) no se puede ser ágil.

En definitiva una gran experiencia, y ahora solo toca esperar que los amigos uruguayos nos sorprendan en el próximo Ágiles 2015 que se realizara en Montevideo.

_DSC0171