“Poquitecto” ¿realidad, broma o necesidad?

Desde hace un tiempo, en un grupo de amigos desarrolladores, bromeamos acerca de como uno de nosotros tiene el rol de “Poquitecto“, la razón de esta broma deriva del hecho de que nuestro amigo tiene el rol de Product Owner, siendo que esta adscrito a un departamento de Arquitectura en su organización, y claro en esta época de “cargo cult agil” nunca esta de mas hacer una broma respecto a que nuevo rol puede inventarse dentro de las organizaciones…

La verdad es que esto no hubiera pasado de una broma o anécdota, si no fuera porque la conversación me hizo recordar que ¡Yo trabaje con un poquitecto!, ¿como así?, bueno, resulta que hace poco mas de un año el equipo en que me encontraba paso por un cambio radical de Product Owner, pasando de alguien con mucho enfoque en la funcionalidad de negocio a agregar y la facilidad de uso respectiva (vamos, un PO “clásico” *), a uno con fuerte base técnica (pero involucrado en la organización y el producto por varios años) que priorizaba y enfocaba las Historias de Usuario con un claro enfoque hacia la arquitectura de la integración tecnológica de nuestra aplicación con otra que estaba siendo desarrollada por otro equipo.

Y claro, las reuniones incluían conversaciones respecto a lo que implicaba el conectarse con la otra aplicación, el como estaba construida nuestra aplicación, diálogos en los que nuestro nuevo PO se implicaba directamente; cabe agregar que nuestro Scrum Master era uno de los que te acompañaba en la depuración de código cuando había que meter un cambio radical a lo que ya se tenia desarrollado y en producción.

¿Que cual de los dos perfiles de PO es el mejor? pues, a riesgo de hablar como consultor daré la respuesta clásica: “depende”, pues en una etapa del ciclo de desarrollo se requería un enfoque totalmente orientado al negocio y a la funcionalidad a agregar, pero en otro estadío dicha visión tecnológica era de gran utilidad (y hasta de necesidad) para lograr orientar adecuadamente los cambios esperados.

Desconozco los detalles del rol de nuestro amigo, pero esta experiencia me indica que a veces puede ser necesario que haya una “fusión” entre las actividades correspondiente a un Product Owner y las de un Arquitecto, tenga esta mezcla el nombre que tenga (llámalo poquitecto si quieres), que en un momento ese nombre se consolide… depende de como siga el cargo cult en nuestras organizaciones(**).

(*) Ya lo he mencionado antes, personalmente creo que es imprescindible que un Scrum Master tenga un conocimiento del ámbito técnico en el que se va a mover con su equipo (sin llegar a ser experto), requerimiento que no considero mandatario para un Product Owner.

(**) Las cuales hablan de la importancia del Agile Technical Coach (si, otro cargo) y de la excelencia técnica, pero a la hora de la verdad no efectúan las acciones reales.

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?

Agilidad ¿responsabilidad de todos?

Si, por aquí de nuevo, luego de unas semanas muy ajetreadas, donde pudimos organizar el Global DevOps Bootcamp, renové mi participación en el programa Microsoft MVP (gracias por la confianza!) y se organizo el Ágiles Perú 2018 con motivo del décimo aniversario de nuestra comunidad.

El evento se realizo en la UTEC, y pese a todo lo acelerado que pasamos como comité organizador fue todo un éxito, mucho interés del publico por las charlas de los asistentes y varias propuestas interesantes en el Open Space.

 

En todo caso la jornada me dejo algunas anécdotas que están derivando en reflexiones, que comparto con uds. Finish Reading: Agilidad ¿responsabilidad de todos?

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.

 

 

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

Finde Agil con Windows 7

Como ya habia comentado nuestro amigo blogger (y MVP!) El Bruno fue elegido para ser anfitrion de una de las fiestas de lanzamiento de Windows 7, asi que el dia elegido fue el pasado viernes 23, el lugar… su nuevo piso alla cerca al final de la Linea 3 del Metro Ligero.

La gracia de estas fiestas es que Microsoft envia al anfitrion una caja con diversos accesorios para la fiesta:

Se sabia que en otras cajas se enviaron globos y vasos o posavasos, en este caso lo que hubo fueron servilletas, y otras cosas como este poster que muestra Bruno:

Pero claro, el componente estrella del envio es el Windows 7 Steve Ballmer Edition, lo cual como podemos ver no era ninguna leyenda urbana:

