El plan de gestión de proyectos, parte 2: una comparación exhaustiva de Waterfall, DAD, SAFe, LeSS y Scrum@Scale

Visión de conjunto

En la Parte 1 del Plan de gestión de proyectos, cubrimos las metodologías de desarrollo de software Lean Software Development, Agile, Scrum y Kanban y cómo todas tienen sus raíces en Lean Manufacturing. Estas metodologías generalmente se implementan en un solo nivel de equipo. Sin embargo, la complejidad crece a medida que los proyectos y los equipos de proyectos se vuelven más grandes y se necesitan nuevos enfoques para ser ágiles a escala.

En la Parte 2, primero nos sumergiremos en cómo los gerentes de proyecto usan la metodología en cascada, que es el marco más común para el desarrollo de software en las empresas tradicionales. En yuxtaposición a eso, cubriremos los marcos más populares que intentan incorporar principios ágiles a escala: Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) y Scrum@Scale.

Cascada

La metodología en cascada (también conocida como modelo de ciclo de vida de desarrollo de software (SDLC)) es una metodología más tradicional en la que el desarrollo de software cae en cascada de una fase a la siguiente como una cascada. Las fases no se superponen y tienen criterios de entrada y salida específicos para pasar de una fase a la siguiente.

Las seis etapas del ciclo de vida del modelo de cascada original son:

1. Requisitos: en esta fase, se definen las expectativas y los objetivos del proyecto, y los requisitos se analizan y documentan ampliamente, generalmente por un analista de negocios. Los requisitos se revisan y aprueban antes de salir de esta fase.
2. Diseño: una vez que se aprueban los requisitos, comienza el trabajo de arquitectura y diseño del producto para cumplir con los requisitos aprobados. La arquitectura física, la arquitectura de los componentes, el diseño de la base de datos, el componente detallado, el diseño del módulo y otros aspectos del diseño están documentados por un arquitecto o diseñador de software. Luego se revisa y aprueba antes de comenzar la implementación.
3. Implementación: después de que se aprueba el diseño, los desarrolladores de software realizan la implementación o la codificación del software de acuerdo con los requisitos y el diseño.
4. Verificación: una vez completada la implementación, el software es probado por el equipo de pruebas o control de calidad para garantizar que se cumplan los requisitos y el diseño y que se logre el nivel de calidad deseado. Los defectos se encuentran, registran, clasifican y, en muchos casos, se corrigen.
5. Lanzamiento y mantenimiento: una vez completadas las pruebas y la depuración, el producto se lanza al cliente y se instala. A menudo, se realiza una ronda de pruebas para garantizar que la instalación se haya realizado correctamente. Una vez que se entrega el producto, se lleva a cabo un mantenimiento y soporte continuos para garantizar que el producto continúe funcionando según lo diseñado.

Ventajas de la cascada

La cascada tiene algunas ventajas y es adecuada para ciertos tipos de proyectos, pero también tiene serias desventajas. Waterfall se adapta mejor a proyectos más cortos donde los requisitos, la tecnología se entienden bien y no es probable que cambien de manera significativa.

Si se aplica al tipo de proyecto adecuado, algunas de las ventajas del modelo en cascada:

• Simplicidad: Waterfall es simple de implementar debido a la identificación del alcance por adelantado y debido a las fases rígidas y una transición clara de una fase a la siguiente.
• Visibilidad: los interesados ​​miden y ven más fácilmente el progreso, ya que el alcance total del trabajo se conoce de antemano y el proyecto pasa de una etapa a la siguiente.
• Documentación: el alcance, los requisitos y los planes se pueden pensar detenidamente y documentar bien, lo que facilita que los equipos menos experimentados trabajen en el proyecto.
• Trabajo por fases: debido a los roles rígidos y la transición entre fases, es posible que los recursos del proyecto trabajen en otros proyectos cuando su fase principal no está en progreso.

Desventajas de la cascada

