Agile facilita la gestión del cambio gubernamental

Publicado el 1 de marzo de 2022 en Transformación digital de la Administración

¿Es la agilidad la fórmula mágica para el éxito de los proyectos gubernamentales? Somos defensores de la metodología ágil porque hemos mejorado nuestros índices de éxito con el desarrollo ágil de productos, la gestión ágil de proyectos y el desarrollo ágil de países. Nuestra metodología, A-i³+qM se basa en buenas prácticas probadas y en casi 40 años de implantaciones exclusivas en administraciones públicas.

¿Qué relación hay entre la gestión del cambio y la metodología ágil?

Las técnicas ágiles, cuando se adaptan a la Administración, integran cambiar. Más allá de la gestión del cambio de software hacia un verdadero cambio organizativo. Planificación de recursos públicos (GRP) está configurado para responder eficazmente a las necesidades reales.

Cuando se practica correctamente, la metodología ágil implica a las partes interesadas desde el principio y con frecuencia. La resistencia al cambio se disipa a medida que se abordan los problemas y se comprueban los avances. Como observa Jason Little, "Agile no es "Agile", es cambio“.

Gestión del cambio en la Administración es especialmente crítica en la implantación de nuevos sistemas financieros, de recursos humanos, de contratación o de rendimiento. En el Marco Cynefin (diagrama anterior), la aplicación de la GRP va más allá de lo técnico. No es sencillo, aunque muchos esperarían que los gobiernos siguieran "buenas prácticas". Muchas de estas prácticas son inadecuadas para el contexto gubernamental del momento.

Además, implantar una GRP es mucho más que un proyecto de gestión de cambios de software. Es transformacional. Hay que llevar a cabo reformas legales, nuevos procesos, reorganizaciones y nuevas mediciones del rendimiento.

El objetivo de las implantaciones de GRP es apoyar buenas prácticaslo que complica su aplicación. La realidad es que las implantaciones se vuelven complejas, a veces caóticas, debido a las singulares limitaciones del sector público:

• Las partes interesadas van más allá de la Administración y se extienden a los ciudadanos
• Capacidad e incentivos de los servicios públicos
• Política, política y más política

¿Cómo se integra la gestión del cambio en Agile?

Aunque existen numerosas técnicas ágiles, (véase el glosario más abajo), gestión del cambio organizativo en el sector público ha estado implícita desde la creación del Manifiesto Ágil. Los valores del Manifiesto muestran que las personas, la colaboración y la flexibilidad son primordiales.

• Personas e interacciones por encima de procesos y herramientasinteracción frecuente con las partes interesadas y los usuarios reduce la resistencia al cambio al tiempo que aumenta la probabilidad de que se aborden las necesidades reales (Un principio ágil: "la gente de negocios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto").
• Software operativo con documentación exhaustivaLa documentación no conduce a una comprensión compartida con las partes interesadas y los usuarios. resistencia al cambio aumentar (Un principio ágil: "el método más eficiente y eficaz de transmitir información a un equipo de desarrollo y dentro de él es la conversación cara a cara").
• Colaboración del cliente por encima de la negociación del contratoLa colaboración da voz a las partes interesadas y a los usuarios
• Responder a los cambios en lugar de seguir un planEl contexto se aprende a través de conversaciones, no mediante una planificación rígida.

Cómo acertar con la gestión ágil del cambio en la administración pública

Agile funciona bien cuando confíe en y se fomenta. Agile permite la gestión del cambio en la Administración cuando se gestiona adecuadamente:

• Consideracióntécnicas ágiles como Design Thinking y PDIA fomentan la empatía y la comprensión de los problemas desde la perspectiva de las partes interesadas y los usuarios
  • IMPACTO: las partes interesadas y los usuarios se dan cuenta de que los sistemas no los imponen los de fuera.
