Nuevamente en las trincheras del trabajo remoto

Si pues, de momento dejaremos nuestra tónica habitual dedicada a la nube y DevOps para comentar algo que, junto a la cuarentena, ha sido uno de los tópicos en estas semanas: el teletrabajo, trabajo remoto, home office, y similares, que no son lo mismo, hay matices, pero no son sujetos de lo que vamos a ver.

Digo de vuelta, porque para mi no es la primera vez que tengo que pasar por estas circunstancias de desarrollar mi trabajo lejos de mis colegas/clientes/proveedores etc, que es básicamente la situación en la que nos encontramos ahora, para lo cual me basare en mi experiencia personal, que si bien no es la fuente de la verdad única me ha permitido extraer algunas conclusiones que espero sean de utilidad.

Mi primera experiencia fue cuando, transicionando entre proyectos, se me pidió hacer una propuesta comercial para la consultora española en la que me encontraba, me tomo alrededor de una semana el completarla, y la primera vez si que fue complicado, pues estar en mi habitación ponía cerca la disponibilidad de reposar un rato y no enfocarme en mis responsabilidades, pero aun así el documento salió adelante y le gusto a mis jefes, pero desde ese entonces me quedo clara la importancia de separar el ambiente de trabajo del de tu reposo, solo que entonces no era posible pues alquilaba habitación.

La segunda situación, intermedia, correspondió a cuando, al regresar a España desde Sudafrica, tuve que hacerme cargo de un equipo de desarrollo en Madrid, pero por la naturaleza del proyecto, se tenían que hacer coordinaciones con el equipo en Joburg, en ese momento las cosas estaban bastante limitadas:

  • No había nube
  • Las transferencias por VPN eran lentísimas
  • Los servicios de voz por IP eran poco fiables

Aun así, logramos adaptarnos, los correos eran muy fluidos, y eventualmente tenia llamadas interdiarias con el QA en Joburg, pero lo de compartir pantalla sencillamente no era viable. Felizmente esas limitaciones ya son historia, pero queda como punto claro la importancia de la disponibilidad de buenos canales de comunicación para los equipos.

La tercera experiencia fue cuando me tuve que hacer cargo de gestión y mantenimiento de varias aplicaciones para la sede española de una multinacional de investigación de mercado, en este caso sí que estaba en la sede del cliente coordinando con la gente de infraestructura y los usuarios, pero tenía que coordinar y asignar tareas a alguien trabajando en la India, el problema es que las formas de asegurar el entendimiento por ambos lados nunca se formalizaron, ya que tiempo después me di cuenta de que cuando preguntaba “Do you understand?” la respuesta de “yes” casi nunca era cierta, amén de que habiendo posibilidad de usar Webex para efectuar las comunicaciones, o chat para cosas urgentes, mi contraparte prefería llamadas por teléfono convencional (con menor calidad de audio), lo cual sumado al hecho de que estaba en un proceso cross o multiprojecto, no permitía un flujo adecuado en el desarrollo de nuestras actividades, esto, en retrospectiva hace clara la importancia de definir o setear los “protocolos” y canales que se usaran para las comunicaciones, y en todo caso generar “actas” que aseguren el entendimiento común de las conclusiones de la reunión.

En los siguientes años la experiencia fue mas frecuente, de la mano con mi regreso al Perú y al trabajar en la mayoría de los casos en proyectos que trataban de seguir marcos agiles, pero con la peculiaridad de que nuestros clientes estaban fuera del Perú, no siendo raro que la mitad del equipo estuviera en Lima, y el resto en otro país (Costa Rica, Argentina, España, USA) solo que en este caso se mezclaba la peculiaridad de ir unos días a la oficina, y a veces trabajar desde casa, por lo que las lecciones en este caso son variadas:

  • Si quieres poner a tu equipo en una sala (para hablar con la otra mitad del equipo), asegúrate que has validado bien el alcance de tus dispositivos para no tener a tu gente gritando.
  • Tener dos pantallas es bueno, pues por un lado ves a tu contraparte, y en la otra pantalla están ambos haciendo el code review o similar.
  • Por otro lado, una segunda pantalla también tiene el riesgo de que ayuda a no ponerle total atención a la reunión en curso.
  • Saber que tienes a tu contraparte a un clic de distancia para tener un chat, y de ser necesario una llamada, ayuda mucho a generar una sensación de equipo pese a la distancia.
  • Una cultura de Pull Request y aprobación/rechazo rápido ayuda mucho, mucho.

