Developing Frogtek

El blog del Departamento de Tecnología

Categoría: scrum (página 1 de 2)

¿Para qué sirve ser ágil en una start-up?

Mucho agile, mucho agile… pero si te descuidas puedes acabar en una empresa en la que lo único agile es el motor y para de contar, más cuando el equipo de producción, como en nuestro caso, está aislado del resto o directamente, como pasa en las consultoras, no hay resto. Ésta es un poco la conclusión que he obtenido tras leer los libros “Lean Start-up Method” de Eric Ries, “The four steps to the epiphany” de Steve Blank y después de conocer un poco el mundillo éste del agilismo en España… y por experiencia propia, por qué no decirlo.

Supongo que en parte es porque el mundo del software ibérico está principalmente orientado a programar para terceros y en ese caso ser ágil es “tan fácil” (y tan difícil) como pegarte unos años hasta que haces scrum, tdd y demás como Dios manda y conseguir que el cliente acuda a las reuniones y se involucre en el proceso de cada sprint. Pero la realidad es que detrás de los métodos ágiles hay mucho más y es algo de lo que no se oye hablar demasiado. Hace mucho que no acudo a ninguna AOS, ni CAS (siempre me coinciden con algo que no puedo dejar para otro momento), pero la primera CAS a la que acudí (2010) me encantó, sabíamos tan poco de métodos ágiles que cada charla era un nuevo mundo de conocimientos y posibilidades. Desde entonces si no yo, siempre alguien de Frogtek ha acudido a estos eventos y trasladado lo que allí ha aprendido. Últimamente, sin embargo, me empezó a sorprender que si bien toda la comunidad está muy interesada en ser técnicamente ágiles, no parece haber tanta ebullición, o al menos yo no la he detectado, una capa por encima de eso. Está bien tener un método de producción iterativo-incremental, está bien ofrecer al cliente (que muchas veces no es el usuario final, desgraciadamente) un proceso súper adaptable a sus cambios de humor y requisitos… pero estaría mejor dotarnos de los procesos, que tiene que haberlos, para utilizar este gran método para crear el producto que el usuario final necesita. Para ello no basta con que el equipo de desarrollo sea ágil, hay que aprovechar esa agilidad para que los equipos de marketing y ventas (o el product owner, o los encargados de desarrollo de cliente, o quien sea) puedan, a su vez, realizar sus propios experimentos, implementar sus propias métricas y tener sus propios objetivos iterativos e incrementales que nada tengan que ver con el desarrollo y sí con el negocio. Por eso, echo de menos, conceptos que Ries maneja en su libro como “indicadores vanidosos”, “indicadores accionables”, “análisis de cohortes”, “contabilidad de la innovación“… conceptos sin los que scrum, tdd, los sprints y todo lo demás no sirven más que para tener un proceso de desarrollo flexible y adaptable… lo cual no tiene porqué evitar que se acabe construyendo de forma eficiente y completamente flexiblemente un producto totalmente inútil. Supongo que, en España, el principal problema es precisamente que no existen muchas start-ups y hay, sin embargo, demasiadas factorías de software… y en una factoría de software es difícil vislumbrar nada más allá de lo técnico (por no hablar ya de meter baza) y suficiente se tiene con lidiar con el cliente.

Frogtek no es una software factory pero también hemos sufrido en parte ese problema. Tras varios años de trabajo teníamos un equipo de tecnología muy “agile” y muy “kaizen” que implementaba las “ocurrencias” de la empresa de manera eficiente y puntual. Ocurrencias, dicho en el mejor de los sentidos y con todo el cariño, que trataban de ser lo más meditadas posible y que suponíamos beneficiosas para los tenderos y que, lo fueran o no permanecían en el producto sine die. El problema de esta aproximación es que no es todo lo científica que debería ya se basa en asunciones que habría que comprobar, pero que rara vez se comprueban, por falta de tiempo y de proceso principalmente. No basta con implementar User Stories por muy bien definidas que estén, el cementerio está lleno de productos técnicamente impecables. Para solucionar esto en Frogtek vamos a utilizar una capa más de abstracción, basada en Épicas, que iría sobre los sprints de User Stories. Una Épica no es más que un objetivo del product owner para un sprint determinado. Algo así como el objetivo estratégico de alto nivel de mejorar el indicador X de la empresa en un x% (p.e. “hay que conseguir que el 80% de los tenderos levanten su inventario en menos de 2 horas”). Muchas veces, este tipo de mejoras no es cuestión de una sola User Story es, más bien y por limitarlo al producto, un conjunto de historias (“el producto debe adivinar los precios”, “el producto debe adivinar los costes”, “el producto debe proponer los productos más comunes”, “el interfaz debe cambiar así o asá”…) que se pueden desarrollar durante un sprint (de forma ágil, claro), la diferencia con nuestra aproximación pasada es que terminado el sprint el trabajo del product owner no ha hecho más que empezar y a la vez que se empieza a pensar en el sprint siguiente, tiene que echarle un ojo al indicador asociado a la Épica del sprint pasado con el objeto de aprender si los cambios en el producto están teniendo el efecto deseado en el comportamiento real de los usuarios o, por el contrario, no han servido para nada y se necesitan más cambios (volver a iterar).

 

El trabajo del product owner se complica, ya que como se ve en el dibujo el contenido del sprint N empieza a analizar incluso antes de que empiece el sprint N-1.  La secuencia es la siguiente:

  1. Recoger indicadores.
  2. Analizar indicadores y Épicas en evaluación para decidir los objetivos (creando nuevas o modificando Épicas).
  3. Desglosar las Épicas en historias de usuario.
  4. Preparar la historias de usuario (mock-ups, pruebas de usabilidad con clientes, más mock-ups…).
  5. Estimar historias de usuario.
  6. Ejecutar el sprint (incluyendo pruebas, instalación en friendly users, etc).
  7. Instalar nueva versión en usuarios.
  8. Vuelta a 1.