• Centrado en el clienteagile trabaja desde el cliente hacia fuera (lo que llamamos "outside-in" en la gestión de productos) en lugar de desde el producto hacia dentro (lo que llamamos "inside-out" en la gestión de productos)
  • IMPACTO: los temores y aspiraciones de las partes interesadas y los usuarios se incorporan a los proyectos.
• ComunicaciónComunicación constante: mantiene al día a las partes interesadas y a los usuarios mediante tablones y otros métodos de comunicación visual para mostrar las decisiones, los avances y los retrasos.
  • IMPACTO: las partes interesadas y los usuarios son menos propensos a imaginar lo peor entre hitos, cuando los progresos se comunican de forma visible.
• ConversaciónConversaciones cara a cara con las partes interesadas y los usuarios, incluidos talleres, tormentas de ideas y guiones gráficos.
  • IMPACTO: las partes interesadas y los usuarios reconocen la capacidad de ajustar los entregables del proyecto a la vez que aprenden más sobre el valor del proyecto para ellos, su organización y su país para aumentar la aceptación del cambio.
• ContextoLos equipos de proyecto comprenden el contexto del país y del gobierno (FreeBalance dispone de herramientas para facilitar este proceso).
  • IMPACTO: se mejora la comprensión compartida entre los participantes para reducir la resistencia al cambio.
• ColaboraciónLos equipos de proyecto, las partes interesadas y los usuarios colaboran para establecer prioridades, resolver problemas y debatir soluciones.
  • IMPACTO: la influencia en el proyecto a través de la participación aumenta la aceptación del cambio
• Creatividadaprovechar la creatividad de las partes interesadas y los usuarios para resolver mejor los problemas
  • IMPACTO: las partes interesadas ayudan a resolver problemas, incluidos los del cambio
• ConfirmaciónColaboración: permite a los participantes confirmar las prioridades del proyecto a lo largo del mismo, en lugar de firmar en los principales hitos como única vía.
  • IMPACTO: se reducen los retrasos del proyecto gracias a la confirmación iterativa, lo que da poco tiempo a que surja la resistencia al cambio, mientras que los bucles de retroalimentación validan las preocupaciones de las partes interesadas y los usuarios.
• Capacidad: la capacidad en materia de proyectos gubernamentales y gobernanza adquirida durante las conversaciones y la colaboración como tutoría, aumenta la formación y mejora el éxito de los proyectos
  • IMPACTO: mantiene la trayectoria de cambio organizativo más allá del proyecto (y hace que el proyecto sea más sostenible).

¿Por qué los gobiernos se resisten a una gestión ágil del cambio?

Algunos clientes de la Administración preguntan por qué implicamos a no expertos en el diseño de soluciones. Las demostraciones parecen ser el mejor enfoque para comunicar el impacto de la agilidad para mejorar la toma de decisiones y la gestión del cambio organizativo en el sector público. Además de utilizar agilidad en las implantacioneshemos utilizado ejercicios ágiles en nuestra reunión anual de Comité Directivo Internacional de FreeBalance (FISC), talleres sobre el cambio y ejercicios sobre el contexto de cada país.

El cambio de actitud de los funcionarios es palpable. Al principio, recelo. Quizá un poco de confusión. Luego, colaboración y conversación. Llega un momento en que todos los grupos de trabajo quieren presentar sus conclusiones en el taller. Colaboración real.

¿Qué es el proceso de gestión del cambio organizativo?

Los procesos tradicionales de gestión del cambio organizativo tienden a seguir una secuencia lineal, tal como se describe en la 5 I's:

1. Iniciación
2. Investigación
3. Intención
4. Introducción
5. Aplicación
6. Integración

Otro enfoque diseñado por John Kotter:

Se trata de marcos excelentes para el cambio organizativo. El enfoque lineal, sin embargo, parece alinearse con el tradicional cascada enfoques. Al igual que agile puede alinearse con las normas CMMi e ISO, no hay razón para que estos enfoques no puedan aprovecharse iterativamente. La iteración puede mejorar los resultados del cambio, del mismo modo que el desarrollo de software y los índices de éxito de la gestión de proyectos mejoran gracias a la agilidad.

