A lo largo de estos años, con la experiencia adquirida, trato de aportar a la comunidad lo aprendido en este post, son breves consejos, aprendizajes y experiencias expuestas sobre el mundo ágil:
- Siempre realizar agilismo sobre un tablón de tareas:
Se puede tener herramientas digitales, claro que sí, siempre que el equipo lo demande, o se tengan equipos des-localizados, pero sea de una u otra forma, siempre trataremos de tener un tablón de tareas para visualizar nuestro trabajo y poder realizar las reuniones de sincronización delante de el.
- Aprender a no hacer daily:
El daily es un "arma" muy poderosa en el mundo agile, no solo en scrum, permite sincronizar los equipos, que se está realizando y donde hay problemas para ayudarse y colaborar en obtener el fin común, que no es otro que finalizar correctamente el sprint, o entregar el mayor valor posible. Pero el daily meeting no es un informe de situación, ni por parte del equipo, ni por parte del scrum master y mucho menos por la gerencia o product owner. Si nuestro daily se convierte en un "informe de situación" es mejor dejar de hacerlo, hasta que se recupere el clima adecuado, la colaboración, la transparencia y la confianza en el equipo.
- Cambiar las preguntas del daily:
Hay tres preguntas que se suelen realizar en los daily, como norma base : ¿Qué has hecho?, ¿Qué vas a hacer?, ¿Qué problemas has encontrado?. Puede darse el caso que en ciertos equipos estas preguntas no aporten nada, terminen siendo un informe de situación, o simplemente el equipo pierda la creatividad, las ganas o la ilusión en realizar el daily, "todos los días es la misma historia". Cuando esto sucede debemos cambiar la estrategia, en lugar de preguntar que he hecho, porque no preguntamos ¿Qué has terminado? , ¿Qué has completado desde el último daily? ¿Qué tarea has finalizado?, ¿Qué historia has finalizado?. Esto nos aportaría 3 nuevas preguntas a formular:
¿Qué has completado?, ¿Qué vas a completar?, ¿Estás seguro que lo terminarás?.
Cambia la pregunta y cambia la visión, ya no se focaliza en que he hecho, en que he trabajado desde el último daily, si no en el compromiso de terminar tareas, historias, se adquiere un nuevo compromiso mayor, que el mero de trabajar.
Compartir la gráfica de burndown en el daily, para saber como está siendo el sprint, visualizar el avance del equipo.
- No hablar si no es tu turno:
Entre los valores ágiles está la comunicación, el foco, etc, pero hay uno superior a todos, el respeto por las personas. Hay que generar equipos con educación y respeto, si no es tu turno no interrumpas, si no te gusta que te interrumpan no hagas aquello que no quieres para ti, si no tienes nada que aportar pues no hables simplemente por hablar, se breve, eficaz y que tu conversación aporte valor.
- Realizar reuniones Parking:
Trata de ser breve y conciso, un motivo por el cual el equipo puede no querer hacer dailys puede llegar a ser el exceso de tiempo, el hablar de cosas no relacionadas con el objetivo del daily, en ese caso aparca esos temas para después, implementaciones concretas, diálogos de dos personas, decisiones que afectan a parte del equipo. Pueden ser temas no relacionados con el sprint ni con el objetivo del daily. Sacarlos a un panel y tratarlos después de finalizar el daily. Centrarás la atención del daily en los temas relevantes y posteriormente, con una visión común del equipo, podrás tratar el resto de temas, que pueden ser tan importantes como los del daily, pero que "ahora" es el turno de tratarlos.
- Realizar las reuniones de pié:
Si, un daily o una retrospectiva es mucho más efectiva de pié que sentados, pierdes concentración, te relajas, te entretienes, si haces dichas reuniones de pié, la gente es más ágil, más rápida en hablar y resolver problemas y cuestiones. Centras la atención y focalizas el contenido en el objetivo marcado y deseado para esa reunión.
- Reunión hospital: Si el daily se convierte en una reunión peligrosa, con problemas dentro del equipo, con malas palabras o formas, donde se vea crispación, es mejor cambiar por una reunión hospital, donde se hablarán dichos temas, y se tratará de identificar los problemas y darles solución, con transparencia, sinceridad y comunicación. Sin escalas, de igual a igual.
- Utilizar un Token:
Para facilitar los dailys o reuniones donde no se respeten los turnos de palabra, o las solicitudes de palabra, es muy útil utilizar un token (bolígrafo,objeto seleccionado por el equipo), y que da al portador del objeto el poder de hablar durante un tiempo prefijado.
- Respetar los tiempos:
Ir a las reuniones con un guión bien definido, planificando los tiempos de antemano (incluso marcar 10 minutos de margen). Esto nos servirá para respetar los tiempos, plazos y temas a tratar, dando valor y autoridad al moderador para aplazar una reunión o darla por finalizada una vez concluido el tiempo marcado con anterioridad. Debemos de ser ágiles, mantener el foco y no abrumar ni cansar a los asistentes. Trataremos de avisar con 24 horas de antelación sobre cualquier reunión a celebrar a futuro.
- Tratar de mantener el compromiso:
Hay que tener al equipo comprometido, valorarlo, mimarlo y visualizar su estado de trabajo y anímico. Evitar aburrimiento, falta de motivación. Esto se puede visualizar con radiadores de información y paneles karma.
- Saber decir gracias: Decir gracias siempre que un compañero hable bien de ti, te reconozcan tu labor, y también cuando te critican constructivamente, para que se vea en que se ha fallado y se aprenda. Esto hace fuerte al equipo, y el equipo lo forman personas.
- No entorpecer las iteraciones: Tratar de no entorpecer las iteraciones, sobre todo durante el primer tercio y último tercio, dejar que se coja velocidad y en el medio de la iteración realizar las reuniones oportunas de priorización, grooming, etc.
- Hacer que el Product Owner trabaje:
No solo el equipo y Scrum Master han de trabajar, el Product Owner durante el sprint ha de trabajar, detallar las futuras historias candidatas a entrar en el siguiente sprint, priorizarlas y hacerlas visibles para el equipo, realizar reunión de grooming con el equipo, descomponerlas más si es necesario, hasta que el equipo comprenda que tiene que hacer, tener establecidas unas pruebas de aceptación iniciales (Definition of done), que irán madurando sprint a sprint o durante el sprint. El Product Owner revisará, eliminará, agrupará y descompondrá las historias.
- Aprender que las estimaciones no tienen que ser finales:
Enseñar, educar al equipo, Product Owner y stakeholders de que las estimaciones no tienen que ser finales, solo cuando entra en el sprint la estimación es válida. Mientras puede suceder que no se tenga suficiente información de dichas historias, o sencillamente que no se hayan empleado todos los recursos necesarios en el análisis de dicha historia. Visibilizar toda la información posible, incógnitas, riesgos, etc, y tratar de eliminar los obstáculos e impedimentos siempre que nos esa posible antes de incluir dichas historias en un sprint.
- Marcar unos objetivos claros:
No perder nunca de vista los objetivos del sprint, de las reuniones, del daily, puntos del día a tratar, límites de tiempos, y tener un moderador siempre, elegido con anterioridad al comienzo de cualquier reunión (esto siempre que no se tenga un Scrum Master). En las reuniones han de ir todo el mundo que sea necesario, no todo el mundo.
- No tener miedo al backlog:
No tener miedo de los elementos que están abajo en la pila del backlog, tratar de identificar riesgos y problemas siempre, aunque estén abajo en el backlog. Nos servirá para que el Product Owner priorice nuevamente al identificarse los riesgos asociados.
- Aprender a decir no:
Hay que educar a las personas en decir no, en mitad de un sprint no se puede meter una historia, "porque yo lo digo", tiene que haber una razón de peso, o una negociación para decir si algo entra, otra cosa sale. Decir no a una historia mal definida, mal planificada, mal estimada, decir que no a un imposible, a algo que no aporte valor y no obtengamos con ello ROI. Hacer ver al Product Owner o stakeholders el valor de ese no, que no piense que es un no porque yo quiero, si no que tiene una razón de peso para el, no solo para el equipo.
- Tratar de tener veneno en las historias:
Si, tratamos de polinizar el conocimiento, de evitar las "islas de conocimiento", para que no tengamos factores de riesgo, El veneno lo podemos identificar en las historias que así lo tengan, y para ello identificamos las historias difíciles, historias que nos hacen salir de nuestra zona de confort, historias que suponen un peligro (tecnológico, riesgos, dificultad).
- Siempre realizar retrospectiva:
Siempre tratar de estar en mejora continua, y dicha mejora viene por inspeccionar lo que hemos realizado, ver lo bueno que hemos hecho y pontenciarlo, aprender de lo malo para no volver a realizar ni caer en los mismos errores. Sirve para inspeccionar y adaptar nuevas prácticas.
- Polinizar:
Polinizar, compartir, educar, fomentar los equipos y las personas comprometidas, con gran capacidad, dejar que fluya su creatividad, la comunicación, la transparencia, por encima de pautas, herramientas y ceremonias, están los valores. Fomentar el espíritu de equipo, la empatía entre las personas, el conocimiento mutuo y compartido, el valor del equipo, de apoyarse y aprender mutuamente.