Waterfall no es adecuado para proyectos más largos donde los requisitos no se comprenden bien y/o es probable que cambien y/o donde existe un riesgo técnico significativo. En la época actual, en la que las condiciones del mercado cambian constantemente y el tiempo de comercialización es fundamental, esto se aplica a la mayoría de los proyectos de software.

Las desventajas del modelo en cascada, que en su mayoría se centran en su incapacidad para adaptarse al cambio, incluyen:

• Alcance monolítico: Premia a las partes interesadas a pensar en TODO al definir el alcance del proyecto, lo que lleva a un alcance monolítico.
• Comentarios tardíos de los clientes: es difícil para las partes interesadas y especialmente para los clientes imaginar el alcance completo y detallado de un proyecto. Dado que la cascada expone a los clientes a los resultados del proyecto principalmente en las últimas etapas del proyecto, inevitablemente se vuelve difícil incorporar los comentarios de los clientes en el proyecto.
• Cambio de requisitos: en proyectos más largos, las condiciones del mercado y, por lo tanto, los objetivos y requisitos del proyecto tienen un riesgo muy alto de cambiar durante el proyecto.
• Valor creado al final: Waterfall requiere mucho trabajo por adelantado, lo que significa que el valor no se produce hasta el final del proyecto.
• Interdependencia de fases: la incorporación de cambios a menudo da como resultado requisitos y/o reelaboración del diseño que pueden afectar otras áreas del proyecto. La dependencia de las etapas posteriores de las etapas anteriores puede hacer que los pequeños cambios en el proyecto sean desproporcionadamente desafiantes.

Entrega ágil disciplinada (DAD)

La entrega ágil disciplinada (DAD) fue formalizada por Scott Ambler en IBM y Mark Lines y amplía los marcos ágiles y scrum, reconociendo que las partes no ágiles de una organización generalmente están involucradas de alguna manera en la entrega de un proyecto de software. Este marco incluye explícitamente actividades de operaciones de TI, arquitectura empresarial, gestión de cartera, finanzas y adquisiciones en el ciclo de vida completo de entrega. DAD tiene como objetivo aumentar la agilidad comercial general de una manera pragmática.

Principios y componentes principales

roles

DAD tiene muchos más roles que scrum y se divide en dos categorías de roles de equipo. Los roles principales están ocupados por personas que trabajan con el proyecto de manera constante. Los roles secundarios generalmente se introducen temporalmente para ayudar al equipo con el escalado u otros problemas. DAD tiene estos roles adicionales porque aborda todo el ciclo de vida de entrega de la solución y porque reconoce los diversos tipos de roles temporales y de apoyo necesarios que se encuentran en el mundo real.

Roles principales:

1. Stakeholder: Alguien que depende de que su equipo termine el proyecto: cliente, usuario final o colega interno.
2. Miembro del equipo: personas dentro del equipo que realmente hacen el trabajo planificado: desarrolladores, diseñadores, evaluadores, etc.
3. Líder de equipo : de manera análoga al scrum master, el líder de equipo funciona como un líder de servicio para el equipo eliminando impedimentos, facilitando la cohesión del equipo y difundiendo valores ágiles.
4. Propietario del producto: a veces se lo conoce como la "voz del cliente". El propietario del producto representa a las partes interesadas y mantiene la lista priorizada de trabajo que debe realizarse.
5. Propietario de la arquitectura: responsable de mitigar el riesgo de la arquitectura a escala. Este rol generalmente lo ocupa un desarrollador senior dentro del equipo, ya que requiere una formación técnica profunda y un conocimiento sólido del dominio comercial.

Roles secundarios:

