Sincronización de los sprints en proyectos con más de un grupo de trabajo

Teniendo en cuenta que habría que estudiar cuál es la solución más adecuada en cada proyecto, soy de la opinión de que resulta más productivo a la vez de que simplifica la gestión, tener sincronizados los sprints de los diferentes grupos de trabajo que participan en el desarrollo de un producto.

Tal vez una primera cuestión, antes de analizar el tema de la sincronización, podría ser si tiene sentido tener varios equipos o no, la respuesta es que depende del número de personas que participan, de si se pueden independizar los desarrollos de manera que no exista gran acoplamiento en los trabajos, de si se tiene uno o más proveedores, de la localización geográfica…, y por supuesto del proyecto.

Si tenemos varios equipos de trabajo es porque de manera acertada o errónea se ha determinado qué es la mejor opción en estos momentos. Superada esa primera decisión, toca determinar si los equipos entregan a la vez o no.

Podría dar igual si cada equipo va desarrollando partes totalmente independientes del producto, es más, podría resultar hasta más productivo de cara a un cliente (aunque no es más que un efecto óptico) ver cómo de manera continua se están añadiendo nuevas funcionalidades al sistema, en lugar de esperar todo un sprint para ver un nuevo incremento. Sin embargo, resulta complicado encontrarnos con situaciones en la que los desarrollos se encuentren totalmente desacoplados, ya que llegará un momento donde será necesario integrar las piezas del puzzle que unen unos desarrollos con otros y esto sucederá tarde o temprano y más de una vez.

Este tipo de desarrollo es demasiado vertiginoso tanto para los propios gestores técnicos del proyecto que tienen que tratar de sincronizar e integrar trabajos de equipos que trabajan en tiempos distintos, como para los propios usuarios que no terminan de trabajar sobre un producto asentado lo que afecta a la calidad de su feedback, a la par de someterles a una gran presión ya que además de eso, deben seguir colaborando en el refinamiento de la pila de producto, proporcionando toda la información y material necesario para que los equipos de proyecto puedan cumplir con sus compromisos.

Además, resulta más fácil alinear los objetivos de varios equipos, así como fomentar su colaboración, ya que tienen un horizonte común que no es otro que la fecha de finalización del sprint, independientemente de las tareas que tengan que realizar cada uno.

A todo lo anterior hay que sumarle el overhead que supone la gestión de más procesos de pasos a producción, que se multiplicarían con aquellos casos en los que sea necesario realizar subidas fuera de sprint para resolver incidencias críticas.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: