Los procesos de transformación generan muchas situaciones desconocidas y, por tanto, muchas preguntas. Por mi experiencia y la de otros Scrum Masters, estos son cinco de las muchas dudas que suelen aparecer.

Como siempre digo, no hay que tomarlas nunca como un ataque. Es normal que la gente se plantee cómo vamos a resolver ciertas cosas. Hay que ser pacientes, explicar, formar y saber leer qué hay detrás de cada pregunta.

Control del trabajo del Development Team

¿Y quién controla que el equipo de desarrollo no está cogiendo menos trabajo del que puede hacer?

Pues en primer lugar es que en Scrum no se habla de control sino de tomar responsabilidades. Si tienes un equipo que no es profesional tu problema no es Scrum. Cambiar de metodología no lo va a solucionar mágicamente. Como mucho meterá el problema debajo de la ilusoria alfombra del control.

Ni el Scrum Master ni el Product Owner son los jefes del equipo. Lo que sí es cierto es que el Scrum Master, como persona que gestiona el proceso de Scrum, será observador de las motivaciones detrás de los comportamientos del equipo. Es su labor ayudarles a encontrar su verdadera medida como equipo y mejorar.

Duda sobre la asignación de las tareas

¿Pero quién asigna las tareas al equipo de desarrollo? No me digas que cada uno decide qué hace, ¿Eso no será el caos?

Si. Nadie mejor que quien va a aplicar las soluciones es mejor para organizarse sobre quién va a hacer cada cosa, cómo y porqué. El Scrum Master hará coaching al equipo para que aprendan a gestionar esa auto-organización. Además, ayudará a crear un entorno seguro y paciente que permita que el equipo pruebe y se suelte, para poder llegar a trabajar así.

Cuando esto se consigue es el propio equipo de desarrollo quien va gestionando de manera dinámica durante el sprint el avance y gestión de los tiempo y tareas.

En ningún caso el Scrum Master debe asignar tareas al equipo elaborando un lista de los asignados a cada Product Backlog Item (PBI).

Disponibilidad del Scrum Master

¿El Scrum Master no puede ser un desarrollador que dedique un poco de su tiempo a gestión?

La idea es que no. El del Scrum Master es un trabajo dedicado y en exclusiva. Las razones de esto dan para todo un artículo. Se trata de una persona que tiene que tener un foco amplio y a distinto nivel de perspectiva del resto.

No debe ser una persona que esté metida en el barro de la tarea del día a día porque esto le roba objetividad, tiempo, foco, efectividad …

Como digo da para otro artículo y habría mucho que decir aquí sobre los valores de Scrum.

Muchos hemos empezado desarrollando y compatibilizando ambos roles. Es posible que al principio no te sea posible hacerlo en exlcusiva. De ser así, trata lo antes posible de hacer entender que los resultados que estás obteniendo son un porcentaje muy bajo de lo que podrías hacer y, sobre todo, las razones detrás de esta afirmación y los problemas que implica no hacerlo así.

La figura del Product Owner

¿Hace falta un Product Owner para decir al equipo qué hacer?

El Product Owner no es un mero despachador de tareas ni mucho menos. El equipo no es una caja donde tiras tickets y salen líneas de código. Pensar así es poco profesional y poco respetuoso.

Parte de la labor de un Product Owner es optimizar el esfuerzo del equipo de Desarrollo. ¿Cómo? Asegurándose de que todo el equipo tiene toda la información necesaria para saber qué tiene que desarrollar. También teniendo conversaciones contínuas con stakeholders para entender sus necesidades y tenerles al día del estado del Product Backlog. El Producto Owner tiene que asegurars de que el Product Backlog es una pila limpia, clara y útil de necesidades reales y explicadas y no un cajón de los deseos o la carta a los Reyes Magos.

Es muy importante que una persona con un foco total en el producto y el negocio sea quien se encargue de estas y otras muchas cosas. El foco del equipo de desarrollo está en desarrollar.

Tener que esperar

¿Y si no se hace mañana tengo que esperar dos semanas?

Los sprints no tienen porqué ser de dos semanas. Pero sí que es importante que los stakeholders entiendan el proceso de trabajo, planificación y entrega del equipo de Scrum.

Además a nadie le gusta tabajar así, con la idea de que cada día venga alguien con algo nuevo que quiere ya para mañana. Está claro que puede haber necesidades relamente urgentes alguna vez, pero la experiencia dice que si pasa mucho, o no son tan urgentes o hay que dejar de correr como pollo sin cabeza. También está claro que hay gente que se ve obligada a trabajar así, pero eso no justifica que se haga a los demás trabajar sin visión ni prioridades.

El Product Owner será quien decida en función de prioridades, objetivos, presupuestos y otras cosas si es el momento de ponernos con algo o no.

Anuncios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.