¿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.

¡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”.