Mención aparte es un problema sobre el cual no he tenido mucha respuesta que ayudara en algo, y es el tema de las Retrospectivas cuando tienes equipos distribuidos (ya sea en casa o en distintas sedes de trabajo), pues cuando empecé con esto de los marcos ágiles, casi todas las dinámicas que se enseñaban o comentaban partían del supuesto de tener todo el equipo en un mismo sitio (recuerdo un libro de varias dinámicas muy interesantes, pero ninguna orientada a equipos distribuidos), que si, que habían herramientas para ayudar en el tema, que básicamente te permitían escribir tus comentarios (Que se hizo mal, Que se hizo bien, Como mejorar) de manera oculta y luego destaparlos, lo que ocasionaba que las retros terminaran convirtiéndose en un Dia de la Marmota.

Si recordamos lo que aprendimos en agilidad, mucho se basa en el ir aprendiendo, evolucionando, mejora continua y todo eso, siendo que si una actividad se vuelve repetitiva… poca ganancia se puede sacar. Una de las pocas mejoras que conseguí en un equipo fue que se rotara al facilitador, lo cual logro que el diferente “estilo” cada vez lograra un mayor dinamismo por parte del equipo, pero eso no es suficiente; así que en esa época en la comunidad consulte a diversos coaches, y gurúes que venían a compartir sus conocimientos y experiencia (en algunos caso muy valiosos), obteniendo generalmente miradas al techo… y alguno en algún arranque de sinceridad me dijo que siempre en sus clientes había trabajado con todo el equipo de manera presencial, y claro es que los equipos que trabajamos offshore nunca habíamos sido el “blanco” de sus actividades, situación que ahora veo que cambia a toda prisa, debiendo improvisar en campos en los que no habían incursionado, ojala que en esta ocasión se escuche a quienes han tenido experiencia real en este aspecto y que hayan podido resolver este impedimento (*).

En todo caso, lo que he comentado hasta el momento tenia una peculiaridad muy muy fuerte, y es que estos equipos en los que participaba estaban orientados hacia un único proyecto/producto, por lo que siempre se tenia el foco de manera clara, pero mi situación actual es diferente, y se podría decir que estoy en un proceso de aprendizaje.

¿Por qué? Desde hace un tiempo he asumido un rol de arquitecto cloud, lo cual por su naturaleza obliga a trabajar en varios frentes de batalla a la vez: revisión de iniciativas para su aprobación, apoyar proyectos en curso, coordinar actividades con otras áreas para establecer algo en conjunto, etc., un reto interesante que obliga a tener otro tipo de orden, en el cual te acostumbras a las charlas de pasillo y a sacarle partido a ellas para aprender mas de los distintos contextos con los que hay que lidiar.

El detalle es que cuando pasas de golpe a un escenario de Home Office colectivo, todos pasamos a un proceso de aprendizaje, reinventando reglas, nuevas formas de coordinar, a lidiar de otra manera con el context switch, con la gestión de las agendas, es un camino que vamos empezando, del cual espero dar conclusiones u opiniones mas definitivas como las he dado para mis escenarios anteriores.

¿Y uds? ¿Qué experiencia o buenas practicas pueden compartir respecto al trabajo distribuido o remoto?

(*) Me comentan que en los últimos dos años han surgido herramientas que ahora si apoyan el poder hacer una buena retro con los equipos distribuidos, soy todo oídos.

Agilidad al borde del nuevo año

El 2019 se cumplirán 10 años que estoy metido en estos temas de la agilidad, escena/movimiento que ha ido cambiando y readapatandose con una velocidad asombrosa, cayéndose, aprendiendo sobre la marcha, generando cuestionamientos, así que este fin de año es una buena ocasión para repasar algunas de las cosas que se han visto en este año en este entorno y comunidad.

