Ayer nos mudamos a las nuevas oficinas de Curridabat. A (casi) todo el mundo le queda más cerca de su casa y la verdad es que están muy lindas, por lo que reina la alegría. Poco importa que el edificio esté a medio construir. El nuevo lugar de almuerzo está genial y estamos por anotarnos en masa en un gimnasio con pileta y todo.El team room tiene muchas paredes y eso sacía mi apetito de post-its. Si me acuerdo, mañana traigo la cámara y empiezo a postear imágenes del lugar de trabajo.
En la retrospectiva del sprint #1 hubo un comentario de parte de un miembro del equipo que me pareció interesante: a pesar de nunca antes habíamos hecho Scrum, su sensación es que las reuniones eran un poco caóticas y que el ScrumMaster (i.e. yo) tenía que poner orden. Mi intención original era comenzar el proyecto siendo permisivo (timeboxing estirable, opiniones de miembros externos no moderadas, roles un poco difusos), pero me di cuenta que el truco está justamente en empezar siendo ortodoxo. Uno de los primeros puntos en los que decidí ponerme inflexible desde el comienzo mismo del sprint #2 es el timeboxing: las reuniones estaban comenzando tarde y muchas veces se extendían demasiado. Siendo que soy un tipo más visual que otra cosa, decidí comunicar la idea del timeboxing de la forma más explícita posible. Lo principal, claro está, fue el cambio en mi actitud, pero estos dos bichos me ayudaron bastante:
- El chanchito: una caja de cartón con un agujerito en su tapa. El que llega tarde a un daily meeting o a la retrospectiva paga según lo estipulado en una tabla que está pegada en la pared:
- 0'<t<5' : 200 colones (0,40$)
- 5'≤t<10': 500 colones (1$)
- 10'≤t": 1000 colones (2$)
- El sapo: una cajita simpaticona que tiene 4 posibles cronómetros - básicamente los únicos que usamos son el de 15' y 60' - a todo el mundo le parece simpática, pero además viene siendo muy efectiva
Nota: hasta el momento llevamos recaudados unos 7000 colones (14$) - la idea es usarlo para comprar snacks para picar durante las reuniones
Finalmente decidí darle un número al sprint abortado, por lo que el que acaba de terminar fue el #3 nomás. El review del viernes salió bastante bien...o por lo menos mucho mejor de lo que me lo esperaba. A diferencia del primer sprint review, esta vez hubo mucho demo y no tanta discusión filosófica. Creo que en ese sentido ayudó bastante el aclarar que íbamos a ser estrictos con el timeboxing y el simple de hecho de que ya habíamos tenido un review antes, que en mi opinión había salido bastante mal.
Unas horas antes del review MC y MR me dijeron que había que preparar una presentación (i.e. PPT, o al menos eso entendí yo) en las que se iba a introducir lo hecho en el sprint. Yo contesté que no era aconsejable invertir más de 1 hora en total en la preparación del review y que, además, el Product Owner era quien había elegido los user stories que iban a ser desarrollados, por lo que no valía la pena explicarle lo que él mismo ya conocía bien. La contra-respuesta fue que iban a asistir a la reunión
personas que poco sabían del proyecto (i.e. futuros miembros del equipo y un directivo de la empresa, así como LC). Mi contra-contra-respuesta, tal vez un poco dura, fue que no era responsabilidad del equipo subsanar el hecho de que no todos los stakeholders habían hecho sus deberes. La c-c-c-respuesta tuvo mucho sentido: "van a pensar que trabajamos mal". Y sigo en forma de diálogo:
- El review no es para quedar bien, sino para obtener feedback
- Pero de qué nos sirve el feedback de alguien que no entiende lo que ve
- Buen punto, pero no tapemos agujeros. Si hace falta que sepan y no saben, que se note
Sin embargo me quedó un sabor amargo después de esta charla...¿Quién tiene que poner al tanto a los stakeholders? ¿Y qué pasa si esos stakeholders están por ingresar al equipo?
Este viernes termina nuestro segundo sprint, que empezó a un tanto abruptamente hace dos lunes. ¿Qué pasó? Érase el martes de la primer semana del que originalmente era el segundo sprint, cuando apareció en nuestro Outlook un tímido mail de QM contando que acababa de salir un nuevo release de PR. ¿Qué es PR? Un producto que en un principio parecía ser un acérrimo competidor, después cambiamos el rumbo con un buen diferenciador...¡y de repente salen con una versión que parece una copia de nuestro Product Backlog! Emergencia, gritos, llantos y la crisis que es oportunidad. Miércoles reunión a las corridas con ZF y AC. Baraja que te baraja alternativas y decidimos volver a reunirnos el jueves, que también resultó a puro debate. Ya pasado el mediodía decidimos apretar el botón rojo: abnormal sprint termination. El viernes lo usamos para preparar entre todos algunas User Stories y el lunes siguiente, a correr. A ver qué nos depara el Review del 2/2...
Como dije, mucho no voy a contar, aunque cuente mucho. Llamemos al proyecto en el que estamos embarcados
CC. El nosotros ya es, como la realidad, complejo de describir: quien suscribe cumple el rol de ScrumMaster,
ZF es Product Owner y el Equipo lo integran, por ahora y solamente por ahora,
AD,
MC y
MR. Estamos trabajando en conseguir por lo menos 5 personas más. Además está
AC, que participa del lado del Product Owner, aunque no puede dedicar mucho tiempo al proyecto. Y además
LC, que va a integrar un equipo aparte, que va a tomar tareas de investigación. Y
QM, que del dominio sabe un montón. Y
SL, que está con temas de marketing. Pero en lo que a mí respecta todos estos últimos no son más que stakeholders. Importantes, cruciales, pero siguen siendo
chickens.
El objetivo es poder tener un beta "lo antes posible". La idea es salir con la versión 1.0 a mediados de año. Como creo haber contado antes, lo que tenemos entre manos es un producto masivo. Lo que se dice software enlatado, aunque la imagen evoque conservas o duraznos en almíbar. El lugar de trabajo por ahora son las oficinas de Sabana Norte, aunque en breve nos vamos a estar mudando a la zona este, por Curridabat. Por ahora tenemos algo bastante parecido a un "team room" (belicosamente conocido también como "war room"), del que espero poder postear algunas fotos en breve. Para realizar el tracking de product backlog items y tareas estamos usando básicamente post-its y papelitos. Estamos probando hacer iteraciones de 2 semanas de duración. El Daily Meeting se hace todos los días a las 13:30hs y está durando unos 8 minutos más o menos. El Sprint Planning Meeting está timeboxeado en 2 horas (1 hora con el Product Owner y 1 hora solamente para el equipo), el Sprint Review Meeting en 1 hora y la Retrospectiva también en 1 hora. Para las llegadas tarde al Daily Meeting tenemos una cajita que usamos de alcancía y que bautizamos "el chanchito". Mandé a comprar un cronómetro para las reuniones de lo más chulo.
(suspiro)...creo que con esos datos ya se pueden ir ubicando...
La idea de este blog va a ser contar esos detalles nimios que colorean todo proyecto de desarrollo. Y no es cualquier proyecto, sino que este va a puro primerizo: mi primer proyecto como ScrumMaster y el primero utilizando Scrum en Artinsoft. Qué puedo decir? Basicamente todo aquello que no puedo. En principio voy a contar poco y nada sobre el producto en si. Lo segundo es más polémico: nombres. Voy a usar iniciales para referirme al resto de los integrantes del grupo de trabajo. Pero esí, chismosos del mundo, a no ilusionarse. La idea no es sacar trapitos al sol, sino simplemente dejar asentado qué pasa en esta oficina...si puedo, día por día.