Bases de uma transformação ágil: desenvolva e execute um framework de melhorias pequenas e contínuas
Na nossa primeira publicação sobre «Planejar seu caminho» da série «Bases de uma transformação ágil» apresentamos conceitos e explicações essenciais da filosofia ágil: seus valores fundamentais, um panorama dos princípios, uma breve história e, acima de tudo, como ser ágil se encaixa em uma mentalidade de «melhoria contínua».
Agile, assim como a melhoria contínua, é mais um âmbito cultural de «perspectivas sobre como lidar com acontecimentos» do que um conjunto de processos definidos de forma abrangente.
Dito isso, há muitos elementos que uma organização precisa considerar e acordar antes de desenvolver um roteiro de transformação ágil: uma visão e missão organizacionais e objetivos estratégicos de alto nível devem ser analisados cuidadosamente para que todos se alinhem a eles e impulsionem a transformação rumo aos objetivos.
Por fim, devem ser consideradas a cultura atual e os valores organizacionais para compreender quais são as práticas atuais de criação de valor e como produzem resultados favoráveis aos objetivos estabelecidos.
Agora, como definir a estratégia de gestão de alto nível para suas operações?
Há tantos casos de sucesso de alternativas comprovadas nos negócios que pode ser difícil decidir quais processos e práticas ajudariam melhor uma organização a se manter no caminho e prosperar no roteiro de crescimento. Na Sophilabs, já argumentamos na primeira publicação da série que a agilidade é um fator essencial para o sucesso ao cumprir nossa visão e objetivos, apoiar a mudança cultural e promover melhoria contínua.
Vamos revisar brevemente as estratégias de gestão mais comuns para fundamentar nossa escolha:
Escolher uma estratégia de gestão: frameworks leves versus metodologias abrangentes
Os projetos são, em muitos sentidos, o padrão para delimitar e gerenciar o trabalho e o valor gerado em um ambiente empresarial em constante evolução. Em algum momento, profissionais de praticamente qualquer setor se familiarizaram em alguma medida com projetos, mesmo sem terem se formado plenamente como profissionais de gestão de projetos.
Por isso, gerenciar projetos com eficácia é uma necessidade há algumas décadas: empresas que querem inovar e revolucionar seus mercados precisam fechar a lacuna entre negócio e operações, otimizar recursos e alcançar resultados melhores a cada vez. Não surpreende que tenham surgido muitas metodologias, frameworks e métodos para apoiar a busca contínua de uma gestão ideal. A gestão eficaz de projetos tem dois aspectos fundamentais:
1. O «conjunto de ferramentas de gestão»
O «conjunto de ferramentas de gestão» permite decidir entre uma metodologia muito detalhada e um framework leve como referência para um projeto.
Em poucas palavras, metodologias são conjuntos de princípios, ferramentas e práticas específicos que podem orientar projetos rumo aos objetivos. Seus benefícios são inegáveis, especialmente em projetos ou setores com grande certeza sobre o produto e poucas mudanças. As desvantagens vêm do fato de serem extensas e prescritivas: não implementá-las completamente como indicado pode aumentar muito a incerteza e os riscos do projeto.
Frameworks são estruturas mais leves e abertas: referências com processos de alto nível suficientemente descritos e espaço para incorporar ferramentas e práticas específicas ao contexto tático, de nível inferior, conforme seu valor ou encaixe no conjunto atual. Permitem grande flexibilidade ao aproveitar ferramentas e técnicas e manter o alinhamento com princípios amplos. Uma desvantagem importante é que, apesar de leves, podem ser difíceis de implementar e gerenciar com eficácia.
2. A «abordagem de criação de valor»: preditiva versus adaptativa
A forma de operar os processos de criação de valor está muito relacionada à mentalidade que orienta a implementação das ferramentas de gestão. Falamos de abordagens operacionais «preditivas» ou «adaptativas», geralmente, mas não necessariamente, ligadas ao próprio conjunto de ferramentas. Diferem na forma de gerenciar risco e incerteza.
Uma abordagem «preditiva» lida com risco e incerteza antecipando necessidades, decisões prováveis e praticamente todos os cenários possíveis por meio de um «planejamento inicial abrangente», antes de considerar as atividades de criação de valor e sua gestão. Isso implica uma dependência detalhada entre fases: lançamento e execução dependem de completar 100% da definição e do planejamento do produto, que, por sua vez, dependem de uma conceituação inicial abrangente. Os clientes só começam a perceber valor nas etapas finais. Há setores que, pela natureza do negócio, obtêm resultados fantásticos e muito sucesso com essa abordagem.
Uma abordagem «adaptativa», por outro lado, reduz o planejamento inicial ao mínimo necessário e aumenta os ciclos de feedback do cliente para maximizar a capacidade de adaptação e oferecer valor incremental desde as primeiras etapas. É ideal para setores com produtos muito inovadores e muito trabalho abstrato e conceitual. O desenvolvimento de software reúne essas características e, como observamos, é precursor das abordagens adaptativas resumidas em «Agile».
Na Sophilabs, preferimos uma abordagem adaptativa com frameworks leves, como Scrum, para a maioria dos novos recursos e produtos inovadores, e métodos como Kanban para esforços com maiores restrições de tempo, como suporte contínuo ao produto.
Esse conjunto central oferece processos completos, mas leves, que complementam nossa agenda de agilidade e melhoria contínua, com flexibilidade para incorporar ou retirar técnicas, ferramentas e práticas conforme necessário para adaptar, alcançar os objetivos e atender aos clientes.
Scrum e Kanban: adoção por meio de um modelo evolutivo ágil
Já argumentamos a favor de Agile, frameworks leves e, especificamente, Scrum e Kanban. Agora enfrentamos algumas perguntas:
- Como promovemos a adoção desses frameworks ágeis?
- Como lidamos com a resistência e facilitamos a mudança cultural?
- Como definimos o roteiro desse esforço?
Depois de analisar cuidadosamente, determinamos que era essencial definir um modelo evolutivo de agilidade para responder de forma simples.
Por que um modelo evolutivo de agilidade
Modelos são representações de um sistema composto por dimensões, como conceitos e práticas, ordenadas para facilitar a compreensão e a gestão do tema representado.
Há muito debate no mundo ágil sobre a necessidade ou relevância dos «modelos ágeis», e muitos defensores afirmam que contradizem o espírito de Agile. O consenso geral parece ser que os modelos podem acabar definindo demais e limitando sua adaptabilidade. No entanto, outros defendem que alguns frameworks ágeis são extensíveis e podem, e às vezes devem, ser complementados com conceitos ou práticas que os adaptem melhor aos cenários organizacionais.
O modelo evolutivo de agilidade da Sophilabs
Precisamos conectar nossos frameworks e práticas operacionais (Scrum, Kanban, Lean, XP e outros), nossos direcionadores organizacionais (visão, objetivos e cultura) e nosso roteiro de melhoria contínua (acompanhar a adoção em uma escala tangível). Por isso, a ideia de um modelo evolutivo de agilidade se tornou atraente.
Promover a adoção de Agile
Promover práticas que revolucionam as formas habituais de trabalhar pode ser muito disruptivo se não for bem pensado. Acreditamos em uma base sólida de boas práticas, refinadas empiricamente para obter resultados bem-sucedidos. Scrum e Kanban oferecem essa base: são leves, flexíveis e bem concebidos, permitindo que as equipes os adotem gradualmente e continuem refinando seus processos.
Facilitar a mudança cultural
A mentalidade centrada no cliente, o empirismo, a autocrítica e a melhoria contínua por inspeção e adaptação constantes são centrais em Scrum e Kanban. Uma organização que siga esses princípios melhorará drasticamente ao adotá-los e também se divertirá muito.
Definir um roteiro de melhoria
Esta pode ser a parte mais difícil, pois Scrum e Kanban não descrevem a melhoria de processos além de considerá-la um resultado natural da inspeção e da adaptação.
Nossa abordagem é direta: acreditamos que a soma de práticas valiosas aplicadas determina o sucesso. Também buscamos uma mudança cultural significativa, em que as equipes incorporem essas práticas de forma incremental ao núcleo dos procedimentos operacionais habituais.
Como alcançar isso? Conversamos com nossas equipes e concluímos que o melhor é:
- Que o roteiro não tenha restrições excessivas. Impor objetivos fixos com prazos arbitrários pode ser contraproducente e pressionar as equipes desnecessariamente. Não se trata de riscar itens de uma lista ou incorporar práticas sem motivo, mas de compreender e aceitar seu valor e construir sobre os resultados. Isso também significa adotar plenamente comportamentos novos e melhores e uma mudança cultural.
- Que o roteiro mostre claramente onde estamos e aonde queremos chegar. Precisamos definir como medir e acompanhar o progresso com o modelo evolutivo. A melhor forma é estabelecer marcos que representem diferentes «níveis de agilidade» e fazer as equipes acompanharem sua «pontuação de agilidade», uma representação do nível operacional atual. Ver o progresso em uma escala simples e bem definida beneficia muito as equipes e orienta a adoção.
Para simplificar, o modelo é estruturado em quatro níveis descendentes: 1) Dimensões, 2) Elementos, 3) Práticas e 4) Resultados.
Vamos explicá-los brevemente:
- As dimensões são as categorias superiores dos objetos do modelo: «Papéis», «Processos e artefatos» e «Resultados».
- Os elementos descrevem componentes básicos herdados dos nossos frameworks e metodologias que se encaixam nas dimensões superiores; por exemplo, «Equipe de desenvolvimento» e «Agile Coach» são agrupados em «Papéis».
Esse nível também representa uma restrição: conforme o framework ou metodologia da equipe avaliada, nem todos os elementos medidos em Scrum serão considerados em Kanban, e vice-versa. - As práticas são objetos cujo cumprimento pode ser medido e que são considerados valiosos para melhorar a agilidade do processo. Costumam ser agrupadas abaixo dos elementos.
- Os resultados são particulares porque há dois tipos: resultados de nível e resultados de dimensão:
- Os resultados de nível representam o cumprimento ou não de uma prática. As equipes, ou seja, projetos específicos, os usam para avaliar se cumprem uma prática prescrita pelo modelo. Seus valores são absolutos: «Sim» ou «Não», porque uma prática é cumprida ou não.
- Os resultados de dimensão representam o valor agregado de cumprimento de 0 a 100, ou seja, a «pontuação de agilidade», delimitada por um «escopo» organizacional ou uma «faixa» de níveis, ou ambos. Assim como os filtros de uma planilha permitem refinar informações valiosas, essas restrições permitem escalar o modelo:
- O escopo organizacional permite focar na pontuação de uma equipe, um subconjunto ou toda a organização.
- Uma faixa de níveis permite determinar a pontuação de elementos ou dimensões específicos para o escopo selecionado. Por exemplo, calcular a pontuação do elemento «Representante do negócio» ou de toda a dimensão «Processos e artefatos», em vez da pontuação do projeto inteiro.
A tabela seguinte mostra um exemplo de uso do modelo completo em um projeto, dividido por níveis:
| Modelo evolutivo ágil | |||
| Dimensões | Elementos | Práticas | Resultados (Sim/Não) |
| Papéis | Equipe de desenvolvimento | A equipe se organiza por conta própria para realizar o trabalho | Sim |
| A equipe é multifuncional | Sim | ||
| Todos concordam com uma «Definição de Pronto» | Não | ||
| A equipe respeita a DoD | |||
| Todos os integrantes trabalham no mesmo local | Sim | ||
| Equipes distribuídas têm regras claras de comunicação | |||
| Agile Coach | Há um Agile Master | Sim | |
| Ajuda a equipe a cumprir práticas e processos ágeis | Sim | ||
| Ajuda a equipe a atingir os objetivos removendo impedimentos | Sim | ||
| O Agile Master protege a equipe (do excesso de trabalho ou da falta de esforço) | Sim | ||
| Representante do negócio/cliente | Há um PO claramente definido | Sim | |
| Tem autonomia para priorizar | Sim | ||
| Tem conhecimento para priorizar | Sim | ||
| Contato direto com a equipe de desenvolvimento | Não | ||
| Contato direto com as partes interessadas | Sim | ||
| Fala com «uma única voz» | Sim | ||
| O PO oferece uma direção clara para o produto e objetivos de curto prazo | Não | ||
| O PO é responsável por um PBL | Sim | ||
| O PO delegou a gestão do PBL | |||
| Processos e artefatos | Lista de recursos do produto (ou seja, PBL) | Existe um PBL | |
| O PO ou seu delegado mantém (gerencia) o PBL | Sim | ||
| O PO ou seu delegado prioriza os primeiros itens por valor de negócio | Sim | ||
| Os primeiros itens estão suficientemente refinados para as iterações | Sim | ||
| A equipe estima os primeiros itens | Sim | ||
| O PO aprova todos os itens do PBL | Sim | ||
| Intervalos de tempo definidos | Duração da iteração: máximo de 2 semanas | Sim | |
| A equipe de desenvolvimento não sofre interrupções nem controle externo | Não | ||
| A equipe entrega o que se compromete a fazer | Sim | ||
| Sempre termina no prazo | Sim | ||
| Gestão do fluxo de trabalho | O fluxo de trabalho é controlado em um quadro Kanban | ||
| O fluxo do quadro corresponde ao processo real da equipe | |||
| A equipe identifica tempos ociosos e conhece seu lead time | |||
| Os gargalos são identificados e há limites WIP para abordá-los | |||
| É atualizado diariamente (progresso do trabalho) | |||
| A equipe entrega nos prazos acordados | |||
| Planejamento | Há alguma forma de planejamento | Sim | |
| O planejamento acontece pelo menos uma vez por semana | Não | ||
| Há um planejamento formal por iteração | Sim | ||
| O PO participa | Sim | ||
| O PO fornece um PBL atualizado | Sim | ||
| Toda a equipe de desenvolvimento participa | Sim | ||
| O PO ou seu delegado está satisfeito com as prioridades e o escopo | Sim | ||
| Toda a equipe está satisfeita com o plano acordado | Sim | ||
| Produz um plano de sprint ou marcos | Sim | ||
| Marcos (por exemplo, backlog do sprint, planos de trabalho) | O plano de trabalho é muito visível | Sim | |
| O plano é atualizado diariamente (progresso do trabalho) | Sim | ||
| O plano é responsabilidade exclusiva da equipe de desenvolvimento | Sim | ||
| Reuniões diárias | As reuniões diárias acontecem pelo menos uma vez ao dia | Sim | |
| A frequência das reuniões diárias é avaliada | Não | ||
| A qualidade das reuniões diárias é avaliada | Sim | ||
| A equipe se organiza para resolver problemas e impedimentos | Não | ||
| Os problemas e impedimentos são reconhecidos | Sim | ||
| Toda a equipe de desenvolvimento participa | Sim | ||
| A duração de cada reunião diária é avaliada (<=5min.) | Sim | ||
| Demonstrações/revisões | As revisões e demonstrações acontecem com frequência | Sim | |
| Participam o PO ou as partes interessadas, ou ambos | Sim | ||
| É mostrado software funcional e testado | Sim | ||
| É recebido feedback do PO e das partes interessadas | Sim | ||
| Retrospectivas | As retrospectivas acontecem com frequência | Sim | |
| As retrospectivas acontecem pelo menos uma vez por iteração | Sim | ||
| Produz planos de ação S.M.A.R.T | Sim | ||
| O cumprimento do plano de ação é acompanhado | Sim | ||
| Resultados | Pontuação de agilidade | Pontuação de agilidade para o framework ágil definido | 89 |
Nível de agilidade no modelo evolutivo
Para ajudar as equipes a entender e acompanhar a transformação, também definimos 5 marcos incrementais de maturidade, que preferimos chamar de «níveis de agilidade»:
| Níveis do modelo evolutivo de agilidade | ||
| Nível | Descrição | Faixa de pontuação de agilidade |
| 5 | Adaptável: responde à mudança por vários níveis de feedback | 80-100 |
| 4 | Eficaz: produz software funcional | 60-80 |
| 3 | Evolutivo: entrega antecipada e contínua | 40-60 |
| 2 | Colaborativo: comunicação | 20-40 |
| 1 | Autoanalítico: identifica áreas de melhoria | 0-20 |
Conforme a pontuação avaliada para determinado escopo e faixa, definimos o nível atual para entender melhor como orientar os esforços de melhoria contínua.
Uma pontuação de 89, como no exemplo anterior, representa um nível de «5». As práticas ausentes ou deficientes precisam ser analisadas cuidadosamente ao pensar no progresso futuro.
Por fim, coloque seu modelo evolutivo de agilidade para trabalhar
Para atingir todo seu potencial, as equipes e as pessoas precisam promover uma cultura autocrítica que busque melhorar continuamente.
De equipes a organizações inteiras, todos podem usar o modelo para estabelecer o nível atual, identificar áreas a melhorar, desenvolver planos de ação inteligentes e, de forma iterativa, acompanhar e controlar a evolução do nível de agilidade.
Na Sophilabs, implementamos o modelo com sucesso há cerca de 6 meses, e os resultados falam por si:
- Alcançamos o nível 4 de agilidade em alguns meses, depois de começar em um nível 3 inicial.
- Os projetos operam com eficácia e continuam buscando e aproveitando oportunidades de melhoria.
- As pessoas e equipes têm mais consciência dos processos e do seu cumprimento, pois desenvolveram progressivamente uma compreensão do seu valor.
- O compromisso com nossa visão, objetivos e princípios cresceu muito; todos estão mais conscientes e comprometidos em oferecer qualidade nessas áreas.
Nas próximas publicações, examinaremos os resultados, os planos de ação que surgiram e nosso caminho para colocá-los em prática.
Referências
- Road-mapping Your Way to Agile Fluency, Kelsey Van Haaster, 2016
- The CMMI Agile Adoption Model, Mukta Telang, 2015
- Measuring Agile Maturity in the Enterprise, Amjad Gani & Jim Starrett, 2017
- The Agile Fluency Model, Agile Fluency Project, 2014
- Agile Maturity Model – 3 Different Approaches, Udayan Banerjee, 2011