Agile Facilita a Gestão da Mudança Governamental

Posted on Março 1, 2022 em Transformação Digital do Governo

Será a ágil a bala mágica para o sucesso do projecto governamental? Somos defensores ágeis devido à melhoria das taxas de sucesso utilizando o desenvolvimento ágil de produtos, a gestão ágil de projectos e o desenvolvimento ágil dos países. A nossa metodologia, A-i³+qM é construído sobre boas práticas comprovadas e quase 40 anos de implementações governamentais exclusivas.

Como é que a Gestão da Mudança está relacionada com a Metodologia Ágil?

As técnicas ágeis, quando adaptadas ao governo, integram alteração. Para além da gestão da mudança de software, a verdadeira mudança organizacional. Planeamento de Recursos Governamentais (GRP) é configurado para satisfazer eficazmente os requisitos reais.

Quando devidamente praticada, a agilidade envolve as partes interessadas cedo e frequentemente. A resistência à mudança dissipa-se à medida que as questões abordadas e os progressos são comprovados. Como Jason Little observa, "Agile não se trata de "Agile", mas sim de mudança“.

Gestão de mudanças no governo é particularmente crítico na implementação de novos sistemas financeiros, de recursos humanos, de aprovisionamento, ou de desempenho. Na Quadro Cynefin (diagrama acima), a implementação do PRG está para além da técnica. Não é simples, ainda que muitos esperem que os governos sigam".as melhores práticas“. Muitas destas práticas são inadequadas para o contexto do governo na altura.

E, implementar um GRP é muito mais do que apenas um projecto de gestão de mudança de software. É transformacional. Há reformas legais, novos processos, reorganizações e novas medidas de desempenho que têm de ter lugar.

O objectivo nas implementações do GRP é apoiar boas práticas, tornando as implementações complicadas. A realidade é que as implementações se tornam complexas, por vezes caóticas, devido a constrangimentos únicos do sector público:

• As partes interessadas estendem-se para além do governo aos cidadãos
• Capacidade de serviço público e incentivos
• Política, política, e mais política

Como é que a Gestão da Mudança é Integral para Ágil?

Embora existam numerosas técnicas ágeis, (ver glossário abaixo), gestão da mudança organizacional no sector público tem estado implícito desde a criação do Manifesto Ágil. Os valores do manifesto mostram como as pessoas, a colaboração e a flexibilidade são primordiais.

• Indivíduos e interacções sobre processos e ferramentas: a interacção frequente com as partes interessadas e utilizadores reduz a resistência à mudança, ao mesmo tempo que aumenta a probabilidade de as necessidades reais serem satisfeitas (Um princípio ágil: "os empresários e os promotores devem trabalhar em conjunto diariamente ao longo de todo o projecto").
• Software de trabalho sobre documentação abrangenteA documentação não conduz a um entendimento partilhado com as partes interessadas e os utilizadores - frequentemente atrasa as implementações dando tempo para resistência à mudança aumentar (Um princípio ágil: "o método mais eficiente e eficaz de transmitir informação para e dentro de uma equipa de desenvolvimento é a conversação presencial").
• Colaboração do cliente na negociação do contrato: a colaboração dá voz às partes interessadas e aos utilizadores
• Responder à mudança de acordo com um plano: o contexto é aprendido através de conversas, não através de um planeamento rígido

Como obter uma Gestão Ágil da Mudança no Governo

Agile funciona bem quando confiança é permitido e encorajado. Agile permite a gestão da mudança no governo quando gerida adequadamente:

• ConsideraçãoTécnicas ágeis como o Design Thinking e PDIA encorajam a empatia e a compreensão dos problemas do ponto de vista das partes interessadas e dos utilizadores
  • IMPACTO: as partes interessadas e os utilizadores percebem que os sistemas não são impostos por pessoas de fora
• Centrado no cliente: trabalhos ágeis a partir do cliente para fora (o que chamamos "outside-in" na gestão do produto) em vez de produto para dentro (o que chamamos "inside-out" na gestão do produto)
  • IMPACTO: os receios e aspirações das partes interessadas e dos utilizadores tornam-se realidade em projectos
• Comunicação: a comunicação constante mantém as partes interessadas e os utilizadores actualizados através de conselhos de administração e outros métodos de comunicação visual para demonstrar decisões, progressos e atrasos
  • IMPACTO: intervenientes e utilizadores menos propensos a imaginar o pior entre os marcos, onde o progresso é visivelmente comunicado