Normalmente los indicadores a recoger y analizar necesitan un tiempo hasta que se generan, al menos en nuestro caso, así que no será extraño que las Épicas que se evalúen en un momento dado se hayan implementado hace dos, tres o más sprints. Por lo tanto el PO, no sólo tiene que estar pendiente del sprint actual sino que tiene que pensar en las Épicas (objetivos estratégicos del producto) que querrá definir para el sprint siguiente, mientras que monitoriza meticulosamente los indicadores asociados a las Épicas que están ahora mismo en evaluación y que pueden seguir así por uno o varios sprints. Porque una Épica, como una User Story, tiene un ciclo de vida ¡e incluso su propia tabla! (se proponen, se discuten, se diseñan, se implementan, se evalúan y si están bien se archivan, muy propio para una tabla de kanban) pero a diferencia de una User Story la evaluación no depende de factores meramente técnicos, si no que es función del valor que aporte al usuario final (si está bien definida y si se monitoriza usando datos reales). El paralelismo con las User Stories también tiene otras ventajas, se puede medir el throughput en Épicas de un equipo, es decir, la velocidad de la empresa para poner hipótesis a prueba y aprender de la realidad, concepto directamente relacionado con las posibilidades de la empresa de sobrevivir.

Al final como en muchos aspectos de la vida, se pueden extraer unas cuantas enseñanzas muy interesantes: No llega más lejos la empresa que hace más User Stories, sino la que hace User Stories como consecuencia del aprendizaje validado de otras User Stories. Es importante tener un framework de gestión del trabajo ágil, pero más importante es integrar en el proceso de producción herramientas de medida como Google Analytics o Flurry que permitan obtener información sobre la utilización de las distintas funciones y que permitan discriminar entre distintos grupos de usuarios con distintas versiones para poder relacionar causas y efectos usando el análisis de cohortes (¿a los usuarios de la versión x+1 les ha ido mejor que los de la version x?). Así que ahí estamos en Frogtek, peleándonos, como buenos novatos, con Analytics y con nuestras propias métricas, discutiendo las métricas que debemos aplicar a las Épicas y tratando de encajar su ciclo de vida con el de definición e implementación de los sprints. Este post, más que una realidad, es una declaración de intenciones acerca de lo que queremos hacer para conseguir ser una “agile data-driven company” para lo cual es necesario ser ágil pero, visto lo visto, no suficiente.

El mítico restaurante italiano

La semana pasada nos tocó dar un curso de iniciación a Scrum en el ITA. Aunque llebamos casi 3 años trabajando con prácticas ágiles, es la primera vez que nos encargaban un curso de este tipo.

Learning by doing with lego

La mayor parte de los asistentes procedían del mundo del Software pero algunos no, por lo que me pregunté como podía mostrar ejemplos claros y simples que ilustrasen los valores de Scrum y otras aproximaciones ágiles. Es entonces cuando recordé este brillante post de Ron Jeffries, uno de los padres del XP y firmante original del manifiesto ágil. Me parece muy acertado porque huye de tecnicismos y humaniza la esencia que yo quería transmitir.

Me gustaría tambien compartir con vosotros mi traducción al castellano (disculpas si he cometido algún error). La adjunto al final de este post.

También aprovecho este post para darle las gracias a Teresa Oliver por dejarme sus legos para usarlos en el curso. Para los que no la conozcáis proyecto SKOK os aconsejo que lo sigáis de cerca. Un acierto seguro.

El mítico restaurante italiano

Kate se reunió con Dean en la cafetería de la calle principal donde él originalmente la había contratado. Disfrutaron del buen clima y charlaron sobre sus vidas. Pero Dan tenía una pregunta.

“Kate”, dijo Dan, “las cosas van bien. Los productos se venden, la gente de marketing es feliz, la calidad ha subido, los clientes están contentos. Sólo tengo una pregunta.”

“¿Qué aumento de sueldo me merezco?”, dijo Kate. “Está muy bien que lo preguntes.”

Dan se echó a reír. “No te preocupes por eso, vas a tener un muy buen regalo llegada la Navidad. No, mi pregunta es, ¿cómo puede estar funcionado lo que estás haciendo? Tan pronto tenemos una idea de producto, incluso concretada a medias, los desarrolladores se ponen a construirla y tienen una versión con la que podemos jugar. Y entonces empezáis a mejorarla a partir de ahí. ¿Cómo es posible que eso funcione? “

“¿Quieres decir técnicamente? Tenemos pruebas, refactorización, … “

“No,” dijo Dan. “Esa es tu competencia. Me refiero a cómo puede funcionar desde un punto de vista empresarial. ¿Cómo podemos hacer todo esto sin fijar los requisitos, la estimación de todo y asegurar que las personas hagan lo que dijeron que harían? Parece como si todo el mundo estuviese improvisando “.

“Bueno, se parece mucho a la improvisación”, dijo Kate. -Montones de preparación, práctica y refinamiento. Tal vez sería útil que te contara acerca de mi tío Guido y su restaurante italiano. “

“No pareces italiana”, dijo Dan.

“Es cierto. Estoy en protección de testigos, pero no se lo digas a nadie. En fin, mi tío Guido tenía un restaurante italiano y decidió que necesitaba un hermoso mural en la pared trasera para dar al lugar un toque de clase. Déjame que te cuente lo que pasó. “

“Guido y sus amigos hablaron sobre ello un poco mientras se bebían algunas botellas de su famoso Chianti Cuestionable. Se decidió que era una gran idea. Pensaron en lo que necesitaban y decidieron darle un aspecto toscano agradable, con tal vez una parra que mostrara que las Uvas Cuestionables fueron cultivadas en el viejo país, y probablemente una imagen de la tataratía Sofía, sentada en una mesa de picnic o quizás tendiendo la colada. Hicieron dibujos de sus ideas en servilletas de bar. Desafortunadamente, la mayor parte de estos dibujos se perdieron, porque el Chianti Cuestionable resulta ser un blanqueador muy bueno.

“Una vez recopiladas algunas ideas, y desaparecidos los dolores de cabeza en su mayoría, empezaron a hablar con los artistas locales y aprendieron mucho, mayormente malas noticias. Los artistas querían “libertad artística”, o decían que el trabajo podría requerir un mes y que necesitaban el restaurante cerrado durante ese período. Había todo tipo de problemas.

“La buena noticia era que esto ayudó a Guido a comprender sus necesidades. Necesitaba mantener el restaurante en marcha, y no quería un paño grande y feo colgando para ocultar la pintura, ya que había puertas en la pared, para los baños y la cocina. Al principio trató de encontrar a alguien que pintase todo el asunto durante un fin de semana, pero nadie se acercó a eso.

