Maturidade 4 em Métodos Ágeis – Agilidade em Escala Organizacional

Em continuidade ao nosso modelo de maturidade em métodos ágeis, iremos falar da escalabilidade das práticas ágeis em organizações. Vimos que no nível 3 de maturidade as práticas ágeis se tornam consistentes dentro de um projeto. O caminho natural  é o espalhamento dessas práticas por diversos projetos, áreas ou até mesmo toda uma organização.

Desde a nascimento dos métodos ágeis há 20 anos atrás, diversos praticantes enfretaram o problema da escalabilidade de métodos ágeis. Os resultados foram diversos e levaram a um conjunto robusto de frameworks de processo. Compilamos alguns abaixo.

LESS (Large Scale SCRUM)

Large Scale Scrum

Origem: O LESS foi compilado a partir das  experiências  de Craig Larman e Bas Voodle em consultoria e desenvolvimento de produtos em larga escala, com centenas de analistas trabalhando simultaneamente com um objetivo unificado.

Bases conceituais: O LESS tem como pilares o SCRUM, o pensamento Lean e Teoria de Sistemas. O SCRUM fornece ao LESS a estrutura, papéis, ritos e produtos de trabalho. O pensamento Lean fornece a esse framework a sólida base de conhecimento do Sistema Toyota de Produção, incorporado com robustez nesse trabalho. A Teoria de Sistemas traz os elementos poderosos de pensamento tais como efeitos defasados no tempo, ciclos de reforço positivos e negativos, análise de causas raízes e arquétipos organizacionais. O sítio mantido pelos autores é uma rica fonte de informações, congregando ao mesmo tempo conceitos sofisticados e práticas aplicáveis em virtualmente qualquer tipo de projeto.

Livro essencial:  Scaling Agile and Lean Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman e Bas Voodle.

Certificação de entrada: Certified LESS Practicioner


 

SAFe (Scaled Agile Framework)

SAFE 4.0
SAFE 4.0

Origem: O SAFE, que teve a versão 4.0 lançada em Janeiro de 2016, é fruto do trabalho de Dean Leffingwell, direcionado para operar uma área de Tecnologia de Informação em alinhamento ao portifólio organizacional, com o uso de princípios e práticas ágeis e lean.

Bases Conceituais: O SAFE também é fortemente baseado no SCRUM e no pensamento Lean. Entretanto, observamos nesse método também conceitos gerenciais clássicos como o uso de cadeias de valor, portifólio e programas de projetos. O SAFE é um método com uma estrutura mais rígida que outros métodos ágeis, o que traz críticas de agilistas mais extremos e elogios de gerentes que estão acostumados com escolas gerenciais mais tradicionais.

Livro Essencial: Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series)

Certificação de Entrada: SAFe Agilist


NEXUS

Nexos Framework
Nexus Framework

 

Origem: O Nexus teve origem a partir da experiência de Ken Schwabber, um dos pais do SCRUM, no desenvolvimento de produtos com vários times Scrum operando em paralelo. O Nexus é mantido pela comunidade Scrum.Org.

Bases Conceituais: O framework Nexus é a sistematização da técnica de escala o Scrum chamada Scrum of Scrums, para projetos que demandem entre 3 e 9 times operando em paralelo. Ele introduz novos papéis e um time especial (Time de Integração) e tem como foco central a integração e coordenação dos esforços de cada time na construção dos incrementos de produtos.

Livro Essencial: Guia do Nexus, já traduzido para o português.

Certificação de Entrada: Scaled Professional Scrum (SPS)


 

Holocracia (Holacracy)

Holocracia
Holocracia

Origem: A Holocracia é um sistema descentralizado de tomada de decisões para que empresas possam criar mecanismos de auto-organização para operar em ambientes dinâmicos e complexos.  

Base Conceitual: A Holocracia tem em seus pilares conceitos sociológicos de organizações de centro vazio, conceitos de auto-organização, teoria da complexidade e teoria da emergência (emergence). A Holocracia não é um framework de TI e tampouco centrada em projetos apenas. Ele lida com o problema de criar organizações anti-frágeis (como definido por Nassib Taleb no seu potente livro Anti-Fragilidade: coisas que se beneficiam da desordem). A Zappos, bilionária empresa americana recentemente comprada pela Amazon, implementa a holocracia como o seu sistema gerencial descentralizado. O portal Holacracy.org é uma vasta fonte de recursos para interessados e praticantes.

Livro Essencial: Holacracy: The New Management System for a Rapidly Changing World 

Certificação de Entrada: Holocracy Practicioner


 

Cada uma desses frameworks possui dezenas de casos documentados e milhares de empresas em todo o mundo que os usam para seu benefício econômico e social. E de volta ao nosso modelo de maturidade, definimos o uso de métodos ágeis em escala organizacional com esses ou outros frameworks similares como sendo o nível 4 de maturidade.

Organizações que atingem esse nível transcedem os projetos de desenvolvimento de software ou infraestrutura. Essas organizações mudam a sua estrutura interna de funcionamento e transcendem as mazelas gerenciais e ineficiências tão fortemente instaladas em muitas organizações ainda presas ao modelo da administração do século XX.

Se você já opera algum método ágil (SCRUM, OpenUP, XP, Entrega Ágil Disciplinada) de forma consistente em seu projeto há mais de 6 meses, talvez exista espaço para você avançar para o nível 4 de maturidade. Algumas dicas rápidas a respeito incluem:

  • estudar o pensamento e práticas lean;
  • estudar práticas de agilidade organizacional citadas nesses frameworks;
  • avaliar os casos de sucesso citados nesses frameworks e se informar como se deu a implementação;
  • promover debates entre times na sua organização que já praticam o SCRUM;
  • começar a incorporar o pensamento lean dentro das suas práticas ágeis;
  • começar a incorporar práticas lean dentro das suas práticas ágeis. Em particular, percebo da minha experiência que práticas lean ligadas à redução de desperdício tem apelo imediato nos gerentes e possuem baixa resistência para adoção.
  • escolher um framework em escala organizacional e começar a incorporar algumas de suas práticas em uma área ou produto de larga escala;
  • buscar apoio de pessoas que já possuam conhecimento mais sólido nesses frameworks.

Os resultados podem ser muito interessantes.

No próximo post, o último dessa série, iremos descrever como organizações podem atingir a excelência através desses métodos através da  mola mestra da melhoria contínua (Maturidade 5).

Pensamento do dia: “If everyone has to think outside the box, maybe it is the box that needs fixing.”, Malcolm Gladwell

Maturidade 3 em Métodos Ágeis – Práticas Consistentes em Projetos e Demandas

Dando continuidade à nossa série de postagens sobre aumento de maturidade em métodos ágeis, desta vez iremos falar sobre a consolidação de práticas em projetos.

A consolidação de práticas ágeis vem através da sistematização destas práticas pelos membros dos times. E para isso devemos falar de dois aspectos fundamentais para essa sistematização, que são os hábitos e os padrões (patterns).

Hábitos em Métodos Ágeis

Um hábito é uma prática humana que é realizada com baixa energia cerebral e portanto não gera resistência ou cansaço excessivo ao ser realizada. Pense por exemplo em alguns hábitos diários que você realiza como a direção de um carro, que envolve controlar a marcha, pedais e volantes do seu carro e observar os transeuntes e outros carros ao seu redor. Tudo isso ao mesmo tempo. Este hábito é realizado naturalmente pelos motoristas, depois de alguma prática. Não existe desconforto ou resistência cerebral nas ações e a repetição leva à excelência na realização deste hábito. Pessoas experientes em uma área de trabalho realizam tarefas complicadas de forma simples, o que pode ser observado ao ver uma partida de futebol do Lionel Messi. Isso faz parte da prática do hábito.

Em métodos ágeis, hábitos são fundamentais. São eles que fazem com que times não gerem resistência ao buscar uma reunião diária, uma revisão, retrospectiva, refatorar código, modelar de forma colaborativa ou jogar um planning poker para estimar o trabalho em uma sprint. Times ágeis em formação ainda podem ter resistências a uma prática ágil, mas isso acontece porque o hábito não se formou.

E a pergunta que surge então é: Como formar hábitos em times ágeis?

A formação de hábitos já foi bastante estudada na psicologia e existem bons livros a respeito. [Recomendo alguns no final deste post]. Mas em linhas gerais, uma abordagem para formação de hábito inclui o seguinte:

  1. Começar leve. Por exemplo, mesmo que a reunião diária não seja realizada com sucesso em um certo dia, é importante persistir e realizá-la todo dia. A repetição é chave para formar um hábito.
  2. Estabelecer um gatilho. Por exemplo, alguns times ágeis colocam um alarme divertido, como uma música do Star Wars,  ou fazem a reunião diária logo após o momento do café ou quando a última pessoa do time chega ao escritório pela manhã. Estabelecer gatilhos facilita a formação de hábitos.
  3. Tratar o evento como um ritual. Seja um facilitador e mostre que vocês estão ali por um motivo e que isso irá gerar um benefício para todos. Abra a reunião, estabeleça o passo a passo e feche a reunião. Ritualize cada encontro.
  4. Estabelecer uma recompensa. Todo hábito (bom ou ruim) se torna forte pelos sistemas de recompensas. Fumantes conhecem isso em profundidade. Enquanto líder facilitador, você deve buscar pequenas recompensas para ajudar o seu time a formar bons hábitos. Elogios públicos são formas simples de recompensas. Em momentos críticos do projeto, após horas extras para entregar um parte do produto, dar folga ao time no dia seguinte também pode ser um exemplo de uma recompensa.
    As recompensas reversas também funcionam. Por exemplo, se uma pessoal quebrou o código do build, ele deve  depositar 1  real na caixinha da cerveja do time ou trazer chocolates para o restante do time no dia seguinte.
  5. Conhecer o mecanismo cerebral humano chamado de willpower, que diz que a força de vontade é um recurso perecível ao longo de um dia. Ou seja, a manhã é um momento mais propício para pedir que pessoas façam coisas que elas ainda não estão acostumadas. Um exemplo reverso deste conceito é observado em pessoas que esgotaram o seu tanque de boa vontade à noite ao tentar o hábito de um regime e atacam impiedosamente a geladeira.

