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

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.