“Guido se quedó perplejo. No podía tener el lugar con un aspecto horrible, y no podía cerrar, pero realmente quería su mural. Finalmente conoció a una artista que tuvo una idea. “¿Qué pasa si dejamos que la gente vea cómo el mural se va creando”, preguntó a Guido. “Trabajaré temprano por la mañana hasta que se abra, y la gente puede venir todos los días y ver lo que está sucediendo. Ellos le pueden dar información, y usted me puede dar retroalimentación y así construiremos el mural que mejor se adapte a sus ideas y presupuesto. “

“Guido pensó un poco y decidió que si no había gases venenosos por la pintura, aquella podía ser una buena idea. Podía ver la cosa tomar forma e ir guiando el proceso. Pero estaba preocupado por el presupuesto. “¿Cómo podemos mantener los costos bajo control?”, se preguntó.

“La artista sugirió lo siguiente:” Vamos a establecer un plazo y el presupuesto total. Te mantendré informado de cuánto se va gastando, y por supuesto vamos a tener el cuadro en la pared a la vista. Cuando lleguemos a mitad de camino, el cuadro deberá tener una calidad suficiente alta, y tener suficientes elementos pictóricos, como para que podamos pararlo en cualquier momento. Tendrás más ideas, por supuesto, pero para entonces los dos tendremos un sentido de lo rápido que podemos progresar, y tu podrás elegir las cosas más valiosas que añadir o cambiar. Vas a tener un control total sobre cómo termina la imagen, y si lo deseas, podemos parar cuando o antes de se te acabe el dinero. “

“Guido no estaba totalmente convencido. Quería saber cómo podía estar seguro de que no se quedaría con una pared horriblemente fea. La artista le dijo que le garantizaba pintarlo de nuevo y parar en cualquier momento que quisiera, y dijo que iba a comenzar trabajando con algún pigmento temporal, como la tiza, por lo que podría borrar y cambiar las cosas fácilmente.

“Guido decidió seguir adelante.”

Dan pensó. “Casi me puedo imaginar aquel trabajo. Pero parece muy caótico. ¿Funcionó? “

Kate dijo: “Espera y verás. La historia continúa. Guido era un tipo de pensamiento serio, al igual que tú. Él había tomado un montón de notas sobre el mural y sus necesidades, y muchas de ellas no habían sido blanqueadas por el Chianti Cuestionable. Su primer pensamiento fue darle todas sus notas a la artista y que ella las pintara. De hecho, he visto algunas de esas notas y eran bastante buenas. Así es como yo recuerdo lo que escribió sobre la tataratía Sofía:

“Sofía era una gran belleza en su juventud. Se decía en nuestra familia que Sofía Loren tomó su nombre porque se parecía a nuestra Sofía. Nuestra Sofía tenía ojos oscuros oscuros, pelo negro azabache que fluía por debajo de los hombros. Ella tenía las curvas por las que los hombres lloran y se movía como una bailarina a pesar de su voluptuosa figura.”

“Tal vez seas italiana, después de todo”, dijo Dan.

“Silencio, estoy contando una historia, señor”, dijo Kate. “Guido había escrito más:

” El mural debe mostrar a Sofía en sus últimos años. Se había redondeado un poco, como solemos hacer los italianos, y de alguna manera parecía más baja. Se podía ver en su rostro el envejecimiento de la hermosa niña que había sido. Y en sus ojos se podía ver los recuerdos de los muchos hombres a los que había conquistado. Después se casó con Francesco, tuvo una larga vida feliz casada y muchos niños que adoraba.

En el mural se le muestra como la abuela Sofía, sigue siendo enérgica y hermosa, todavía gobierna la familia con suavidad pero con firmeza. Hay que dejar que la gente vea el gran patrimonio de la familia que llega hasta nosotros y debe sugerir que, así como Sofía creaba maravillosa comida para su familia, nosotros creamos comida exquisita para nuestros clientes.

La imagen también debe mostrar que Sofía era frugal, al igual que nuestros precios son bastante razonables dada la alta calidad de la comida que servimos. Y ella debería verse muy trabajadora, para demostrar que vamos a trabajar duro para nuestros clientes.

“Wow”, dijo Dan. “Pide mucho de una foto de una señora mayor.”

“Guido fue poeta de corazón”, dijo Kate. “Pero dime una cosa: si usted fuera un artista, podría dibujar una imagen de Sofía a los 55 años o así, y que se viese como en la memoria de Guido?”

Dan sólo tuvo que pensarlo un momento. “No. He entendido que ella era una señora encantadora, pero no tengo ni idea de cómo sería su cara. Oye, ¡espera! ¿Esto es una alegoría no es así? ¿Estás hablando conmigo acerca de las especificaciones escritas? “

Kate se echó a reír. “Me pillaste. Tenemos el mismo problema que la artista había tenido con la hermosa prosa de Guido: no le decía lo que tenía que hacer “.

“¿Qué hizo ella?”

Kate dijo: “En primer lugar, leyó todas las páginas de notas de Guido. Afortunadamente no hubo demasiadas, pero había un montón de cosas sobre las que el había tomado notas: “

La familia tenía un ratón mascota llamado Petra. El mural debe mostrar al ratón, pero sin verse como que el restaurante está infestado.

Además, ahora que lo pienso, una especie de sensación  de Jardín del Edén puede ser bueno, ya que nuestro restaurante es un pequeño paraíso. Y los postres son muy tentadores. Tal vez debería haber una serpiente para tentar a la gente. Tal vez una pitón.

No te olvides de las uvas Cuestionables de las cuales obtenemos nuestro famoso Chianti.

La familia tenía cabras y ovejas. Tal vez podría haber algunos cerros con animales que juegan.

Recuerdo que una vez un lobo o algo acabó con mi pequeña cabra favorita. ¿Debería haber un lobo?

Kate tomó un respiro. “La lista de Guido seguía y seguía.”

Dan dijo. “Espera. ¿Guido quería una pitón? ¿En un mural de restaurante? ¿De la Toscana? “

Kate dijo: “Resulta que Guido estaba muy flipado con la pitón. A la artista le costó un montón hacer que la olvidara. Y hablar es lo que hicieron.

“La artista se reunió con Guido después de leer todas sus notas. Guido comenzó diciendo que quería diseño del mural y su calendario detallado. Afortunadamente, ella tenía una idea mejor. “Las palabras que describen imágenes no funcionan muy bien, Guido. Yo sugiero dibujarte algunos bocetos de lo que yo entiendo. Vamos a trabajar con los bocetos durante un tiempo, y luego vamos a empezar a trabajar directamente en la pared donde tus clientes puedan ver el mural “.

Dan dijo: “¡Maldita sea, esto es una alegoría no es así? Tu educación jesuita está saliendo “.

“No, no, todo esto es verdad, lo juro”, dijo Kate, levantando los dedos cruzados. “Sin embargo. Tiene mucha relación con la forma en que trabajamos en tus productos “

Dan dijo: “OK, vamos a ver. Comienzas con cualquier material que tengan los de Marketing, y entonces te sientas y hablas con ellos. Y tan pronto como puedas, empiezas a mostrar piezas del producto, como los bocetos de la artista. “

“Sí, es cierto. Y, tan pronto como sea posible, tenemos las piezas del producto en las manos de los clientes, al igual que la artista puso las cosas en la pared en el restaurante tan pronto como fue posible “, dijo Kate.

Dan dijo: “¿No hubo problemas en el camino, al igual que con el aspecto de la tía Sofía y la sangrienta pitón?”

“La artista lo gestionó muy bien. Su primer paso sobre Sofía consistió en pedir fotos de ella a la edad que Guido tenía en mente. Naturalmente, había un montón de fotos en los álbumes familiares. Le hizo elegir sus favoritos y en un principio esbozó algunas muestras, posteriormente, hizo realmente algunas pequeñas entregas con tiza o algo así. En el momento en que Sofía estaba en la pared, ellos tenían una buena idea del aspecto que tendría “

Dan dijo: “¿Hicieron todo el resto de esa manera, con un montón de bocetos en primer lugar?”

“Afortunadamente, no”, dijo Kate. “Una cosa que ayudó fue que, aunque algunas de sus reuniones habían sido fuera del restaurante, enseguida tuvieron una reunión allí, debido a que la artista quería ver la instalación real. Dos cosas importantes salieron de ahí:

“En primer lugar, no pudo evitar darse cuenta de las dos puertas en la pared, que Guido no le había mencionado ni en las conversaciones ni en las notas. Y vio que una llevaba a los baños, y la otra llevaba a la cocina. Ella le preguntó si el mural debía incorporar las puertas, y si era así, si una debía parecer abierta y acogedora, mientras que la otra pareciese cerrada, para que la gente no tratase de entrar a la cocina. Guido estuvo de acuerdo, por supuesto.

“La artista esbozó un par de ideas … una con la puerta del baño pintada para parecerse a un sendero atractivo, y uno con la puerta de la cocina luciendo como una valla cerrada. También le mostró uno con las puertas de la cocina pintadas con el fin de ocultar el hecho de que eran puertas en absoluto. “

Dan dijo: “Has dicho dos cosas. ¿Qué más? “

“La artista descubrió que había mesas pegadas a la pared del mural, no para los clientes, sino para guardar los cacharros del restaurante, como los platos y la cubertería. En los bocetos que había hecho, había detalles de todo el camino hasta el suelo, pero esos detalles no serían visibles en absoluto. Así que estar en la situación real les había dado algunas ideas importantes, una de ellas Guido la había pensado, pero olvidó mencionarla, y la otra era nueva para ambos. “

Dan dijo: “OK, ¿cuál es la lección de todo esto,  jesuita descarada?”

“Ah, Watson, conoces mis métodos. Tratamos de reunirnos no sólo con las personas con ideas sino con los clientes reales de nuestro software. En el caso de Guido,  eran la misma persona, pero al poner a Guido en el restaurante con la artista, surgió una nueva percepción. Cuando nos reunimos, no sólo con marketing sino con nuestros clientes reales y potenciales, con la presencia de simplemente esbozos de ideas de producto, aparecen siempre nuevas y buenas ideas. “

“Está bien, qué más le pasó a tu imaginario tío Guido?”, Dijo Dan.

“¿Imaginario? ¿Imaginario? Por eso, me tienes que llevar a cenar a su restaurante. En fin, trabajaron con bocetos durante un poco más de tiempo, y luego la artista dijo que era hora de empezar a trabajar en la pared real. Guido era bastante reticente. Tenía miedo de que si algo realmente feo aparecía allí, pudieran perder clientes. La artista estaba de acuerdo, pero estaba pensando en la pitón.

“Así que le preguntó a Guido si prefería seguir mirando bocetos y luego cerrar el restaurante durante un tiempo mientras ella pintaba la pared real. Evidentemente Guido no quería cerrar, y entonces se dio cuenta de que no importa la cantidad de trabajo que hubiese en los bocetos, no tendría una idea de cómo la pared quedaba hasta que no estuviese terminada. “

“A menos que se sentase allí y la viese todo el tiempo”, dijo Dan.

“Sí. Y ninguno de los dos pensaba que eso tuviese mucho sentido, y de todos modos habrían utilizado todo su tiempo y flexibilidad de costes en los bosquejos. No habría mucha capacidad para cambiar, sólo la capacidad de fallar y volver a empezar. “

“Entonces, ¿qué hicieron?”, Dijo Dan.

Kate dijo: “Al igual que ella había sugerido. La artista empezó a llegar por la mañana y pintar con tiza el mural en la pared. Ella marcaba grandes áreas, a veces, pintaba zonas más en detalle. Creo que hizo a la tía Sofía y la Parra Cuestionable con más detalle desde el principio.

“Guido estaba preocupado al principio, pero a los clientes les encantó. Les preguntaban qué estaba pasando, y ofrecían comentarios. El restaurante entero se convirtió en una especie de pequeño pueblo donde la gente hablaba entre sí y con el personal y Guido sobre lo que estaba ocurriendo. Un montón de nueva gente comenzó a llegar con más frecuencia para ver qué estaba pasando con el mural. “

Dan dijo: “¿todo se pintó sin problemas en su lugar?”

“Ni de broma”, dijo Kate. “Había un montón de cambios, algunos que Guido vio, y algunos que los clientes vieron. En una ocasión, la artista dibujó la pitón, y la gente pidió sentarse lejos de ella. Supongo que era una serpiente pitón muy convincente. Guido cedió con la pitón en ese punto. “

“OK, así que en nuestra empresa, se pone el producto ante los clientes antes de que termine, y se deja que nos den su opinión sobre él”, dijo Dan.

“Sí, es cierto. Y lo construimos suficientemente ligero como para que cuando lleguemos a las buenas ideas, podamos introducirlas sin demasiados problemas. Ahí es donde nuestras pruebas y refactorización entran en juego “

Dan dijo: “¿Qué pasa con la pared? Cuando comenzó a usar la pintura real, ¿quedaban todavía cambios pendientes? “

“Por supuesto, un montón”, dijo Kate. “Muchos vinieron de los clientes, algunos de Guido, algunos de la propia artista. En el arte, simplemente se pinta sobre los trozos malos o se borra y se vuelve a empezar en alguna zona. En el software, refactorizamos más a menudo, y a veces se reemplazan partes enteras. Preferimos refactorizar, porque es menos costoso, pero a veces simplemente nos equivocamos. “

Dan dijo: “¿Pero no es un desperdicio? ¡Si hubieras planeado mejor, no tendrías que rehacer todo ese trabajo! “

Kate sonrió. “Buen intento. Pero la cuestión no es en la planificación. Ningún número de palabras hubiera conseguido definir el aspecto deseado en la cara de Sofía. Guido tuvo que verlo en la pared. De hecho, hizo que la artista lo cambiase varias veces hasta que captó su visión de esta mujer mayor santa, pero aún sexy. La cosa fue mejorando poco a poco, y volvieron a bocetos un par de veces, pero las cosas en la pared tienen un aspecto diferente al de los bocetos.

“Creo que Guido hizo algunas concesiones importantes para que las cosas saliesen bien. La artista insistió en que se detuvieran a tiempo y en presupuesto. Por aquel momento, Guido estaba sumergido en la creatividad y podría haber estado eternamente refinando a Sofía. La artista lo trajo de vuelta a la tierra recordándole la planificación acordada. En un punto, Guido renunció a alguno de los animales del campo para centrarse un poco más en Sofía. “

Dan dijo: “Eso es lo que hace Susan, ¿no? Recuerdo que una vez me informó de que había retrasado mi funcionalidad favorita para robustecer otra funcionalidad. Tuvo serias dificultades para convencerme, pero fue bastante insistente. Al final, me di cuenta que le había dado la autoridad y la dejé ir hacia adelante. Resulta que todo fue bien, y ella puso mi funcionalidad en una actualización posterior. “

“Exactamente”, dijo Kate. “Construir el mejor producto posible en el tiempo y el dinero que tenemos no es fácil. A veces tenemos que tomar decisiones difíciles, y a veces hasta se hacen mal. Nadie es perfecto. Lo que nuestro enfoque hace es mantener todo visible: el producto a medida que crece, el presupuesto que se gasta, el tiempo conforme se agota. Y mantenemos el cuadro en la pared en todo momento, así que cuando es el momento para la gran fiesta, la imagen está lista.

“Y el mural estuvo listo para la gran fiesta de Guido también. Su hija Amelia decidió casarse, de repente según me contaron, y Guido organizó la fiesta más grande imaginable, en el restaurante. Fue pocos días después de la fecha límite original, y por supuesto fueron un montón de personas que nunca habían visto el restaurante de Guido. Se lo pasaron en grande y a todo el mundo le fascinó el mural. Por lo que yo sé, nadie preguntó por qué no había una serpiente pitón en la imagen. “

Dan pensó un momento. “Creo que lo he entendido. Tu trabajas lo más cerca posible del producto real, evolucionando tu comprensión y el producto, al mismo tiempo. Y tomas decisiones sobre la marcha, haciendo lo mejor que puedas, y asegurándote de que está siempre listo para la próxima fiesta – quiero decir listo para enviar. Suena fácil. “

Kate sonrió. “Bastante cerca. Una cosa: no es fácil. Uno tiene que estar dispuesto a trabajar en público, con todo lo bueno y todo lo malo a la vista. Uno tiene que estar dispuesto a tomar decisiones, y a redefinirlas, y uno tiene que trabajar con el fin de hacer el cambio fácil.  No es que realmente sea más fácil que las formas más antiguas. Simplemente,  es mucho mejor “.

“Es mucho mejor”, dijo Dan. “Cuando hablamos por primera vez, pensé que tendría que cerrar la empresa. Ahora tenemos un flujo constante de nuevos productos y un flujo constante de clientes más satisfechos. Gracias por explicarme cómo lo haces, adornándomelo con la historia mítica del restaurante de Guido. “

“¿Mítica?”, Dijo Kate. “Espera a degustar la Piccata de ternera de Guido en la cena que me vas a pagar. No te parecerá mítica entonces. ¿Y los baños? Son por esa puerta que se parece a un sendero cubierto junto a la parte privada del jardín. “

Avances en burn-down charts: la “burn-up-down” chart

Hacemos Scrumban y eso nos ha obligado a hacer alguna que otra cosa curiosa. Una de ellas consistía en tener dos gráficas el burn-down para nuestras historias de Scrum (las planificadas) y el burn-up para nuestras historias de Kanban (las no planificadas). Básicamente se trataba de poner un objetivo de historias planificadas y una especie de tope a las historias no planificadas… planificar el trabajo que te va a llegar de forma no planificada tiene algo de absurdo, pero se puede hacer. No hay que medir el pasado y esperar que el futuro se comporte. Tener dos gráficas resulta un poco incómodo, aunque no es un gran problema. Reservar ya desde el principio una parte de tu ancho de banda a Kanban denota que tenemos unos POs un poco “volubles”. Tampoco pasa nada.

En cualquier caso en la última vuelta de tuerca a nuestro sistema hemos decidido superponer ambas gráficas para así poder saber de un vistazo cómo va el Sprint independientemente de haya habido mucho o poco Kanban. Aquí os pongo un ejemplo de nuestra “burn-up-down chart”:

En este caso la línea azul señala el ritmo ideal de completado de US de Scrum del Sprint. En rojo vemos la realidad, como la parte de Scrum lleva un pequeño retraso; en amarillo el Kanban real, las historias no planificadas que se han ido terminando. De esta gráfica podemos obtener la siguiente conclusión, la primera semana a pesar de que se acumuló retraso entre las historias planificadas el equipo de desarrollo cumplió con su objetivo (ya que lo que faltó de Scrum se hizo de Kanban), la segunda semana la cosa fue peor.

