Sprints, líneas temporales, entregas y proyectos

Desde algún otro punto de vista, el tema de organizarse “orientado a equipos” vs organizarse “orientado a proyectos” ya lo hemos tocado alguna vez. De hecho, este post de hoy, podría ser una continuación, o consecución, de aquel de más allá del concepto “proyecto” en tecnología #noprojects #beyondproject, que quizá te perdiste, salió en el duro mes de julio español, pero que te recomiendo encarecidamente que leas.
Yo siempre que hablo con alguien y sale este tema, el de la “orientación a equipos” a la que conlleva la, llámala, agilidad, digo que esto es fácil de decir, “orientate por equipos frente a proyectos” pero que a la hora de la verdad a la gente le cuesta mucho interiorizarlo, son demasiados años de trabajo orientado a proyectos como para cambiar el chip rápidamente.
Yo casi siempre que le cuento esto a alguien me dice “sí, es lo más lógico”, pero luego me suele acompañar esa respuesta diciendo algo que indica que realmente no lo había interiorizado, no había llegado aún la profundidad de este tema.
Y este post nace, literalmente, de una de esas frases con las que algún día alguien acompañó a la frase “sí [organizarse por equipos frente a por poryectos], es lo más lógico”.
Modelos como Scrum están más pensados para establecer un marco de trabajo para el equipo, hay quien incluso dice que al Product Backlog habría que haberlo llamado “Team Backlog”, marcando que ese Backlog realmente refleja las cosas que tiene que hacer un equipo, normalmente para un “producto”, pero no necesariamente… podría ser para varios, e incluso podría contener cosas sin relación explícita y directa con un producto.
El problema, o uno de ellos, viene cuando una organización trabaja por proyectos. Es decir, ya sabes, que te voy a contar, fecha inicio, fecha fin y entregas, con grandes cantidades de tiempo entre ellas.
Entonces, de entre muchas cosas (que nos darán para varios post), sucede que alguien sí que “compra” la idea de fijar equipos estables, pero necesita que estos equipos hagan proyectos, destaco el plural, proyectos. Proyectos, porque es lo único que entienden sus clientes entienden, sólo entienden la palabra proyecto, fecha inicio, fecha fin y entregas.
Tras lo anterior, organizado un equipo (o varios, pero no quiero complicar el post), el lado oscuro nos hace pensar en trabajar en líneas temporales adaptadas a los proyectos y sus entregas. Incluso a tener varias líneas temporales de Sprints por cada proyecto, adaptando los finales de Sprints a las entregas. He llegado a ver a un único equipo gestionando (malamente) tres líneas temporales, cada una con sus Sprints, cada una con Sprints de temporalidad diferente, cada uno adaptado a un cliente.
Como te puedes imaginar, lo anterior es un lío con las dimensiones de un Destructor Estelar clase Imperial.
Un equipo sólo puede hacer lo que puede hacer, la carga de trabajo que pueda resolver, independientemente de los proyectos que le carguemos. Un único Backlog, el Backlog del equipo, pudiera, si no tengo más alternativa, contener cosas de varios proyectos. La línea temporal, e infinita, de los Sprints con los que trabaja un equipo debiera ser única y tienes que verla más como una herramienta para gestionar el trabajo de un equipo, para que se auto-gestione, que como una adaptación a entregas de proyectos – clientes. Y el final de un Sprint no necesariamente implica una entrega al cliente.
Te pongo el ejemplo cercano de cómo trabajan 233 Grados de TI: no sé ni cuantos «proyectos» se tocan por sprint, cuyas actividades están priorizadas en un único Backlog y con una ÚNICA temporalidad de sprints inamovible desde hace años.
Sé que incluso este post es algo ínfimo para poder contar y explicar algo tan profundo como a la vez sencillo cuando se entiende y complicado de llegar a hacerlo cuando se ha trabajado proyectos toda la vida.
Mantén equipos fijos, fija una temporalidad inamovible (salvo causa mayor) para sus Sprints y si necesitas ponerle cara de proyecto a tus clientes, ves metiendo, y priorizando en su único Backlog las cosas que hay que hacer de uno, o varios, proyectos. Los finales de Sprint terminarán con entrega al cliente o, lo más normal, sin entrega al cliente. Los fin de sprint terminarán con un “incremento” de valor.

4 comentarios en “Sprints, líneas temporales, entregas y proyectos”

  1. Buenas Javier,
    Muy interesante el post, yo trabajo en una consultora y todos nuestros grandes clientes se han movido a la gestión de proyectos en forma Agile, aquí me surge una duda. El cliente tiene unas necesidades las cuales tú resuelves con una propuesta incluye la solución, el tiempo de resolución y el coste, este coste viene definido por las personas involucradas en la solución por el tiempo de permanencia de cada persona, hasta aquí lo normal de toda la vida en consultoría y ahora entra el tema Agile, tú tienes unas fechas de entrega y las tienes que encajar en los sprints, entonces la velocidad y los puntos de historia pierden su sentido. Yo creo que tanto a las consultoras como a las empresas nos queda mucho por aprender, usamos Agile solo para tener un seguimiento mucho mas continuo y ver incidentalmente la solución pero seguimos pensando y gestionando los proyectos de forma tradicional, ¿Que opinas tú? y ¿como crees que podríamos cambiar esto?.
    Muchas gracias un saludo.

    1. EL primer punto es que las necesidades, en las que tradicionalmente se basa todo, pasta, tiempo, estimación, la realidad es que cambian, y en gestión tradicional, visión proyecto, son inamovibles, y con ello las fechas, los contratos, etc., resultado, algo que cumple el tiempo, normalmente para ello saltándose mínimos de calidad, lo que implica deuda técnica para los restos… y un desarrollo que cumple tiempos y especificaciones pero que en parte… no le vale a nadie.
      Solución, trabajar con marcos que posibiliten el cambio en necesidades (antiguos requisitos)… sino vuelta a lo de siempre….

Deja un comentario

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

Share This
Ir arriba