¿Cómo fomentar que mantengamos el foco desde el Product Backlog?

Agile promueve que los equipos se focalicen en lo más relevante en cada momento. Hoy os contamos cómo ayudar a poner foco desde el Product Backlog.
foco desde el Product Backlog

Agile promueve que los equipos se focalicen en lo más relevante en cada momento. Hoy os contamos cómo ayudar a poner foco desde el Product Backlog.

Una de las primeras cosas que enseñamos a nuestros clientes y sus equipos es a identificar qué es lo más importante para el negocio y a trabajar primero en lo que más valor aporte a la empresa y a sus clientes. Es decir, que su capacidad de generar valor esté focalizada siempre en lo más importante.

A priori puede parecer relativamente sencillo, establecemos unos buenos criterios de priorización, definimos que se considera valor, identificamos el beneficio de cada necesidad, y ordenamos nuestro Product Backlog con ellos. ¿Fácil no?

Si además utilizamos Scrum o Kanban para asegurar que se ponen en marcha eventos de planificación, ya sea una sesión periódica o continuada según vamos teniendo hueco en nuestra capacidad, debería resultar fácil que los equipos tengan foco en lo más importante en cada momento.

Si a esto le añadimos un Backlog de Portfolio ordenado por consenso con las área de negocio, como se dice de manera coloquial está chupao.

¿Cuál es la realidad?

Antes de explicarte nuestra propuesta, quiero contarte qué me he encontrado en nuestros clientes. La realidad no es tan sencilla. En la mayoría de las PYMES el área o departamento de IT, Tecnología, Software o como lo llamen, se ocupa de dar servicio a muchos “clientes” internos y externos. Las mismas personas se ocupan de evolucionar y mantener un amplia variedad de productos que cubren las necesidades dispares de los clientes de la empresa y de las áreas de negocio. No tienen un único producto que crear, no tienen foco en una necesidad; ese lujo sólo lo tienen algunos equipos y en muy pocas empresas.

La realidad es que la gran mayoría de los equipos lidian en su día a día con cambios de foco constantemente, intentando repartir su capacidad para atender a las diferentes necesidades que les llegan. Y muy probablemente, además tendrán que atender las incidencias que ocurren en el día, que como ya os contamos son interrupciones directas, y por tanto, más cambios de foco en el trabajo de los equipos.

Puedes decirme “bueno, es que no están organizados por cadenas de valor y por eso tienen este problema.” Y tienes razón, pero de nuevo, una cosa es la teoría y otra lo que es posible en cada momento. Con la transformación Agile en el largo plazo la empresa debería llegar a un modelo basado en cadenas de valor, con equipos multidisciplinares capaces de atenderlas. Pero ¿y mientras llegan a ese estado “perfecto”? ¿Y si la empresa no quiere o no ve la necesidad de llegar a ese lugar? La realidad es más tozuda que cualquiera de nosotros, y siempre se impone.

Así que tenemos a uno o varios equipos, con Product Owners (o rol similar) teniendo que atender muchas necesidades dispares, con unas personas que ven como constantemente tienen que cambiar de foco, ya no por interrupciones, si no porque el producto a construir es diferente. Personas con la sensación de estar a todo y a nada a la vez, y que se ven impactadas por el efecto de esa multitarea: Efectos de la multitarea en tu productividad.

Poner foco desde Product Backlog

Te voy a contar una propuesta para ordenar el Product Backlog, que puedes utilizar tanto en equipos Scrum como Kanban. Ya la hemos puesto en marcha en nuestros clientes, y ha mejorado la sensación de las personas de estar más focalizados. En términos más cuantitativos, se han reducido los tiempos para entregar valor y el número de fallos en el producto entregado.

Cuando utilizamos Kanban el propio método te estará llevando a poner foco, ya que busca la eficiencia de flujo; es decir, focalizar al equipo en lo que entra en el sistema para sacarlo rápido del mismo. Entra y sale lo más rápido posible. Pero, ¿Qué hago si cada token es de una necesidad diferente? Eso va a provocar que cada elemento que entre en el sistema cambie el foco del equipo.

Cuando utilizamos Scrum en la planificación del Sprint debemos establecer el objetivo del Sprint. Eso hace que el equipo ponga foco en conseguir ese objetivo durante un Sprint. Pero ¿y si tengo más de un objetivo? ¿Y si tengo que cubrir varias necesidades en el mismo Sprint? Me puedo encontrar en una situación en la que cada PBI (Product Backlog Item) cambie el foco a una necesidad diferente. Así que, ¿Cómo preparamos nuestro Product Backlog para que nos ayude a tener menos cambios de foco? Te lo cuento desde un caso real.