Al final la manera de leer esta gráfica es sencilla.

  • Si las gráficas amarilla y roja se cortan antes de terminar el Sprint el equipo de desarrollo ha cumplido su objetivo.
  • Cuanto más suba la línea amarilla peor planificación se hizo.

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

  • El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
  • El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
  • El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

  • Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
  • No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
  • Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
  • Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro. 🙂

Sprints fijos, entregables adaptables (I)

Cualquiera que nos haya seguido desde el inicio sabe que hemos cambiado de metodología varias veces. Unos lo llamarán Kaizen, otros lo llamarán “culo veo culo quiero”, otros lo llamarán “vagabundeos por la el mundo de la agilidad”. La cuestión es que empezamos con un SCRUM chapucero, evolucionamos a un Kanban de postal y ahora estamos con un ScrumBan del que nos podemos sentir bastante orgullosos.

El tamaño del sprint también ha sufrido alguna que otra modificación. Empezamos, como mandan los cánones, haciendo sprints de 2 semanas (casi tan difíciles de estimar como de implementar), el resultado, por novatos, fue tan malo que nuestra evolución por reacción nos llevo al lado contrario, “¿un sprint largo? ¡no!, mejor”, fuera sprints y viva el despliegue continuo. El despliegue continuo (también llamado bug continuo por aquellos tiempos), funcionó mientras teníamos una aplicación beta en un puñado de tiendas alrededor de nuestro apartamento de Bogotá. En cuanto nuestra red de tiendas y nuestra exigencia aumentó volvimos a los sprints, esta vez largos, de 2 meses, dada la gran dificultad para actualizar todas y cada una de las tiendas a mano y volvimos, por tanto, a Scrum pero con un toque de Kanban: Scrumban.

Pronto nos dimos cuenta de que el entorno real en el que se ejecutaba nuestra aplicación no era comparable al de nuestra oficina, ni a nada que pudiéramos reproducir en ella, así que seleccionamos una tienda como beta tester y decidimos instalarle antes las versiones que producíamos. Concretamente decidimos dividir nuestro sprint de dos meses en tres mini-sprints de 3 semanas e instalar la versión resultante de cada uno de esos mini-sprints en la tienda de nuestro compañero Boris para que él nos diera feedback temprano.

El resultado ha sido que las primeras historias que se implementan en el sprint no tienen que esperar dos meses para llegar a una tienda de verdad, sólo 3 semanas, de forma que detectamos los errores antes y los corregimos antes, además de que repartimos los tests exhaustivos pre-release durante todo el sprint en lugar de acumularlos todos al final y mantenemos la tensión (la buena, se entiende) del equipo de forma constante. No hemos, no obstante, modificado la estructura del sprint, que se planifica para dos meses, es decir, no hacemos planficación, demo y retrospectiva en cada uno de los mini-sprints, sino sólo en el sprint principal. Los mini-sprints nos marcan los hitos en los que es necesario alimentar a nuestro beta-tester para ir cazando errores complicados, (para los fáciles tenemos el TDD, los test de integración y demás) que de otra manera se macerarían durante unas cuantas semanas provocando una infección de las buenas al final del sprint.

Así llevamos varios meses y varios meses nos quedan por delante. Hasta que llegue un momento en el que el ritmo de añadir funcionalidad a TiendaTek disminuya, la necesidad de nuevas versiones también y todos nuestros esfuerzos pasen a un entorno mucho más amigable y actualizable como es la web, entonces… ¿qué haremos?

Carta abierta a una historia de usuario

Estimada Historia de Usuario:

Empezamos mal. Tú y yo sabemos que de estimada nada de nada. Algo de cariño, cierta relación amor-odio, un respeto mutuo inquebrantable… eso sí. Pero de estimarte en Frogtek poco o nada.

Es posible que los gurús del agilismo no comprendan nuestra relación, demasiado liberal quizá, poco comprometida dirán. Me llamarán poco ortodoxo, hereje y hasta libertino. Pero es lo que hay, en Frogtek no te estimamos. Y no me refiero a tus tareas internas o a tus detalles más íntimos, me refiero en general, al objeto que centra la atención de cada uno de nuestros programadores cada día por un periodo indeterminado de entre media hora a cinco días.

Sé que te preguntas qué me has hecho, porqué cuando todas las empresas ágiles debaten interminablemente cual es la mejor manera de estimar una historia de usuario, yo te pago con el desprecio. Ellos te asignan puntos, te dedican tiempo, algunos hasta te compran ropa y tú disfrutas del momento orgullosa, coqueta, probándote las distintas tallas. Y yo nada, pasas discretamente por mi tabla, sin grandes entradas, sin protagonismo, sin que hablen los programadores demasiado de ti hasta que no te llevan al huerto. Aquí te pillo, aquí te mato. Y la salida es peor, si te visto no me acuerdo.  En el fondo no sé de qué te extrañas, todas sois similares y a largo plazo me parecéis todas idénticas. Además mis sprints son largos, así que es mejor para los dos mantener las distancias, es que no sólo sois todas iguales, es que encima sois muchas. Dirás que tengo miedo al compromiso, que para llevar dos años en esto de agilismo soy uno inmaduro, que soy caprichoso e infiel, que soy, en definitiva, un cerdo sólo interesado en coleccionar una historia de usuario tras otra, una muesca más en mi revólver… y algo de razón no te falta.

Hubo un tiempo en el que te estimé, lo sabes. Y no funcionó. Era una relación demasiado absorbente, suponía demasiada dedicación, horas y horas hablando de ti, alimentando tu ego cuando tan sólo habíamos empezado a conocernos y nada sabíamos el uno del otro… me agobié. Lo intenté y fue mal, te estimé y tú siempre te quejabas, te sentías, a veces, sobre-estimada, otras, las más, era todo lo contrario. Así que ya ves, para hacerlo mal, mejor no lo hacemos. Además en Aragón siempre hemos sido más de guiñote.

Ahora me va mejor. Soy más feliz y estoy centrado en lo que realmente me gusta. Os trato a todas por igual y al final del sprint he tenido tiempo para todas vosotras que esperáis desde el principio de cada sprint, para muchas otras que vienen sin avisar y para mi mismo, sin comerme la cabeza. Quizá algún día estime una historia de usuario, quizá algún día le vea el valor a una relación más estable, profunda y comprometida, pero de momento… esto es lo que hay.