Hemos visto algunos proyectos en los que la gestión del cambio organizativo en la Administración se consideraba un añadido a la gestión de proyectos. El resultado suele ser una gestión del cambio ineficaz.
Tiene sentido contar con expertos en cambio en los proyectos. A menudo se produce una desconexión cuando los expertos en cambio carecen de conocimientos especializados. Por eso es más eficaz que el cambio forme parte integral de los proyectos. Contar con personal de proyecto que fomente el cambio y la credibilidad.

¿Cuáles son las ventajas de la gestión ágil del cambio en la administración pública?

Reed Deshler ve la necesidad de una enfoque en tiempo real a la gestión del cambio en proyectos ágiles. Esto incluye la adaptación de los procesos de gestión del cambio entendidos para que sean "aptos para el propósito" de cada proyecto. Un estudio de Prosci analizó las prácticas de gestión del cambio en proyectos ágiles. El análisis determinó que el éxito de la gestión del cambio en proyectos ágiles requiere:

• Enfoques iterativos en lugar de lineales
  • OBSERVACIÓN: todos los componentes del proyecto son iterativos en agile, y el impacto de la gestión del cambio es continuo para lograr la aceptación del cambio
• Planes de cambio diseñados para adaptarse
  • OBSERVACIÓN: los planes de cambio deben modificarse a medida que los participantes en el proyecto aprenden más sobre el contexto a través de la conversación y la colaboración; considérelo como una adaptación a la retroalimentación.
• Requiere más tiempo por adelantado
  • OBSERVACIÓN: agile proporciona el marco de comunicación para el cambio para facilitar la planificación, mientras que una mayor planificación del cambio se produce a través de una menor planificación y documentación del proyecto - donde la gestión del cambio se convierte en una prioridad más alta

Nuestra experiencia con la metodología ágil en el mundo real es que genera el tipo de resultados rápidos necesarios para mantener la aceptación del cambio. Agile proporciona pasos visibles entre las victorias rápidas gracias a la implicación, la flexibilidad y la creación de prototipos. Nos hemos beneficiado del diseño de productos del FreeBalance Accountability Suite™ gracias a métodos de configuración que permiten confirmar las reglas de negocio y la configuración en talleres. Esto permite el tipo de desarrollo ágil que no está disponible en el software gubernamental totalmente personalizado o en el software del sector privado fuertemente personalizado, como la planificación de recursos empresariales (ERP).

Enfoque PDIA de la gestión ágil del cambio en la administración pública

Como se ha descrito anteriormente, el contexto de la gestión del cambio organizativo tiende a ser más complejo en el gobierno que en las empresas. Adaptación iterativa basada en problemas (PDIA), una metodología de desarrollo del sector público y excelente herramienta de gestión del cambio aborda este reto de complejidad. La PDIA es cada vez más aceptada en el ámbito de la buena gobernanza y la gestión del cambio. comunidad de desarrollo del país.

El PDIA fue desarrollado por la Building State Capacity facility de la Harvard Kennedy School of Government. Es mucho más que un ejercicio académico con numerosos casos prácticos en el mundo real. Forma parte del Un desarrollo diferente movimiento. Somos grandes fans de PDIA. Muchos de nuestros ejecutivos han cursado Executive Education de PDIA. Muchos de nuestros empleados han tomado cursos en línea de PDIA.

PDIA prioriza el cambio y la persuasión, permite asignar funciones y estrategias de comunicación. El PDIA incorpora el mapeo de las partes interesadas, las comunicaciones y la colaboración.

PDIA permite analizar la cambiar espacioLa superposición de autoridad, capacidad y aceptación. Se trata de una técnica de gestión del cambio especialmente eficaz. Como se describe en el Manifiesto por un desarrollo diferente: el éxito pasa por la legitimación "a todos los niveles (político, empresarial y social), creando apropiación e impulso a lo largo del proceso para ser 'propiedad local' en la realidad (no sólo sobre el papel)".

