O, cómo empatizar con un PO y avances en reuniones diarias, que dirían en Microsiervos.
En el día a día de un proyecto de Scrumban con duraciones de sprints de alrededor de unos dos meses los programadores corren el riesgo de convertirse en "operarios" de una especie de "cadena de montaje" a los que les llegan una detrás de otra User Stories, más o menos relacionadas entre sí, que implementan como churros. Lo de los churros está bien, es decir, está bien la idea es tener un equipo que sea capaz de sacar funcionalidad adelante de la forma más optimizada posible, que sean una máquina engrasada que funciona a toda velocidad. El problema es controlar que el equipo no pierda la perspectiva de por qué se está haciendo lo que se está haciendo y tenga pequeños objetivos intermedios que puedan plantearse conforme se avanza en el sprint. Todos estos problemas los discutimos en una de nuestras reuniones de retrospectiva. Tomamos dos decisiones.
La primera pedir a los Product Owners que a parte de toda la parafernalia que acompaña a una User Story (a saber: título descriptivo, descripción detallada si es necesaria, lista de Acceptance Tests y archivos adjuntos con los recursos gráficos) añadieran previa a la descripción de la US un párrafo que explicara el porqué. Algo así como:
"Hemos decidido simplificar el flujo del interfaz de esta funcionalidad ya que las estadísticas de Google Analytics nos indican que los usuarios no están usándola y en las pruebas de usabilidad hemos visto que se debía a que el acceso es complicado."
Es un esfuerzo extra para los POs, pero es importante hacerlo para que la relación PO-equipo siga siendo sana. Ya que hay que ser muy consciente que uno de los puntos de fricción que puede existir en un equipo es la relación entre el parte que decide lo que se va a hacer y aquellos que lo implementan, más si cabe en un equipo como el nuestro en el que, por un lado, POs y desarrolladores están separados por miles de km y, por otro lado, la especial naturaleza de nuestros clientes hace que los POs puedan esgrimir razones que los programadores difícilmente pueden rebatir, del estilo de "es que los tenderos lo han pedido", "o es que las cosas en la Base de la Pirámide son así". Ser ágiles, entendiendo en este caso la agilidad como la capacidad de ir decidiendo la funcionalidad sobre la marcha e iterando sobre el producto, tampoco ayuda. Es decir, está muy bien porque consigues seguir de cerca la estela de lo que el cliente va pidiendo, pero a la vez también te lleva a reprogramar algunas partes de la aplicación más de una vez. Y eso, si se repite mucho, es frustrante para los programadores y fácilmente puede llevar al típico comentario de "das más vueltas que un PO". Así que hay que fomentar la empatía PO-developer y viceversa. Y explicar por qué se hacen las cosas es una forma barata de hacerlo.
La segunda decisión que se tomó la propuso Pedro tras leer un post de Joakim Karlsson. Joakim básicamente aboga por añadir a las tres típicas preguntas individuales de todo stand-up, tres más que se responderían como grupo:
- ¿Qué tal nos fue como equipo con el objetivo de ayer?.
- ¿Qué objetivo tenemos como equipo para hoy?.
- ¿Qué problemas tuvimos ayer como equipo que impidieron completar los objetivos?
Parece buena idea y ayuda a que haya cierta visión de conjunto a más corto plazo que el mero hecho de acabar con todas las US del sprint antes de la fecha límite. A nosotros al contrario que a Joakim, sin embargo, plantear objetivos de equipo diarios nos pareció demasiado complicado. Así que decidimos hacerlos semanales. De esta forma un día a la semana hacemos un stand-up 2.0 y escribimos en la pared los objetivos como equipo, objetivos que quedan allí durante 7 días y que revisamos una semana después. Otra forma barata de hacer equipo y asegurarnos de que todos remamos en la misma dirección. A priori hacer el stand-up 2.0 los lunes parece lo más normal pero en nuestro caso dada la diferencia horaria con los POs y que muchas veces es en nuestro lunes por la tarde cuando el PO vuelca en el proceso de Scrumban toda la creatividad acumulada durante el fin de semana, decidimos plantearnos objetivos de martes a martes.