El Sistema Safe para la Gestión de Portfolio: Kanban, Roles y responsabilidades y Agile PMO. Este es el nombre del segundo artículo la serie de 4 posts que, desde PPM School hemos preparado sobre el marco de trabajo Scaled Agile Framework (SAFe). En el anterior artículo, tratamos la importancia de los Principios SAFe en la gestión Ágil del Portfolio. Su importancia viene dada debido a que estos conforman la base de este método y condicionan toda la forma de trabajo. Es por ello fundamental conocer cuáles son, e identificar cuáles afectan en mayor medida a la gestión del portfolio.
Teniendo en cuenta lo anterior, ha llegado el momento de prestar atención al “cómo”, a la forma en que SAFe plantea la Gestión de Portfolio Ágil, a través de un sistema de gestión compuesto por los siguientes elementos:
- El Portfolio Kanban
- Roles y responsabilidades
- El Lean Portfolio Management
- La PMO Ágil
Veamos a continuación cada uno de estos elementos, y cómo interactúan entre ellos.
1. Gestión de Portfolio Kanban
A nivel de gestión de portfolio, el Kanban se utiliza para visualizar, gestionar y analizar la priorización y el flujo de las Epicas (Epics). Con esta técnica de gestión se puede visualizar todo el flujo: desde la ideación hasta la implementación y finalización de las Epicas.
El concepto de Epica que emplea SAFe difiere un poco del que se emplea en los entornos Ágiles más habituales como Scrum. En el contexto de SAFe, las Epicas hacen referencia a iniciativas suficientemente grandes como para requerir un análisis, la definición de un Producto Mínimo Viable (MVP) y la aprobación financiera antes de su implementación. Por todo ello, la implementación de una Epica tiene lugar en varios Program increments (PI). La construcción o desarrollo de estas sigue el ciclo Lean: construir-medir-aprender.
Sistema Kanban de Portfolio de SAFe
El sistema Kanban de Portfolio de SAFe describe, tal y como aparece en el siguiente diagrama, el estado de las Épicas a medida que avanzan en su flujo de decisión y realización (o rechazo).
Observa como el sistema propuesto se compone de seis columnas, que presentan las diferentes fases de gestión:
- Funnel; en esta columna o parte del proceso es donde vienen a parar todas las nuevas ideas, oportunidades de negocio, etc. El “embudo” se utiliza para capturar todas las grandes ideas nuevas. Pueden provenir de cualquier fuente y pueden ser conceptos de negocio o técnicos (habilitadores).
- Reviewing; las Epicas que alcanzan este punto requieren más tiempo y esfuerzo. En esta fase se procede a realizar una estimación aproximada del “tamaño” y del valor. La inversión en tiempo se limita a la discusión, con quizás una investigación preliminar
- Analyzing; cuándo un Épica llega hasta este punto merece un análisis más riguroso, y requieren una mayor inversión. Los Epic Owner asumen la responsabilidad de este trabajo, para lo cual es necesario establecer colaboraciones con otros roles. Veremos más respecto a los roles en el siguiente apartado.
- Portfolio Backlog; esta columna del tablero o “fase” recoge las Épicas aprobadas a través del Lean Portfolio Management (LPM). Las Épicas que forman parte de este Backlog se revisan y priorizan periódicamente utilizando el WSJF, un modelo de priorización utilizaco para secuenciar el trabajo. Cuando se disponga de capacidad suficiente en los ART, la Épica en cuestión avanzará al estado siguiente: implementación.
- Implementing; a medida que se va liberando capacidad las Épicas se mueven hasta el kanban correspondiente (Large Solution o Programm). Recuerda que SAFe (Full SAFe) se estructura en cuatro niveles. Una vez allí, las Épicas son generalmente sometidas a un análisis adicional antes de proceder a su desarrollo. Por ejemplo, las Épicas suelen dividirse en capacidades (capabilities) y características (features), y se establecen criterios de aceptación.
- Done; una vez que se ha evaluado su resultado, la Épica se considera terminada. Si la evaluación es positiva podría realizarse más trabajo en base a capacidades, características o épicas. En caso contrario, el portfolio podría cambiar de enfoque o abandonaría la iniciativa por completo.
Cada una de las seis columnas o estados se refieren a las fases por los que atraviesa una Épica desde su ideación hasta la implementación. Es necesario tener en cuenta que los estados detallados en el diagrama anterior tan solo representan un ejemplo, que puede servir como idea inicial.
Una vez se pone en marcha y se genera aprendizaje, el diseño del Kanban debería evolucionar para reflejar las mejoras en el proceso. Estas pueden derivar de ajustes en los límites al WIP, de dividir o combinar estados, o agregar clases de servicio para optimizar el flujo y la prioridad de las épicas.
La importancia de los WIP
Como ya sabrás un Kanban representa el flujo continuo de trabajo de un proceso de desarrollo de producto. Una de las formas más eficaces de organizar ese flujo continuo es establecer límites al trabajo en curso (WIP, Work In Progress).
Si bien la teoría de los WIP es fácil de entender, la aplicación práctica de estos resulta complicada, y aún más a nivel de Portfolio. De hecho, la aplicación práctica de esos límites dentro del Kanban a nivel de Portoflio es una de las partes más difíciles de la iniciativa de transformación Ágil.
¿Cuál es el principal problema al respecto?… En casi todos los procesos se ponen en marcha demasiadas iniciativas estratégicas simultáneamente para satisfacer a la mayor cantidad posible de partes interesadas. Y en la mayoría de los casos, las mismas partes interesadas se frustran cuando los equipos de TI no pueden implementar todas sus solicitudes.
Para el cliente y los usuarios, TI es responsable de los retrasos, de los largos tiempos de espera y de las expectativas no cumplidas. Pero en la mayoría de ocasiones los equipos de trabajo están haciendo todo lo posible; el problema real es la falta de gestión del flujo (los WIP).
Un departamento de banca de inversión quería presentar Scrum a sus equipos de TI. Un breve análisis de su proceso de desarrollo mostró que los equipos de TI no eran el cuello de botella del proceso: más del 70% del tiempo de ciclo se dedicó a analizar las tareas comerciales antes de que los equipos de desarrollo recibieran los nuevos requisitos de productos de inversión. Después de implementar un proceso de cartera Agile con un Kanban administrado por WIP, el tiempo de análisis disminuyó en más del 50%.
Durante el proceso de gestión del portfolio es fundamental establecer los WIP. Esta es en muchas ocasiones una tarea delicada que requiere de un “buen equilibrio” político: los intereses de los diferentes stakeholders son muchos, pero los recursos limitados.
Para tener éxito debemos responder a las siguientes preguntas:
- ¿Cómo funcionan y cooperan los roles de SAFe definidos a nivel de portfolio? ¿Y quién más, basado en nuestra experiencia, debería estar trabajando a nivel de portfolio para impulsar la épica?
- ¿Cuáles son los resultados y las políticas para los diferentes estados de Kanban y cómo se documentarán?
- ¿Cómo pueden, las prácticas de portfolio, explicarse e implementarse como una estimación más ágil y la gobernanza?
2. Roles & Responsabilidades en el Portfolio Kanban
El sistema Kanban es una técnica para la gestión de flujo de trabajo, pero son las personas quienes realizan todo el trabajo. Para ayudar en este proceso SAFe establece y describe los roles de Epic Owner y Enterprise Architect, así como, “Solution Portfolio Management” y “Agile Project Management Office” (APMO) como roles adicionales en el Nivel de Portfolio.
Pero, ¿cómo pueden implementarse con éxito y cuáles son las buenas y malas prácticas en el ejercicio de su trabajo? A continuación se describen de forma general estos roles y algunas de dichas prácticas.
-
Epic Owner:
En SAFe el rol de “Epic Owner” es una responsabilidad asumida por un individuo, no un título de trabajo. El “Epic Owner” desempeña un papel central en el proceso de gestión Lean-Agile del portfolio, ya que es el responsable de conducir las épicas a través de todo el sistema Kanban.
-
Descripción
El rol de Epic Owner es responsable de coordinar las Épicas del Portfolio a través del sistema Kanban de gestión del Portfolio. Al respecto es responsable de definir la Épica, su producto mínimo viable (MVP) y el caso de negocio Lean, y cuando se aprueba, también lo es de facilitar su implementación.
Cuándo una Épica es aceptada, el rol de Epic Owner trabaja directamente con los niveles inferiores, Agile Release Train (ART) y Solution Train, para definir las características y capacidades que realicen el valor.
-
Recomendaciones
Además de experiencia en su área de negocios y en la gestión de temas complejos dentro de un sistema políticamente diverso, los “Epic Owner” deben comprender los fundamentos, las características y las herramientas de un sistema Kanban, así como desarrollar una comprensión general de los Principios del Flujo de Desarrollo de Productos.
-
¿Quién está cualificado para desempeñar este rol?
A menudo, hay gerentes de programas o gerentes de negocios / proyectos que tienen algunas de las habilidades y características requeridas de un propietario épico. Sin embargo, dado que la mayoría de ellos ha trabajado en entornos tradicionales, no Lean-Agile, deben recibir capacitación sobre la nueva mentalidad, principios, prácticas, herramientas y métricas.
-
Enterprise Architect
La planificación técnica estratégica, la comunicación y la visibilidad son clave para el rendimiento de la organización. Para hacerlo posible, SAFe establece los roles de System y Solution Architects, responsables en los niveles de Large Solution y Programme.
-
Descripción
Los “Enterprise Architect” actúan como “Epic Owners” que lanzan iniciativas de arquitectura a nivel de “Large Solution Trains” y “Agile Release Trains” y las conducen a través del Portfolio Kanban. El concepto que SAFe utiliza pare referirse a este tipo de iniciativas es de enablers. Los enablers son menudo son creados por arquitectos o por ingeniería de sistemas en los distintos niveles.
El Enterprise Architect promueve el diseño adaptativo y las prácticas de ingeniería e impulsa iniciativas de arquitectura a nivel de Portfolio. Además, las personas que desempeñan este rol también facilitan la reutilización de ideas, componentes, servicios y patrones probados en varias soluciones a nivel de Portfolio.
-
Recomendaciones
Este rol generalmente funciona correctamente si la persona que ostenta dichas responsabilidades no funciona guiado por un pensamiento tradicional up-down (de arriba hacia abajo).
Lean Portfolio Management (LPM)
SAFe describe la función Lean Portfolio Managment (LPM) como «aquella que tiene el nivel más alto en la toma de decisiones y ostenta responsabilidad financiera para los productos y soluciones en un Portfolio SAFe».
-
Recomendaciones
El primer paso antes de implementar el LPM en una organización es comprender a los equipos de gestión, los procesos y los comités directivos existentes:
- ¿Qué comités están activos?
- ¿Quiénes son los miembros?
- ¿Quién o quiénes tienen autoridad para tomar qué decisiones?
Al iniciar una transformación Ágil habitualmente comprobaremos que existen muchos comités, con grupos superpuestos de miembros que no están de acuerdo, o incluso que se anulan entre sí, lo que lleva a un estancamiento y a conflictos internos. Por lo tanto, el requisito esencial para construir un LPM exitoso es que sólo un comité decida sobre un único Backlog del Portfolio.
Antes de comenzar con el nuevo LPM, en una organización de desarrollo de aproximadamente 500 trabajadores del conocimiento, eliminamos más de 20 comités, en su mayoría comités directivos específicos de proyectos, que representaron alrededor del 80% de todas las decisiones de priorización.
Una vez establecido es único comité, el siguiente paso es definir el calendario para las reuniones mensuales de LPM y crear una agenda de reunión. La siguiente figura muestra el contenido de una Agenda que podría tomarse como punto de partida.
Como podemos ver en la agenda, la Gestión Lean del Portfolio requiere información no solo del Kanban y del trabajo acumulado, sino también de los informes sobre el estado actual de la implementación. Al respecto, la PMO Ágil, puede desempeñar un papel vital en el suministro de dichos informes, como veremos en el siguiente punto.
Por supuesto, no todas las Épicas que han cambiado de estado en el tablero Kanban deben discutirse en detalle, solo sería necesario revisar un subconjunto. Los elementos del backlog de portfolio seleccionados serán presentados por el “Epic Owner”. La experiencia nos dice que entre el 20% y el 30% de las Épicas, tienen que ser discutidas en detalle. Todo lo demás es decidido por los “Epic Owner”, en colaboración con sus “Business Owners”. Cuanto mayor es el porcentaje de épicas «no discutidas» en el LPM, mayor es la madurez de la organización con respecto a la toma de decisiones descentralizada.
- ¿Quiénes están cualificados para cumplir esta función?
Las personas que cumplen con estas responsabilidades pueden tener varios títulos y roles. Pero esta función generalmente incluye a los gerentes de negocios y ejecutivos que entienden la posición financiera de la empresa y son en última instancia responsables de la estrategia de cartera, las operaciones y la ejecución.
Budgeting and Planning
Respecto del LPM (Lean Portfolio Management), la experiencia nos ha enseñado que la mayoría de las sesiones de trabajo tienen un enfoque especial. Y que al menos, una vez o mejor dos o tres veces al año, la atención debería estar puesta en el presupuesto y la planificación a largo plazo.
Respecto de la actividad de presupuesto y planificación lean del portfolio, se deberían de considerar varios aspectos:
- Definición del tamaño del presupuesto y asignación a las Solution Trains y ARTs. El LPM debe decidir si el Portfolio dispone del valor suficiente para ampliar los equipos de implementación (el conjunto existente de ART y/o Solution Trains) y aumentar sus presupuestos, o bien para reducirlos, a medida que los ciclos de vida de las soluciones se vayan desvaneciendo.
- Asignación de capacidad para mantenimiento, necesidades técnicas y trabajo de arquitectura. Asignar fondos según el tipo de trabajo también es importante. LPM tiene una visión bastante amplia de estos factores, pero la priorización en los presupuestos asignados debe descentralizarse a los Product Owners y Enterprise Architect, y no necesita ser gestionado en detalle por el proceso central de gestión del Portfolio.
- Gestión de recursos y habilidades. Después de revisar las épicas de los portafolios con los valores más altos, LPM también tiene que estimar qué conocimientos y habilidades son necesarios para implementarlos. ¿Hay cuellos de botella en el «know-how»? ¿Debemos formar y capacitar al personal actual o contratar personas con el conocimiento requerido? (Para esto, a veces implementamos un rol adicional dentro de nuestro equipo de líderes: el Líder de Habilidad y Personas. Esta persona es responsable de coordinar todas las actividades en la organización con respecto al rol de «líder como desarrollador de personas»).
Además, cada pocos meses (según el ciclo de PI), el LPM debería poner el foco en decidir qué épicas se incluirán en la columna de implementación, para que planifiquen en la próxima planificación del PI.
Una tercera área a revisar son las ideas en el embudo (funnel o primera columna del Kanban): decidir cuáles tienen el potencial de ser épicas de alto valor. A veces será necesario profundizar y hacer un análisis detallado. Esto podría consumir cierta capacidad de los Solution Trains y, por lo tanto, debe discutirse en la siguiente sesión de Planificación de PI. En la Figura 3 se muestra un calendario de ejemplo. Vemos que hay un claro ritmo de enfoque entre una vista más estratégica y una vista más operativa del backlog del portfolio.
Figura 3. Ejemplo de calendario LPM
4. La PMO Ágil
Hasta ahora hemos visto tres de los cuatro elementos que conforman el sistema de gestión planteado por SAFe:
- El Potfolio Kanban
- Roles y Responsabilidaes
- El Lean Portfolio Management
La Oficina de Proyectos Ágiles, o Agile PMO es la cuarta categoría de elementos que conforman en un sistema de Gestión del Portfolio Lean-Agile.
La “Agile Project Management Organization” (APMO), junto con los “Solution Train Engineers” (STEs) y los “Release Train Engineers” (RTEs), son generalmente los responsables de apoyar la ejecución de programas descentralizados pero eficientes. Estos entes, proporciona soporte a través de informes estandarizados, mejores prácticas, y la difusión del conocimiento institucional.
En un entorno SAFe, la “Agile PMO” funciona como una unidad de servicio para los Trains (STEs y RTEs). Recopila y agrega los datos de ejecución los trenes para informar del trabajo al LPM, a la Gestión del Portfolio a nivel de Solución y los “Epic Owners”.
Un indicador claro del avance en el grado de madurez de una iniciativa de transformación Agile es cuando se definen a nivel de portfolio un nuevo sistema de métricas e informes. A menudo, cuando se intenta crear por primera vez un sistema de gestión del Portfolio Lean-Agile, no se quiere renunciar a las métricas más tradicionales, como: la supervisión de proyectos como centros de costos o el objetivo de orientación de alcance.
Sin embargo, en un entorno Lean-Agile las métricas tradicionales muestran solo a superficie de control de una cultura de gestión de proyectos convencional. Una mirada más cercana a menudo revela los procesos tradicionales de presupuestación de proyectos, así como las prácticas de gestión tradicionales.
La semana que viene publicaremos la tercera parte de la serie: El sistema SAFe para la gestión del portfolio. Si realmente queremos implementar un proceso de portfolio Lean-Agile, tenemos que cambiar nuestros informes y nuestras métricas. De esta manera, analizaremos: métricas de Portfolio; mapa de flujo de valor; diagrama de flujo acumulativo; informe de progreso épico y valor y costo: Burn Up