Invitados sorprendidos por lo que envia Microsoft:

Bolsas de recuerdo:

Bruno no dejo la ocasion de mostrarnos el fierro que hasta hace poco tenia online a Elbruno.com el cual temporalmente se encuentra en alojado en Geeks.ms

En fin, una simpatica reunion, con mucho frikismo y conversa medio tecnica donde solo falto una instalacion de Windows 7, la cual espero acometer en una semana luego de haberla probado en maquinas virtuales. Mil gracias a Bruno y familia por la hospitalidad de esa noche…. ahhh y visiten su blog, claro esta.

Lamentablemente tuve que irme temprano (12:30 + viaje de hora y media) pues el sabado me tenia que ir al Agile Open Spain 2009 en la Escuela Universitaria de Informatica de la Universidad Politectnica de Madrid, como le he estado cogiendo interes al tema de las metodologias agiles y especialmente a SCRUM, era para mis imprescindible tener que ir.

Por razones de la fiesta ya comentada, no pude asistir a la reunion preparatoria del viernes, pues no se trataba de la usual serie de conferencias decididas “desde arriba”, no, es viernes sirvio para que se propusieran ideas para sesiones y que los propios participantes eligieran cuales se realizarian… o no, el resultado lo podemos ver en la siguiente foto, este panel sirvio ademas como guia para saber a que sesion ir:

Mi interes se orientaba a ver el tema Agil dentro de las organizaciones y asi como las reticencias al cambio, en ese sentido las sesiones de Jorge Uriarte (“CMMI & Agile”) y Angel Medinilla (“Es muy dificil”) fueron muy utiles ya que la experiencia comentada por los diversos asistentes dieron muchas pistas sobre como introducir procesos agiles y como vencer la resistencia de las organizaciones, aun en las que se han metido en procesos CMMI, ya que Agile y CMMI no son totalmente incompatibles (a pesar de algunas dificultades), pero siempre y cuando la adopcion de una certificacion venga dada por el interes de mejorar los procesos y no solo porque quede bien de cara al mercado tener dicho estatus, situacion ultima que parece no es nada rara de cara a lo dicho en las sesiones.

Correspondio a Leo Antoli el dirigir la sesion “Ser cliente no es facil”, donde se pudo ver ambas caras de la moneda, de clientes que no son capaces de encontrar proveedores confiables que hagan uso de practicas agiles, y por otro lado proveedores agiles que se ven enfrentados a pliegos “cerrados” o desconfianza del responsable de aprobacion de compras. El camino de conciliacion es duro, pero es posible y se basa sobre todo en generar confianza y luego flexibilidad buscando nuevas formas de contratacion que vayan mas alla del pliego cerrado.

Llegados a este punto debo indicar que como se ve habia 4 sesiones en simultaneo, y que la sesiones mas que una conferencia tenian el formato de debate dirigido, lo cual ayudo mucho a compartir experiencias, el problema viene dado cuando una sesion tiene demasiados asistentes por lo que algunas personas se quedaron paradas, y no fue tan posible promover la participacion.

Luego del almuerzo, asisti a la charla dedicada a kanban metodologia que entra con la controversia de que seria lo que reemplace a Scrum, la charla de Xavier Quesada logro el objetivo de dejarnos con la curiosidad y cuestionamientos a esta propuesta, por lo que le dedicare un post aparte.

Y para terminar tocaba una sesion sobre offshore y proyectos internacionales, tema que vista mi experiencia africana no dejaba de serme de particular interes, nuevamente tuvimos a Angel Medinilla como moderador invitando a quienes habiamos tenido experiencia con esta clase de proyectos a contar lo mas relevante de estas experiencias, la conclusion es que hay factores adicionales que se tienen que tener en cuenta para esta clase de proyectos, ser consciente de ellos y que los problemas usuales (malas especificaciones, retrasos, etc) de un proyecto “normal” tambien pueden aparecer por lo que se debe de tener cuidado de que los costes ocultos no se terminen comiendo los supuestos ahorros; una cosa que Angel se cuido de hacernos recordar es que se debe dedicar un tiempo al arranque del proyecto desde el punto de vista de las comunicaciones: tecnologia, horarios, facilidades, “protocolo”, es que ya luego en marcha es peor.

En resumen, una excelente jornada, un formato agil (aunque suene redundante) que ha motivado a quienes asistimos a seguir investigando y a difundir estas formas de trabajar, a ver si esto continua.