Ágil em Escala

Framework de Ágil em Escala

Escalar o Ágil não ocorre apenas em processo e metodologia, mas também em cultura, gestão de produtos e serviços. Para isso, é necessário refletir em como escalar os valores e princípios do Manifesto Ágil nas organizações:

Valores do Manifesto Ágil

  • Indivíduos e interações mais que processos e ferramentas;
  • Software em funcionamento mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos;
  • Responder a mudanças mais que seguir um plano.

Princípios do Manifesto Ágil

  1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
  2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
  3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
  4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
  5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
  6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
  7. Software funcionando é a medida primária de progresso.
  8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
  9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
  10. Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
  11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
  12. Em intervalos regulares, a equipe reflete sobre como  se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Como percebemos, muitos dos valores e princípios são relacionados à cultura, e não métodos. Então escalamos ágil tanto em cultura, quanto em processos e produtos.

1. Atributos de Ágil em Escala

Quando diversas pessoas e times trabalham em conjunto, desenvolvendo diversas partes conectadas e integradas do produto final, é necessário realizar a gestão de dependências e sincronizar o trabalho de todos.

1.1 Gestão de Dependências

Este é um princípio importante de ágil em escala. Caso as dependências não sejam geridas pelo próprio processo ou pelas pessoas, muito desperdício haverá, tal como espera, retrabalho e estoque.

Existem diversas práticas de gestão de dependências. Uma delas é o Program Board utilizado pelo SAFe, o qual é criado na PI Planning (planejamento da iteração de programa) com todos os times, e mantido e atualizado ao longo das iterações. As dependências entre os times são mapeadas através das iterações (em vermelho na imagem a seguir).

Program Board do SAFe para Gestão de Dependências

Outra prática é do Spotify, definindo time a time quais tipos de dependências existem entre squads e tribos. Se a dependência é entre tribos, pode ser mais crítica, pois buscam dividir tribos para que não hajam dependências entre elas.

Gestão de Dependências no modelo Spotify

Em Kanban, a prática está em gerir as dependências com gestão visual, tornando o trabalho visível a todos num fluxo de trabalho representado num quadro. Para isso, divide-se os itens em Upstream e Downstream. Upstream representa a descoberta e priorização de itens, enquanto no Downstream o desenvolvimento de cada item puxado. No Kanban Maturity Model (KMM), essa prática de dividir o fluxo em Upstream e Downstream está no Nível de Maturidade ML3: Fit for Purpose, onde o fluxo de trabalho é escalado e adaptado ao que o cliente realmente necessita. Veja na imagem a seguir.

Upstream e Downstream representando a escala do fluxo de trabalho (ref. Kanban Maturity Model)

1.2 Sincronização

Para não haver espera e desperdícios relacionados a dependências, é necessária a sincronização do trabalho. Pode ser planejada em iterações, tal como no SAFe, ou realizada através de priorização em classes de serviço num fluxo contínuo de desenvolvimento, tal como em Kanban.

1.3 Pessoas

O ágil não escala sem a cultura ser disseminada entre as pessoas. De nada adiantará tendo processos e ferramentas ideais, se as pessoas não estiverem seguindo os valores e princípios ágeis.

O Spotify estabelece Guilds e Chapters para escalar ágil de uma forma orgânica tanto dentro das tribos, quanto entre tribos. Uma tribo é uma coleção de squads que trabalham em áreas relacionadas. Dentro das tribos, estabelecem Chapters (Capítulos) para troca de conhecimento especializado e focado na própria tribo. Já entre as tribos, as Guilds (Guildas) para troca de conhecimento organizacional e a nível de produto. Para escalar o ágil, estabelecem Chapters e Guilds de agilistas e agilidade.

Tribos, Squads, Guilds e Chapters no Spotify

2. Escalando Cultura

Escalar cultura está em levar os valores e princípios ágeis para as pessoas da organização. Existe uma grande diferença em fazer ágil e ser ágil. Fazer ágil é seguir processos, e ser ágil é agir e decidir conforme o manifesto ágil. A chave está em ser, além fazer ágil.