Siempre podemos ser amigos.

Atentamente,  Frogtek.

Revisión de código

Code Review

¿Revisar código?

¿Para qué?

¿Lo has probado?

Pues ya está ¿no?

Pues no. O al menos en Frogtek no nos vale. Y se agradece, la verdad. Veamos cómo y cuándo hacemos las revisiones de código.

Actualmente realizamos tres tipos de revisión de código:

  • Revisiones de código de las User Stories. Una vez terminadas y subidas al repositorio se revisan usando ReviewBoard, dando feedback, cuando sea necesario, a través de la herramienta. Dicha revisión se realiza dos veces. La primera por un programador y la segunda, por el tester antes de realizar el testing y verificación de la User Story.
  • Reuniones de revisión de código. Consisten en unas reuniones semanales en las cuales nos juntamos todos a ver, revisar, comentar… una funcionalidad nueva o un refactor especialmente delicado. Cualquier programador puede proponer código para ser revisado y nos animamos unos a los otros a ello.
  • Pair programinng de User Stories o parte de ellas. Aunque lo realizamos menos de lo deseado, lo usamos sobre todo cuando la funcionalidad que programar es complicada o propensa a errores. Nos ha dado muy buenos resultados siempre que lo hemos utilizado.

Solo llevamos alrededor de un año aplicando estás técnicas de manera exhaustiva, pero creo que las mejoras han sido sustanciales en la calidad de nuestro código y de nuestras habilidades.

Personalmente, lo que más me ha gustado es el conocimiento que se adquiere de toda la aplicación gracias a las revisiones. Ya no solo sabes lo que tú has hecho, sino gran parte de lo que el resto ha programado también.

Como nota final, un vídeo gracioso sobre Pair programing. En Inglés, lo siento.

Evolucionando hacia Scrumban

Creo que fue Heráclito el que dijo que “todo fluye”, bueno según Wikipedia dijo “En un río entramos y no entramos, pues somos y no somos”, mucho más poético y críptico… Pues bien, en Frogtek no sabemos si todo fluye o no, si somos o dejamos de ser, y de momento, lo de entrar en el río, dado que fuera (en Morillo) a la orilla del río Cinca, hay unos tres grados bajo cero, no nos lo planteamos. Lo que no ha dejado de cambiar desde que empezamos con los método Ágiles ha sido nuestra tabla de Kanban, ni nuestra forma de trabajar. Resumamos en unas lineas nuestros “vagabundeos” por este mundo de las metodologías ágiles.

Tras darnos cuenta enseguida de que Waterfall no nos servía para Frogtek, empezamos queriendo implementar Scrum, y con toda nuestra buena voluntad tratamos de adquirir todos y cada uno de los artefactos que Scrum define. Nos surgieron varios problemas, a saber, reuniones interminables de planificación, estimaciones poco afortunadas, cliente ausente… Lo del cliente merece una explicación, nosotros creamos software para pequeños tenderos en países emergentes, hay millones de ellos pero nunca se van a involucrar real y profundamente en un proceso de diseño como el nuestro (suficiente trabajo y problemas tienen), además nuestro potencial cliente no era uno sólo de ellos o un grupo de tenderos, si no los tenderos del mundo en general, casi nada. El resultado es que David, el CEO, hacía de PO, diseñaba las funcionalidades en función del feed-back informal que recibía en sus visitas por las calles de Bogotá y las empaquetaba en Sprints para que nosotros programáramos.

Pronto nos dimos cuenta que necesitábamos algo más flexible, las reuniones de planificación no es que fueran muy útiles (3 horas de reunión es la receta perfecta para el aburrimiento), no entendíamos bien los datos, burn-down charts, que nos proporcionaba nuestra excesivamente completa herraminenta AgileBuddy, no dábamos ni una con las estimaciones y sobretodo el feed-back recibido por los tenderos no era ni formal, ni periódico, ni definitivo, por lo que las prioridades cambiaban rápido, incluso demasiado para Scrum. Así que Kanban nos pareció más adecuado: implementemos sobre la marcha lo que el PO decida que necesitamos en cada momento y saquemos 10 ó 20 versiones de pre-producción al día (gracias a Dios, bueno y a Julio, por la Integración Continua y HUDSON) y versiones de producción bajo demanda. Perfecto cuando tienes 5 tiendas. Además puedes diferenciar entre US y Bugs, medir la velocidad semanal.

El problema surge cuando en lugar de 5 tiendas alrededor de nuestro apartamento de Bogotá tenemos 25, 30 o más repartidas por toda la ciudad. Y qué ciudad. Moverse de una tienda a otra puede costar cerca de dos horas en algunos casos, la conexión para que los tenderos puedan actualizarse automáticamente TiendaTek (como hacemos en segundos en España) funciona de pena. En resumen aunque la tecnología esté preparada para escalar sin problemas, los temas operativos a pie de calle son un verdadero reto, y cada vez que sacábamos una nueva versión era un dolor de cabeza considerable, primero por lo costoso del despliegue y segundo porque aparecían bugs que nos complicaban todo más si cabe.

Así que se acabó el aquí te pillo aquí te mato (fue bonito mientras duró) y empezamos a plantearnos evolucionar poco a poco hacia Scrum de nuevo. Básicamente retomamos los Sprints de entre 1 y 2 meses, ya no era viable hacer versiones del software del teléfono cada 2 semanas, nos olvidamos de herramientas personalizadas online y recuperamos las reuniones de planificación, aunque seguimos sin estimar de manera propiamente dicha (ya hablaremos de esto pronto), sin embargo la manera que tiene Kanban de tratar con la gestión de Bugs nos seguía gustando… Y en estas apareció Medinilla, su presentación de Scrumban en la Agile Open Spain y casi nos “corren a gorrazos” porque el pobre Pedro definió lo que hacíamos en Frogtek en una de las sesiones como “Kanban puro“. Puro, el que nos metieron.

La consecuencia fue una magnífica reunión de retrospectiva donde dimos unos cuantos pasos adelante y entre los más importantes, el pomodoro síncrono (¡que funciona!) y migrar a un Scrumban más académico. O “lo que es lo mismo” una nueva versión de nuestra tabla, con dos filas (por proyecto, aunque esto realmente da igual) una para las US de Scrum (las que hemos planificado para el Sprint), la superior, otra para los Bugs (los errores que surgen sin previo aviso) y US de Kanban (las que no estaban planificadas, pero surgen por urgencias de todo tipo o mala planificación), la inferior.