Alguns estudos mostram que hábitos demoram entre 30 a 70 dias para se formarem e portanto é importante perseverar. Talvez a diferença mais fundamental entre métodos ágeis e métodos tradicionais é que os primeiros requerem disciplina. E sabemos que ter disciplina requer formar bons hábitos.

Patterns em Métodos Ágeis

Padrões são amplamente disseminados em TI. Eles representam melhores práticas da indústria e se dominados pelo praticante, podem tornar o trabalho mais simples e ao mesmo tempo mais efetivo. Patterns tem nomes divertidos, resolvem problemas concretos e apresentam soluções guiadas para estes problemas. Os padrões mais populares são os Design Patterns, embora existam também Analysis Patterns, Implementation Patterns ou mesmo SCM Patterns. Existem também Agile Patterns ou SCRUM Patterns, que representam melhores práticas compiladas por praticantes que operam este método há mais de 20 anos.

Compilo aqui uma lista de 7 SCRUM Patterns que podem servir para o leitor levar o sua prática ágil para um nível acima.

  1. Product Backlog
    • Problema: O seu time e os interessados no seu produto tem dificuldade de definir a ordem de entrega das funcionalidades de um produto. Conflitos e insatisfações surgem por toda parte.
    • Forças: Quando tudo é importante, nada é importante. Ou seja, uma lista de prioridade é fundamental para determinar o quem vem primeiro lugar, o que vem em segundo lugar e assim sucessivamente.
    • Solução: Crie uma lista de itens com incrementos de produto chamada de backlog do produto. Cada item deve representar uma micro-funcionalidade do produto (e não tarefas). A lista deve ser ordenada, ou seja, cada item deve ter uma ordem específica, representando a prioridade do item. Esta lista deve ser priorizada coletivamente, ser publicada em um repositório público e deve ser mantida do início ao final do projeto.
  2. Pigs Estimates
    • Problema: O time tem dificuldades para cumprir os prazos estipulados pela gerência de projeto.
    • Forças: Estimativas devem ser realizadas baseadas em racionais estruturados, ao invés de desejos e fantasias gerenciais.
    • Solução: Deixe a pessoa que for realizar o trabalho realizar a estimativa do número de horas do seu trabalho. Estabeleça tempo para que ele realize a estimativa e forneça os insumos necessários para esta estimativa. Se possível, use todo o time para realizar as estimativas em conjunto com o padrão Planning Poker.
  3. Planning Poker
    • Problema: Um desenvolvedor se sente inseguro em fornecer uma estimativa para o seu gerente. Ele se coloca na defensiva e bastante incomodado com a pressão em ter prazo.
    • Forças: Pessoas com pouco conhecimento de um assunto ou de uma tecnologia temem ser julgados por uma estimativa ruim. Isso gera desconforto e uma situação de pânico quando gerentes pedem por estimativas.
    • Solução: Faça uma estimativa em grupos através de uma dinâmica com um baralho de cartas, em uma reunião com aproximadamente 2 horas. Cada pessoa tem um baralho com cartas com valor 1, 2, 3, 5, 8, 13 ou 21. Um facilitador seleciona um item do backlog (ou uma tarefa). Cada pessoa seleciona em silêncio uma carta. Todos jogam as suas cartas. Se existe um consenso coletivo, então a rodada de estimativa do item é terminada. Se não existe um consenso, os jogadores com estimativa mais alta e mais baixa debatem e após isso uma nova estimativa é buscada para aquele item, até que haja um consenso. Depois, o processo é repetido para todos os itens do backlog.
  4. Daily Clean Code.
    • Problema: A qualidade do código do seu time degrada ao longo do projeto ou longo das manutenções evolutivas.
    • Forças: Você toma banho em base diária. E provavelmente o seu cachorro toma banho em base semanal. Até o seu carro toma banho eventualmente. Pessoas e coisas que não tomam banho começam a cheirar mal e degradar. Software inclusive. Ou seja, dê banho no seu código em base diária para que ele mantenha boa manutenibilidade.
    • Solução: Reserve dez a quinze minutos por dia para refatorar o seu código. Refatore o seu código, rode os seus testes de unidade e publique o código limpo em base diária. Para saber mais a respeito de banhos e software, veja o livro Código Limpo – Habilidades Práticas do Agile Software.
  5. Definition of Ready
    • Problema: O seu time tem dificuldade de trabalhar os requisitos, o que gera mal-entendidos, atrasos na implementação e testes e consequente estresse.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, estabelecer requisitos claros não é trivial.
    • Solução: Estabeleça com o seu time um critério chamado de “Preparado/Ready”. Este critério é usado pelo seu time para aceitar (ou não) um requisito para construção. Se um requisito trazido pelo PO não atender ao critério de “preparado” do time, ele é adiado para um novo ciclo (sprint). Exemplos desses critérios podem incluir, para produtos de software, protótipos de tela ou regras de negócio formalizadas. Para implantações de redes sem fio em um time de infraestrutura, esse critérios poderiam incluir a topologia da rede a ser implantada e um estudo que demonstre a cobertura dos pontos de acesso a ser instalados.
  6. Definition of Acceptance Criteria
    • Problema: As demonstrações dos seus incrementos de produto não atendem as expectativas dos seus usuários. As expectativas desalinhadas geram mal entendidos e frustrações nos seus clientes e também nos membros do time. Os julgamentos sobre a atuação dos analistas de requisitos surgem e são negativos.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, capturar e comunicar requisitos não é trivial.
    • Solução: Formalize com os seus clientes internos e externos os critérios de aceite dos incrementos de produto. Exemplos de critéros de aceite podem incluir evidências de testes, usos de dados reais ou atendimento a normas e padrões de qualidade como segurança ou interoperabilidade. O PO é o papel responsável por verificar se os critérios de aceite de cada incremento de produto foram atendidos ou não ao final de cada sprint.
  7.  Definition of Done
    • Problema: O seu time técnico reclama que não tem “tempo” para implementar boas práticas. Ao longo do projeto, começam a surgir várias pontas soltas e o débito técnico se acumula. No final do projeto, o seu produto entra em produção com um déficit técnico interno e gera problemas diversos carregados para a manutenção.
    • Forças: A urgência sempre irá ganhar das coisas importantes. Portanto, é importante estabelecer na largada condições mínimas de saúde do projeto e criar o conceito de qualidade contínua desde o começo do projeto. Fazer um item pela metade e depois voltar a ele para melhorar um atributo técnico é um exemplo da má prática chama de “Trabalho Parcialmente Feito”, bastante discutida e combatida no pensamento Lean.
    • Solução: Estabeleça, com o seu time técnico, “cláusulas pétreas” que não podem ser violadas e que devem ser implementadas para qualquer item do backlog. Exemplos incluem: regras de negócio financeiras devem ter testes automatizados; códigos devem passar em um teste de regressão no repositório em base diária; liberações em produção devem ter um documento com as notas da liberação (release notes), implantações de infraestrutura devem ter a planta da topologia física da empresa redesenhada (modelo as-built).
      As estimativas dos itens do trabalho já devem considerar o esforço necessário para entregar o item com a sua definição de “Done”. O SM é responsável por garantir o cumprimento desta constituição técnica, que deve fornecer conforto ao time e que possa ser absorvida no custo do projeto.

Em uma postagem futura em uma série própria dedicada à temática de patterns, iremos este conceito de padrões para métodos ágeis e compilar aqui 50 Agile Patterns.

Em resumo, a sistematização envolve a repetição de boas práticas. Ao repetir através de bons hábitos as melhores experiências do mercado, você provavelmente irá levar o trabalho do seu time para um nível acima. Isso irá gerar resultados temporais e financeiros expressivos, ao mesmo tempo que irá promover maior transparência e colaboração.

No próximo post desta série, iremos falar no quarto nível de maturidade em métodos ágeis, que leva os princípios ágeis muito além dos times dos produtos de inovação ou da tecnologia da informação, mas para toda a estrutura de uma empresa.

Uma lista breve de livros sobre a formação de hábitos – Conforme prometido 🙂

  • O Poder do Hábito – Simples, direto e divertido.
  • Essential Zen Habits – Minimalista, inspirador e acionável .
  • A Guinada – Tratamento técnico e ao mesmo tempo divertido sobre porque criar hábitos é difícil e como acionar mecanismos que simplificam a formação de hábitos.