Agile Facilita o Gerenciamento de Mudanças Governamentais

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

Será a ágil a bala mágica para o sucesso do projeto do governo? Somos defensores ágeis por causa da melhoria dos índices de sucesso usando desenvolvimento ágil de produtos, gerenciamento ágil de projetos e desenvolvimento ágil do país. Nossa metodologia, A-i³+qM é construído sobre boas práticas comprovadas e quase 40 anos de implementações governamentais exclusivas.

Como o Gerenciamento de Mudanças está relacionado à Metodologia Ágil?

Técnicas ágeis, quando adaptadas ao governo, integram mudar. Além do gerenciamento de mudanças de software, a verdadeira mudança organizacional. Planejamento de recursos governamentais (GRP) é configurado para atender às necessidades reais de forma eficaz.

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

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

E, implementar um GRP é muito mais do que apenas um projeto de gerenciamento de mudança de software. É o transformacional. Há reformas legais, novos processos, reorganizações e novas medidas de desempenho que devem ser realizadas.

O objetivo nas implementações do GRP é apoiar boas práticas, o que torna as implementações complicadas. A realidade é que as implementações se tornam complexas, às vezes caóticas, por causa de restrições únicas do setor público:

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

Como o Gerenciamento de Mudanças é Integral para Ágil?

Embora existam numerosas técnicas ágeis, (ver glossário abaixo), gestão da mudança organizacional no setor 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 fundamentais.

