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.

¡Y se viene el Agile Open Lima VI!

Por si no lo saben, el próximo domingo 26 de Agosto se viene el VI Agile Open Lima, asi que por si no te has apuntado ya te estas demorando demasiado :), este evento es peculiar pues por primera vez se hace en domingo y en las afueras de Lima (si, aun mas lejos que Surco o La Molina) concretamente en Ñaña en la sede de Universidad Peruana Union, lo cual permitirá realizar algunos juegos agiles al aire libre. Para esta ocasión estoy proponiendo las siguientes sesiones:

 Estoy muy entusiasmado con estas sesiones, llevo varios meses probando la versión Beta de Team Foundation Service, y me ha sorprendido gratamente sus capacidades para llevar a cabo integramente la gestion del Ciclo de Vida de las Aplicaciones, desde la toma de requerimientos y gestion del Backlog hasta la automatización del despliegue (y por supuesto haciendo la Build en la nube), si creías que TFS es solo un “source safe mas potente”… esto te hara pensar ;).

Sobre la segunda charla, intentare replicar un estilo “reality show” que pude ver en acción por parte del maestro Angel Medinilla en el Agile Open Spain del 2009, compartiendo las experiencias que hayamos tenido trabajando con equipos distribuidos, ya sea como cliente o como proveedor, en un momento en que el desarrollo de proyectos offshore esta creciendo en nuestro país, sera algo muy interesante para ver como mejoramos nuestra forma de desarrollar esta clase de proyectos desde un enfoque agil.

Así pues cuento con ustedes en este nuevo Agile Open Lima y en particular con sus votos para poder llevar a cabo estas sesiones :), ¡nos vemos en Ñaña!!.

_DSC8580.jpg IMG_5890.jpg _DSC8807.jpg

¿Flexibles, puristas o simplemente … Agiles?

He estado pensando en escribir este post desde hace unas semanas cuando empecé una reflexión sobre que tan rígidos somos (o debemos ser) al intentar aplicar metodologías agiles, y todo empezó con este dialogo con un amigo que trabaja fuera de Perú:
Amigo: tudo bem?
Yo: tranqui…tratando de introducir Scrum por aqui…
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio…. y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y… usan planning poker para estimar?
Amigo: no idea….
hay jefes de proyecto en varios niveles….no se como hacen sus pronosticos del tiempo.
Yo: pero … hacen retrospectivas?

Amigo: no tengo vision global

Yo: me refiero, retrospectivas a nivel de equipo
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm…. entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno… antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso… todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible….o como lo quieras llamar, para un purista, no aplica
Yo: pero… alguna vez el equipo hizo retrospectiva? veamos… hay cosas en q si puedes ceder y cosas en que no…las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de “nada interrumpe” al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace… eran del jp con el cliente, ahora… tu puedes indicar cuanto t puede tomar….y en base a eso el jp… trata de decir si va o no va… o si va, cuanto les va a costar.
Yo: veamos…. se negocia el orden del backlog y siempre hay repriorizaciones…
Amigo: para eso esta el jp
Yo: veamos… tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo… pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace…etc
el jp, del jp de desarrollo, seria el scrumMaster… mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint… este permanece inamobible?
Amigo: todo depende del jp de desarrollo….el evalua en que casos se pueden hacer cambios
Yo: uhmm… los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio….
Amigo: no hay nada q hacer…. q eres un purista

Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.

Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar “Scrum” en un proyecto:

  1. Queda bien de cara al mercado decir que se usa
  2. Hay una necesidad de mejorar la manera de hacer software (problemas de tiempos, alcance, calidad o todo junto)
  3. Se escucho en alguna conferencia y se decidió ir por ello, o algún “guru” que paso por ahí lo recomendó
  4. Se desea mejorar la organización y se pensó que Scrum seria un buen componente dentro de ese proceso

No conozco mas detalles, pero si bien cualquiera de esas razones puede llevar a la situación planteada, solo las “pares” dan un punto de partida razonable, pero aun así son incompletas si no tienen como base el asumir la “filosofía” detrás del Manifiesto Agil, y se paso directamente a querer implementar la “metodologia” y luego a “adaptarla”.

Adaptar… interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba “uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización”, lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de “equipos autoorganizados” o “propiedad colectiva” del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.