Una de las cosas que afecto la escena agil mundial en los primeros meses del año fue el asesinato de Mike Beedle, firmante del Manifiesto, el cual poco antes había publicado esto

 

Reflexión totalmente valida (sumada a otra en la que proclamaba “arreglar” Scrum para seguir avanzando *) en un contexto en el que se hizo énfasis el ver la agilidad como algo solo organizacional y/o cultural, olvidándose de que el pilar técnico es importante el proceso de desarrollo de software, lo cual de la mano con el omnipresente “cargo cult” derivo que el rol mas demandado el año pasado y principio de este fuera el de Agile Coach y derivados, es que claro, si se quiere seguir escalando ser Scrum Master ya no es suficiente.

La consecuencia de ese boom fue que se empezó a dar una imagen de que para lograr hacer cambios hacia la agilidad lo importante era tener buenos coaches (externos, claro esta) y Scrum Masters, que no tenían porque entender (que no es lo mismo que ser expertos, ojo) las complejidades del desarrollo de software en un problema en concreto, sino en procurar la búsqueda de la felicidad de los equipos, y si al final del PI se tenia un bonito tablero frente al que sacarse fotos, mejor que mejor… y claro, este fenómeno se replico en las comunidades y eventos, generando una saturación del tema coach y relacionados, olvidándonos de como hacer bien software (en un momento en que todos p. ej. quieren hacer microservicios porque esta de moda, y no hay quien les pare la mano).

Este problema, porque hay que reconocer que es un problema, derivo en otros dos fenómenos relacionados, por un lado los mas hardcore empezaron a sentir que ya no tenían su lugar en la agilidad por lo que procuraron consolidar espacios para hablar en profundidad de los temas de software, y por otro lado el empezar a apuntar que algo esta mal, lo cual se hizo mas evidente con el ya famoso discurso de Martin Fowler en Australia, donde básicamente instaba a afrontar los siguientes retos:

  • Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
  • Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
  • organize around products.

Ah si! porque me olvide de algo, es que durante este tiempo (junto a los coaches) no falto quienes se subieron al carro para venderles a las empresas (ansiosas de comprar, hay que decir) el como volverse ágiles, pero para variar, aplicando estrategias top down que generalmente dejan intactos los esquemas, pero claro, queda muy bien decir que se esta muy involucrado con la agilidad por ir contratando varios SM y coaches.

El discurso de Fowler tuvo su impacto (por ejemplo la respuesta de Uncle Bob) a nivel global y debate a nivel de la comunidad, en la que si por un lado se paso a revalorar (**) la importancia técnica en el desarrollo de software, por otro lado se ha dado una vuelta de tuerca con el mensaje de que “Agilidad no es Agile”, que Agile solo es a nivel de software, que agilidad va mas allá, “esto no lo logras  en la agilidad de equipos”; todo este nuevo buzz me parece que puede salirse de control, pues empuja la idea de que esto de lo que hemos tratado de hablar en estos años solo corresponde al “nivel estratégico”, lo cual termina dando un carácter secundario a objetivos como los de empoderar a los equipos y sus miembros o valorar el trabajo real sobre la imagen … , suma esto al hecho de afirmar que los coaches requieren “espacios seguros” para perfeccionarse, y tenemos una receta perfecta para segmentar a una comunidad que debería empujar un proceso de construcción colectiva.

Hay esperanzas, por un lado algunas organizaciones ya no están cayendo en la búsqueda de coaches (o SM) al peso, sino valorando sus meritos per se, aunque claro… el cargo cult terminara buscando nuevas figuras para asegurar la relevancia cuando un termino ya dejo de ser cool; por otro lado esta nuestra responsabilidad y consciencia de asegurar que los tópicos vinculados a la excelencia en nuestros ámbitos de dominio sigan presentes, y eso es tarea de todos en la que seguiremos.

(*) Lo cual hace inevitable recordar el como hay quienes saltan diciendo “eso no es Scrum” cuando ven que algunos equipos han evolucionado a practicas que les son mas eficientes en su contexto, pero que ya no siguen Scrum al pie de la letra.

