Empowering the team

Es la típica frase que se lee en toda la literatura sobre agilidad. Pero cómo definirlo. Es algo así como la confianza, y la autoridad derivadas de la naturaleza de las decisiones que el equipo puede tomar por sí mismo. Y el proceso de delegar en los equipos aquellas decisiones que, por su naturaleza, sean más eficientes tomarlas en el seno del propio equipo.

Está claro que no se puede delegar en cada equipo individual todas las decisiones de un proyecto o una compañía.

Sobre las decisiones de compañía hay mucho escrito (planificación estratégica, lean startup, segmentación, etc.).

En esferas más cercanas al desarrollo de software, existen límites más bien naturales que requieren acuerdos entre equipos (por ejemplo talleres Lean VSM para modificar procesos en un value stream, o talleres de Inspect & Adapt en el marco de un programa SAFe). Estos procesos no dejan de ser ejemplos de empowerment pero a una escala superior (equipos operativos en Lean, o programas formados por equipos ágiles en SAFe).

Scrum, entendido desde la óptica de la Scrum Guide, está lleno de aspectos que en sí mismos dan poder al equipo (mi traducción de Empower the team).

1. Equipo auto-organizado y auto-gestionado.
2. Estimaciones realizadas por el propio equipo.
3. Liderazgo servil.
4. La propia dinámica de Retrospectiva.
5. La dinámica del Refinamiento del backlog.

En general, en vez de tomar la decisión en nombre del propio equipo y comunicarla, presenta el problema y da pie a que el equipo decida qué hacer (por ejemplo a la hora de resolver un defecto que el usuario acaba de reportar en pleno sprint).

Si te examinas de la certificación de Profesional Scrum Master de Scrum.org, en general la imposición de decisiones, salvo la cancelación del Sprint por parte del Product Owner, suelen ser una pista de que la respuesta no es correcta.

La esencia de Agile

Llevo un tiempo preguntándome qué hace que, en última instancia, Agile funcione mucho mejor que todo lo anterior.

Creo que este párrafo de Pete McBreen de su libro Software Craftsmanship: The New Imperative lo explica a la perfección:

La diferencia fundamental de la artesania en el desarrollo de software es que los desarrolladores y los usuarios se entienden mejor, y pueden ayudarse mutuamente a tomar decisiones a tomar decisiones donde una decisión excluye a otras. Hay veces hay que tomar decisiones difíciles, pero es mucho más fácil si existe una relacion basada en respeto y la confianza mutua.

Bloquear para resolver

El equipo en SCRUM se ha comprometido con unos objetivos para el Sprint y tiene 2 personas que les facilitan el camino para conseguirlo. Estas dos personas son el Product Owner, que debe aclarar y especificar cualquier duda sobre el producto (funcional o técnica) que pueda surgir, y el Scrum Master que en esencia se encarga del resto de los impedimentos.

Casi todas las herramientas permiten bloquear elementos de trabajo (historias de usuario, tareas, defectos, etc…).  Este mecanismo, utilizado adecuadamente, es una garantía de que el equipo no se para.  Es la forma adecuada de escalar, aunque por supuesto no es sustitutiva de una conversación en persona.

El objetivo de bloquear, es que otros miembros del equipo en primera instancia, y luego el Scrum Master o el Product Owner tomen cartas en el asunto y resuelvan este tema, para que cuando esté resuelto el tema se pueda retomar. Es por tanto una manera de no quedarse atascado y coger la siguiente tarea por importancia.  Es la forma de escalar un impedimento, o un bloqueo, que supera a la persona que está intentando construir la historia de usuario, resolver la tarea, o corregir el defecto.

En cualquier caso, es crítico describir el motivo por el cual no se puede avanzar y los pasos realizados por el equipo antes de decidir escalar el impedimento.

¿Cuándo bloquear?

1. Cuando alguna de las asunciones que se realizaron durante la planificación del sprint resulta ser falsa y no se puede compensar de alguna manera. Por ejemplo: está reflejado en la historia de usuario que hay una guía para realizar una tarea y esta no aparece o está desactualizada.
2. Faltan recursos, o entornos, para poder realizar la tarea (por ejemplo, no hay máquina disponible para realizar las pruebas).
3. Alguna dependencia realmente no se ha resuelto

En definitiva: bloquea, explica qué necesitas y coge la siguiente tarea por importancia. Colabora con las personas que estén intentando resolver el impedimento, y retoma el tema cuando vuelva a haber vía libre.

Qué engloban los puntos de historia

El proceso de estimación de las historias de usuario es un proceso de estimación bajo incertidumbre. De hecho, desde mi punto de vista, Poker planning podría ser una gamificación del método Delphi de consenso de un panel de expertos.

SAFe explica muy bien que debe tener en cuenta el equipo a la hora de decidir cuantos puntos de historia deben asignarse a una historia de usuario. Una estimación de puntos de historia mide:

• Volumen – ¿Cuánto trabajo hay que hacer?
• Complejidad – ¿Es un trabajo sencillo o es algo extremadamente complicado?
• Conocimiento – ¿Qué sabemos?
• Incertidumbre – ¿Qué no sabemos?