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.

 

 

Otro gran reencuentro: Ágiles 2015 en Montevideo

Con algo de retraso y con la emoción y entusiasmo aun en mi, repaso estos tres días en que los agilistas latinoamericanos nos reunimos en Montevideo, Uruguay para celebrar el Ágiles 2015, esta fue mi tercera participación en el evento y fue bueno reencontrarse con los amigos, conocer nueva gente y sobre todo… compartir experiencias y conocimiento.
_DSC2810

Excelente el keynote de Mary Poppendieck “Fricción” que nos hizo plantearnos en que debemos enfocarnos en resolver problemas que a agregar “caracteristicas”, procurar ir evolucionando y no temer a la experimentación constante, aparte claro esta de reducir la “fricción”.
_DSC2862

Ese mismo día me tocaba mi sesión “Gestión Ágil de Entornos de Despliegue en la Nube”, tema en el cual he tratado de volcar mis reflexiones producto de la practica este año, así como de la elaboración de los posts que hemos visto sobre el tema, todo salio bien (¡la sala se lleno!) salvo por el tema de Internet, ya que debido a la propia naturaleza de la charla era necesario explicar en vivo los entornos de despliegue sobre los que estábamos hablando, felizmente tenia un vídeo hecho anteriormente que ayudo a mitigar un poco el problema, aquí las diaspositivas de mi sesión:

Como nota curiosa debo decir que la keynote me dio la inspiración para indicar el como los procesos que recomiendo para despliegue tienen como objetivo reducir la “fricción”, eso lo capto bien el gran Martin Salias que hizo la facilitación gráfica de mi sesión.

IMG_0978-2

Finish Reading: Otro gran reencuentro: Ágiles 2015 en Montevideo

Reflexionando sobre DevOps y Cloud computing

Como indique en el post anterior, mi sesión “El reto del DevOps ágil” trajo buen debate e inquietudes, por lo que en el Open Space del #Agiles2014 propuse una sesión dedicada al tema de Cloud Computing, a la vez Adrian Moya propuso otra para profundizar el tema de DevOps, luego de una breve coordinación fusionamos las sesiones, así que luego del almuerzo nos reunimos en una de las salas y empezó la conversación cuyas ideas fuerzas trate de reflejar aquí:

_DSC0059

Mas que un tema técnico, la reunión se enfoco desde el punto de vista organizacional, ver el porque las organizaciones están adoptando cloud, como lo están haciendo y también porque no lo hacen.

_DSC0058

Dentro de las experiencias se evidencio que el cloud permite empoderar a las unidades de negocio (que usualmente tenían que esperar mucho para la asignación de un recurso *), lo cual puede lograrse mediante nube publica o mediante nube privada si es que hubiera restricciones de seguridad (generalmente por temas legales).

Algo que me llamo la atención fue que si bien un escenario PaaS (Plataform as a Service) esta mas orientado para implementar aplicaciones escalables desde el inicio, las empresas han empezado usando IaaS (Infraestructure as a Service) debido a que ya hay mas madurez en herramientas de automatización, como Puppet y Cheff, y porque este modelo no se queda tan corto como Paas aparte de que nos permite desplegar las aplicaciones ya existentes, a tenerlo en cuenta para entender las necesidades de una organización que quiera dar el salto a la nube.

Un punto clave que salto en el dialogo es que para una implementación adecuada de cloud es imprescindible medir las fortalezas de la organización, así como entender cuales son los blockers que afectarían a la organización en este proceso, en adición a los ya mencionados de seguridad y leyes hay que tener en cuenta el si la organización ya ha hecho una fuerte inversión en hardware, eso me hizo acordar lo que comento Alex Le Bienvenu de Microsoft en su momento, que ese es un escenario muy difícil de adopción y que se podría intentar entrar ofreciendo cloud como mecanismo de contingencia.

Ya metidos en el tema de los blockers afloro el tema del sector bancario, sector que (aparte del tema legal y seguridad) por su dependencia a tecnologías legacy como AS/400 y RPG se encuentran en escenarios mas complicados para poder implementar cloud, pero se menciono que algunos bancos están utilizando cloud para proyectos No Core, y que han empezado a surgir plataformas cloud especialmente orientadas a sus necesidades como FinQloud, habrá que hacer seguimiento a estas opciones.

Llegados al tema de precio, quedo claro entre los asistentes que debemos entender que el uso de cloud no necesariamente es mas barato que tener una infraestructura on premise, siendo que los ahorros van por otro lado debido a que se pueden provisionar los recursos teniendo en cuenta los picos y caída de demanda, en ese sentido es necesario validar los costes desde el principio, hacer seguimiento del consumo (un compañero comento como se les disparo la facturación mensual por una transferencia de datos) y tomar en cuenta la letra pequeña de los contratos.

El tema de desarrollo no podía ser dejado de lado y se recordo que los desarrolladores deben ser conscientes del entorno en que se va a correr la aplicación, pues de lo contrario no se podrá aprovechar las características de escalabilidad de la nube, o tener problemas al toparse con algo usualmente trivial como los FileSystem.

El tiempo paso rápido y fue un gran momento de aprendizaje mutuo para todos los asistentes, espero poder repetir esta clase de diálogos mas adelante en Perú o en próximos Ágiles.

Luego los amigos de Tech & Solve tuvieron otra charla donde comentaron su experiencia y problemas en la evolución del modelo DevOps, donde de paso nos explicaron sobre un producto muy interesante: Docker que están utilizando como una manera ágil para poder provisionar infraestructura (de momento Linux) vía código de manera sencilla, como feedback ante sus problemas debemos recordar que la tendencia DevOps se trata de colaboración entre áreas para llegar a soluciones y no centrarse unicamente en lo técnico, esto viene después.

_DSC0067

Ademas de Adrian, un gran agradecimiento a Diego Garber (extremo derecho en la foto **) que estuvo presente en todas estas sesiones compartiendo su experiencia y punto de vista.

_DSC0068

* Como dije en otro post, en este blog no usamos la palabra “recursos” para referirnos a las personas, siendo que en este caso usamos la palabra para referirnos a maquinas físicas, maquinas virtuales, espacio en disco, websites…

** El asistente del medio también estuvo muy presente y activo en estas sesiones DevOps, pero se me paso apuntar su nombre, así que si alguno de los asistentes al Ágiles lo puede identificar se agradecerá.

“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