• Conversação: conversas presenciais com intervenientes e utilizadores incluindo workshops, brainstorming, e storyboards
  • IMPACTO: os intervenientes e utilizadores reconhecem a capacidade de ajustar os resultados do projecto enquanto aprendem mais sobre o valor do projecto para eles, a sua organização, e o seu país para aumentar a aceitação da mudança
• Contextoo contexto do país e do governo torna-se compreendido pelas equipas do projecto (e, a FreeBalance tem ferramentas que permitem este processo)
  • IMPACTO: a compreensão partilhada entre os participantes é reforçada para reduzir a resistência à mudança
• Colaboração: equipas de projecto, partes interessadas e utilizadores trabalham em conjunto para estabelecer prioridades, resolver problemas e discutir soluções
  • IMPACTO: a influência sobre o projecto através do envolvimento aumenta a aceitação da mudança
• Criatividade: alavancar a criatividade das partes interessadas e dos utilizadores para melhor resolver problemas
  • IMPACTO: as partes interessadas ajudam a resolver problemas, incluindo problemas de mudança
• Confirmação: a colaboração dá aos participantes a confirmação das prioridades do projecto ao longo de todo o projecto, em vez de se inscreverem em marcos importantes como única via
  • IMPACTO: os atrasos do projecto foram reduzidos devido à confirmação iterativa, dando pouco tempo para que a resistência à mudança se construa, enquanto os loops de feedback validam as preocupações dos intervenientes e utilizadores
• Capacidade: capacidade governamental de projecto e domínio da governação construída durante conversas e colaboração como mentor, aumentando a formação e melhorando o sucesso do projecto
  • IMPACTO: sustenta a trajectória de mudança organizacional para além do projecto (e torna o projecto mais sustentável)

Porque é que os governos resistem à gestão ágil da mudança?

Alguns clientes do governo perguntam porque é que envolvemos não especialistas na concepção de soluções. As demonstrações parecem ser a melhor abordagem para comunicar o impacto do ágil para melhorar a tomada de decisões e a gestão da mudança organizacional no sector público. Para além de utilizar ágil para implementaçõesutilizámos exercícios ágeis no nosso FreeBalance International Steering Committee (FISC), seminários de mudança e exercícios de contexto de país.

A mudança de atitude entre os funcionários públicos é palpável. A princípio, a suspeita. Talvez um pouco de confusão. Depois, a colaboração e a conversa. Chega-se ao ponto em que todos os grupos de trabalho querem apresentar os resultados ao workshop. Colaboração real.

O que é o Processo de Gestão da Mudança Organizacional?

Os processos tradicionais de gestão da mudança organizacional tendem a ser uma forma sequenciada linear, tal como descrito pelo 5 I's:

1. Iniciação
2. Investigação
3. Intenção
4. Introdução
5. Implementação
6. Integração

Outra abordagem concebida por John Kotter:

Estes são quadros excelentes para a mudança organizacional. A abordagem linear, no entanto, parece alinhar-se com a abordagem tradicional queda de água aproxima-se. Tal como o ágil pode alinhar-se com as normas CMMi e ISO, não há razão para que estas abordagens não possam ser alavancadas iterativamente. A iteração pode melhorar os resultados da mudança, tal como o desenvolvimento de software e as taxas de sucesso na gestão de projectos melhoram através da agilidade.

Vimos alguns projectos em que a gestão da mudança organizacional no governo foi considerada um complemento à gestão de projectos. Isto resulta frequentemente numa "drive-by" e numa gestão de mudança ineficaz.
Faz sentido ter peritos de mudança em projectos. Há frequentemente uma desconexão quando os peritos em mudança carecem de conhecimentos de domínio. Portanto, é mais eficaz ter a mudança como parte integrante dos projectos. Ter o pessoal dos projectos a construir mudança e credibilidade.

Quais são os benefícios da utilização da Gestão Ágil da Mudança no Governo?

Reed Deshler vê a necessidade de um abordagem em tempo real para mudar a gestão em projectos ágeis. Isto inclui a adaptação de processos compreendidos de gestão da mudança para serem "adequados aos objectivos" de projectos individuais. Um estudo realizado por Prosci analisou as práticas de gestão da mudança em projectos ágeis. A análise concluiu que uma gestão da mudança bem sucedida em projectos ágeis requer:

• Abordagens iterativas em vez de lineares
  • OBSERVAÇÃO: todas as componentes do projecto são iterativas de forma ágil, e o impacto da gestão da mudança é contínuo para construir a aceitação da mudança
• Planos de mudança concebidos para se adaptarem
  • OBSERVAÇÃO: os planos de mudança devem mudar à medida que os participantes do projecto aprendem mais sobre o contexto através da conversa e da colaboração - considere isto como uma adaptação ao aspecto de feedback
