Pages Menu
Categories Menu

Posted by on Jun 15, 2016 in General | 1 comment

Escalar Agilidad: Niveles de planificación

Una de las críticas, o excusas, más clásicas cuando una organización mediana o grande… simplificando… una organización que está en el intento de disponer de varios equipos ágiles (ya sabes, cada uno de ellos pequeño, menos de 10 personas, multifuncionales y auto-organizados) se plantea el uso de Scrum es que pierde la visión global.

Eso así que queda un poco ambiguo, “perder la visión global”, bueno, eso viene a ser que si hay muchos equipos, cada uno con su product backlog, su sprint backlog, etc., el jefe, gerente, director, o a quien le caiga la responsabilidad global de todos esos equipos, no le queda claro hacia donde van las cosas, se pierde en los detalles, o ni siquiera entra en los detalles.

Nótese, que este problema podía pasar antes, con agilidad y sin agilidad, etc. Pero bueno, sigamos con lo nuestro.

En el objetivo de, partiendo de un Scrum, resolver, o minimizar este problema, entran diferentes estrategias, desde la gestión de varios Product Backlog, Product Backlog de orden superior, niveles de Product Owner (ejemplo light de ello es el modelo de Spotify), los Portfolios (que han ido introduciendo poco a poco herramientas como Jira o Rally), etc.

De hecho, de una forma u otra, los diferentes llamados “framewoks para escalar agilidad, DAD, SAFe, Less o Nexus, tratan los anteriores (de una forma u otra).

Al final del post te dejo una recopilación de post en los que hemos ido tratando cosas sobre escalar agilidad y en este quería pararme en los niveles de planificación.

Obvio es que hay diferentes niveles de planificación, según sean las necesidades. Para revisar estos niveles, si bien cada uno le pone sus nombres, voya tirar primero de los que habla  Disciplined Agile Delivery (DAD) y de la propuesta de  Mike Cohn en su libro Agile Estimating and Planning

Los diferentes niveles y alcances de la Planificación

Partiendo desde un nivel de mayor de abstracción, más generalidad y menor detalle, estos serían los diferentes planes que DAD contempla, resumidamente, los diferentes alcances de planificación:

– El plan de Portfolio. A esto hay quien le llama cartera de productos, con los productos y proyectos potenciales, nuevos.

– El plan de soluciones. Con el número de lanzamientos próximos en producción o plan de pasos a producción, según el sitio.

Por si acaso, los dos anteriores no se tratan en DAD, los menciona pero poco más.

– El plan de releases. Aquí se reflejan las principales partes del ciclo de vida de un “proyecto” incluido el inception, la creación y la transición (son fases de DAD). Aquí en este nivel, normalmente, se usan Epopeyas e Historias de Usuario.

– Plan te iteraciones. Este no está considerado como tal en DAD, lo he sacado de Agile Estimating and Planning, y es aquel cuyo alcance es la iteración. En Scrum sería el Sprint Planning.

– El plan diario. Ya a más nivel de detalle.

Los anteriores niveles de DAD están inspirados, vamos que son prácticamente los mismos (incluso así se cita en el libro de DAD) en los que menciona Mike Cohn en su libro Agile Estimating and Planning, si bien usa un nivel más, que ya te había incluido en la lista anterior: Strategy, Portfolio, Product, Release, Iteration y Day.

Un detalle más, es que normalmente, a un equipo ágil solo le preocupan los tres niveles inferiores, Release, Iteration y Day. Y a los jefes los niveles superiores.

Para continuar con todo esto de escalar agilidad te dejo la serie completa de post en os que hemos ido tratando el tema:

Escalar Agilidad: Portfolio Management
Escalar Agilidad: las dependencias entre equipos
Escalar agilidad: Liderazgo tribal (1/3). ¿Qué cultura tiene la tribu en la que trabajas?
Escalar agilidad: Liderazgo tribal (2/3). Moviendo a una tribu de una etapa a la siguiente
Escalar agilidad: Liderazgo tribal (3/3). El camino hacia la deseada etapa cuatro
Escalar Scrum: el Executive Action Team, el Meta-Scrum y Scrum of Scrums
Escalar Scrum: Cuántos Product Owner debería haber

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. Buen post Javier,

    Leffingwell también empezo con una jerarquía de requisitos (u horizontes de planificación) en su libro Agile Software Requirements, antes de lanzar SAFe.

    Como bien dices, estos niveles de planificación son relativamente parecidos e integrarlos en los ciclos de decisión (aprobación del presupuesto, aprobación de proyectos, hitos de entrega, etc.)

    ¡Saludos!
    Alex Ballarin @ http://www.itnove.com

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This