• Indivíduos e interações sobre processos e ferramentas: a interação frequente com as partes interessadas e usuários reduz a resistência às mudanças, ao mesmo tempo em que aumenta a probabilidade de que as necessidades reais sejam atendidas (Um princípio ágil: "os empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto").
• Software de trabalho sobre documentação abrangenteA documentação não leva a um entendimento compartilhado com as partes interessadas e os usuários - frequentemente atrasa as implementações, dando tempo para resistência à mudança para aumentar (Um princípio ágil: "o método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe 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 usuários
• Respondendo à mudança seguindo um plano: o contexto é aprendido através de conversas, não através de um planejamento rígido

Como obter uma gestão ágil da mudança no governo

Agile opera bem quando confiança é habilitado e encorajado. Agile permite o gerenciamento de mudanças no governo quando administrado adequadamente:

• ConsideraçãoTécnicas ágeis como Design Thinking e PDIA estimulam a empatia e a compreensão dos problemas do ponto de vista das partes interessadas e dos usuários
  • IMPACTO: as partes interessadas e os usuários percebem que os sistemas não são impostos por pessoas de fora
• Centrado no cliente: trabalhos ágeis do cliente para fora (o que chamamos de "outside-in" no gerenciamento do produto) em vez de produto para dentro (o que chamamos de "inside-out" no gerenciamento do produto)
  • IMPACTO: os medos e aspirações das partes interessadas e dos usuários se transformam em projetos
• Comunicação: a comunicação constante mantém as partes interessadas e os usuários atualizados através de conselhos e outros métodos de comunicação visual para demonstrar decisões, progresso e atrasos
  • IMPACTO: partes interessadas e usuários menos propensos a imaginar o pior entre os marcos, onde o progresso é visivelmente comunicado
• Conversação: conversas presenciais com as partes interessadas e usuários, incluindo oficinas, brainstorming e storyboards
  • IMPACTO: as partes interessadas e os usuários reconhecem a capacidade de ajustar os resultados do projeto enquanto aprendem mais sobre o valor do projeto para eles, sua organização e seu país para aumentar a aceitação da mudança
• ContextoO contexto do país e do governo é compreendido pelas equipes do projeto (e a FreeBalance tem ferramentas para viabilizar este processo).
  • IMPACTO: a compreensão compartilhada entre os participantes é reforçada para reduzir a resistência à mudança
• Colaboração: equipes de projeto, partes interessadas e usuários trabalham em conjunto para estabelecer prioridades, resolver problemas e discutir soluções
  • IMPACTO: a influência sobre o projeto através do envolvimento aumenta a aceitação da mudança
• Criatividade: alavancar a criatividade das partes interessadas e dos usuários para resolver melhor os 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 projeto ao longo de todo o projeto, em vez de assinar os contratos em marcos importantes como única avenida
  • IMPACTO: atrasos no projeto reduzidos por causa da confirmação iterativa, dando pouco tempo para que a resistência à mudança seja construída, enquanto os laços de feedback validam as preocupações das partes interessadas e dos usuários
• Capacidade: capacidade governamental de projeto e domínio de governança construída durante conversas e colaboração como mentoria, aumentando o treinamento e melhorando o sucesso do projeto
  • IMPACTO: sustenta a trajetória de mudança organizacional além do projeto (e torna o projeto mais sustentável)

Por que os governos resistem a uma gestão ágil da mudança?

Alguns clientes do governo perguntam por que envolvemos não especialistas no projeto 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 setor público. Além de utilizar o ágil para implementaçõesusamos exercícios ágeis em nossos exercícios anuais Comitê de Direção Internacional FreeBalance (FISC), oficinas de mudança e exercícios de contexto do 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 todo grupo de trabalho quer apresentar os resultados à oficina. Colaboração real.

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

Os processos tradicionais de gerenciamento de mudanças organizacionais tendem a ser uma forma sequenciada linear, conforme 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 projetada por John Kotter:

Estas são excelentes estruturas para a mudança organizacional. A abordagem linear, no entanto, parece estar alinhada com a abordagem tradicional queda d'água se aproxima. Assim 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 das mudanças, assim como o desenvolvimento de software e os índices de sucesso na gestão de projetos melhoram através da agilidade.

Vimos alguns projetos em que a gestão de mudanças organizacionais no governo foi considerada um complemento à gestão de projetos. Isto freqüentemente resulta em "drive-by" e gerenciamento de mudanças ineficaz.
Faz sentido ter especialistas em projetos de mudança. Muitas vezes há uma desconexão quando os especialistas em mudanças carecem de conhecimento de domínio. Portanto, é mais eficaz ter a mudança integral nos projetos. Ter uma equipe de projetos construindo mudança e credibilidade.

Quais são os benefícios de se utilizar o Gerenciamento Ágil de Mudanças no Governo?

Reed Deshler vê a necessidade de um abordagem em tempo real para mudar a gestão em projetos ágeis. Isto inclui a adaptação de processos compreendidos de gerenciamento de mudanças para serem "adequados à finalidade" de projetos individuais. Um estudo realizado por Prosci analisou as práticas de gerenciamento de mudanças em projetos ágeis. A análise constatou que o sucesso no gerenciamento de mudanças em projetos ágeis requer:

• Abordagens iterativas em vez de lineares
  • OBSERVAÇÃO: todos os componentes do projeto são iterativos em agilidade, e o impacto da gestão da mudança é contínuo para construir a aceitação da mudança
• Planos de mudança projetados para se adaptar
  • OBSERVAÇÃO: os planos de mudança devem mudar à medida que os participantes do projeto aprendem mais sobre o contexto através de conversas e colaboração - considere isto como uma adaptação à aparência de feedback
• Requer mais tempo de antecipação
  • OBSERVAÇÃO: agile fornece a estrutura de comunicação para facilitar o planejamento, enquanto mais planejamento de mudanças vem através de menos planejamento e documentação do projeto - onde o gerenciamento de mudanças se torna uma prioridade maior

Nossa experiência com ágil no mundo real é que ela gera o tipo de ganhos rápidos necessários para manter o buy-in de mudança. Agile fornece passos visíveis entre os ganhos rápidos graças ao envolvimento, flexibilidade e prototipagem. Nós nos beneficiamos com o projeto do produto do FreeBalance Accountability Suite™ graças aos métodos de configuração que permitem confirmar as regras comerciais e a configuração em oficinas. Isto permite o tipo de desenvolvimento ágil não disponível em software governamental totalmente personalizado ou software do setor privado altamente personalizado como o Enterprise Resource Planning (ERP).

Abordagem PDIA para a 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 por Problemas (PDIA), uma metodologia de desenvolvimento do setor público e uma excelente ferramenta de gestão de mudanças, responde a este desafio de complexidade. O PDIA está se tornando mais aceito na boa governança e comunidade de desenvolvimento do país.

A PDIA foi desenvolvida pela Construindo as instalações da Harvard Kennedy School of Government. Isto é muito mais do que um exercício acadêmico com numerosos estudos de caso no mundo real. Faz parte do Fazendo o desenvolvimento de forma diferente movimento. Somos grandes fãs da PDIA. Muitos de nossos executivos levaram a Educação Executiva para o PDIA. Muitos de nossos funcionários fizeram cursos online para a PDIA.

A PDIA prioriza a mudança e a 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 incorporadas no PDIA.

Conjunto de funções	Papéis	Comunicações
Contribuições substantivas	1. Construir, comunicar problemas   2. Apresentar idéias para a reforma 3. Fornecer visão de implementação
Contribuições processuais	4. Fornecer autoridade formal   5. Motivar e inspirar a reforma 6. Capacitar outros agentes
Contribuições de manutenção	7. Convocadores de pequenos grupos 8. Conectores para agentes distribuídos

A PDIA permite analisar o espaço de troca: a sobreposição de autoridade, habilidade e aceitação. Esta é uma técnica particularmente forte de gerenciamento de mudanças. Como descrito no Fazendo o desenvolvimento de forma diferente Manifesto: o sucesso vem através da legitimação "em todos os níveis (político, gerencial e social), construindo propriedade e dinâmica ao longo do processo para ser 'propriedade local' na realidade (não apenas no papel)".

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

O que é a Metodologia FreeBalance Agile?

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

• Acelerado eliminando tantos processos legados de cascata que levam a problemas no projeto. Isto inclui documentação desnecessária e planos detalhados do projeto, em favor de oficinas e etapas curtas do processo. Os tamanhos das equipes são mantidos pequenos para permitir a comunicação com o 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 às exigências do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores e a equipe de desenvolvimento. As equipes de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
• Iterativo ser responsiva às mudanças do cliente e de implementação utilizando fases. A metodologia alavanca o melhor das metodologias comprovadas de desenvolvimento de software e serviços "lean" com workshops, pequenas iterações, histórias de usuários, marcos miliários e a capacidade de mostrar progresso. Estas técnicas são estendidas além da organização de desenvolvimento para serviços de implementação alavancando ganhos de produtividade e a capacidade de reagir às exigências do cliente.
• Foco na implementação com modelos de boas práticas e processos comprovados de gerenciamento de programas. Esta metodologia está focada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objetivos internos ou arbitrários. A implementação e o desenvolvimento de produtos são gerenciados através de um Escritório de Gerenciamento de Programas.
• Qualidade assegura que o software seja liberado e suportado atendendo às boas práticas do Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, estresse 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 gerenciamento de projetos nas implementações de GRP. E, os padrões de falhas.

Glossário Ágil

Todas as definições, com exceção da 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 no desenvolvimento rápido de aplicações (RAD). Ele encarna o princípio de que a adaptação contínua do processo ao trabalho em questão é o estado normal de coisas.
• Desenvolvimento ágil de software é uma abordagem ao desenvolvimento de software sob a qual os requisitos e soluções evoluem através do esforço colaborativo de equipes auto-organizadas e multifuncionais e de seu(s) cliente(s)/usuário(s) final(ais)[1]. Ela defende o planejamento adaptativo, o desenvolvimento evolutivo, a entrega antecipada e a melhoria contínua, e incentiva uma resposta rápida e flexível à mudança.
• Pensamento em design refere-se aos processos cognitivos, estratégicos e práticos pelos quais os conceitos de design (propostas para novos produtos, edifícios, máquinas, etc.) são desenvolvidos por designers e/ou equipes de design. Muitos dos principais conceitos e aspectos do pensamento em design foram identificados através de estudos, em diferentes domínios do design, da cognição do design e da atividade de design, tanto em laboratório quanto 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 em que fornece recursos, correções e atualizações freqüentemente em estreito alinhamento com os objetivos comerciais.
• Entrega ágil e disciplinada (DAD) é uma estrutura de decisão de processo que permite decisões de processo simplificadas em torno da entrega de soluções incrementais e iterativas. O DAD se baseia nas muitas práticas defendidas pelos defensores do desenvolvimento ágil de software, incluindo Scrum, modelagem ágil, desenvolvimento de software lean, e outros.
• Método de desenvolvimento de sistemas dinâmicos (DSDM) é uma estrutura ágil de entrega de projetos, inicialmente utilizada como um método de desenvolvimento de software.
• Programação extrema (XP) é uma metodologia de desenvolvimento de software que visa melhorar a qualidade do software e a capacidade de resposta às mudanças nas exigências dos clientes. Como um tipo de desenvolvimento ágil de software, ela defende "lançamentos" freqüentes em ciclos curtos de desenvolvimento, que se destinam a melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos do cliente podem ser adotados.
• 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 projeto iterativo ou método iterativo e modelo de construção incremental para desenvolvimento.
• Kanban (japonês 看板, letreiro ou outdoor) é um método enxuto para gerenciar e melhorar o trabalho em sistemas humanos. Esta abordagem visa gerenciar o trabalho equilibrando as demandas com a capacidade disponível, e melhorando o manuseio de gargalos a nível de sistema.
• Desenvolvimento de software enxuto é uma tradução dos princípios e práticas de produção enxuta para o domínio do desenvolvimento de software. Adaptado do Sistema de Produção Toyota, ele está surgindo com o apoio de uma subcultura pró-lean dentro da comunidade Agile. Lean oferece uma sólida estrutura conceitual, valores e princípios, assim como boas práticas, derivadas da experiência, que apóiam as organizações ágeis.
• Scrum em grande escala (LeSS) é uma estrutura de desenvolvimento de produto que estende Scrum com regras e diretrizes de escalonamento sem perder os objetivos 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 conceituais de todos os tópicos relacionados a um problema específico. Portanto, ela destaca e visa a representações abstratas do conhecimento e das atividades que governam um domínio de aplicação particular, ao invés dos conceitos de computação (isto é, algoritmia).
• Estrutura de Soluções Microsoft (MSF) é um conjunto de princípios, modelos, disciplinas, conceitos e diretrizes para a prestação de serviços de tecnologia da informação da Microsoft. MSF não se limita ao desenvolvimento de aplicações apenas; ele também se aplica a outros projetos de TI como implantação, redes ou projetos de infra-estrutura. MSF não força o desenvolvedor a usar 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 (planejado) a ajudar os engenheiros de software a entender melhor e melhorar seu desempenho, trazendo disciplina à forma como eles desenvolvem o software e acompanhando seu desenvolvimento previsto e real do código. Ele mostra claramente aos desenvolvedores como gerenciar a qualidade de seus produtos, como fazer um plano sólido e como assumir compromissos. Ele também lhes oferece os dados para justificar seus planos.
• Adaptação Iterativa Orientada por Problemas (PDIA) é um processo de emergência facilitada que se concentra nos problemas (não nas soluções) e segue um processo passo a passo (não um plano rígido) que permite uma aprendizagem flexível e adaptação, projetado 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, usado para se referir a abordagens de desenvolvimento adaptativo de software, bem como o nome da abordagem de James Martin para o desenvolvimento rápido. Em geral, as abordagens RAD ao desenvolvimento de software colocam menos ênfase no planejamento e mais ênfase em um processo adaptativo. Os protótipos são freqüentemente usados em adição ou às vezes até no lugar das especificações de projeto.
• 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 processo prescritivo concreto, mas sim uma estrutura de processo adaptável, destinada a ser adaptada pelas organizações de desenvolvimento e equipes de projeto de software que selecionarão os elementos do processo que são apropriados para 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 orientar as empresas em práticas enxutas e ágeis de escalonamento. Junto com o Scrum de grande escala (LeSS), a entrega ágil disciplinada (DAD) e Nexus, SAFe é uma das estruturas em crescimento que procuram resolver os problemas encontrados ao escalar para além de uma única equipe.
• Scrum é uma estrutura ágil para gerenciar o trabalho de conhecimento, com ênfase no desenvolvimento de software, embora tenha ampla aplicação em outros campos e esteja lentamente começando a ser explorada por equipes de projeto tradicionais de forma mais geral. É projetado para equipes de três a nove membros, que dividem seu trabalho em ações que podem ser concluídas dentro de iterações com timebox, chamadas sprints, não mais que um mês e, mais comumente, duas semanas, depois acompanham o progresso e planejam novamente em reuniões de 15 minutos, chamadas scrums diárias.
• Scrumban é uma metodologia de gestão ágil que descreve híbridos de Scrum e Kanban e foi originalmente projetada como uma forma de transição de Scrum para Kanban. Hoje, Scrumban é uma estrutura de gerenciamento que emerge quando as equipes empregam Scrum como sua forma de trabalho escolhida e usam o Método Kanban como uma lente através da qual podem ver, entender e melhorar continuamente a forma como trabalham
• SEMAT (Método e Teoria da Engenharia de Software) é uma iniciativa para remodelar a engenharia de software de tal forma que a engenharia de software se qualifica 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 à ação e uma declaração de visão. A iniciativa foi concebida como um esforço de vários anos para preencher 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 da equipe (TSP) fornece uma estrutura de processo operacional definida que é projetada para ajudar as equipes de gerentes e engenheiros a organizar projetos e produzir software os principais produtos que variam em tamanho desde pequenos projetos de vários milhares de linhas de código (KLOC) até projetos muito grandes com mais de meio milhão de linhas de código.
• O Processo de Desenvolvimento de Software Unificado ou Processo unificado é uma estrutura iterativa e incremental do processo de desenvolvimento de software. O refinamento mais conhecido e amplamente documentado do Processo Unificado é o Rational Unified Process (RUP). Outros exemplos são o OpenUP e o Agile Unified Process.