El PDIA reconoce que un cambio sustancial no depende de un líder heroico. El éxito del cambio en el sector público depende de muchos líderes. Se trata de agentes. Esto va más allá del enfoque tradicional de los agentes de cambio y se convierte en agentes de escalado. El cambio a escala se presenta con un copo de nieve metáfora.

¿Qué es la metodología ágil FreeBalance?

Nuestra metodología ha iterado a lo largo de los años. La versión actual es A-i³+qM (acelerado, integrado, iterativo, centrado en la aplicación, gestión de la calidad):

• Acelerado eliminando el mayor número posible de procesos heredados en cascada que provocan problemas en los proyectos. Esto incluye documentación innecesaria y planes de proyecto detallados, en favor de talleres y pasos de proceso cortos. Los equipos son pequeños para facilitar la comunicación con el cliente y reducir los gastos de coordinación.
• Integrado a través de una metodología única para apoyar el desarrollo y la implantación de servicios. Esto se integra con los requisitos del cliente a través de los procesos centrados en el cliente. Esto proporciona transparencia entre el personal del cliente, los implementadores y el equipo de desarrollo. Los equipos de implantación y desarrollo de productos se integran siguiendo prácticas DevOps.
• Iterativo responder a los cambios del cliente y de la aplicación mediante fases. La metodología aprovecha lo mejor de las metodologías "lean" de desarrollo de software y servicios, con talleres, iteraciones cortas, historias de usuario, hitos y la capacidad de mostrar el progreso. Estas técnicas se extienden más allá de la organización de desarrollo a los servicios de implantación, aprovechando las ganancias de productividad y la capacidad de reaccionar a los requisitos del cliente.
• Centrado en la aplicación con plantillas de buenas prácticas y procesos probados de gestión de programas. Esta metodología se centra en el éxito de la implantación por parte del cliente, más que en un lanzamiento de software que alcance objetivos internos o arbitrarios. La implantación y el desarrollo del producto se gestionan a través de una Oficina de Gestión de Programas.
• Calidad garantiza que el software se publique y reciba soporte cumpliendo las buenas prácticas de Commercial Off-the-Shelf (COTS) con pruebas unitarias, de sistema, de estrés y de regresión. La calidad se integra con la implementación, en la que FreeBalance realiza pruebas basadas en los entornos de los clientes.

A-i³+qM reconoce las deficiencias de los procesos tradicionales de gestión de proyectos en las implantaciones de GRP. Y, los patrones de fracaso.

Glosario Ágil

Todas las definiciones, excepto PDIA, vía wikipedia.org