Como es evidente, poco de eso ha sido tomado en cuenta en esta implementación de Scrum, quedando solo las iteraciones, pero lo peor es que no ha sido asimilado por el Equipo, el cual puede llegar a ver todo lo demás como “purista”, y si, caer en el purismo a rajatabla es un riesgo, por lo cual hay cosas que se pueden ajustar en cierto punto como el mapeo de roles a algo mas cercano a la realidad organizacional,

Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos… Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo… lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar “baby steps” como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.

Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de “nada interrumpe el  Sprint”.

Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo “compre” la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible…. lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara “scrum flexible”.

La nefasta obsesión por “entregar valor al cliente”

Y uno al leer el título podría pensar que se esta incurriendo en un desprecio hacia el cliente que nos ha encargado el desarrollo de un software, pero nada más lejos de la realidad, la reflexión viene a algo que aun sigue siendo mal entendido por quienes estamos involucrados en el desarrollo de software.

No cuento nada nuevo que tradicionalmente (modelo “cascada”) el desarrollo de software tiene un historial de fracasos totales o parciales, ya sea en funcionalidad incompleta, sobrecostos de tiempo y dinero, lo cual lleva como consecuencia en que los aun medianamente exitosos tengan la presión por conseguir entregar “lo que se pide” “a tiempo”, y claro muchas veces sin importar el “cómo” que es a lo que nos lleva el título de este post, el cómo la obsesión por entregar algo que el cliente pueda usar hace que se pierda la perspectiva global del problema.

Y el problema (deuda técnica) ya es conocido: métodos de más de 400 líneas de código, código muerto y/o duplicado, lo cual deriva en poca mantenibilidad, bugs como consecuencia de la extensión de la funcionalidad, pobre performance, etc; síntomas que hacen que el que hereda un código desee ir corriendo tras el que hizo el código originalmente, (y un cliente pagando resignado los costos de implementar un parche o una mejora menor).

En este punto se nos podría decir que esto ocurre porque el equipo de desarrollo no aplicó un buen patrón de diseño, que no siguió los principios S.O.L.I.D., lo cual si bien tiene algo de cierto no es sino la segunda capa de un problema mayor que veremos en breve.

Se pensaría que con la irrupción de las metodologías ágiles la situación ha estado cambiando, pero no, la realidad no es tan hermosa, pues si bien ahora tenemos más visibilidad sobre los elementos (historias de usuario) que se están desarrollando no debemos de olvidar que las metodologías imponen un proceso de priorización, en el cual lamentablemente las historias funcionales (si, las que “dan valor”) toman precedencia siempre sobre las técnicas, las cuales tienen que rogar para hacerse un lugar en el sprint o en el flujo del Kanban, y muchas veces nunca logran entrar por la sencilla razón de que “no hay como justificar ante el cliente algo que no se ve que le reporte valor”. Así pues, se cumple con la entrega de funcionalidad continuamente, pero seguimos acumulando deuda técnica pues, a pesar de seguir perfectamente el proceso, sólo nos estamos enfocando en entregar un software que funcione sin fijarnos en qué es lo que hay detrás de este software que se entregó perfectamente en plazos pues lo importante es que funcione, ¿no? ¿qué hay deuda técnica? tranquilos, eso lo solucionamos con una refactorización circunstancial (léase: arreglamos cuando podamos y no nos quite mucho tiempo).

Recomiendo leer este interesante articulo de Lucas Ontivero donde nos cuenta como las cosas han seguido yendo mal en el lado técnico a pesar del agilísimo.

Adicionalmente tenemos el factor del QA (Quality Assurance), uno podría creer que en empresas grandes este equipo tendría una visión integral de la calidad del producto, lo cual debería incluir tanto la verificación de la mantenibilidad y calidad del código como de la validación de la arquitectura, pero no, al parecer su visión va sólo al lado funcional, o sea a lo “visible” del gráfico anterior, siendo que temas como la mantenibilidad “lo ve el equipo de desarrollo”, así pues por un lado se exige un cumplimiento funcional (muchas veces sin entender las razones por las que “la gente de desarrollo” opto por implementar de una manera diferente a como QA lo pensaba) estricto pero por otro lado se omite la validación de la calidad de lo técnico, pues claro… no es lo que ve el cliente de manera directa, por más que este sea el que luego tenga que pagar los “intereses” de la deuda técnica(*). No se ustedes pero si un equipo que se supone se encarga de la “calidad” durante el ciclo de desarrollo ignora la parte técnica de la implementación (¿alguien dijo auditorías?) , le esta haciendo un flaco favor al proyecto y al cliente.