1. Especialista: personas que se unen al equipo temporalmente para ayudar en un rol especializado. Por ejemplo, un analista de datos puede unirse para proporcionar capacidades de investigación en las primeras etapas de un proyecto.
2. Experto en dominio: asesores fiscales, asesores legales y otras personas que tienen experiencia en el dominio y ayudan al equipo en desafíos relacionados.
3. Experto técnico: administrador de base de datos, maestro de compilación experto en seguridad, etc. Estas personas ayudan a los miembros más generales del equipo en puntos clave del ciclo de vida.
4. Probador independiente: si bien los probadores suelen formar parte del equipo principal, en algunos casos los requisitos reglamentarios de la vida o los sistemas muy complejos, los probadores independientes trabajan en paralelo para validar el trabajo de entrega.
5. Integrador: a escala, diferentes equipos están trabajando en diferentes partes de todo el sistema. Un integrador ayuda al equipo a integrar su parte con todo el sistema y administra las dependencias.

Soporte de ciclo de vida

DAD promueve un ciclo de vida de entrega completo, no solo la parte de programación y lanzamiento cubierta por ágil/scrum, sino también la fase de inicio donde se define y aprueba la visión del proyecto y las fases de soporte y retiro después del lanzamiento. Actualmente, DAD admite 6 ciclos de vida diferentes:

• El ciclo de vida ágil: un ciclo de vida del proyecto basado en Scrum
• El ciclo de vida Lean: un ciclo de vida del proyecto basado en Kanban
• La entrega continua: ciclo de vida ágil
• La Entrega Continua: Ciclo de Vida Esbelto
• El ciclo de vida exploratorio (Lean Startup)
• El ciclo de vida del programa para un equipo de equipos

Estos ciclos de vida representan diferentes estilos de trabajo, niveles de agilidad de la empresa y otras situaciones en las que los equipos pueden encontrarse. El punto principal es que estos ciclos de vida actúan como sugerencias. DAD promueve el pragmatismo sobre el purismo ya que cada situación es única y los practicantes ágiles disciplinados deben adaptar el proceso ágil a sus necesidades.

Objetivos del proceso

DAD utiliza un enfoque basado en objetivos para crear y adaptar procesos ágiles. Los autores de esta metodología describen los 21 procesos más importantes y comunes que la mayoría de los equipos enfrentarán durante sus ciclos de vida.

Todos estos procesos tienen puntos de decisión documentados que requerirán que el equipo decida cómo estructurarán ese proceso. Cada punto de decisión proporciona técnicas o prácticas sugeridas que se pueden utilizar para implementar la decisión. Puedes ver un ejemplo de esto en la siguiente imagen. Un proceso de “Desarrollo de una visión común” tiene 6 decisiones que se deben tomar. Cada una de esas decisiones tiene de 2 a 5 prácticas sugeridas. Las flechas indican que los autores de DAD ordenaron la lista con el elemento superior como la mejor práctica y el elemento inferior como la peor práctica en esta lista. El texto _ en negrita y cursiva_ significa buenos puntos de partida para los nuevos equipos, que recién comienzan con DAD.

Escalado de DAD

Disciplined Agile Delivery aborda la escalabilidad desde dos ángulos diferentes:

• Agilidad táctica a escala

• Agilidad estratégica a escala

La agilidad táctica trata de abordar los factores de escala del equipo individual, como el tamaño, la distribución geográfica, la complejidad del proyecto, etc., a través de la aplicación situacional de los objetivos del proceso y sus prácticas sugeridas.

La agilidad estratégica trata de abordar el escalamiento a través de la aplicación de estrategias ágiles y esbeltas en toda la organización ampliando el marco para abordar diferentes áreas de la organización:

• DevOps disciplinado: cubre el uso de DevOps para proporcionar resultados más efectivos a una organización.

• TI ágil disciplinada (DAIT): cubre cómo aplicar estrategias ágiles y eficientes a todos los aspectos de TI.

• Empresa ágil disciplinada:. cubre cómo aplicar lean y ágil en toda una empresa.

A salvo

Scaled Agile Framework (SAFe) es el marco Agile escalado más popular, así como el más complejo y completo en este momento. El 29% de los encuestados en el Informe anual sobre el estado de Agile afirma que utiliza este marco en sus organizaciones. A su vez, existen muchos gestores de proyectos SAFe en el mercado.