(**) Por ejemplo en el HT #PorfaArgentina salto la importancia de asegurar espacio para el contenido técnico en el próximo Ágiles 2019.

 

¿Qué es lo que esperamos de nuestros Scrum Masters?

Normalmente en los artículos y conferencias vinculados a la agilidad se nota mucho el enfoque de como los Scrum Master (y Agile Coaches) pueden ir mejorando, evolucionando y lograr lo mejor de los equipos para conseguir los objetivos esperados de la organización, pero… ¿cuantas veces hemos reflexionado sobre que es lo que esperamos los miembros “de base” de los equipos ágiles de nuestros respectivos SM? (*)

Es así que en la pasada reunión de Agile Perú, propuse el tema así que comparto las reflexiones de dicha reunión sumado a los comentarios de entonces y los que luego tuve en conversaciones posteriores.

Como punto de partida previo, hay que tener claro que no se esperaba que el Scrum Master fuera un “cargo” institucionalizado, si no mas bien un “rol” dentro de los integrantes del equipo; lamentablemente, por la deriva que ha tenido la “escena ágil”, la figura se ha consolidado, tanto por el movimiento de ex PMs que se acercaron a la agilidad, como por los profesionales que buscan ir a la rama de “gestión” esquivando lo técnico, esa es la realidad y si bien hay que recordar cual era la intención original del rol, también es bueno procurar canalizar de manera adecuada la situación en aras de lograr lo mejor para los equipos.

Con esto como base, soy de los que considera que el objetivo del Scrum Master es volverse prescindible para el equipo ya que ha procurado que este haya llegado a un grado de madurez que permite se pueda confiar en su auto-organización, esto implica muchos retos, pues el perfil de cada equipo es diferente, puede tratarse de profesionales con poca experiencia en las practicas ágiles (o en el dominio tecnológico respectivo) por lo que corresponderá un acompañamiento adecuado para que esto se vaya impregnando en el hacer de los miembros del equipo, o también tratarse de un equipo de rockstars con mucha experiencia tanto tecnológica como en agilidad y que por lo mismo tocara hacer los esfuerzos para que las diversas personalidades logren la sinergia y colaboración esperada. Como se ve, retos diferentes pero con el (se supone) mismo objetivo, convertir un grupo de personas en un equipo auto-organizado, así que creo que el éxito de la carrera de un SM (**) debe apreciarse por como (y a cuantos) ha contribuido a lograr que los equipos hayan llegado a ese estadio, que (por cierto esta en el Manifiesto Ágil) : “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados“. Finish Reading: ¿Qué es lo que esperamos de nuestros Scrum Masters?

De valor, historias técnicas y mantenimiento

A veces una reunión de la comunidad te genera un debate interno una revisión de tópicos que ya se habitan visto antes pero que conviene reflexionar y visitar de nuevo, así en la ultima reunión de Agile Perú Cynthia presento como tema principal si existían las historias técnicas, planteándose los siguientes conceptos clave: los componentes técnicos dependen o tienen que depender de un requerimiento de valor de negocio, siendo mayormente tareas y no deberían ser considerados como “historias” puesto que estas son una base para conversar, siendo clave el reflexionar valor de negocio que se le deja al cliente si al día de hoy se acaba el proyecto.

El debate posterior fue interesante, se comento que de haberlas no se debería llamarla “historias” sino “epicas” “enablers”, que si lo que importa únicamente es el negocio, lo cual me ha derivado a unas reflexiones que quiero compartir con ustedes.

Ante todo, hay que precisar ¿a que llamamos historias técnicas? En mi experiencia creo que corresponde llamar así a las actividades técnicas (sorry por lo redundante) que no se pueden subordinar o mapear directamente a requerimientos de negocio, siendo así ¿deberíamos considerar como tal al código que implementa una funcionalidad o historia de usuario? para respondernos planteémonos el caso de que  por X razones debemos escribir un script para conectarnos a una BD externa a fin de lograr realizar una consulta para uso de nuestros usuarios, pues no… no es historia técnica a pesar de su complejidad ya que hay una vinculación directa con un historia de usuario, lo contrario pasa con actividades tales como refactorización, configuración de infraestructura, etc, procesos que por su naturaleza transversal No deberíamos forzarlos (como muchas veces se insiste) a que encajen como tareas hijas de una historia de usuario.

