La preparación es muy importante

Obtén la versión básica de tu idea

Deja que las cosas sigan su cauce 

Usa timebox para tomar decisiones

Mentores sí, pero con cuidado

Acostumbrate, cometerás fallos

Agradecimientos

Este domingo por la tarde estaba haciendo un postre, lo he hecho múltiples veces, y por lo que dicen mis compañeros no me queda mal :-) En esta ocasión cuando lo saqué del horno y lo probé, tras dejarlo enfriar claro, casi me muero del susto, no estaba malo, estaba mucho peor. ¡Me olvidé de poner el azúcar!, un error de principiante. Pero se me encendió una bombilla ya que de esta experiencia podía sacar un artículo "interesante" para el blog.

El post de Ancor que me animo a escribir esta entrada en el blog.

Es curioso como puedes conectar cualquier anécdota cotidiana para sacar conclusiones de otro campo que nada tiene que ver. Aquí van las conclusiones que saqué de hacer un postre, aplicadas al desarrollo de software.

Evita el Cowboy Style

Cuando a la gente le hablas por primera vez de desarrollo ágil muchas veces piensa que no es más que tirar la documentación y ponerse a programar como si no hubiese mañana. Nada más lejos de la realidad. El desarrollo ágil intenta evitar hacer cosas que no tienen valor (muy parecido a "lean"), pero eso no quiere decir que no haya que planificar o tener en mente la "imagen global" del proyecto.

Lo que yo he hecho en la cocina es Cowboy Style, he ido cogiendo los ingredientes a medida que los necesitaba y mezclándolos, incluso prestando atención a otras cosas durante el proceso, lo raro es que no hubiese metido la pata más aún. Gracias a Dios no es lo que hago normalmente. Lo que debía haber hecho es terminar con todo lo que estuviese haciendo para que no hubiesen intromisiones, preparar todos los ingredientes antes de empezar revisándolos con la lista de la receta y posteriormente con calma preparar el postre.

En el desarrollo de software es exactamente igual, incluso muchos equipos han incluido un sus tableros Scrum o Kanban (o Scrumban o como quieras llamarlos) una columna que indica cuando una funcionalidad está lista para ser implementada, es decir cuando tienes todos los datos necesarios para no hacer una chapuza y que dicha funcionalidad de verdad aporte valor una vez la hayas completado. Si, en cambio, haces lo que yo he hecho en la cocina terminarás trabajando por dos o peor.

Que lo hayas hecho muchas veces no quiere decir que no te pueda salir mal

Este postre en concreto lo había hecho unas cuantas veces, razón por la que me he confiado, muy mal. Ya habéis visto que incluso cuando tienes experiencia puedes meter la pata, somos humanos. Ya tenía un proceso que me funcionaba, ha sido cuando he modificado ese proceso, sin ninguna razón aparente, cuando todo ha fallado.

Lo mismo se puede aplicar al desarrollo y sus metodologías. Si tienes un proceso que te funciona, o no, no lo puedes cambiar de cualquier manera, tienes que experimentar, documentarte sobre como mejorarlo, pero no cambiarlo a la ligera porque algo simplemente no te gusta. Ocurre muy a menudo que equipos que aplican Scrum en sus proyectos no terminan de sentirse cómodos, pero lo que hacen muchos es cambiar sus practicas sin una experiencia previa, mal, porque no sabes si estas mejorando o empeorando.

Intenta hacer TDD 

Recordando el tweet de Ancor, ha sido el no tener una prueba unitaria lo que ha provocado que fallase al hacer el postre. Imaginad que con la lista de ingredientes los preparo todos y los dispongo para hacer la masa. Luego cuando termino de hacer la masa reviso que los he utilizado todos, no habría cometido ese error, ¿verdad?

En desarrollo de software puedes lograr algo muy similar haciendo uso de TDD (Test Driven Development). Al pensar en una prueba antes de desarrollar la funcionalidad, te está forzando a pensar el problema de forma que se evita fácilmente el Cowboy Style. Y como punto extra, tienes un código soportado por pruebas :-)


Y eso es todo por esta vez amigos :-)

La semana pasada tuve la oportunidad de impartir un taller de Scrum en AdejeTec 2012, no es el tipo de formación al que estoy acostumbrado, pero utilizando la experiencia de algunos gurús, mi propia experiencia en el uso de Scrum día a día y poniéndole un poco de empeño, parece que salió bastante bien. Por esta razón voy a explicar que es lo que hice, así podrás decirme si se puede mejorar de alguna manera o tal vez quieras organizar tu propio taller. Te aseguro que es aun más divertido de lo que yo pensaba.

Tenía libertad total para el desarrollo del taller, por lo que no quería que fuese una clase magistral en la que yo hablo 2 horas y los asistentes se duermen al fresco del aire acondicionado. Desde el principio quería que fuese una actividad en la que todo el mundo participase y los conceptos fuesen surgiendo durante la ejecución, de esta forma se entienden mucho mejor.

Como es inevitable, comencé con una pequeña presentación, al fin y al cabo, ninguno de los asistentes conocía lo que era Scrum. Eso sí, la intente hacer en 15 minutos o menos, porque yo soy de esas personas que cree que la teoría de Scrum no es para nada compleja, en realidad es muy sencilla. Lo realmente complicado es llevarla a la práctica.