El inicio de SAFe fue el libro de Dean Leffingwell "Agilidad de software escalable: mejores prácticas para grandes empresas", publicado en 2007. Leffingwell es ahora el metodólogo jefe de SAFe, pero muchas otras personas también contribuyen a este marco. Actualmente, en la versión 4.6, este marco se parece a un producto de software con control de versiones, compatibilidad con versiones anteriores y varios componentes.

Principios y componentes principales

El objetivo principal de SAFe es facilitar la creación y el crecimiento de una empresa Lean, ya que reconoce que muchos tipos diferentes de empresas son, en parte, empresas de software que necesitan ofrecer valor continuamente en el período de tiempo más breve y sostenible.

SAFe for Lean Enterprises intenta crear una empresa Lean proporcionando una base de conocimientos de principios probados, competencias y mejores prácticas.

SAFe 4.6 define las Cinco Competencias Básicas de Lean Enterprise. Cada competencia es un conjunto de conocimientos, habilidades y comportamientos relacionados, que juntos permiten a las organizaciones sobresalir:

1. Liderazgo Lean-Agile : describe cómo los líderes impulsan y sostienen el cambio organizacional a través del aprendizaje, la enseñanza y la implementación de la mentalidad Lean-Agile de SAFe.

2. Agilidad técnica y de equipo : describe las habilidades, los principios y las prácticas que se necesitan para crear equipos ágiles de alto rendimiento.

3. DevOps y lanzamiento bajo demanda : describe cómo la implementación de DevOps y una canalización de entrega continua proporciona a las organizaciones la capacidad de lanzar incrementos de productos en cualquier momento que sea necesario para satisfacer la demanda.

4. Soluciones comerciales e ingeniería de sistemas lean : describe cómo aplicar principios y prácticas lean-agile a la especificación, el desarrollo, la implementación y la evolución de aplicaciones de software grandes y complejas.

5. Gestión de cartera ajustada: alinea la estrategia y la ejecución mediante la aplicación de enfoques de pensamiento sistémico y ajustado a la estrategia y la financiación de inversiones, las operaciones de cartera ágiles y la gobernanza.

Cada una de las competencias básicas se asigna directamente a su nivel respectivo en el diagrama del proceso SAFe, excepto Liderazgo Lean-Agile, que abarca todo el proceso.

Competencia de liderazgo Lean-Agile

El objetivo principal de la competencia de liderazgo Lean-Agile es ayudar a transformar la organización en una empresa lean-agile. Esto se logra aprendiendo, practicando y enseñando la mentalidad, los valores, los principios y las prácticas Lean-Agile de SAFe.

Los valores fundamentales de SAFe guían la transformación hacia la empresa ajustada. En cada oportunidad, el comportamiento de un líder juega un papel fundamental en su promoción. Los valores fundamentales son:

1. Alineación : comunicar la misión, la estrategia de la cartera y la visión de la solución. Lleve a cabo sesiones informativas relevantes y participe en la planificación del incremento del programa (PI) y el mantenimiento de la cartera de pedidos.

2. Transparencia : visualice todo el trabajo relevante.

3. Calidad incorporada : participe en prácticas para brindar calidad a lo largo del ciclo de vida. Negarse a aceptar trabajos de baja calidad. Apoyar inversiones en mantenimiento y reducción de deuda técnica.

4. Ejecución del programa : Participar como dueños de negocios en la ejecución de PI y establecer valor comercial. Asegúrese de que el alcance esté alineado con la demanda y la capacidad. Eliminar agresivamente los impedimentos y desmotivadores.

Los valores fundamentales de SAFe están respaldados por la adopción de la mentalidad Lean-Agile y la aplicación de los principios de SAFe:

1. Tener una visión económica

2. Aplicar el pensamiento sistémico

3. Suponga variabilidad; preservar opciones

4. Cree gradualmente con ciclos de aprendizaje rápidos e integrados

