En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Cuando iniciamos la implementación de Scrum la decisión sobre el momento en que se considera que el producto es sencilla. Cuando cumple el DoD y está en Done. Así de simple. Con esta idea ponemos en marcha a los equipos Scrum, empiezan a construir producto sprint a sprint, y son independientes para entregar. Este sería el proceso normal.

Proceso Scrum Normal

Ese es el ideal, y en el que parte de los equipos Scrum existentes se encuentran. Pero hay otra gran mayoría de equipos Scrum en los que no resulta tan sencillo determinar cuándo es entregable el producto. Y el problema principal es la relación con terceros.

 

Cuando están involucrados IT y Negocio

Pongamos algo de contexto. Las áreas de Negocio, tal y como indica Scrum, deben estar involucradas en todo momento en el proceso de creación de Producto, desde el entendimiento de la necesidad, pasando por la división en PBIs asumible por el equipo Scrum, hasta la validación final de cada uno de los entregables que construye un equipo Scrum durante el Sprint. Habrá etapas en las que participen más que en otras, pero el equipo Scrum estará en contacto constante con ellas.

En algunos clientes nos encontramos con que las áreas de Negocio apenas participan durante el proceso de construcción, siendo su mayor aporte expresando la necesidad y validando antes de ponerla en manos del Cliente final de la empresa. Esto provoca que las áreas de IT entreguen el producto no al Cliente final de la empresa, sino al área de negocio peticionaria (Cliente interno), y sea ésta quien decida si el producto está listo para ponerse en manos del Cliente o no. 

En estas situaciones les planteamos diferentes posibilidades sobre en qué momento deben establecer los equipos Scrum que han entregado, es decir, cuándo consideran que han finalizado su trabajo y pueden pasar a realizar la siguiente historia.

Proceso Scrum con Negocio validando

Si adoptan la opción 1, estarán incorporando a las personas que representan al área de negocio en el proceso de entrega de producto.

Como ventajas tendrán que el equipo Scrum entrega el producto completo y estará seguro que ha construido una solución acorde a las necesidades que se expresaban en la solicitud. Además se involucra a las áreas de negocio en el proceso, fomentando la colaboración entre IT y Negocio, y tener equipos multidisciplinares más allá de los conocimientos técnicos.

Como desventaja principal es la dependencia de la disponibilidad de las personas de negocio en el proceso, que puede llevarles a demorar la entrega, e incluso a largos tiempos de espera con producto que no pueden finalizar.

Si adoptan la opción 2, consideran que el trabajo del equipo Scrum acaba cuando el producto está listo para que las áreas de Negocio validen la entrega.

Como ventaja principal es que eliminan la dependencia del área peticionaria, y dan independencia al equipo Scrum para determinar que ha entregado el producto.

El inconveniente más relevante es que el producto puede no cumplir las necesidades del área de negocio, y se lo devuelvan. Ya sea a través de incidencias o de nuevos Product Backlog Item. Y dado que están asociados a un producto que se ha priorizado por delante de lo que esté trabajando actualmente el equipo Scrum, tendrán que dejarlo, ocuparse de realizar los cambios, y retomar el trabajo parado. Con el impacto que esto puede provocar en su plan para el Sprint, y por tanto, en la capacidad de generar nuevo producto del equipo Scrum.

Cuando aparece un tercer actor en el proceso

¿Y si por decisiones de la empresa aparece un tercer actor entre IT y Negocio? ¿O llega un proyecto transversal a la compañía en la que hay un tercero que lidera el proyecto? ¿O es una multinacional y la validación está en la sede corporativa central?

En todos estos casos lo que nos encontramos es que tienen un nuevo actor en su proceso de entrega de producto. Que además se sitúa entre los equipos Scrum y las área de Negocio, haciendo una validación y/o integración del producto previa a la validación por parte del Cliente interno

De nuevo tienen diferentes posibilidades.

Proceso Scrum con Negocio y Terceros

En la opción 3 en este caso tendrán las mismas ventajas que en la opción 1, pero aumenta el riesgo de sufrir las desventajas que te contaba antes: retraso por las dependencias.
En la opción 4, tendrán una mezcla que les lleva a tener las ventajas y desventajas de las 2 opciones del proceso IT-Negocio, todas a la vez. Es un término medio, que sin una coordinación muy fina con el Tercero, les va a suponer un verdadero quebradero de cabeza.
En la opción 5, tendrán las mismas ventajas y desventajas que la opción 2. Aquí el riesgo de verse impactados en su plan del Sprint y ver comprometida su capacidad de generar nuevo producto se multiplica exponencialmente. Va a requerir un esfuerzo mayor por parte de sus equipos Scrum en asegurar la calidad del producto entregado, para que el número de incidencias o cambios tienda a cero.

Impacto en las Métricas

Independientemente de la opción que adoptes, tendrás un impacto en las métricas de los equipos Scrum.
Si tomamos como ejemplo el Lead Time, en las opciones 1, 3, y 4 será mayor cuanto menor sea la disponibilidad de las áreas de negocio, del tercero o de ambos. En las opciones 2, y 5 será menor al depender únicamente del equipo Scrum. 

En cualquier caso tendrás que ajustar los valores objetivo de tus métricas o KPIs, desde el entendimiento de la opción que adoptes.

Resumen

Cuando entran en juego otros actores adicionales al equipo Scrum en la generación de producto entregable, hay que decidir a qué se renuncia y dónde se quiere sufrir las consecuencias de depender de terceros. Eso sí, recuerda, con lo que nunca se negocia es con la Calidad del Producto.

0 comentarios

Enviar un comentario

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

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies