Category Archives: Agile

¿Puede ser ágil un caracol?

by

Como algunos ya sabréis, esta semana he participado junto a y en el lanzamiento de una campaña llamada . Entre otras muchas cosas, está siendo una experiencia de la que estoy aprendiendo mucho. Trabajar con una antropóloga y un diseñador es algo mucho más complicado de lo que yo me imaginaba al principio sobre todo porque muchas veces nuestros presupuestos son muy diferentes e incluso en ocasiones divergentes. (Y del lenguaje ese gótico que usan, ni contaros…) :-)

Sin embargo, está siendo una de las experiencias más excitantes y enriquecedoras de mi vida, no sólo de mi vida profesional, sino también de mi vida personal. Pedro y Maica, además de polifacéticos, son personas tremendamente exigentes y con unos puntos de vista muy creativos, tanto que a veces me dejan tan descolocado que no soy capaz de seguirlos. Pero a la vez son muy generosos y capaces de tener paciencia, explicar su punto de vista, escuchar los puntos de vista de los demás, e incluso dar una oportunidad aunque no lo vean nada, nada, nada claro. Eso no significa que todo vaya como la seda. Somos un equipo con personalidades muy fuertes y eso a veces nos para. Pero lo más bonito de este proyecto está siendo cómo, especialmente en esos casos de disensiones profundas, nos detenemos a analizar el porqué y tratamos de aprender de ello.

Voy a poner un ejemplo. es, no voy a desvelar ningún secreto a estas alturas, una campaña que trata de comunicar, de una manera desenfadada, valores que nos parecen interesantes como los del Movimiento Slow, el Decrecimiento, la recuperación de las tradiciones populares, etc. Es una campaña que tiene un ritmo diferente a las campañas que estamos acostumbrados a ver: campañas explosivas que tratan de captar muchos usuarios y ser trending topic en menos de una hora. Nosotros empezamos (casi sin quererlo, para ser honestos) hace ya algunas semanas con aquello del que habréis visto alguna que otra vez en vuestro timeline si me seguís por twitter. Sin embargo, es curioso cómo, a pesar que los tres estamos muy motivados por esta idea de “lo lento”, hemos caído en muchos de las trampas del tiempo en este tipo de proyectos. Nos hemos puesto fechas y ¡hemos corrido detrás de ellas!.

- ¡Ay, Beas! ¿No decías que eras agilista? :(

Pues sí, ya véis, en casa de herrero, cuchillo de palo. No hemos respetado la revisión de la segunda iteración.

- ¡Beas, Beas! ¿Agilista tú? ¡Vamos, anda! :(

Estamos aún en el proceso de retomar nuestro ritmo sostenible. Pero en vez de echarnos las manos a la cabeza, volvernos locos y seguir improvisando o tirarnos trastos unos a otros, nos hemos reunido, hemos visto qué podíamos hacer para recuperar el ritmo y dónde estabamos patinando más. Nos hemos preocupado también de si la campaña estaba funcionando también o no, hemos tomado decisiones para ir corrigiendo, pero con tranquilidad porque es una campaña lenta. :)

- ¿Es eso una retrospectiva? No lo parece :(

¡Ejem! Bueno, ya sé que va a sonar a excusa de “todo a 100″ pero es que no somos un equipo con dedicación exclusiva y no es nuestra prioridad DEFCON 1. Además, uno de los objetivos que nos hemos marcado Maica, Pedro y yo es no aplicar ninguna práctica ni metodología porque sí. Lo mismo aplica a la retrospectiva. De momento hacemos el seguimiento del proyecto de manera iterativa, con revisiones semanales del avance (sería algo así como la “demo” en un desarrollo con Scrum), revisiones del proceso desde un punto de vista de equipo y metodológico (que de momento implementamos como una retrospectiva formal) y la replanificación de los alcances (que vendría a ser como la sprint planning meeting de Scrum). Y además, hacer encajar Scrum en este tipo de proyectos es tremendamente complicado:

  • no estamos llevando un único proyecto adelante ( es sólo uno de ellos),
  • sólo somos tres personas en el equipo (cosa que afecta sobre todo a las dinámicas y al reparto de actividades),
  • estamos repartidos geográficamente (Pedro está en Sevilla),
  • no todos tenemos experiencia en un desarrollo iterativo e incremental de un proyecto,
  • todos somos equipo, dueño de producto y cliente a la vez (lo peor con diferencia) :-)

Pero seguiremos trabajando en ello porque es uno de los objetivos que perseguimos. Entre otras cosas estamos empeñados en ver de primera mano los retos que un equipo pequeño de emprendedores se encuentra a la hora de sacar a la calle un producto, con poco tiempo y mucha presión. Cómo manejar la incertidumbre y el feedback (o la carencia del mismo) es algo donde los principios ágiles y los principios lean nos están siendo de mucha ayuda. Con estamos aprendiendo mucho y lo aplicaremos en el futuro. Stay tuned!

P.S.
Por favor, no dejéis de ayudar al pobre Félix. ;)