Para isso, pode-se estabelecer Agile Centers of Excellence (Agile CoEs), que é um grupo de especialistas em ágil na organização. Geralmente um grupo de agile coaches e agilistas. Na DBC, temos o DBC AGIL, um grupo de Agile Coaches, Scrum Masters e Agilistas com o objetivo de prover melhores serviços ágeis para clientes e projetos. Esse grupo possui uma liderança técnica de um Enterprise Agile Coach.

De uma forma mais orgânica, as Comunidades de Prática são grupos de especialistas ou interessados numa área do conhecimento, focados na mentoria e em troca de conhecimento sobre práticas e ferramentas. No Spotify também é chamado de Guilda (Guild). Na DBC, possuímos a CoP de Agilidade e a CoP de POs, as quais possuem encontros frequentes ou sob demanda própria do grupo.

Para engajamento das pessoas em maestria técnica e no aprender fazendo, a empresa pode patrocinar eventos organizacionais como Exploration Days, Hackathons ou ShipIt Days. Esses eventos podem ser organizados também a nível de times ou departamentos, o que torna mais acessível a realização. Exclusivamente para o time, Mob Programming é uma prática onde todos se reúnem e realizam uma tarefa por vez, gerando muito aprendizado e alinhamento com o trabalho ágil.

3. Escalando Produto

Ao escalar o ágil na organização, é necessário também pensar em formas e estratégias para escalar produtos em relação ao negócio e à qualidade interna do produto.

Para escalar o produto ao negócio, OKRs Objetivos e Resultados-Chave auxiliam a gerenciar metas flexíveis que engajem as pessoas que desenvolvem o produto. MVPs (Produto Mínimo Viável) podem ser desenvolvidos para testar o mercado e evoluir o produto, além coletar feedback dos usuários, numa visão de Lean Startup num ciclo de Construir, Medir, Aprender (Build, Measure, Learn).

Na organização do desenvolvimento de produto, é essencial ter um Backlog Único de Produto visível a todas as pessoas envolvidas. Também ter uma DoD (Definição de Pronto) Base para o produto, e então especializar essa DoD para cada time ou linhas de produto.

Na estruturação dos times e departamentos de produto, as tribos são divididas para desenvolver partes específicas do produto. Chapters auxiliam na melhoria do produto dentro de cada tribo.

Ao escalar um produto é preciso também investir na qualidade interna. “Você não pode escalar código malfeito” (“You can’t scale crappy code”). Essa frase do SAFe resume tudo. Práticas de eXtreme Programming (XP) e DevOps auxiliarão a construir um produto que suporte ser escalado. Diversas práticas de XP e DevOps tais como Design Emergente, YAGNI “You Ain’t Gonna Need It”, KISS “Keep It Simple, Stupid”, DRY “Don’t Repeat Yourself”, Posse Coletiva de Código, Padrão de Codificação, Revisão por Pares, Trabalho em Pares, Agile Testing, Automatização de Testes, Refatoração, Feature Toogles, Integração Contínua, Entrega Contínua, Deploy Contínuo, Monitoração, entre outras.

4. Escalando Processo

Ao escalar ágil na organização, é possível utilizar as estratégias de Gestão de Mudança Top-down ou Bottom-up, ou então de uma forma transversal que venho chamando de Processo Puxado. Top-down é quando a gestão da empresa demanda o ágil de uma forma diretiva (empurrada), através de uma decisão de cima para baixo na hierarquia da empresa. Bottom-up é quando um time inicia com métodos ágil, mostrando resultados e então escalando para outros times e departamentos.

Gestão de Mudanças de Processos de Ágil em Escala.

Processo Puxado é um formato transversal onde as práticas ágeis vão sendo utilizadas e combinadas conforme demanda, através de um ciclo de melhoria contínua. Inicia-se com o mínimo de processo possível, e frequentemente vai se adaptando. Não necessariamente através de retrospectivas, mas através de um processo contínuo de melhoria de processo.

Não há um formato ideal de abordagem para escalar ágil na organização. Tudo depende da estratégia, do contexto, da cultura, além da urgência e do momento que se está.

Agile Fluency Model é um formato bottom-up, onde se inicia com a cultura ágil nos times. Posteriormente, segue-se para a melhoria da entrega dos times, para apenas depois então focar na otimização e fortalecimento da organização. Veja na imagem a seguir.

Agile Fluency Model.

Nexus é framework do Scrum escalado. Segue os mesmos princípios do Scrum, porém para 3 a 9 times desenvolverem um produto único. Uma prática interessante nesse framework é que a reunião de Revisão da Sprint é realizada com todos os times, para reforçar a integração do produto. Algo que se deve estar atento ao utilizar o Nexus é que ele pode ter uma quantidade excessiva de reuniões. Em geral, Nexus é implantado top-down.

O Framework Nexus™ para escalar o Scrum

SAFe, Scaled Agile Framework, é um conjunto de práticas de ágil em escala para portfólio, soluções e sincronização de times. Muito mais que um framework, é um corpo de conhecimento (poderia se chamar de SABOK – Scaled Agile Body of Knowledge).  Em geral, SAFe é implantado top-down.

SAFe, Scaled Agile Framework.

O Kanban Maturity Model (KMM) auxilia na avaliação e na evolução do processo, de nível em nível. Para escalar processos ágeis com Kanban, busca-se implementar o Nível de Maturidade ML3: Fit for Purpose, onde a organização possui um fluxo de valor focado no cliente através de classes de serviço, com processos de sincronização nas linhas de produto e serviços compartilhados. Veja na imagem a seguir os níveis de maturidade de Kanban.

KMM Kanban Maturity Model.

Referências

Agile Fluency Model https://www.agilefluency.org/

Kanban Maturity Model https://www.kanbanmaturitymodel.com/

Manifesto para Desenvolvimento Ágil de Software https://agilemanifesto.org/iso/ptbr/manifesto.html

Nexus https://www.scrum.org/resources/nexus-guide

Scaled Agile Framework https://www.scaledagileframework.com/

Scaling Agile @ Spotify https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Agile Team Poker DBC, um Assessment para Times Ágeis

O Agile Team Poker é um método para auto-avaliação de times sobre diversos atributos que compõem um time ágil, independente de metodologia de trabalho. Foi desenvolvido pelo Enterprise Agile Coach da DBC Dionatan Moura em 2019 e já aplicado em dezenas de times e clientes DBC. Categorias e atributos avaliadas no Agile Team Poker:

Categorias e Atributos de Avaliação de Times Ágeis

O assessment avalia a efetividade do time no momento, e traz uma previsão do que está melhorando, estável ou piorando atributo a atributo. O assessment então serve como forma de criar um plano de ação de melhorias pelo próprio time, com auxílio da gestão e lideranças. Evite o termo “maturidade” do time, porque pode parecer pejorativo. Utilize os termos de “efetividade” do time, ou “saúde” do time.

A base dele foi inspirada em outros assessments tais como o Squad Health Check Model do Spotify [1] e diversos artigos científicos sobre características de times tais como do que faz um time efetivo realizado pelo Google [2]. Estes atributos estão divididos em categorias tais como Negócio, Agilidade, Time e Formação de Time.

Gestão Visual dos Resultados

Após todo o time realizar a dinâmica do Agile Team Poker, o resultado é construído de uma forma visual e de fácil entendimento a todos. Gestores e lideranças do time também participam. É essencial a participação deles, até porque eles fazem parte do time.

O resultado fica como verde para atributos que estão indo bem, amarelo para quando não estão bem mas nem tão ruim assim, e vermelho quando não está nada bom. As setas mostram a tendência do atributo do presente para o futuro próximo. Seta para cima mostra que o atributo está evoluindo, que ações estão sendo feitas. Seta estável mostra que o atributo não piora nem melhora, e que nenhuma mudança ou ação de melhoria existe. Seta para baixo é quando o atributo está piorando, e que ações imediatas precisam ser feitas. O triângulo vermelho com um “!” mostra pontos de atenção, que são atributos que não estão indo bem e nada está sendo realizado de ação de melhoria. Resultado visual do Agile Team Poker DBC:

Agile Team Poker DBC Resultados

Como Funciona o Agile Team Poker DBC

Cada membro do time, incluindo o gestor e lideranças, possui um deck com um sinal verde, amarelo ou vermelho. E uma seta subindo, estável ou descendo. Cada membro joga às cegas (por isso o nome poker) na mesa, para que não influencie os outros membros do time. Após todos terem jogado as cartas, o time todo desvira as cartas ao mesmo tempo. A partir daí o time precisa discutir os pontos de vista e entrarem num consenso sobre qual é o resultado do atributo avaliado. Há uma carta para cada atributo onde o facilitador vai trazendo aleatoriamente (para não influenciar no resultado). Confira o deck individual de cada membro. (Design por Rafael Oliveira, UX Lead na DBC):

