Cuando empezamos con un equipo que hace “algo de Agile”, encontramos muchos puntos de mejora para empezar a trabajar con ellos. Trabajar como consultores nos da la oportunidad de poner en práctica todos los conceptos y valores que llevamos años enseñando.
De todos estos hilos que surgen, hay algunos que se repiten con más asiduidad. Entre ellos están:
- La incomprensión de los roles como el de Product Owner o Scrum Master. Porque algunas organizaciones deciden “actualizar” el rol para adecuarlo a lo que mejor les viene en ese momento. Lo que genera grandes problemas en el resto del equipo. Esto nos lleva a:
- Tener empleados frustrados porque quieren hacer muchas cosas y no pueden, así que hacen otras.
- Utilizar algunos elementos de Scrum o Kanban, en vez del marco o método completo. Este es el principal de los problemas, ya que ambos están planteados para utilizar el conjunto de sus elementos. Suponer que no están enlazados entre sí y que pueden utilizarse por trozos es un error básico de conocimiento, y de querer adaptar el sistema a la organización y no la organización al sistema, es decir, tomar el camino más fácil y con menos impacto.
- La elección de una herramienta de gestión del trabajo que obliga a los equipos a cambiar su forma de trabajar para adecuarse a ésta y no al revés. Lo cual va en contra de uno de los valores del Manifiesto Agile.
- El alto porcentaje de externalización con mucha rotación no permite que las prácticas se asienten o que todos los empleados se desarrollen profesionalmente a la velocidad que la empresa lo necesita.
- Por supuesto, “la lucha contra Waterfall” y sus seguidores hace de todo esto un entorno mucho más complicado, en el que unos quieren evolucionar y otros prefieren quedarse en lo de siempre: “Más vale lo malo conocido que lo bueno por conocer” ¿no?
- Las personas que han apostado por traer la Agilidad a la compañía son presas del “Cargo Cult” y además, tienen que medirse para justificar los beneficios de Agile contra lo que conocemos de Waterfall.
- Nadie mide nada de forma real. Nos basamos en métricas subjetivas o de actividad y no en datos y métricas de valor o impacto. Para eso es importante empezar a conocer las métricas que podemos usar.
- Por último: las personas que quieren utilizar Agile se olvidan de la meta. No queremos ser buenos en Scrum y Kanban, son herramientas para un objetivo mayor: Queremos entregar productos que generen valor.
Como puedes ver, existen muchas vías de mejora. Siempre se puede mejorar, pero la base está en ser conscientes de que necesitamos mejorar. Puede que este sea el mayor de todos los retos: Abrir los ojos y las mentes de los que viven la transformación.
Empecemos por el principio: El Producto
¿Qué hacemos cuando llegamos a un equipo que ni siquiera sabe para qué existe su producto? Claramente necesitamos entender esta situación.
Supongamos que estamos “trabajando con Scrum”. Falta de transparencia, de comunicación, de equipo… Puede que el Product Owner no esté ejerciendo su labor respecto al equipo, puede que ni siquiera esté presente en el día a día o que directamente haga las labores de un Stakeholder.
¿Y el Scrum Master? ¿Es una persona dedicada a asegurar que Scrum se ejecuta correctamente o tiene más de un sombrero que no debería? Es posible que, si hay mucho desconocimiento y falta de implicación por lo mismo, Scrum o cualquier otro marco de trabajo se convierta en un circo con payasos.
“Para que un equipo pueda implicarse, necesita entender para qué hace lo que hace.”
Una vez que el equipo entiende la misión de su trabajo y la visión de negocio podemos empezar a trabajar en otros aspectos más mundanos y no por ello menos importantes.
El Product Backlog
Tener claros todos los conceptos nos ayudará a utilizarlos mejor y entender el para qué de las cosas. En Scrum el Product Backlog es una lista ordenada de elementos necesarios para construir el producto. Todo tipo de trabajo ejecutable tiene cabida aquí siempre y cuando ayude a la construcción y evolución del producto.
Elementos que pueden encontrarse en un Product Backlog:
- Tareas. Entendiéndolo como tarea y no subtareas de otro tipo de elemento.
- Funcionalidades.
- Requisitos técnicos y funcionales.
- Casos de uso.
- Mejoras.
Ninguno de los elementos listados arriba es obligatorio, al igual que ninguno es imprescindible. He podido ver Product Backlogs en los que la mayoría de elementos eran mejoras porque el producto ya estaba operativo desde hacía tiempo y no había novedades a corto plazo.
Dentro del Product Backlog siempre podemos utilizar prácticas recomendadas como las Historias de Usuario y las Épicas para organizar los elementos. Otra función importante que cubrimos con esta técnica es la de dar más transparencia de cara a personas ajenas al desarrollo como pueden ser los propios usuarios.
Elementos que no forman parte del Product Backlog:
- Eventos.
- Reuniones.
- Actividad de refinamiento.
- Actividades de Teambuilding.
- Reportes.
Estos elementos listados arriba no pueden formar parte del Product Backlog como elemento ejecutable, ya que por ellos mismos no aportan valor al incremento. Pueden ser necesarios para llevar a cabo otros elementos, pueden ser consecuencia de otros elementos o como en muchos casos he llegado a ver, gestión de las personas del equipo y el tiempo que dedican a los elementos.
Como puedes ver en el listado inferior, el Product Backlog no contiene todo lo que hacemos ni pretende justificar por qué se nos paga por las horas que estamos trabajando. En resumen: si es un elemento necesario para el producto que aporta valor el usuario, aparece. Si no es así, no debe aparecer.
Cuando no hay producto
Hay muchas otras formas de trabajar en las que primero se necesita tener una lista de elementos para ir cogiendo y ejecutando. Pero si al final del proceso no entregamos un incremento en un producto, como puede ser software, documentación o incluso experiencias turísticas (por ejemplo), no tienes un producto y por tanto no tienes un Product Backlog. Tendrás una lista de elementos para hacer. Trabajar por proyectos no incapacita el uso de Scrum. En Scrum un Sprint puede considerarse un proyecto como en el caso de las releases.
En el método Kanban puedes tener un Backlog de elementos diferentes con distintos fines, por eso se utilizan los Work Item Types y las Clases de Servicio, para tener claras las prioridades de cada tipo de trabajo. Aunque esto te pueda permitir un abanico más grande en cuanto a tipos de elementos siguen existiendo (como en el caso de Scrum) elementos que no tiene sentido que se encuentren en el Backlog. En cualquier caso, ni Scrum, ni Kanban, sirven para justificar nuestro trabajo sino para gestionar sistémicamente trabajo y que las personas se auto-organicen alrededor de dicho sistema.
Y tú, lector ¿tienes claro si hay producto o es un servicio?
Deja una respuesta