Go to Scrumio.com

«¿Has actualizado Jira?»


Persigues al Equipo de Desarrollo para que actualice los tickets de Jira. Sobre todo a un par de desarrolladores, que son un desastre y te ignoran, a pesar de tu insistencia. «¿Has movido tus tickets en Jira?», preguntas a tus desorganizados compañeros. Cuando ves que los tickets no se están moviendo o actualizando, sientes que pierdes el control como Scrum Master, que las cosas van mal. Te genera hasta ansiedad. Si algún jefe te pregunta que cómo va el Sprint, no sabrás qué contestar.

Has mandado correos, recordatorios por Slack y por el calendario, hablado one to one con los insolidarios que no actualizan “sus” tickets, y nada. Solo te queda reportar el problema a algún manager y asegurarte de que este comportamiento sea tenido en cuenta en las evaluaciones de rendimiento. Entre tanto, te toca mover los tickets de los desarrolladores díscolos. Incluso, has instaurado un nuevo formato para la Daily: ahora lo hacéis con Jira por delante, le vas preguntando a cada desarrollador por el avance de tus tareas, y tú mismo vas moviendo los tickets sobre la marcha. Ya no tienes que perseguir a nadie y Jira es actualizado al menos una vez al día. Además, en cada una de las ceremonias te aseguras de anotar todos los detalles de las conversaciones en el correspondiente ticket, para que no se pierda nada.

¿Te suena esta situación? 😊

Es muy difícil ser “el buen Scrum Master”. Ahora bien, “perseguir” a los desarrolladores o actualizar por ellos el progreso de sus tareas no les permitirá funcionar como equipo autoorganizado. Con ello solo conseguirás que el Sprint Backlog, que es un artefacto que debe pertenecer en exclusiva al Equipo de Desarrollo, te pertenezca a ti como Scrum Master. Esta no es forma de desarrollar tu rol como servant leader. A lo más, te convertirás en el secretario del equipo o en un project manager “a la antigua usanza”.

Algunas estrategias a probar si tu equipo “pasa” de actualizar Jira -o, mejor dicho, el Sprint Backlog- pueden ser:

– ¡Deja de perseguir a los desarrolladores! ¡Y ni se te ocurra tocar Jira! Deja que las cosas “se vayan de madre” y que sea el propio Equipo el que rectifique cuando no haya forma de coordinar el trabajo diario. Como decía Tyler Durden en la película Fight Club, «just let go».



– Al final del Scrum Diario, pregunta al Equipo si ha habido cambios que afecten al plan del Sprint, y cómo mostrarían tales cambios. Invitemos a la gente a reflexionar sobre Scrum y el Sprint Backlog, más allá de la herramienta de ticketing de que se trate.

– Utiliza la Retrospective para debatir sobre por qué es importante que el Sprint Backlog sea transparente: sirve para que el Equipo vea el progreso día a día hacia el Objetivo del Sprint; para que identifiquemos dependencias, el número de elementos en curso, posibles impedimentos; para que stakeholders o personas externas al Equipo puedan estar al corriente sobre cómo avanza el Sprint, sin tener que pedir informes que distraerán al Equipo Scrum; para que podamos tener una conversación informada con el Product Owner si es necesario ajustar el alcance del Sprint; para que el Scrum Master no se nos vaya al “lado oscuro de la fuerza”; etc.

Si te has visto en este círculo vicioso de Jira y has salido de él, ¿cómo lo hiciste?


Imagen: Nguyen Hung Vu en flickr.

Comparte este post

Publicado por Patricia Carballar

Scrum.org, European Scrum, Prince2 and Expert ITIL Certified. Former Scrum Master at Rainbird Technologies and SAP Service Manager at Abengoa. Passionate about Scrum, people and process optimisation.

Posts relacionados

Comentarios

Deja tu comentario

Tu dirección de correo no será publicada. Lo campos requeridos están marcados con *

Recibe artículos sobre ágil y promociones en tu email.