Esto nos permite medir nuestra velocidad de Scrum, nuestra velocidad de Kanban “bueno” y la de Kanban “malo“. O lo que es lo mismo, si definimos:

  • [VS], velocidad Scrum
  • [VK+], velocidad Kanban bueno
  • [VK-], velocidad Kanban malo
  • [VT] = [VS] + [VK+] + [VK-]

podemos saber cosas como:

  • El nivel de trabajo máximo al que nos podemos comprometer en un momento dado, [VS] + [VK+]
  • El nivel de trabajo medio que sacamos normalmente adelante, [VS].
  • La tasa de fallos que tenemos, [VK-] / [VT].
  • El “focus factor”, o cómo de enfocados estamos, [VS] / ([VS] + [VK+])

Con un buen equipo de programadores [VK-] debería ser pequeño, con un buen PO y Scrum/Kanban Manager (y un buen cliente, por pedir que no quede) [VK+] debería ser pequeño y por lo tanto el Focus Factor grande cercano al 100%. El objetivo, acercarse al Nirvana de cualquier start-up, “hacemos lo que estaba previsto hacer y a la primera lo hacemos bien“. Si ya encima te pudieras asegurar de que la US en cuestión era lo que quería el cliente y la va usar realmente…

Al final del proceso y si cuentas las US y Bugs que se terminan cada semana te sale una gráfica como la siguiente*.

* En la gráfica a parte de ver los puntos de Scrum (en azul y morado), los de Kanban bueno (en amarillo y naranja) y los de Kanban malo (en rojo) tenemos una diferenciación más: entre US que aportan nueva funcionalidad al usuario y US de infraestructura que que no aportan directamente pero son necesarias para optimizar o como base tecnológica para hacer luego alguna otra cosa. Tuvimos que meter esa diferenciación para controlar el trabajo en las “catacumbas” de nuestros productos, ya que a veces pasar la escoba es necesario y hasta divertido, pero no tenemos que olvidar que nuestra prioridad es el cliente y que “lo mejor es enemigo de lo bueno“.

Agile Open Spain 2010

Los días 12 y 13 de Noviembre se celebró el segundo Agile Open Spain (AOS), esta vez en Barcelona, y como no podía ser menos, allí estuvo Frogtek. Fueron dos días, bueno un día y medio, muy intensos, donde llenamos nuestras mochilas de nuevas ideas.

Algo que nos llamó la atención fue el formato del evento donde para comenzar e ir rompiendo el hielo, un poco de networking, así los asistentes nos íbamos agrupando en función de algunos puntos en común, por ejemplo el lugar de procedencia, hobbies… Una vez que ya habíamos calentado tocaba organizar la agenda del sábado, eso si, tenía que ser de manera ágil y abierto a todo el mundo, de manera que aquel que quisiese podía proponer un tema y después colocabas una pegatina a aquellos debates, presentaciones… que te resultasen de mayor interés. Nosotros propusimos tres temas: experiencias Kanban, TDD vs Test On Demand y Como diseñar tu propia metodología. Para finalizar se distribuían por las diferentes salas y franjas horarias. Ya estaba todo listo!

Para tratar de recoger la mayor información posible, Pedro, Jose y yo nos distribuimos por las diferentes salas. Entre los temas de debate se habló sobre el uso de frameworks, software craftmanship, Kanban/Scrumban, TDD, diseño ágil, como convencer al cliente, incentivos en el trabajo, como matar scrum … entre muchos otros donde el objetivo era difundir y compartir conocimiento y experiencias.

A modo de conclusión, el AOS nos supuso varios puntos de reflexión, tanto profesional como personalmente. Ye tenemos pensado algunas posibles mejoras en nuestra metodología de trabajo que os iremos contando conforme las vayamos aplicando. Una de ellas la práctica del pomodoro.

El curso de SCRUM en Walqa: ¿un éxito? no… dos!

Esto lleva un tiempo un poco parado, es cierto, pero no es que lo hayamos abandonado, es que tenemos mucho trabajo y a veces encontrar tiempo para ordenar las ideas y escribir un post resulta complicado. Hoy, sin embargo, me he decidido a romper este silencio por algo que pasó ayer.

Resulta que estábamos en pleno TPV, dando cuenta del menú de Walqa y viendo un video más gracioso que científico (bueno para gustos colores) cuando unas 20 personas irrumpieron en nuestra oficina porque querían ver nuestra tabla de Kanban. ¿Una manada de groupies de Frogtek?. No. ¿La gente del Agile Open Spain venían a flagelarnos porque tenemos más de un Product Owner?. Tampoco… menos mal. Mucho mejor, era la segunda tanda de gente del Curso de SCRUM que Teresa Oliver estaba dando en Walqa.

Da mucho gusto que te tomen como modelo para este tipo de cosas. Nosotros ni somos perfectamente ágiles según los estándares del “Agilismo puro”, ni pretendemos serlo, ni seguramente conseguiríamos serlo aunque lo intentáramos. Hemos avanzado muchísimo desde que empezamos y estamos encantados de contar lo que hemos aprendido por el camino, y de aprender muchas otras cosas más. Ójala pronto empecemos a ver alguna otra tabla más por Walqa, será señal de que estamos en el camino correcto.

También da mucho gusto saber que las iniciales dudas de si habría al menos 10 personas para hacer un curso de ese estilo en Walqa han sido ampliamente superadas con casi 4o personas… y eso que me consta de 3 ó 4 amiguetes que hubieran querido asistir y no han podido, lástima porque hubieran podido aportar cosas importantes ya que son gente que sabe mucho de tecnología y de proyectos. Bueno, al grano, parece que hay masa crítica así que pronto llegará el momento de mover más la cosa empezando por… ¿un curso de TDD?.

Y por cierto… aprovecho para arrojar el guante para que alguno de mis compañeros que estuvo en la Agile Open Spain 2010 se anime a contar lo que allí vimos, aprendimos y cómo nos dieron algún que otro revolcón… y voy a romper una lanza por Jose, Linares y Pedro que se atrevieron a hablar de Frogtek delante de gurús de la talla de Medinilla & company.

Antiguas entradas