5. Basar los hitos en una evaluación objetiva de los sistemas de trabajo

6. Visualice y limite el WIP, reduzca el tamaño de los lotes y administre la longitud de las colas

7. Aplicar cadencia, sincronizar con la planificación entre dominios

   

8. Desbloquear la motivación intrínseca de los trabajadores del conocimiento

9. Descentralizar la toma de decisiones

Estos principios son similares a los principios Lean y Agile. Finalmente, la transformación de la organización se logra siguiendo la hoja de ruta de implementación de SAFe.

Competencia de equipo y agilidad técnica/nivel de equipo

La competencia de agilidad técnica y de equipo describe las habilidades, los principios y las prácticas necesarias para crear equipos ágiles de alto rendimiento que crean soluciones de alta calidad. Dos características clave son críticas:

• Agilidad del equipo : los equipos adoptan prácticas y principios ágiles, que les permiten trabajar, aprender y adaptarse con una cadencia confiable

• Agilidad técnica : los equipos aplican prácticas técnicas ágiles que garantizan la calidad del código y los componentes, y la mantenibilidad del código que producen. La calidad es un gran enfoque en la competencia de agilidad técnica y del equipo. Para lograr esto, se aplican técnicas de ingeniería ágiles como el desarrollo impulsado por el comportamiento (BDD) y el desarrollo basado en pruebas (TDD) para aumentar la calidad y el flujo. El flujo rápido depende de la calidad del edificio en todo el sistema, ya que los errores pueden afectar gravemente el flujo y retrasar las liberaciones.

El nivel de equipo del diagrama SAFe describe cómo operan los equipos Agile individuales. Todos los equipos son parte del Agile Release Train que trabaja para entregar un Product Increment. Se aplica la mayor parte del flujo ágil/scrum tradicional, donde los equipos trabajan en iteraciones para entregar sistemas que funcionen. Los roles de maestro de scrum, propietario del producto y miembro del equipo se utilizan en SAFe al igual que la mayoría de las actividades y artefactos de scrum. Los equipos también cuentan con el apoyo de funciones a nivel de programa, como Gestión de productos, Arquitecto de sistemas y otros servicios compartidos. Kanban se utiliza para ayudar a visualizar el flujo de funciones a lo largo del ciclo de vida de la entrega y las interacciones y transferencias entre equipos.

DevOps y Release on Demand Nivel de competencia/programa

La competencia DevOps y Release on Demand describe cómo "implementar DevOps y un canal de entrega continua brinda a la empresa la capacidad de liberar valor, en su totalidad o en parte, en cualquier momento necesario para satisfacer la demanda del mercado y de los clientes".

DevOps trabaja para alinear el desarrollo, las operaciones, el negocio y otras áreas para trabajar juntas y generar resultados comerciales. Si bien no todas las organizaciones necesitan lanzar con tanta frecuencia como algunos de los líderes de la industria del movimiento DevOps (Amazon lanza cada pocos segundos), todas las organizaciones deben poder lanzar a pedido.

• DevOps proporciona el enfoque de cultura, automatización, flujo esbelto, medición y recuperación (CALMR) que permite la entrega continua y el lanzamiento bajo demanda

• Los trenes de lanzamiento ágiles (ART) son equipos de equipos ágiles que están organizados para entregar valor bajo demanda a través de una canalización de entrega continua

El nivel de programa del diagrama describe los roles y las actividades necesarias para entregar continuamente a través de un Agile Release Train (ART) . Este nivel funciona de forma iterativa similar al nivel de equipo, pero integra varios equipos ágiles e incluye más ciclos. El ART es un equipo ágil de equipos compuesto por 5 a 12 equipos (50 a 125 personas) que incluyen los roles ágiles tradicionales, así como roles críticos del programa como Ingeniero de capacitación de lanzamiento (RTE) y Gestión de productos. El ART ofrece Incrementos de programa (PI) de 8 a 12 semanas que se planifican a través de PI Planning y están dirigidos por un Product Manager .