Durante la presentación se explican los roles involucrados en Scrum, las actividades y "artefactos" de Scrum y algunos consejos relevantes así como una breve bibliografía. De esta manera se rompe un poco el hielo, los asistentes hacen unas cuantas preguntas y se ponen en situación, facilitando el taller posterior.

La verdad es que aunque me encantan los juegos para mostrar conceptos, mi favorito es The Marshmallow Challenge, en mis fuentes habituales, como TastyCupcakes, no encontraba nada que me convenciera. Así que tocó googlear un poco y llegué a dos páginas que me parecieron muy interesantes.

• Play the Scrum Simulation (based on XP Game) de Michael Sahota
• Training excercise: Scrum simulation de Karen Graves

La idea de Michael Sahota de utilizar las tarjetas de XP Game como historias de usuarios me pareció fantástica, porque en 2 horas hay muy poco tiempo para que los propios asistentes escriban sus historias de usuario. Y por otra parte las historias descritas en XP Game son increíblemente simples y divertidas, se trata de actividades muy sencillas, o quizás no tanto, como inflar 10 globos de un determinado tamaño o hacer 5 barquitos de papel. Además ya tienen un valor de negocio asignado que me parece bastante apropiado porque hace plantearse a los jugadores que historias son más convenientes y cuales son muy complejas para el valor de negocio que aportan.

Historias de usuario y tarjetas de roles utilizadas

Como al taller solo fueron 7 personas tuve la oportunidad de hacer un único equipo y estar con ellos todo el rato, creo que esto influyó en que fuese tan bien. Así que después de entregar las tarjetas de los roles al azar, y tuviésemos nuestro Scrum Master, el Product Owner y los miembros del Equipo, les entregué el taco de tarjetas con las historias de usuarios. Durante los primeros 20 minutos crearon un Product Backlog priorizado y estimado, y prepararon el primer Sprint.

Se pusieron manos a la obra, y cuando acabaron se dieron cuenta que la estimación no había sido tan buena como creían. Cada sprint lo realicé de 4 minutos, tiempo que creo que es bastante bueno, ni mucho ni poco. Algunas tareas habían llevado mucho más de lo que creían y otras menos, pero no lograron completar tantas tarjetas como habían estimado.

El equipo trabajando al 100% para completar su sprint

Ningún problema, durante 10 minutos se planificó el segundo sprint y posteriormente lo ejecutaron durante 4 minutos. Como muchos habréis adivinado, en esta ocasión acertaron mucho más, ya tenían cierta experiencia. En el tercer sprint fue mucho mejor aún, y ellos mismos se iban dando cuenta de estos detalles y haciendo preguntas sobre la organización del backlog, el uso de prototipos o spikes para estimar en la siguiente iteración, auto-organización del equipo, etc.

Al final los tiempo elegidos estuvieron muy bien, 20 minutos para la planificación inicial, 10 minutos para cada planificación de sprint posterior, 10 minutos para cada revisión de sprint y 4 minutos para ejecutar cada sprint. Parece que puede sobrar mucho tiempo, pero no es así, primero necesitas dejar tiempo para una retrospectiva, y segundo necesitas responder dudas sobre el proceso que les van surgiendo poco a poco.

Conclusiones

Las conclusiones en un evento de este tipo siempre son subjetivas, pero creo que son unas buenas ideas de partida para mejorar la experiencia.

• Los asistentes me comentaron que posiblemente estaría bien llevar más documentación escrita, eso haría que la pudiesen consultar en cualquier momento y además serviría como apuntes para el futuro.
• En la retrospectiva detecté que hubiese sido interesante realizar algunas preguntas que les hubiese forzado a plantearse nuevas situaciones o problemas, de forma que surgiesen más dudas respecto al uso diario de Scrum.
• Mantener el proceso lo más simple posible y dejarles tomar decisiones hace que se esfuercen mucho y hagan sus propias preguntas. Siempre dentro de unos límites para que no se alejen de Scrum, al fin y al cabo primero tienen que aprender como funciona, antes de cambiar nada.
• Dejar algunas tareas definidas de manera poco específica hizo que al final de un sprint se dieran cuenta que quizás esa no era la solución deseada, eso está muy bien porque es algo que ocurre en la vida real continuamente.

Ideas

No lo tengo claro, pero quizás vosotros me podais dar una segunda opinión respecto a algunos temas.

• ¿Sería interesante aumentar el tiempo del taller para que los asistentes aprendan a crear historias de usuarios? Yo no tengo clara mi posición respecto a esta cuestión, aunque siempre he creído que las historias de usuario pueden ser un taller bastante largo por si solas. 
• El equipo en ningún momento creó tarjetas ni actualizó el scrum board durante la iteración, ¿habría sido interesante alargar el taller y que lo hicieran? Debido al límite temporal del taller decidí que dicha actividad no les habría aportado tanto como el resto, por lo tanto es algo que les expliqué y debatimos pero no se practicó.
• En vez de tener una única retrospectiva al final del taller, ¿sería interesante hacer una retrospectiva al final de cada sprint, teniendo en cuenta el coste temporal para el taller?