Siendo así ¿que tipos de historias técnicas hay? pues Alexander Menzinsky nos recuerda una muy razonable categorización (**):  Arquitectura, Infraestructura de Producto, Infraestructura del Equipo, Refactorización y Spikes (investigación).

Como pueden darse cuenta, mi posición es a favor de la “existencia” de las historias técnicas como la ha sido desde hace unos años, ya entonces insistía en su lugar debido a la necesidad de hacer visible el “como” se llega a la necesaria entrega de valor que se propugna desde la agilidad, los años transcurrido han reafirmado mis posturas visto que las tendencias que ya comentaba entonces respecto al descuido al componente técnico no han hecho sino acrecentarse, siendo que sin pelear por la visibilidad no se lograra el cambio. ¿Y por qué es importante esa visibilidad? pues, como me comentaba Omares como si las historias (tradicionales) se hubiesen hecho para mostrar el exterior y no el interior… ” por lo que “hay una especie de vacío sobre donde poder ver dichos aspectos (técnicos) y que se valoren” ya que “las historias están hechas para conversar con el cliente y entenderse….pero la parte técnica, no la comprenderá mucho pero la valorara de la forma que pueda y en ese sentido la relegara hasta que pueda aprender sobre la importancia de esta en algún momento“, lo cual nos lleva a algo que sale a nuestras conversaciones de tanto en tanto, la importancia de explicar adecuadamente el rol estos componentes para que el Producto Owner acepte su inclusión en los sprints que vayan saliendo, y claro… ¿como se puede iniciar el dialogo sobre estos componentes si no están visibles? (*).

Dicho esto queda pendiente sobre como se deben visibilizar y nombrar, y reitero que no debe forzarse su subordinación a una historia de negocio, sino asumir su rol transversal en la generación de valor con calidad y su impacto en la capacidad del equipo, ahora… que no te guste el nombre de “historias técnicas” es otra cosa (a mi si, aunque si no te gusta usa otra opción, pero siempre hay que recordar que la nomenclatura tiene impacto en como entendemos las cosas), pero no por eso hay que retirar su lugar visible dentro de los flujos de un equipo, muy por el contrario toca potenciarlo como muestra Henrik Kniberg:

Dicho esto, toca tener un necesario balance para evitar que por mor de la excelencia técnica nos encontremos atrapados en ciclos de refactorización sin generación de valor como ironiza Angel Medinilla:

 

Así que toca seguir dando vueltas y recalcar la importancia de la visibilidad de los componentes técnicos dentro de nuestros backlogs y sprints, como parte importante de la calidad del software y el valor que entregamos.

Y ya que hablamos de valor, no puedo dejar de mencionar una conversación en la que se hablaba de como pasar de los ciclos de desarrollo y entrega a la etapa en que un software es mantenido, en ese momento se comenzó de hablar de “equipos de mantenimiento” y de “equipos que generan valor”, lo cual me hizo un ruido instantáneo por lo que tuve que manifestar mi postura respecto a que ese lenguaje involucraba que los equipos de mantenimiento NO generaban valor, siendo que consideraba que hay valor en el sostenimiento de las operaciones del negocio, y que encima agravaba las barreras dentro de la organización, generando naturales recelos que no hacen sino bloquear los objetivos de la organización, es que las palabras cuentan, y mucho.

(*) Mas allá del caso obvio de los aspectos de Infraestructura de Producto, como puede ser la instalación y configuración de un servidor, escenarios sobre los cuales también he escuchado defensas de colocarlos como subordinados a una historia técnica.

(**) Gracias a Guino por apuntar que quien planteo esta categorización fue Robert Galen.

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 camino de la agilidad personal…

