Este es el resumen de la iteración 20 de Elemento115.
Fue una retro más pequeñita y recogida de lo habitual, ya que faltaban dos personas del equipo, y en un equipo de 7 eso se nota =)
Quizá por esa razón fue una retro un poco más corta de lo normal y muy enfocada.
MAD / SAD / GLAD
Empezamos con una ronda de calentamiento, poniendo en común, sobre el sprint que terminaba, las cosas que nos habían hecho sentir alegría, tristeza o enfado y, al ponerlo en común, generar reflexiones y conversaciones interesantes sobre nuestras emociones.
Cosas que nos hicieron sentir alegría
- El nuevo enfoque comercial, adelantando las fases iniciales del proyecto a la etapa de preventa utilizando design thinking.
- El empujón de marketing en la web con nuevas secciones y contenidos.
- El compañerismo vivido con una nueva colocación de puestos.
- Los nuevos retos superados al publicar nuestra primera app para android.
- El trabajo bien hecho al cumplir con lo planificado.
- La satisfacción por sentirse productivo y resolver problemas complejos autónomamente.
Cosas que nos hicieron sentir tristeza
- La sensación de pérdida del foco y no saber qué hacer a veces.
- El caer en los mismos errores como equipo siempre.
- Los bloqueos personales que provocan improductividad y errores.
- La sensación de hablar al vacío en las dailys.
- El gran esfuerzo depositado en un proyecto sin que se vea brillar a pesar de todo.
Cosas que nos hicieron sentir enfado
- El agobio y frustración por no llegar a todos los proyectos
- El descuadre de tiempos entre estimaciones y trabajo / esfuerzo final.
- El encallar en problemas sin haber pedido ayuda antes.
Landscape diagram
A continuación, a través de la técnica de «Landscape diagram», nos pusimos un poco en orden. Tenemos un montón de iniciativas y experimentos en marcha para mejorar la forma en la que trabajamos. Y quise poner foco, para detectar aquellos en los que poner más esfuerzo en la próxima interación.
Gracias a esta herramienta, se evalúan dos aspectos de los problemas o iniciativas puestas sobre la mesa:
- ¿Qué acuerdo hay sobre si resolver ésto tendrá un gran impacto positivo?
- ¿Qué certezas tenemos sobre los primeros pasos para abordarlo?
Ayudados de una gráfica, pusimos en el cuadrante que correspondiera todas los temas que tenemos en marcha más o menos lanzados o más o menos atascados, según cómo se mire =)
Una vez representados todos los temas, escogimos 2 temas de la parte superior derecha (cuadrante con máximo acuerdo sobre retorno positivo y con máxima certeza sobre cómo conseguirlo) y un tema de la parte central.
Por otra parte, consideramos que la daily a las 8.30 caiga quien caiga y la estimación de tiempos en JIRA ya los hemos adoptado.
Como conclusión del ejercicio, tomamos las siguientes como las iniciativas más importantes en las que esforzarnos durante el próximo sprint:
Primer pirata Roberts: Yon.
Misión: romper cosas.
Oí sobre el pirata Roberts en un interesante post de Antonio de la Torre hace ya bastantes años.
Al igual que en aquel momento en Kaleidos, ahora en Elemento115 no tenemos un especialista en QA, y eso, si el equipo está muy concentrado en determinados momentos en la labor de desarrollo, puede afectar negativamente a la calidad, y aumentar la deuda técnica del proyecto.
El corto plazo no pasa por contratar a un especialista de QA, pero sí mejorar en ese aspecto. Así que hemos decido adoptar y «adaptar» la práctica del Pirata Roberts.
De momento, el Pirata Roberts tendrá como misión «Romper cosas, romper proyectos», o dicho de otro modo, una vez «terminada» la historia de usuario por desarrollo, es quien verificará que se cumplen los criterios de aceptación.
Hay otros muchos aspectos dentro de la posible misión del «Pirata Roberts» que me interesan, sin embargo, creo que es buena idea empezar poco a poco.
Generar backlog a 2 sprint vista
Misión: que no nos pille el toro.
Al final de este sprint nos pasó que nos habíamos merendado el backlog de casi todos los proyectos. No quiere decir que nos quedáramos sin más trabajo para el sprint que entra, si no que, el trabajo pendiente no estaba en formato de backlog: historias descritas y priorizadas.
Por tanto, tuvimos que, deprisa y corriendo, dedicar un esfuerzo extra, en algo que si hubiéramos llevado más al día no hubiera supuesto ningún problema.
Nos hemos dado cuenta de que debemos dedicar más tiempo del sprint, a adelantar la escritura y refinamiento de backlog de dentro de 2 sprints. Creo que esto nos ha pasado por que el equipo ha ido cogiendo ritmo, y ahora somos más, a cada sprint que pasa, sacamos más trabajo, y hay que adecuar los ritmos de generación de backlog para que no nos pille el toro.
Hay que evitar que la columna de «Ready for development» se quede vacía.
Mejorar nuestro compromiso con el cliente.
Misión: Fijar fechas de entrega y demo
Uno de los beneficios de las metodologías ágiles es la flexibilidad. Flexibilidad en el alcance y flexibilidad en las fechas de entrega.
Aceptamos cambios, incluso en fases tardías, para beneficiar la competitividad del cliente, esto es una fuente habitual de grandes éxitos, pero también de grandes retrasos.
Eso es así.
El lado oscuro de esa flexibilidad es que puede conducir fácilmente a retrasos o a entregas donde no se ha completado parte de lo que había previsto:;
- A veces por que no se ha sabido decir que no.
- A veces por que no se ha dejado caer alguna tarea cuando se ha añadido una nueva.
- A veces por que no había fecha concreta de entrega y simplemente era «cuando se terminaras de desarrollar las historias».
Nuestro compromiso en este sprint cosiste en obligarnos a respetar fechas de entrega.
Ser más estrictos y disciplinados.
Esto nos exigirá una mayor labor de repriorización y estar mucho más enfocados en la entrega de valor, y en el objetivo del sprint que en las historias concretas. A ver qué tal se da.
—
Manuel Barroso Parejo
Co-fundador Elemento115
@manubarpar