Agile Team Poker DBC Deck

A dinâmica dura de uma hora e trinta minutos a três horas. Dependerá do tamanho do time, e de quanto já vem conversando sobre esses itens em outros momentos.

São nove as possibilidades de cada avaliação individual de atributo. Preste atenção nos seis pontos de atenção. Possibilidades de cada avaliação individual de atributo:

Agile Team Poker DBC Deck Completo

Assessment Online

Ok, mas e agora que a maioria dos times estão trabalhando remotamente? Os mesmos atributos são avaliados por respostas num formulário online. Google Forms é uma ferramenta gratuita e excelente para isso. Cada indivíduo responde as perguntas, incluindo o gestor e liderança do time.

O resultado do time fica como a seguir, exibindo as médias das categorias dos atributos e as médias das respostas individuais dos atributos. O resultado deve ser sempre compilado por time, e nunca individualmente.

Resultado de Avaliação de Times Ágeis

O questionário possui uma afirmação para cada atributo do Agile Team Poker DBC:

  1. O planejamento de entregas do time é realizado de uma forma organizada numa frequência ideal.
  2. O trabalho realizado pelo time entrega alto valor ao negócio.
  3. Há uma alta qualidade tanto nas entregas quanto na solução desenvolvida pelo time.
  4. Existe uma ótima colaboração e comunicação do time com o cliente, e do cliente com o time.
  5. O time consegue responder às mudanças sempre que necessário, conseguindo se adaptar rapidamente.
  6. As atividades do time são claras.
  7. Os papéis dos membros do time são bem definidos.
  8. O time busca a simplicidade nas soluções.
  9. Há aprendizado e troca de conhecimento entre o time.
  10. O time possui ferramentas e infraestrutura adequadas.
  11. Há uma excelente comunicação entre os membros do time.
  12. O processo de trabalho melhora continuamente.
  13. O time possui uma boa auto-organização.
  14. O time possui uma boa sinergia entre os membros.
  15. O time possui um ritmo sustentável de trabalho.
  16. O time possui suporte da gestão.
  17. O time possui um ambiente seguro para discutir ideias e realizar melhorias.
  18. O time possui conhecimento técnico suficiente para realizar o trabalho necessário
  19. O time possui conhecimento de negócio suficiente para realizar o trabalho necessário
  20. Os membros do time buscam a multidisciplinaridade. Ou seja, cada especialista busca entender outras áreas de conhecimento relacionadas ao trabalho.

As respostas ficam em escala Likert, e o membro do time responde se concorda ou discorda com a afirmação. O que gera uma porcentagem de 0 (0%) a 4 (100%).

Escala Likert qualitativa sendo quantificada

Após os resultados serem compilados, crie um plano de ação com o time, gestão e liderança olhando cada categoria e atributo.

Licença para Utilização

A licença do Agile Team Poker e do Assessment Online é a Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional (CC BY-NC-SA 4.0). Você pode utilizar livremente em seu trabalho, nunca vender o material, e se modificá-lo, deve atribuir sempre à DBC. https://creativecommons.org/licenses/by-nc-sa/4.0/deed.pt

Referências

[1] Squad Health Check model – visualizing what to improve
https://engineering.atspotify.com/2014/09/16/squad-health-check-model/

[2] The five keys to a successful Google team https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/

Framework de Transformação Ágil

Transformar a cultura, produtos e processos da organização com os valores e práticas da agilidade.

Premissas para uma Transformação Ágil eficaz:

  • Produtos (e serviços) ágeis são resultados de uma cultura ágil com processos ágeis;
  • Focar na transformação ágil apenas em processos ágeis será ineficaz;
  • Produtos já maduros desenvolvidos de uma forma não ágil podem ser a maior dificuldade na transformação ágil;
  • O porquê da transformação é aprimorar os produtos, através de processos e cultura ágeis, num fluxo de cima para baixo na pirâmide, e não o inverso (evitar o antipadrão Ágil Pró-Forma);
  • A transformação não deve ter um fim, num processo de melhoria contínua.
Framework de Transformação Ágil