Hace unas semanas durante un “after” luego de una de las reuniones de Agile Perú, surgió la cuestión de que la agilidad cada uno la vive de manera personal … diferente y si, conforme dimos nuestras opiniones vimos que cada uno lo veía bajo un angulo distinto, pero igual de valido; así hubo quien dijo que lo que le gustaba de la agilidad era el poder experimentar, alguien mas comentaba que era el cambio lo mas importante, otro punto de vista era que la agilidad era el poder eliminar desperdicio, también se menciono que lo que atraía de la agilidad era el poder motivar a las personas y equipos, en mi caso personal comentaba que para mi el ser ágil era el poder entregar valor (*) …

Nótese el detalle… distintas aristas, distintos enfoques, todos complementarios, pero en ningún caso hicimos mención a temas de “gestión de proyectos” ni entregar el alcance antes, no… hablábamos de como la agilidad como filosofía (por decirlo de alguna forma) había influenciado nuestras vidas, y que esto era un camino constante… lo cual me hizo traer a colación algo que había comentado hace unas semanas “Si crees que lo de agilismo va esencialmente de gestión, es que tu camino recién ha empezado…”, la conversación de esa noche me lo reafirmó, así que … sigamos en el camino, o inicialo si es que recién estas viendo de que trata esto, no te arrepentirás.

(*) ¿Será por eso que me atrajo el enfoque DevOps?

¿Tenemos interés por lograr el cambio en el entorno?

El como funciona el sector informático varia por países, y uno de los problemas que tenemos en Perú y España (si, en ambos casos pasa lo mismo con sus respectivos matices) es la posibilidad de realizar una carrera profesional dentro del área técnica sin tener que pasar a “gestionar” para poder evolucionar económica y profesionalmente, siendo que en la mayoría de los casos uno debe dejar la programación para gestionar o … intentar una Carrera en Y para poder ascender (*).

Por contraste veamos este comic de CommitStrip:

Strip-Coder-ou-plus-650-finalenglish

Alucinante ¿no? Preferir seguir codificando en lugar de ascender y ser un manager ¿esta loco? eso es lo que nos diríamos en nuestros países, pues es la verdad, así como están las cosas ese ES el camino de mejora, lo cual trae de rebote otros problemas:

  • Se pierde un buen programador y se corre el riesgo de tener un mal manager
  • Managers que desde que salieron de la universidad han evitado de cualquier forma posible el contacto con la tecnología
  • Un mercado laboral que considera al programador como una etapa en la vida, por lo que no se consideran experiencias mayores a 6 años en las ofertas, total.. todo puede hacerlo un practicante.
  • Egresados de informática quejandose de que en la universidad se les enseño “demasiada programación” y poco de gestión, lo ironico es que los contenidos actuales de programación no tienen la profundidad necesaria para los retos que hay que enfrentar en el mercado global.
  • Una plana gerencial poco receptiva a las innovaciones y buenas practicas como el agilismo, integración continua, etc.

En ese sentido, la innovación en las organizaciones va cuesta arriba, dándose el caso de que muchas veces los cambios en las consultoras vienen dados porque el cliente da el giro hacia el agilismo, obligando a todo el ecosistema de proveedores a dar el cambio y avanzar poco a poco justos en la mejora.

Siendo así, hace poco un amigo comentaba las innovaciones que en la consultora que estaba trabajando se estaban dando: establecimiento de una linea de carrera para los perfiles técnicos, buenas practicas como entrega continua, visual story mapping, y por supuesto: agilismo, todo sonaba bien pero cuando le pregunte si ya iban a empezar a atacar el mercado peruano (su cartera de clientes es remota) dijo “No, no pagan”, ahi todo se desbarato, pues se pierde una oportunidad para replicar los cambios y las buenas practicas en nuestro contexto, pues dicho escenario virtuoso se vuelve una isla que no replica lo bueno que esta haciendo a lo que pasa en el país. A seguir buscando los nichos de mejora…

Queda en nuestras manos en seguir evangelizando, y no dejar de apuntar los problemas.

(*) Y el problema no es tan solo de algunos países, algunas corporaciones multinacionales de consultoría tienen muy incorporado en su ADN que si uno entra a la linea técnica nunca podrá acceder al anhelado grado de “socio”.

¿Qué se requiere para ser un DevOps?

