Agile Projeto

Agilidade não é só para TI: uma abordagem passo-a-passo

A agilidade não é só para TI, o mundo se move rapidamente e a agilidade é necessária para qualquer tarefa que você faça, seja pessoal ou profissional. O Agile1 não é apenas flexível, mas “flexível com um propósito” e ele ajuda você a rodar em qualquer ambiente de ritmo acelerado.

No mundo dos negócios, os modelos ágeis têm ganhado popularidade. A última década viu cada vez mais organizações de TI avançarem para a transformação ágil, principalmente com a bolha de startups.

Mas a adoção ágil em organizações que não são de TI tem sido um desafio, especialmente com o alcance de uma maturidade ágil. Embora muitas organizações tenham concluído a adoção, apenas algumas conseguiram atingir um alto nível de maturidade.

As organizações de TI têm um caminho relativamente mais fácil para adotar práticas ágeis, já que o histórico do ciclo de vida de desenvolvimento de software ajuda a obter suporte mais rapidamente e facilmente das partes interessadas.

As organizações que não são de TI enfrentam um desafio maior, pois as partes interessadas têm um histórico limitado com o CVDS2, desta forma a aceitação de práticas ágeis é relativamente difícil.

Embora muita pesquisa tenha sido conduzida para dar suporte à adoção ágil em geral, há pouca informação ou suporte disponível para a abordagem a ser usada por organizações que não são de TI. Este artigo tem como objetivo ajudar.

O ágil funciona para organizações que não são de TI?

Agile não é apenas sobre desenvolvimento de software, deve se aplicar a tudo que uma organização produz. Recursos humanos, finanças e produção vivem em bunkers fechados com processos escritos na pedra. Um dos principais objetivos do agile é a entrega contínua, e não há motivos para que isso se aplique apenas ao software.

As aplicações e possibilidades ágeis são infinitas, e o espectro entre as indústrias tem aumentado – indo além das organizações e projetos de TI tradicionais.

Os princípios ágeis ajudaram a construir o Burj Khalifa em Dubai, o edifício mais alto do mundo3. E os valores e princípios ágeis influenciam positivamente a indústria da hospitalidade.

A maneira tradicional de servir os clientes vem mudando, com conceitos como “faça sua própria refeição” e uma “cozinha aberta” tem ganhando popularidade em uma ampla variedade de cadeias de alimentos, onde os clientes estão envolvidos desde o início.

A lista de realizações ágeis está aumentando continuamente com mais e mais ideias e conceitos inovadores chegando, este escopo está se estendendo muito além do software para muitas áreas e indústrias o que estabelece fortemente a aplicabilidade ágil bem além das organizações de TI.

Então, se ágil é aplicável a organizações que não são de TI, por que precisamos de uma abordagem diferente?

A razão é simples: embora os modelos baseados em ágil tenham sido aplicados ao software nas últimas duas décadas, sua maturidade em outros setores ainda é baixa, exigindo, portanto, um tratamento e uma abordagem diferentes.

O que se segue é uma abordagem passo a passo derivada da experiência prática e conceitos tradicionais de gerenciamento de projetos, juntamente com valores e princípios ágeis.

O framework pré-agile

A razão para manter isso como uma estrutura é enfatizar que isso seria um modelo e não uma metodologi,a essa estrutura precisa ser convertida em um modelo baseado no contexto organizacional.

Essa estrutura fica no topo do scrum (não estou reinventando a roda aqui e, portanto, não abordarei os conceitos de Scrum4 em detalhes).

Papéis

As funções de scrum permanecem intactas e as mesmas definições padrão de scrum para todas as funções podem ser aplicadas: product owner, scrum master e scrum team.

Cerimônias

1 – Backlog Refinement

Preparação do Refinamento: o exercício de preparação do backlog pode ser difícil de praticar inicialmente. O estabelecimento de uma compreensão das histórias e a capacidade de realizar estimativas de tamanho alto podem não ser viáveis em uma única reunião de preparação.

Um refinamento preparado pode ser conduzido para tornar mais fácil. Isso acontece em duas etapas:

  • Parte 1: Esta parte visa fornecer uma compreensão das histórias e abordar quaisquer dúvidas ou esclarecimentos sobre os requisitos de negócios:

Scrum Não TI

  • Parte 2: Esta parte visa capacitar a equipe a realizar estimativas.

Como um pré-requisito, a equipe deve estar pronta com uma análise de impacto, além de ser clara sobre os requisitos. A análise de impacto deve fornecer informações sobre o que a história envolve em termos de componentes impactados, refletindo portanto nas complexidades.

A análise de impacto exigiria que a equipe investisse tempo após a primeira fase de preparação, portanto, é necessário haver alguma lacuna entre os dois. Essa reunião deve resultar em estimativas de pontos da história.

Horas ideais com pontos de história: Em um cenário usual, as estimativas baseadas em pontos de história devem ser adequadas para o desenvolvimento. Mas inicialmente, pode ser um desafio realizar uma estimativa baseada em pontos de história confiáveis, para que as horas paralelas possam ajudar.

Quando uma velocidade confiável é estabelecida, a equipe pode interromper as horas ideais. Velocidade confiável aqui significa velocidade suave e sem variação alta.


2 – Planejamento da Sprint

Histórias provisórias: para obter o compromisso inicial da equipe com a Sprint pode não ser fácil. Além disso, as partes interessadas podem não ter um alto nível de confiança com o novo modelo.

Pode ser uma boa ideia introduzir os conceitos de histórias experimentais aqui.