Retorciendo Agile para no ser ágil

by

Leo en el último párrafo de un blog:

Constatando, como solemos comentar, que la teoría ágil se debe adaptar a cada caso en particular, muchas veces relajando la agilidad, obteniendo la verdadera riqueza y productividad de las múltiples soluciones que ofrece la ingeniería del software.

Lo que me recuerda la keynote que JB Rainsberger dió este año en la Conferencia Agile-Spain 2011.

Rainsberger explica en la keynote cómo, en estos 10 años de Agile, muchos nos frustramos porque no nos funciona nuestra implementación de Agile y por ello comenzamos rápidamente a “innovar” y crear cosas como “post-Agile” pero sin experiencia real en practicar con éxito los fundamentos. Como colofón a su charla, Rainsberger nos aconseja leer sobre eXtreme Programming (XP) y practicar mucho hasta interiorizar los fundamentos. Sólo entonces estaremos en condiciones de adaptar con éxito los procesos a “el mundo real”. Afirmar esto en “el mundo real” parece muy radical, utópico y no sé qué otras palabras más pronunciadas con un tono poco amable, pero lo cierto es que ya era algo que hace un par de años Xavi Gost me avisaba cuando le comentaba mi intención de explorar el Agile coaching y ahora refrendado por la experiencia. Cada vez que me acerco a “el mundo real” y tratamos de hacer Agile (llámese Scrum, XP o lo que sea), el mayor obstáculo es el rechazo de las organizaciones (y las personas que las forman) a cambiar sus procesos. Esos procesos, que presuntamente funcionan, no se pueden cambiar por otros, que siendo “lo que se debería hacer” según ellos mismos, porque los nuevos son muy costosos en el plano de las responsabilidades personales, nos sacan a todos de nuestra zona de confort y nos ponen en la tesitura de atrevernos a equivocarnos (y luego reconocerlo). Y por ello comienzan a retorcer los principios ágiles (los de la parte de atrás del Manifiesto) para hacer el cambio posible y no sé cuantas cosas más, en vez de echar mano de los valores de XP, en particular del coraje y atreverse a realmente intentarlo.

Lecturas recomendadas

Además del seminal de Beck, XP Explained, yo recomendaría también la lectura del de Jeffries, XP Installed, también citado por Rainsberger en esa keynote.

Agile inception

by

Esta semana he hecho dos incepciones ágiles para dos proyectos muy diferentes. Para el que no sepa qué es una incepción, probablemente lo pueda resumir como “una receta para una reunión de trabajo donde las personas implicadas en la elaboración de un producto definen juntos las expectativas del mismo”.

Me gustaría hacer hincapié en el hecho de que el objetivo final de la incepción es llegar a un punto de acuerdo sobre las expectativas del producto que hay que construir. El producto puede ser desde software hasta una silla de madera, eso es lo de menos, lo realmente importante es que todos los que están en la reunión son los que van a construir esa silla de madera, además de los que se van a sentar en ella, los que la van a vender, los que la van a comprar y cualquier otro intermediario. (En un escenario ideal, claro).

Esta semana he hecho una para arrancar un proyecto para el que ya se había hecho una consultoría previa y en la cuál no estaba el cliente ni el usuario final. Eso nos obligó a imaginar mucho sobre los personajes relacionados con el producto. Pero también me obligó a trabajar mucho, como facilitador de la incepción, en tratar de evitar que esa consultoría nos influyera demasiado en la averiguación conjunta de cuál debe ser el plan iterativo e incremental que el equipo debe seguir.

En la otra incepción, el escenario era diferente, aunque quizás no tanto. Se trataba de un producto cuya construcción se ha atascado y no son capaces de poner en producción. Como detectamos que había una discrepancia fuerte entre lo que se entendía que era el producto, planteé esta incepción. Pero durante la sesión fueron saliendo que las discrepancias son muy de fondo. Trabajamos mucho, mucho, mucho en qué no hace el producto y nos centramos sólo en un personaje para tratar de construir el plan para el MVP (Minimum Viable Product) y permitir que construyan sobre él. Wow! Eso costó. Creo, sin embargo, que mereció la pena, aunque sólo el tiempo lo dirá.

Como resumen:

La incepción es una poderosa herramienta si se usa con sabiduría.

Perdón por la pedantería, pero en la práctica he comprobado que no es una receta “for dummies” porque requiere de mucha mano derecha para avanzar y mucha mano izquierda para ayudar a que salgan las discrepancias que permiten avanzar con seguridad. Es una herramienta que puede crear la falsa sensación de tener un buen plan pero, si no se ha sido honesto, puede haber dejado riesgos latentes; o si no se ha contado con todas las personas necesarias (porque es una reunión muy cara) haber construido una imagen falsa del producto.

Esto me recuerda eso de:

Individuos e interacciones sobre procesos y herramientas

P.S.
Si hubiera querido ser psicólogo habría estudiado psicología. ;)