El progreso de las características de PI, las epopeyas, etc., se rastrea y administra a través de un tablero Program Kanban. El RTE actúa como Scrum Master en el ART. Las reuniones diarias de sincronización incluyen reuniones diarias del equipo, Scrum-of-Scrums (RTE y Scrum Masters), PO Sync (administración de productos y propietarios de productos) y ART Sync (Scrum-of-Scrums y PO Sync juntos). Cada PI tiene una Demostración del Sistema y una Retrospectiva.

Competencia en soluciones comerciales y ingeniería de sistemas Lean/Nivel de solución grande

La Competencia de Ingeniería de Sistemas Lean y Soluciones de Negocios describe "cómo aplicar los principios y prácticas Lean-Agile a la especificación, desarrollo, implementación y evolución de aplicaciones de software grandes y complejas y sistemas ciberfísicos".

Además de los principios SAFe, la aplicación de los siguientes 8 principios cuando se trabaja en grandes soluciones es clave para esta competencia:

El nivel de solución grande contiene los roles, artefactos y procesos necesarios para crear soluciones grandes y complejas. Múltiples ART están trabajando juntos en Solution Trains para entregar Soluciones . Los objetivos principales son:

• Gestionar la integración frecuente

• Abordar continuamente las preocupaciones de cumplimiento

• Arquitecto de escala, modularidad, liberabilidad y capacidad de servicio

Solution Management controla el contenido de una solución y Solution Train Engineer (STE) guía el trabajo. Solution Architect es responsable de mantener una buena arquitectura para todos los ART en la solución. La planificación previa y posterior a PI se utiliza para planificar soluciones entregadas a través de múltiples incrementos de programa. Una cartera de soluciones contiene capacidades y epopeyas de soluciones y se realiza un seguimiento a través de un tablero Kanban de soluciones.

Nivel de cartera/Competencia de gestión de cartera ajustada

La competencia Lean Portfolio Management “alinea la estrategia y la ejecución mediante la aplicación de enfoques Lean y de pensamiento sistémico a la estrategia y la financiación de inversiones, las operaciones ágiles de cartera y la gobernanza”.

Lean Portfolio Management se centra en las siguientes áreas:

1. Estrategia y financiamiento de inversiones: conecta la cartera con la estrategia empresarial, financia flujos de valor y establece el flujo de la cartera

2. Operaciones de cartera ágiles: coordina los flujos de valor, apoya la ejecución del programa y la excelencia operativa

3. Gobernanza ajustada: pronostica presupuestos, mide el rendimiento de la cartera y exige el cumplimiento

El Nivel de Portafolio contiene los principios, prácticas y roles necesarios para iniciar y gobernar un conjunto de Flujos de Valor de desarrollo. Un Backlog de Portafolio contiene Épicas de Negocios y Épicas de Habilitador y se rastrea a través de un tablero Portfolio Kanban*. **Lean Portfolio Management (LPM) decide qué flujos de valor hay en una cartera e incluye a los máximos responsables de la toma de decisiones en una empresa. Un arquitecto empresarial guía el trabajo y coordina los flujos de valor.

Menos

El marco Scrum a gran escala (LeSS) fue creado por Craig Larman y Bas Vodde, quienes lo basaron en su experiencia en las industrias financiera y de telecomunicaciones. Como su nombre lo indica, LeSS promueve tener la menor cantidad posible de procesos y procedimientos para que muchos equipos Scrum trabajen juntos. Escalar es difícil porque las personas lo hacen complejo, por lo que el objetivo aquí es hacerlo lo más simple posible.

Principios y componentes principales

“LeSS es Scrum, aplicado a muchos equipos, trabajando juntos, en un solo producto”. LeSS se basa en diez principios que le resultarán familiares a cualquiera que esté familiarizado con los principios Lean-Agile:

1. Scrum a gran escala es Scrum

2. Control empírico de procesos

3. Transparencia