As histórias podem ser duvidosas devido a qualquer um dos seguintes motivos:

  • Muito tempo para se ajustar a uma Sprint;
  • Algumas áreas cinzentas nas histórias ou apenas no limite da capacidade da equipe.
  • As histórias preliminares seriam histórias não comprometidas e não contariam com o cumprimento da meta de Sprint.

Objetivo de publicação: faria muito sentido começar a publicar a meta da Sprint como um compromisso da equipe. Isso deve listar todas as histórias comprometidas e provisórias.

Isso ajuda na construção de uma comunicação aberta e estabelece o comprometimento da equipe e das partes interessadas.

3 – Daily Scrum

Conceito de to-do: as atividades planejadas diariamente de todos os membros da equipe Scrum são publicadas para a equipe e as partes interessadas.

Sim, (qualquer ferramenta ágil) tem essa informação de alguma forma, mas como as partes interessadas e a equipe ainda estão construindo sua compreensão sobre o agile, pode ser útil promover a comunicação aberta e para aumentar a confiança entre equipe e as parte interessadas.

Converse mais no início, aplique ferramentas à partir da maturidade adquirida.

4 – Revisão da Sprint

Avaliação intermediária: embora não seja obrigatória, as revisões intermediárias podem ser realmente úteis para suprir as expectativas entre a equipe e todas as partes interessadas.

Isso também ajuda a equipe a avaliar seu alinhamento para as metas de sprint.

Publicar o resultado da sprint: embora não seja necessário para equipes ágeis maduras, a publicação do resultado da sprint (incluindo a conformidade da meta da sprint) pode ser útil para uma equipe que está sendo introduzida na agilidade.

5 – Retrospectiva de sprint

Publicar ações retrospectivas: as equipes podem não estar familiarizadas com a retrospectiva e as ações identificadas, o que pode facilitar para eles percam de vista os objetivos.

Nesse cenário, pode ser útil publicar periodicamente ações e progressos retrospectivos, com foco na pessoa responsável.

Artefatos: Os artefatos necessários para manter essa estrutura permanecem os mesmos e todos os artefatos padrão do Scrum permanecem aplicáveis.

Abordagem de Implementação

Qualquer organização que não seja de TI pode seguir essa abordagem passo a passo. Embora essas etapas possam ser aplicáveis em geral, o foco está no Scrum:

Scrum para não técnicos 2

Etapa 1: Construir o contexto organizacional.

Entenda a organização. O primeiro passo em qualquer transformação ou implementação ágil para uma organização é construir o contexto organizacional, lembre-se sempre de que cada organização é diferente, portanto, a aplicação de qualquer modelo deve envolver uma boa compreensão do funcionamento da organização.

Isso pode envolver a compreensão de processos internos e externos, processos de negócios organizacionais, maturidade de TI, etc.

Compreender os principais interessados ​​e suas expectativas. O próximo passo é entender o grupo/unidade onde a transformação ágil deve ser aplicada com a lista exaustiva de partes interessadas internas e externas.

Entender o histórico de partes interessadas e sua exposição a conceitos ágeis também é importante. As expectativas das partes interessadas precisam ser cuidadosamente estudadas, com clara compreensão dos objetivos do negócio.

Prepare um organograma. Isso pode não parecer relevante, mas é um passo importante para esclarecer o modo de trabalho da organização, incluindo papéis e responsabilidades.

As organizações tradicionais podem não ter qualquer referência a funções relacionadas ao ágil, portanto, este passo deve identificar claramente e mencionar o papel do Scrum para cada posição.

Etapa 2: Desenvolver um modelo ágil provisório.

Esta etapa envolve a criação do modelo de desenvolvimento ágil / Scrum, esse modelo é a estrutura de tentativa ágil descrita acima, inserida no contexto da organização.

Isso pode envolver uma descrição adequada de funções, cerimônias e artefatos para caracterizar claramente o modelo.

Etapa 3: Pratique o modelo.

O modelo deve ser praticado com a equipe durante um período de tempo, defina este tempo com a equipe de transformação ágil, erre muito mas erre rápido.

Etapa 4: Inspecione e adapte.

Inspeções e adaptações periódicas ajudam a equipe a ganhar maturidade e, consequentemente a aprendizagem resultante para a execução do modelo. As áreas individuais para agilidade provisória podem ser amadurecidas em total agilidade.

Etapa 5: estabeleça agilidade total.

Uma vez que a equipe amadurece para todas as cerimônias desejadas pela recomendação do Scrum, as práticas ágeis tentativas podem ser descontinuadas e a equipe pode atingir a agilidade total.

Se a equipe/organização estiver cumprindo suas metas de negócios, a agilidade provisória poderá continuar; a equipe ou organização pode não querer atingir a agilidade total.

Conclusão

A transformação para agilidade total pode ser uma jornada longa e incerta – especialmente para organizações que não são de TI. A agilidade total pode ser caracterizada pelo início completo de todos os valores ágeis, não apenas na equipe do Scrum, mas em toda a organização.

A maturidade ágil da organização deve evoluir ao longo do tempo com um ritmo suave e não pela força, as organizações ainda podem ser altamente bem-sucedidas sem total maturidade ágil.

A abordagem sugerida acima pode ser aplicada em qualquer organização, é completa em todos os aspectos e pode ser uma maneira eficaz de alcançar a transformação para a agilidade total dentro de um período de tempo razoável.

Referências

Referências

  1. The Agile Manifesto
  2. Ciclo de vida de desenvolvimento de sistemas – Wikipedia
  3. Burj Khalifa – Wikipedia
  4. The Scrum GuideTM, Ken Schwaber and Jeff Sutherland, Novembro 2017
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.