• Requer mais tempo inicial
  • OBSERVAÇÃO: agile fornece o quadro de comunicação para facilitar o planeamento, enquanto mais planeamento de mudança vem através de menos planeamento e documentação do projecto - onde a gestão da mudança se torna uma prioridade maior

A nossa experiência com o ágil no mundo real é que ele gera o tipo de ganhos rápidos necessários para manter o buy-in de mudança. Agile proporciona passos visíveis entre os ganhos rápidos graças ao envolvimento, flexibilidade, e prototipagem. Beneficiámos da concepção do produto do FreeBalance Accountability Suite™ graças a métodos de configuração que permitem confirmar as regras de negócio e a configuração em oficinas. Isto permite o tipo de desenvolvimento ágil não disponível em software governamental totalmente personalizado ou em software do sector privado altamente personalizado como o Enterprise Resource Planning (ERP).

Abordagem PDIA para uma Gestão Ágil da Mudança no Governo

Como descrito anteriormente, o contexto de gestão da mudança organizacional tende a ser mais complexo no governo do que nos negócios. Adaptação Iterativa orientada para o Problema (PDIA), uma metodologia de desenvolvimento do sector público e uma excelente ferramenta de gestão da mudança responde a este desafio de complexidade. O PDIA está a tornar-se mais aceite na boa governação e comunidade de desenvolvimento do país.

O PDIA foi desenvolvido pela Construção das instalações estatais da Harvard Kennedy School of Government. Isto é muito mais do que um exercício académico com numerosos estudos de casos no mundo real. Faz parte do Fazendo o desenvolvimento de forma diferente movimento. Somos grandes fãs do PDIA. Muitos dos nossos executivos levaram a Educação Executiva para o PDIA. Muitos dos nossos funcionários frequentaram cursos on-line do PDIA.

O PDIA dá prioridade à mudança e à persuasão, permite o mapeamento de papéis e estratégias de comunicação. O mapeamento das partes interessadas, as comunicações e a colaboração são integrados no PDIA.

O PDIA permite analisar o mudar de espaço: a sobreposição de autoridade, capacidade e aceitação. Esta é uma técnica de gestão da mudança particularmente forte. Tal como descrito no Fazendo Desenvolvimento Diferentemente Manifesto: o sucesso vem através da legitimação "a todos os níveis (político, de gestão e social), construindo propriedade e dinâmica ao longo de todo o processo para ser 'propriedade local' na realidade (não apenas no papel)".

A PDIA reconhece que a mudança substancial não depende do líder heróico. Uma mudança bem sucedida no sector público vem de muitos líderes. Estes são agentes. Isto vai além da abordagem tradicional dos agentes de mudança aos agentes de escalada. A mudança em escala é apresentada com um floco de neve metáfora.

O que é a Metodologia do FreeBalance Agile?

A nossa metodologia tem vindo a iterar ao longo dos anos. A versão actual é A-i³+qM (acelerado, integrado, iterativo, orientado para a implementação, gestão da qualidade):

• Acelerado eliminando tantos processos de cascata legados que levam a problemas no projecto. Isto inclui documentação desnecessária e planos de projecto detalhados, a favor de workshops e passos curtos do processo. As dimensões das equipas são mantidas pequenas para permitir as comunicações do cliente e reduzir as despesas gerais de coordenação.
• Integrado através de uma metodologia única para apoiar o desenvolvimento e a implementação de serviços. Isto é integrado com os requisitos do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores, e a equipa de desenvolvimento. As equipas de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
• Iterativo ser responsiva às mudanças dos clientes e de implementação utilizando fases. A metodologia aproveita o melhor do desenvolvimento de software e metodologias de serviços "lean" comprovadas com workshops, pequenas iterações, histórias de utilizadores, marcos miliários e a capacidade de mostrar progressos. Estas técnicas são alargadas para além da organização de desenvolvimento para serviços de implementação, alavancando ganhos de produtividade e capacidade de reagir às exigências do cliente.
• Foco na implementação com modelos de boas práticas e processos comprovados de gestão de programas. Esta metodologia está centrada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objectivos internos ou arbitrários. A implementação e o desenvolvimento de produtos são geridos através de um Gabinete de Gestão de Programas.
• Qualidade assegura que o software é lançado e apoiado em reuniões de boas práticas de Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, stress e regressão. A qualidade é integrada com a implementação onde os testes FreeBalance são baseados nos ambientes do cliente.

A-i³+qM reconhece as deficiências dos processos tradicionais de gestão de projectos nas implementações GRP. E, os padrões de fracasso.

Glossário Ágil

Todas as definições, excepto para PDIA, via wikipedia.org

• Desenvolvimento de software adaptativo (ASD) é um processo de desenvolvimento de software que nasceu do trabalho de Jim Highsmith e Sam Bayer sobre o desenvolvimento rápido de aplicações (RAD). Incorpora o princípio de que a adaptação contínua do processo ao trabalho em questão é o estado normal de coisas.
• Desenvolvimento de software ágil é uma abordagem ao desenvolvimento de software sob a qual os requisitos e soluções evoluem através do esforço colaborativo de equipas auto-organizadas e multifuncionais e do(s) seu(s) cliente(s)/utilizador(es) final(ais)[1] Defende o planeamento adaptativo, o desenvolvimento evolutivo, a entrega antecipada, e a melhoria contínua, e incentiva uma resposta rápida e flexível à mudança.
• Pensamento do design refere-se aos processos cognitivos, estratégicos e práticos através dos quais os conceitos de design (propostas para novos produtos, edifícios, máquinas, etc.) são desenvolvidos por designers e/ou equipas de design. Muitos dos conceitos e aspectos chave do pensamento design foram identificados através de estudos, em diferentes domínios do design, da cognição do design e da actividade de design, tanto em laboratório como em contextos naturais.
• DevOps é um conjunto de práticas de desenvolvimento de software que combina o desenvolvimento de software (Dev) e operações de tecnologia da informação (Ops) para encurtar o ciclo de vida do desenvolvimento de sistemas ao mesmo tempo que fornece características, correcções e actualizações frequentemente em estreito alinhamento com os objectivos empresariais.
• Entrega ágil e disciplinada (DAD) é um quadro de decisão de processo que permite decisões de processo simplificadas em torno da entrega de soluções incrementais e iterativas. O DAD baseia-se nas muitas práticas defendidas pelos defensores do desenvolvimento de software ágil, incluindo Scrum, modelação ágil, desenvolvimento de software lean, e outros.
• Método de desenvolvimento de sistemas dinâmicos (DSDM) é uma estrutura ágil de entrega de projectos, inicialmente utilizada como método de desenvolvimento de software.
• Programação extrema (XP) é uma metodologia de desenvolvimento de software que se destina a melhorar a qualidade do software e a capacidade de resposta à alteração das necessidades dos clientes. Como um tipo de desenvolvimento ágil de software, defende "lançamentos" frequentes em ciclos de desenvolvimento curtos, que se destinam a melhorar a produtividade e a introduzir pontos de controlo nos quais novos requisitos do cliente podem ser adoptados.
• Desenvolvimento orientado para as características (FDD) é um processo de desenvolvimento de software iterativo e incremental. É um método leve ou ágil para o desenvolvimento de software.
• Desenvolvimento Iterativo e Incremental é qualquer combinação de desenho iterativo ou método iterativo e modelo de construção incremental para o desenvolvimento.
• Kanban (japonês 看板, letreiro ou cartaz) é um método enxuto para gerir e melhorar o trabalho em todos os sistemas humanos. Esta abordagem visa gerir o trabalho equilibrando as exigências com a capacidade disponível, e melhorando a gestão de estrangulamentos a nível do sistema.
• Desenvolvimento de software magro é uma tradução dos princípios e práticas de lean manufacturing para o domínio do desenvolvimento de software. Adaptado do Sistema de Produção Toyota, está a emergir com o apoio de uma subcultura pró-lean no seio da comunidade Agile. Lean oferece uma sólida estrutura conceptual, valores e princípios, bem como boas práticas, derivadas da experiência, que apoiam as organizações ágeis.
• Scrum em grande escala (LeSS) é uma estrutura de desenvolvimento de produto que estende Scrum com regras e directrizes de escalonamento sem perder os objectivos originais do Scrum.
• Engenharia orientada por modelos (MDE) é uma metodologia de desenvolvimento de software que se concentra na criação e exploração de modelos de domínio, que são modelos conceptuais de todos os tópicos relacionados com um problema específico. Assim, destaca e visa representações abstractas dos conhecimentos e actividades que regem um determinado domínio de aplicação, em vez dos conceitos de computação (isto é, algoritmica).
• Estrutura de Soluções Microsoft (MSF) é um conjunto de princípios, modelos, disciplinas, conceitos e directrizes para a prestação de serviços de tecnologia de informação da Microsoft. MSF não se limita apenas ao desenvolvimento de aplicações; é também aplicável a outros projectos de TI como a implementação, redes ou projectos de infra-estruturas. MSF não obriga o programador a utilizar uma metodologia específica (como o modelo de cascata ou o desenvolvimento ágil de software).
• O Processo de software pessoal (PSP) é um processo estruturado de desenvolvimento de software que se destina (planeado) a ajudar os engenheiros de software a compreender melhor e a melhorar o seu desempenho, trazendo disciplina à forma como desenvolvem software e acompanhando o seu desenvolvimento previsto e efectivo do código. Mostra claramente aos programadores como gerir a qualidade dos seus produtos, como fazer um plano sólido, e como assumir compromissos. Também lhes oferece os dados para justificar os seus planos.
• Adaptação Iterativa orientada para o Problema (PDIA) é um processo de emergência facilitada que se concentra em problemas (não em soluções) e segue um processo passo a passo (não um plano rígido) que permite uma aprendizagem flexível e adaptação, concebido pela Building State Capacity Facility da Harvard Kennedy School of Government.
• Desenvolvimento rápido de aplicações (RAD), também chamado Rapid-application building (RAB), é um termo geral, utilizado para se referir a abordagens de desenvolvimento adaptativo de software, bem como o nome da abordagem de James Martin ao desenvolvimento rápido. Em geral, as abordagens RAD ao desenvolvimento de software dão menos ênfase ao planeamento e mais ênfase a um processo adaptativo. Os protótipos são frequentemente utilizados em complemento ou por vezes até no lugar das especificações de concepção.
• O Processo Racional Unificado (RUP) é uma estrutura iterativa do processo de desenvolvimento de software criada pela Rational Software Corporation, uma divisão da IBM desde 2003[1]. O RUP não é um único processo prescritivo concreto, mas sim uma estrutura de processo adaptável, destinada a ser adaptada pelas organizações de desenvolvimento e equipas de projecto de software que irão seleccionar os elementos do processo que são adequados às suas necessidades. O RUP é uma implementação específica do Processo Unificado.
• O Estrutura Ágil em Escala (abreviado como SAFe), é um conjunto de padrões de organização e fluxo de trabalho destinados a guiar as empresas em práticas de escalonamento enxutas e ágeis. Juntamente com Scrum de grande escala (LeSS), entrega ágil disciplinada (DAD), e Nexus, SAFe é um de um número crescente de estruturas que procuram resolver os problemas encontrados ao escalar para além de uma única equipa.
• Scrum é uma estrutura ágil para gerir o trabalho de conhecimento, com ênfase no desenvolvimento de software, embora tenha uma vasta aplicação noutros campos e esteja lentamente a começar a ser explorada por equipas de projecto tradicionais de forma mais geral. Foi concebida para equipas de três a nove membros, que dividem o seu trabalho em acções que podem ser concluídas dentro de iterações com timeboxed, chamadas sprints, não mais do que um mês e mais comumente duas semanas, depois acompanham o progresso e planeiam novamente em reuniões de stand-up com 15 minutos de duração, chamadas scrums diárias.
• Scrumban é uma metodologia de gestão ágil que descreve os híbridos de Scrum e Kanban e foi originalmente concebida como uma forma de transição de Scrum para Kanban. Actualmente, Scrumban é uma estrutura de gestão que emerge quando as equipas empregam Scrum como forma de trabalho escolhida e utilizam o Método Kanban como uma lente através da qual podem ver, compreender e melhorar continuamente o seu funcionamento
• SEMAT (Método e Teoria da Engenharia de Software) é uma iniciativa para remodelar a engenharia de software de modo a que a engenharia de software se qualifique como uma disciplina rigorosa. A iniciativa foi lançada em Dezembro de 2009 por Ivar Jacobson, Bertrand Meyer e Richard Soley com uma declaração de apelo à acção e uma declaração de visão. A iniciativa foi concebida como um esforço plurianual para colmatar a lacuna entre a comunidade de desenvolvedores e a comunidade académica e para criar uma comunidade que dê valor a toda a comunidade de software.
• Em combinação com o processo de software pessoal (PSP), o processo de software de equipa (TSP) fornece um quadro de processo operacional definido que é concebido para ajudar as equipas de gestores e engenheiros a organizar projectos e a produzir software os produtos principais que variam em dimensão desde pequenos projectos de vários milhares de linhas de código (KLOC) a projectos muito grandes com mais de meio milhão de linhas de código.
• O Processo de Desenvolvimento de Software Unificado ou Processo unificado é um quadro iterativo e incremental do processo de desenvolvimento de software. O aperfeiçoamento mais conhecido e amplamente documentado do Processo Unificado é o Rational Unified Process (RUP). Outros exemplos são o OpenUP e o Agile Unified Process.