4. más con menos

5. Enfoque de producto completo

6. Centrada en el cliente

7. Mejora continua hacia la perfección.

8. Pensamiento sistémico

9. pensamiento esbelto

10. Teoría de colas

LeSS tiene solo dos funciones principales, ambas tomadas de Scrum:

1. Propietario del producto: trabaja con 2-8 equipos.
2. Scrum master: Trabaja con 1-3 equipos.

Todos los equipos trabajan con la misma acumulación de productos en sprints de 1 a 4 semanas. Los equipos trabajan en paralelo, lo que significa que comienzan y terminan los sprints al mismo tiempo. Al final del sprint, los equipos entregan colectivamente un incremento de producto . Puede parecer casi imposible que un propietario de producto trabaje con 8 equipos. LeSS promueve trasladar la responsabilidad de la aclaración de los elementos de la cartera de productos a los equipos. A su vez, los equipos deben ser multifuncionales y contener no solo competencias de codificación, diseño y prueba, sino también conocimiento del dominio empresarial. Más importante aún, los equipos deben estar capacitados para poder llegar a los clientes.

Planificación de Sprint

La planificación se divide en dos partes:

1. Planificación de sprint 1: donde los representantes de los equipos se reúnen con el propietario del producto y deciden qué elementos del backlog abordarán y discuten cualquier cooperación potencial que pueda ser necesaria entre los equipos durante el sprint.
2. Planificación de Sprint 2: Al igual que en el scrum tradicional, cada equipo se reúne por separado para crear un plan sobre cómo se realizarán los elementos del backlog.

Refinamiento de la cartera de productos

El refinamiento de la cartera de productos (PBR) se realiza durante el sprint para preparar los elementos de la cartera de productos para la planificación del sprint. LeSS no ofrece reglas sobre cómo hacer PBR y deja que las empresas descubran por sí mismas su proceso más efectivo. PBR implica tres actividades clave:

1. Dividir artículos grandes.
2. Detallando artículos hasta que esté listo.
3. Estimando.

Fin de Sprint

Al final de cada sprint suceden tres cosas:

1. Sprint Review: una demostración de Sprint compartida, donde los equipos y los clientes exploran lo que se hizo durante el Sprint y lo que se debe hacer a continuación.
2. Retrospectiva: Cada equipo realiza su propia retrospectiva para mejorar su proceso.
3. Retrospectiva general: los equipos, los propietarios de productos y los maestros de scrum se reúnen para inspeccionar y adaptar las prácticas organizacionales para que sean más efectivos.

Scrum@Escala

Scrum at Scale y Scrum@Scale se usan indistintamente. Esta metodología fue introducida por Jeff Sutherland en 2014, quien creó la metodología Scrum y fue uno de los firmantes del Manifiesto Ágil.

Scrum@Scale toma Scrum como punto de partida y ofrece un marco simple y liviano para escalar Scrum con una "burocracia mínima viable". Es menos prescriptivo que las otras metodologías ágiles escaladas y puede considerarse como un meta-marco. Destaca los problemas y áreas de escala y ofrece un marco mental sobre cómo podrían abordarse.

Principios y componentes principales

Scrum@Scale es un marco que simplifica radicalmente el escalado mediante el uso de Scrum para escalar Scrum. En Scrum, el "qué" (propietario del producto) está claramente separado del "cómo" (scrum master). La misma estrategia se utiliza en Scrum@Scale para que la jurisdicción y la responsabilidad se entiendan bien, eliminando el desperdicio y el conflicto.

Scrum@Scale contiene dos ciclos para separar claramente las jurisdicciones: el ciclo Scrum Master y el ciclo Product Owner con dos puntos de contacto: Proceso a nivel de equipo y Comentarios sobre la versión del producto.

Ciclo Scrum Master

El ciclo scrum master es responsable de cómo se construirán las cosas que identificó el ciclo del propietario del producto. En Scrum@Scale, los equipos individuales de Scrum tienen los mismos roles, artefactos, actividades y ceremonias que el Scrum tradicional.