Así pues mucho del problema viene dado por la importancia que se le quiere dar al elemento técnico del proyecto, el cual viene tradicionalmente es relegado por debajo del administrativo, siendo que muchos profesionales hacen gala de haber tocado muy poco los elementos correspondientes a la programación en su formación profesional, lo cual en mi opinión generalmente (he conocido excepciones) ocasiona que no se sepa (debido a que a veces no se entiende) el impacto de una decisión técnica que se tome en cualquier etapa del desarrollo, razón por la cual prime el componente funcional/visible a la hora de definir prioridades en el desarrollo.

Afortunadamente hay caminos de solución, uno de ellos es tratar de entender qué es lo que ha derivado en la creación del Manifesto for Software Craftsmanship como una evolución del Manifiesto Agile (esto lo explica muy bien Edson en esta presentación); y por otro lado, dentro del marco de las metodologías ágiles, reconocer de manera visible el rol que deben de jugar los componentes técnicos, en ese sentido me sorprendió muy gratamente como en su reciente conferencia "Lean from the Trenches" Henrik Kniberg indicó claramente cómo dentro de su proceso ágil (basado en Kanban) había reservado, dentro de su tablero, el espacio necesario para las historias técnicas, de esta manera

Es que como Henrik dijo, en un mundo ideal sólo habría historias de negocio, pero no estamos en un mundo ideal, los problemas técnicos existen y no podemos pretender seguir ignorándolos, o creer ingenuamente que efectivamente lo “solucionaremos después”, o ya en el lado extremo seguir en la ilusión de que cualquier programador podrá implementar algo si le damos una especificación funcional completa y detallada.

Entonces, regresando al título de este post, creo que debe de quedar claro que no es que no tengamos como meta el entregar funcionalidad y software, sino también validar el cómo llegamos a ese entregable, procurando (entre otras cosas):

  • Dar el espacio a las historias técnicas cuando corresponda, y no relegándolas a cuando “haya tiempo”.
  • Sospechar del programador que defiende una mala implementación con un “pero funciona”.
  • Ser consciente de los riesgos que significa ir por el camino rápido en aras de entregar la funcionalidad pedida.
  • Que todo el equipo (y no sólo el que implementa) sea consciente de lo que hay en la implementación (arquitectura, algoritmos, etc) y de como eso condiciona los tiempos de desarrollo, especialmente cuando se trata de agregar una nueva funcionalidad.
  • Valorar el factor técnico, procurar la mejora de las habilidades técnicas de los desarrolladores: mentorship, revisión por pares, dojos, etc.

Claro que mucho de esto tendría que ir de la mano con un reconocimiento dentro de las organizaciones al rol que juegan las TI en su crecimiento como negocio, pero por ese lado la cosa esta bien complicada.

(*) Se entiende como “intereses” de la deuda técnica al hecho de que conforme pasa el tiempo será más difícil corregir las malas decisiones o malas implementaciones de código, ya sea porque el desarrollador que implementó algo de manera críptica ya no se encuentra en el equipo, porque nueva funcionalidad superpuesta generó más dependencias o simplemente porque por el tiempo que pasó ya es más difícil acordarse el porque se tomó esa decisión que “parecía buena en su momento”.

TFS con Kanban….ahora se podra


Durante un tiempo he estado siguiendo entusiastamente las metodologias agiles, y recientemente he practicado algo de Kanban, y si bien me han terminado gustando algunos de sus enfoques me he sentido frustrado por la impedancia entre el hecho de que el backlog se manejara por un lado usando un Excel y por otro la visibilidad de las tareas en progreso (WIP: Work in progress)unicamente mediante postit’s en la pizarra.

Si a esto le sumas el hecho de que el TFS solo se usa como repositorio de código fuente y no como la herramienta de ALM que es la decepción es mayor, pero en este caso se puede entender los reparos si es que no se incluye de entrada un soporte para el modelo Kanban, como si que lo incluye para CMMI y SCRUM.

Al parecer esto va a cambiar pues gracias a Ulises me vengo a enterar de que en CodePlex los Visual Studio ALM Rangers estan desarrollando la Practical Kanban Guidance con Team Foundation Server y Visual Studio, dentro de este proyecto (para TFS 2010 y el inminente TFS 2012) se incluye la nueva plantilla Microsoft Kanban 1.0 Process Template así que con esto se abre un nuevo capitulo para consolidar el uso de TFS en las diversas metodologías ágiles, tratando de demostrar que su uso incrementa (y no reduce) el ancho de banda en la comunicación del equipo.

Queda ver si es posible usarlo desde la nube via TFS Preview