Hace unos días tuve la suerte de participar en uno de los #DevHangout que organiza Lennon, y en esta ocasión el tema trato sobre DevOps por lo que base la presentación en la que había hecho para el Agiles 2014 y que pueden ver aquí.

El modelo de los #DevHangout permite bastante la interacción mediante Twitter, por lo que conforme avanzaba la sesión afloraron recurrentemente preguntas del tipo “¿Qué se necesita saber para ser un DevOps?” “¿Cuál es el perfil de un DevOps?” “¿No es lo que hacen los sysadmin (IT Pro)?”, así que pensando en resolver estas dudas va esto…

mindsetComo indico en la sesión, lo de DevOps va más allá de la definición de un nuevo rol, sino que es, como dijo , “la búsqueda de la sinergia…” lo cual nos indica que nos encontramos ante una nueva forma de trabajar, donde evitamos los comportamientos estancos, la tradicional separación entre IT y Desarrollo y por el contrario buscamos una mayor colaboración de cara a lograr mejores resultados como organización.

Dicho esto, es perfectamente comprensible que haya necesidad de introducir el rol en la organización a fin de evolucionar a una cultura de ese estilo, así que trataremos de plantearnos consideraciones generales para dicho “rol”, tratando de explotar los tres retos que planteamos en El reto del DevOps ágil.

Primera condición para ello es ser curioso, tratar de salir del molde, si se es desarrollador estar interesado sobre el entorno (el fierro, el SO) sobre el que van a correr las aplicaciones que se están desarrollando (la de desarrolladores .Net que nunca habían configurado el IIS) y saber como este condiciona la performance; y si se es IT Pro, ser consciente del rol que juegan las diversas aplicaciones corriendo en la infraestructura, el stack usado para desarrollarlas; ahhh y en ambos casos (si se trata de empresas “cliente”) ser consciente del diverso grado de importancia de las aplicaciones en la cuenta de resultados de la organización.

Antes de proseguir, ya que hablamos de Desarrolladores y IT Pro, he notado recientemente que la mayoría de las ofertas (¡y documentación!) de tipo DevOps (y también las de cloud, todo hay que decirlo) se orientan hacia un perfil de IT Pro, lo cual indica que no se ha entendido claramente el cambio que implica el movimiento DevOps y de la sinergia que se espera conseguir siendo que esta puede partir tanto de un perfil desarrollador como de operaciones, habiendo elementos que se pueden ganar de ambas miradas.

La segunda condición ya sea para el rol como para la cultura DevOps, es la famosa empatia, ponerse en el lugar del otro, si uno es desarrollador hablar con los de infraestructura para saber lo que están haciendo, tener referencias de cómo está su granja de servidores (con las palabras adecuadas los administradores de red te cuentan emocionados sobre el fierro que acaban de comprar), convocarlos periódicamente a las reuniones de desarrollo y hacerlos parte activa; y por el otro lado dejar de mirar los proyectos de desarrollo como algo que va a afectar la estabilidad y predictibilidad de la infraestructura sino como algo que se ha pedido como necesario para que la organización logre sus objetivos, por lo cual es necesario colaborar activamente; y en ambos casos… tratar de hablar el lenguaje del interlocutor.

Algo común para cualquier caso es estar pendiente del estado del arte, saber que es lo que puede hacer una nueva tecnología y como podría potencialmente ayudar a lo que se esta haciendo a fin de poder proponerlo cuando corresponda a las necesidades de la organización (aquí le corresponde a la administración tener mas apertura a la innovación, so pena de desalentar a sus equipos), esto claro viene de mano con una vocación de no dejar de estudiar bajo ningún concepto, así que esto de DevOps no es para quien se sienta cómodo con ofertas de tipo “resuelve problemas que son de menor complejidad y que pueden ser de carácter rutinario”.

Como pueden ver, esto de DevOps si bien en la hora de la cancha puede ser algo muy técnico, pero para empezar se requiere un cambio de mentalidad, tanto en las personas involucradas como en la organización.

***

Mil gracias a Lennon y al equipo de DevAcademy.la por invitarme por segunda vez a sus #DevHangout y porque luego pasan cosas como esta que alegran el día 🙂