Los equipos de Scrum se agrupan en un Scrum de Scrums (SoS) que es responsable conjunto de producir un incremento de producto conjunto. Participan en la preparación y priorización conjunta de la acumulación, realizan retrospectivas, mantienen la acumulación de impedimentos y realizan un Scaled Daily Scrum (SDS) (similar en formato al scrum diario) para coordinar los equipos y eliminar los obstáculos. El SDS es atendido por al menos un representante (generalmente el scrum master del equipo) de cada uno de los equipos participantes y está dirigido por el Scrum of Scrums master (SoSM) quien es responsable de coordinar con los equipos scrum y los propietarios de productos.

Si se necesita una mayor escala, hay un scrum de scrum de scrums (SoSoS) creado a partir de múltiples SoS que también se reunirían diariamente, y así sucesivamente. El líder general es el Equipo de Acción Ejecutiva (EAT) , que es responsable de promover Agile en la organización, coordinar los equipos Scrum según sea necesario y ser la última parada para eliminar los impedimentos.

Ciclo del propietario del producto

El Product Owner Cycle es responsable de qué producto o servicio se creará y todas las actividades necesarias para respaldarlo. Los Product Owners se asignan a los equipos Scrum y llevan a cabo todas las actividades de su función definidas en Scrum. Los propietarios de productos se agrupan en equipos de propietarios de productos que se asignan a los equipos de SoS. Los equipos de propietarios de productos se reúnen diariamente en un Meta Scrum para discutir una estrategia de alto nivel para los equipos y coordinar según sea necesario con el SoSM correspondiente y otros propietarios de productos y partes interesadas. Los Meta Scrums están dirigidos por un propietario de producto jefe (CPO) .

Los Product Owners escalan de manera similar al ciclo scrum master, dependiendo del tamaño de la organización y culminan en un Executive Meta Scrum (EMT) , que es responsable del establecimiento de prioridades en toda la empresa.

Implementando Scrum@Scale

La implementación de Scrum@Scale comienza con la creación de un modelo de referencia escalable, es decir, un pequeño conjunto de equipos que utilizan Scrum a pequeña escala. Esto se hace para resolver las políticas organizacionales y las prácticas de desarrollo que obstaculizan la agilidad. Scrum@Scale sugiere resolverlos temprano porque es probable que todos los equipos enfrenten estos problemas generales de la organización y las frustraciones consiguientes podrían dificultar la adopción de Agile. Luego, el modelo de referencia se usa como patrón para escalar Scrum a otros equipos y departamentos.

El equipo de acción ejecutiva (EAT) debe crearse inicialmente para implementar el modelo de referencia. EAT está compuesto por personas que tienen poder político y financiero dentro de la organización, ya que podrán implementar los cambios de política organizacional.

Conclusión

En esta segunda parte del plan de gestión de proyectos, hemos cubierto algunos de los marcos más populares utilizados en proyectos o programas más grandes. Waterfall todavía se usa ampliamente en muchas organizaciones y, si bien tiene muchas desventajas debido a sus procesos inflexibles, a veces tiene sentido usar este marco cuando los proyectos son pequeños y el alcance está bien definido y es poco probable que cambie.

A medida que las empresas se enfrentan a proyectos más grandes y complejos con requisitos u objetivos en constante cambio, buscan enfoques más ágiles. Como Agile originalmente estaba destinado a equipos pequeños de 5 a 9 personas, varios practicantes de Agile han llegado con múltiples formas de escalar ágil de equipos individuales, a múltiples equipos, a toda la empresa. En este artículo, cubrimos Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) y Scrum@Scale.

En la parte final del plan de gestión de proyectos, cubriremos algunos marcos específicos de gestión de proyectos como PMP (PMBOK) y PRINCE2. También repasaremos algunos procesos y marcos de innovación como "trabajos por hacer" (JTBD) y "pensamiento de diseño".