• Desarrollo de software adaptable (ASD) es un proceso de desarrollo de software que surgió del trabajo de Jim Highsmith y Sam Bayer sobre el desarrollo rápido de aplicaciones (RAD). Incorpora el principio de que la adaptación continua del proceso al trabajo en cuestión es el estado normal de las cosas.
• Desarrollo ágil de software es un enfoque del desarrollo de software según el cual los requisitos y las soluciones evolucionan gracias al esfuerzo de colaboración de equipos autoorganizados y multifuncionales y sus clientes/usuarios finales[1]. Aboga por la planificación adaptativa, el desarrollo evolutivo, la entrega temprana y la mejora continua, y fomenta una respuesta rápida y flexible al cambio.
• Pensamiento de diseño se refiere a los procesos cognitivos, estratégicos y prácticos mediante los cuales los diseñadores o los equipos de diseño desarrollan conceptos de diseño (propuestas de nuevos productos, edificios, máquinas, etc.). Muchos de los conceptos y aspectos clave del pensamiento de diseño se han identificado a través de estudios, en diferentes ámbitos del diseño, de la cognición y la actividad de diseño tanto en contextos de laboratorio como naturales.
• DevOps es un conjunto de prácticas de desarrollo de software que combina el desarrollo de software (Dev) y las operaciones de tecnología de la información (Ops) para acortar el ciclo de vida de desarrollo de sistemas al tiempo que ofrece características, correcciones y actualizaciones con frecuencia en estrecha alineación con los objetivos de negocio.
• Entrega ágil y disciplinada (DAD) es un marco de decisión de procesos que permite tomar decisiones simplificadas en torno a la entrega de soluciones incrementales e iterativas. DAD se basa en las numerosas prácticas adoptadas por los defensores del desarrollo ágil de software, como Scrum, el modelado ágil y el desarrollo de software ajustado, entre otras.
• Método de desarrollo de sistemas dinámicos (DSDM) es un marco ágil de entrega de proyectos, utilizado inicialmente como método de desarrollo de software.
• Programación extrema (XP) es una metodología de desarrollo de software cuyo objetivo es mejorar la calidad del software y la capacidad de respuesta a las cambiantes necesidades de los clientes. Como tipo de desarrollo de software ágil, aboga por "lanzamientos" frecuentes en ciclos de desarrollo cortos, con los que se pretende mejorar la productividad e introducir puntos de control en los que puedan adoptarse nuevos requisitos de los clientes.
• Desarrollo basado en características (FDD) es un proceso de desarrollo de software iterativo e incremental. Es un método ligero o ágil para desarrollar software.
• Desarrollo iterativo e incremental es cualquier combinación de diseño iterativo o método iterativo y modelo de construcción incremental para el desarrollo.
• Kanban (en japonés 看板, cartel o valla publicitaria) es un método ajustado para gestionar y mejorar el trabajo en los sistemas humanos. Este enfoque pretende gestionar el trabajo equilibrando las demandas con la capacidad disponible y mejorando la gestión de los cuellos de botella a nivel de sistema.
• Desarrollo ajustado de software es una traslación de los principios y prácticas de la fabricación ajustada al ámbito del desarrollo de software. Adaptado del Sistema de Producción Toyota, está surgiendo con el apoyo de una subcultura pro-lean dentro de la comunidad Agile. Lean ofrece un sólido marco conceptual, valores y principios, así como buenas prácticas, derivadas de la experiencia, que sirven de apoyo a las organizaciones ágiles.
• Scrum a gran escala (LeSS) es un marco de desarrollo de productos que amplía Scrum con reglas y directrices de escalado sin perder los propósitos originales de Scrum.
• Ingeniería basada en modelos (MDE) es una metodología de desarrollo de software que se centra en la creación y explotación de modelos de dominio, que son modelos conceptuales de todos los temas relacionados con un problema específico. De ahí que destaque y tenga como objetivo las representaciones abstractas de los conocimientos y actividades que rigen un dominio de aplicación concreto, en lugar de los conceptos informáticos (es decir, algorítmicos).
• Marco de soluciones de Microsoft (MSF) es un conjunto de principios, modelos, disciplinas, conceptos y directrices para la prestación de servicios de tecnologías de la información de Microsoft. MSF no se limita únicamente al desarrollo de aplicaciones; también es aplicable a otros proyectos de TI como proyectos de implantación, redes o infraestructuras. MSF no obliga al desarrollador a utilizar una metodología específica (como el modelo de cascada o el desarrollo ágil de software).
• En Proceso de software personal (PSP) es un proceso estructurado de desarrollo de software que pretende (está previsto) ayudar a los ingenieros de software a comprender mejor y mejorar su rendimiento, aportando disciplina a la forma en que desarrollan el software y haciendo un seguimiento de su desarrollo previsto y real del código. Muestra claramente a los desarrolladores cómo gestionar la calidad de sus productos, cómo elaborar un plan sólido y cómo asumir compromisos. También les ofrece los datos necesarios para justificar sus planes.
• Adaptación iterativa basada en problemas (PDIA) es un proceso de surgimiento facilitado que se centra en los problemas (no en las soluciones) y sigue un proceso paso a paso (no un plan rígido) que permite un aprendizaje y una adaptación flexibles, diseñado por el Building State Capacity facility de la Harvard Kennedy School of Government.
• Desarrollo rápido de aplicaciones (RAD), también llamado Rapid-application building (RAB), es tanto un término general, utilizado para referirse a los enfoques adaptativos de desarrollo de software, como el nombre del enfoque de James Martin para el desarrollo rápido. En general, los enfoques RAD de desarrollo de software ponen menos énfasis en la planificación y más en un proceso adaptativo. Los prototipos se utilizan a menudo además de las especificaciones de diseño, o a veces incluso en su lugar.
• En Proceso Racional Unificado (RUP) es un marco de proceso iterativo de desarrollo de software creado por Rational Software Corporation, una división de IBM desde 2003[1]. RUP no es un proceso prescriptivo concreto único, sino más bien un marco de proceso adaptable, pensado para ser adaptado por las organizaciones de desarrollo y los equipos de proyectos de software que seleccionarán los elementos del proceso que sean apropiados para sus necesidades. RUP es una implementación específica del Proceso Unificado.
• En Marco Scaled Agile (abreviado como SAFe), es un conjunto de patrones de organización y flujo de trabajo destinados a guiar a las empresas en la ampliación de prácticas ágiles y ajustadas. Junto con Scrum a gran escala (LeSS), la entrega ágil disciplinada (DAD) y Nexus, SAFe es uno de los cada vez más numerosos marcos que tratan de resolver los problemas que surgen cuando se amplía más allá de un único equipo.
• Scrum es un marco ágil para gestionar el trabajo del conocimiento, con énfasis en el desarrollo de software, aunque tiene amplia aplicación en otros campos y está empezando a ser explorado lentamente por los equipos de proyectos tradicionales de forma más general. Está diseñado para equipos de entre tres y nueve miembros, que dividen su trabajo en acciones que pueden completarse en iteraciones de tiempo limitado, denominadas sprints, de no más de un mes y normalmente dos semanas, y que realizan un seguimiento de los progresos y replanifican en reuniones de 15 minutos de duración, denominadas scrums diarios.
• Scrumban es una metodología de gestión ágil que describe híbridos de Scrum y Kanban y fue diseñada originalmente como una forma de transición de Scrum a Kanban. Hoy en día, Scrumban es un marco de gestión que surge cuando los equipos emplean Scrum como su forma elegida de trabajo y utilizan el método Kanban como una lente a través de la cual ver, entender y mejorar continuamente la forma en que trabajan
• SEMAT (Método y Teoría de la Ingeniería del Software) es una iniciativa para remodelar la ingeniería del software de modo que ésta se considere una disciplina rigurosa. La iniciativa fue lanzada en diciembre de 2009 por Ivar Jacobson, Bertrand Meyer y Richard Soley con una llamada a la acción y una declaración de visión. La iniciativa se concibió como un esfuerzo plurianual para tender un puente entre la comunidad de desarrolladores y la comunidad académica y para crear una comunidad que aporte valor a toda la comunidad del software.
• En combinación con el proceso de software personal (PSP), el proceso de software en equipo (TSP) proporciona un marco definido de procesos operativos diseñado para ayudar a los equipos de gestores e ingenieros a organizar proyectos y producir productos de principios de software que van desde pequeños proyectos de varios miles de líneas de código (KLOC) hasta proyectos muy grandes de más de medio millón de líneas de código.
• El Proceso Unificado de Desarrollo de Software o Proceso unificado es un marco de proceso de desarrollo de software iterativo e incremental. El refinamiento más conocido y ampliamente documentado del Proceso Unificado es el Proceso Unificado Racional (RUP). Otros ejemplos son OpenUP y Agile Unified Process.