Acercandonos a #NoEstimates

Hace un tiempo tropecé en Twitter con este hashtag: https://twitter.com/hashtag/NoEstimates?src=hash y me llamo mucho la atención pues a lo largo de mi carrera me ha tocado ser victima de las estimaciones que alguien mas hizo, o en algunos casos entregar mis propias estimaciones, circunstancias en las que por mas buena intención que haya (y que ventas no haya presionado para meter mano) siempre hay algo que no se ha contemplado que hace fallar cualquier supuesto.

En este tiempo he estado revisando interesantes materiales (como este) y la idea básica detrás de esta tendencia es reconocer que las estimaciones, como las hemos conocido hasta ahora, no son útiles para la toma de decisiones, pues están basadas en una gran incertidumbre y no dejan de ser una opinión, por lo que se debe de tender a trabajar con hechos y en base a ellos hacer las proyecciones y sobre todo, enfocarnos en dar prioridad a lo que efectivamente da valor antes que tener el detalle ultracompleto sobre las tareas que se van a programar.

Con ese contexto y curiosidad previa me vengo a encontrar que Vasco Duarte, una de las voces mas lucidas en este movimiento esta preparando un libro enfocado en el tema, el cual (como es usual en editoriales como Manning) ofrece la opción de que los lectores interesados seamos Beta Readers para lo cual solo debemos registrarnos en el formulario de la pagina.BetaReader

Luego de inscribirnos se nos enviara el primer capitulo, para poder leer el 2do capitulo uno debe enviar el feedback sobre el capitulo, y así sucesivamente… paso a paso, lo cual me parece una gran manera para garantizar el flujo de lectura de los interesados.

De momento llevo leídos tres capítulos y el enfoque es muy interesante, nos pone en el escenario de una PM a la cual se le ha pedido hacer una estimación “precisa” de un mega proyecto, y poco a poco vamos entendiendo como las estimaciones son esencialmente una opinión y no un hecho, ademas de cosas muy interesante como que el famoso “cono de incertidumbre”, muy usado por nosotros los agilistas, ya había sido desacreditado hace un tiempo por Laurent Bossavit upss.

Así que si quieres ir aprendiendo poco a poco de que trata todo esto de #NoEstimates y no caer en la trampa de “Tenemos que ser mas precisos en nuestras estimaciones” (que en el libro se dice que es mas o menos como comprar números de lotería ganadores) apuntarse como Beta Reader es una gran oportunidad.

Lectura sugerida:

How to not shoot yourself in the foot with estimates

Kanban in Action de Hammarberg y Sundén

Durante el año pasado tuve la oportunidad de ser revisor de el libro de Marcus Hammarberg y Joakim Sundén: Kanban in Action.

Fue una gran oportunidad el poder ver los borradores del libro, y desde el inicio me engancho con su enfoque, un primer capitulo destinado a demostrar como es posible (mediante la ayuda del equipo ficticio Kanbaneros), partiendo de la situación actual, implementar un flujo de Kanban en tu organización o proyecto de manera sencilla.

El resto del libro nos ayuda a ir comprendiendo la teoría detrás de Kanban (metricas, clases de servicio, planificación, etc), el porque es bueno tener controlado el Work In Process, recomendaciones y alternativas para cuando nos encontremos con situaciones particulares (una emergencia que debe ser solucionada de inmediato, por ejemplo), de una manera muy clara. Para lograr esto en todo momento los diversos Kanbaneros aparecerán con preguntas y conversaciones para clarificar los puntos.

Definitivamente recomiendo la lectura de este libro, pues como digo en mi comentario en la contraportada es “A practical way to start with kanban … and learn the theory along the way”, lo unico que lamento del libro es que al final no se incluyo el capitulo de Scrumban o el detenerse un poco mas en utilizar Kanban en procesos iterativos como.. si.. Scrum.

Pues nada, si quieren tener una buena introducción a como empezar a usar Kanban les recomiendo leer el capitulo 1. Ademas nuestros amigos de Manning nos estan regalando el capitulo 13, con diversos juegos para aprender Kanban de manera divertida.