Agrupa por área de negocio 

En uno de nuestros clientes tenemos un Backlog de Portfolio priorizado en consenso por las áreas de negocio. Este backlog contiene Épicas con la necesidad o iniciativa de negocio, que se dividen en Features, que son PBI que se pueden construir en 2 meses (4 sprints) o menos. Bimestralmente las Features se reparten entre 3 equipos Scrum, capaces de atender cualquier necesidad cualquiera de ellos. Cada equipo Scrum divide a su vez las Features en Historias de Usuario, que son las que planifican en sus Sprints. Hasta aquí nada fuera de lo habitual.

Los Product Owners, siguiendo el objetivo de distribución del conocimiento y que cualquier equipo atiende cualquier petición, se reparten las Features atendiendo a la prioridad establecida en el portfolio. Deciden junto con todo el equipo Scrum en que Sprint lo van a entregar, usando ese mismo criterio. Dividen en historias y las planifican en cada Sprint atendiendo de nuevo a la prioridad y a cuando deben empezar para entregar a tiempo. Lo cual está alineado con la idea de ocuparse primero de lo más importante. En realidad no estaban haciendo nada “mal”.

Pero esta forma de actuar estaba teniendo una consecuencia inesperada: cambios de foco constantes dentro del Sprint. Y generando un impacto negativo en las personas. Hemos hecho varios cambios en el reparto y planificación de los PBI en cada uno de los puntos del proceso.

    • A nivel de Portfolio la Features se reparten agrupando las de un área de negocio en un equipo.
      • Empezamos a hacer que al menos cada equipo Scrum se focalice en 2 ó 3 áreas de negocio.
    • A nivel de planificación bimestral, se colocan las Features por Sprint tratando de agrupar las de un área de negocio en los mismos Sprint.
      • Como equipo tiene que atender diferentes áreas, por lo tanto tratamos de realizar primero todas las de un área, luego las de otro, y tener los menos cambios de foco posible dentro del bimestre.
    • A nivel de Sprint Planning, se agrupan las historias por área de negocio, realizando primero todas las de un área, luego las de otro, y así sucesivamente.
      • Promovemos que haya 1 ó 2 cambios de foco durante el Sprint en la generación de valor.
esquema Product Backlog
esquema Product Backlog

El concepto es simple (y de sentido común), hay tantas cosas que atender que el cambio de foco es inevitable, pero lo que sí podemos hacer es mitigarlo distribuyendo y planificando en cada nivel el producto a construir, de forma que nos ayude a que el número de cambios sea menor. Buscamos un equilibrio entre lo prioritario y la eficiencia, entre las necesidades de la empresa y las necesidades de las personas.
Se puede complicar aún más cuando tenemos diferentes tecnologías conviviendo en los equipos Scrum, puesto que nos podemos encontrar con sobrecarga o falta de trabajo en una parte del equipo. Si tú objetivo es que todos estén ocupados todo el tiempo, es un problema si, pero si estás buscando eficiencia en el flujo de entrega no lo será tanto.

¿Foco desde el Product Backlog? Consíguelo de forma sencilla

Nuestra propuesta está inicialmente pensada para nuestros Clientes, y es perfectamente reproducible en cualquier empresa con equipos que se encuentren en una situación similar. Si quieres ponerlo en marcha o tienes cualquier pregunta que hacernos sobre tu caso, sólo tienes que ponerte en contacto con nosotros, estaremos encantados de atenderte.

Tabla de contenidos

Comparte:

Más artículos

lean-kanban

Lean Kanban ¿qué es?

El Toyota Production System, data de los años 50 del siglo pasado. Es un complejo conjunto de principios y prácticas que han llevado a Toyota

Devops ¿qué es?

DevOps surge de la necesidad de mejorar el proceso de gestión de las operaciones en los equipos de desarrollo de software. Está basado en un

valor en empresa

Define qué significa VALOR en tu empresa con estas claves

En términos de agilidad, lo primero que se nos viene a la mente es “aporte de valor”. Es una expresión muy manida, con frases como “Con Scrum maximizamos el aporte de valor” o “Primero abordamos los elementos que aporten más valor”.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!