Crystal: Um Método Ágil nascido para escalar

Compartilhe:

Este final de semana estive na casa de meus pais fazendo uma limpa e me deparei com um trabalho da minha primeira pós-graduação. O método ágil Crystal. Na corrida dos métodos ágeis é perceptível que o Scrum ganhou ampla dianteira e o Kanban bem logo atrás. O terceiro método provavelmente seria o eXtreme Programming (XP). Este é o método que você usa sem saber. Coisas como trabalho em par, integração contínua e entregas curtas vêm daqui. 

Entretanto, outros métodos acabaram meio que esquecidos pelo caminho como foi o caso do Crystal, Feature-Driven Development (FDD), Dynamic System Developed Method (DSDM) e Disciplined Agile Delivery (DAD). Como você pode perceber, todos estão bastante focados no desenvolvimento de software. O Crystal sempre chamou minha atenção, pois é um método que já nasceu com a ideia de escalar para times médios, grandes e gigantes. Neste artigo tentarei explicar um pouco sobre esse método, suas principais características e ideias.

Crystal

Esse método foi criado pelo peculiar Alistair Cockburn por volta dos anos 90. O nome vem de uma ideia do Alistair de que o cristal (crystal) reflete a transparência, adaptabilidade e diversas cores que um cristal poderá ter. O time que deseja utilizar esse método deverá escolher um dos diversos tipos de “cristal” que existem dentro do modelo. É necessário que ele avalie o tamanho desse time / squad e o risco que o produto que ele trabalha pode causar para sua empresa, clientes e população em geral.

Seu foco principal é a comunicação direta. Ele inclusive criou um dos gráficos que acho mais interessante sobre canais de comunicação. 

Gráfico de canal de comunicação do Crystal. Os itens de mais eficazes para os menos eficazes são: Face a face com quadro branco; conversa face a face; conversa por vídeo; Opções por Modelagem; conversa por telefone; Vídeo gravado; conversa por e-mail; Áudio gravado; e Papel
Riqueza e eficácia do canal de comunicação segundo Alistair Cockburn.

Nesse gráfico temos no Eixo X a riqueza do canal de comunicação indo dos mais frios: papel e áudio gravado, para os mais quentes: comunicação face a face e comunicação face a face com um quadro branco para as pessoas desenharem quando necessário. O Eixo Y é a eficácia da comunicação do menos eficaz para os mais eficazes.

Além disso, segundo Alistair no seu livro Agile Software Development The Cooperative Game defende que o Crystal busca atender às sete propriedades de projetos extremamente bem-sucedidos. São elas:

  1. Entregas frequentes: Quanto mais frequente, mais feedbacks e mais oportunidades de correção.
  2. Melhoria Reflexiva: Refletir sobre como melhoramos a forma de trabalhar, nosso produto ou serviço.
  3. Segurança Pessoal: As pessoas podem conversar com gestores e clientes de forma transparente sem temer pelos seus empregos.
  4. Foco: Estamos focados no que estamos construindo e sabemos qual é a prioridade atual.
  5. Fácil acesso a usuários reais: Quanto mais próximo dos usuários, mais rico será o feedback e mais rápido esclarecemos as dúvidas.
  6. Ambiente técnico com testes automatizados, gestão de configuração e integração contínua: Automação de código-fonte. 
  7. Colaboração através de fronteiras organizacionais: Se você já dependeu de times externos ao seu, você sabe o quanto isso é relevante. Navegar através dos times dentro da organização é muitíssimo importante.

Comparação entre o Crystal, Scrum e Kanban

A tabela abaixo apresenta um resumo das principais diferenças entre Crystal Scrum e Kanban.

Item Crystal Scrum Kanban
Processo Altamente flexível Estruturado em Sprints Fluxo contínuo
Papéis Não formalizados Papéis definidos (Scrum Master, PO, Time) Não prescreve papéis
Ciclos de Trabalho Adaptáveis Sprints fixos Fluxo contínuo
Reuniões Flexíveis Conjunto definido de eventos Flexíveis
Métricas Personalizáveis, não são o foco central “Velocidade” Lead time, WIP, Vazão etc.
Foco Comunicação e pessoas Entrega incremental de valor Otimização do fluxo de trabalho
Escopo de Aplicação Adaptado para diferentes tamanhos e criticidades Times pequenos e moderados Qualquer tamanho de equipe

Papéis e Responsabilidades do Crystal

Além disso, fazendo uma comparação entre o Crystal, Scrum e Kanban, diria que o Crystal está mais próximo do Kanban. Ele não possui um conjunto de papéis bem definidos como no Scrum. No texto aparecem responsabilidades que tradicionalmente podem ser desempenhadas por uma pessoa ou um grupo. Vou colocar aqui as responsabilidades que o Crystal define, os papéis que são citados, porém não obrigatórios.

 

Responsabilidade Papéis possíveis
Coordenação, facilitar a remoção de impedimentos, facilitar a comunicação entre os membros do time Ninguém específico (times pequenos) ou Gerente de Projetos
Construção do produto, definições técnicas, comunicação com os stakeholders. Desenvolvedores, em times maiores podem ser mais especializados, como Testadores, Especialista em Interface de Usuário, Líder Técnico etc.
Fornecimento de Feedback, priorização de requisitos. Stakeholders (clientes, gestores etc.)

Reforço, o Crystal não tem uma definição tão rígida quanto a definições de papéis como o Scrum, mas reconhece que há responsabilidades que devem ser respeitadas. 

Reuniões, Cadências ou Cerimônias no Crystal

Assim como no Kanban, não há uma exigência para a realização de reuniões. Os times vão se incorporando conforme a necessidade surge. A ideia é implantar e adaptar as reuniões para resolver problemas que acontecem ao longo da vida do time. 

Os diferentes crystals

A seguir apresento os diversos tipos de adaptação do Crystal, o porquê da mudança do nível e quais reuniões e papéis costumam surgir com cada nível, assim como a gestão do backlog. 

Tl; dr; sobre os diferentes crystals

Segue uma tabela com o resumo que pedi para o Chat GPT gerar, caso você não tenha muito tempo para ler os detalhes

Tipo do Crystal Tamanho da Equipe Exemplos de Riscos Tratados Gestão do Backlog Reuniões
Crystal Clear Até 6 pessoas Baixo impacto financeiro ou falhas operacionais sem consequências graves. Exemplo: falhas que afetam apenas poucos usuários internos. Backlog simples e informal. Geralmente gerido pelos próprios desenvolvedores com o cliente. Prioridades definidas em reuniões diretas.
– Reuniões diárias informais
– Revisões de entrega (opcional)
– Retrospectiva (opcional)
Crystal Yellow 7 a 20 pessoas Riscos operacionais moderados, com impacto financeiro ou operacional significativo. Exemplo: falhas que podem causar interrupções em sistemas de médio porte. Backlog mais estruturado. Pode ser gerido por um representante do cliente ou equipe, com maior formalidade na priorização.
– Reuniões diárias
– Planejamento de iteração
– Revisão de entrega
– Retrospectiva
Crystal Orange 20 a 50 pessoas Riscos elevados, como falhas que afetam a reputação da empresa ou causam perdas financeiras. Exemplo: falhas que interrompem serviços críticos para clientes. Backlog formalizado, revisado regularmente. Gestão compartilhada entre líderes técnicos, gerente de projeto e stakeholders. Sub-equipes podem ter backlogs próprios, mas todos coordenados.
– Reuniões diárias por subequipes
– Planejamento de iteração
– Revisão de entrega
– Retrospectiva
– Checkpoints regulares
Crystal Red 50 a 100 pessoas Riscos muito elevados, como falhas que podem causar grandes perdas financeiras ou afetar diretamente a vida de pessoas. Exemplo: interrupções em serviços financeiros ou médicos. Backlog formal e complexo, com priorização contínua. Envolve mais papéis, como gerente de projeto, analista de negócios, e cliente. Priorização precisa ser mais rigorosa.
– Reuniões diárias por subequipes
– Planejamento de iteração
– Revisão de entrega
– Retrospectiva
– Checkpoints regulares
– Reuniões de gestão de riscos
– Reuniões de priorização
Crystal Marrom Mais de 100 pessoas Riscos críticos e globais, como falhas que podem impactar grandes sistemas governamentais ou infraestruturas críticas. Exemplo: interrupção de serviços públicos essenciais. Backlog formal, gerido por uma equipe de gestão dedicada. Envolve revisões e auditorias constantes. Coordenação com várias subequipes e stakeholders para alinhamento estratégico.
– Reuniões diárias
– Checkpoints regulares
– Revisão de entrega
– Reuniões de gestão de riscos
– Reuniões de conformidade/auditoria
– Reuniões de priorização
Crystal Violeta Equipes muito grandes, multi-regionais (1000+ pessoas) Riscos globais e de missão crítica, como falhas que podem resultar em catástrofes, afetar a segurança de milhões de pessoas, ou causar perdas financeiras massivas. Exemplo: falhas em sistemas de controle aéreo ou bancário global. Backlog global, gerido por múltiplas equipes de gestão e priorização estratégica. Priorização e coordenação entre múltiplas subequipes. Alto nível de formalidade com revisões frequentes e controle rigoroso.
– Reuniões diárias
– Checkpoints constantes
– Revisão de entrega
– Reuniões de integração entre subequipes
– Reuniões de gestão de riscos
– Reuniões de conformidade/auditoria
– Reuniões de priorização

 

Crystal Clear (Cristal Transparente)

É o primeiro nível de Crystal recomendado para equipes pequenas com até 6 pessoas, onde a comunicação tende a ser rápida e informal. 

Papéis

No geral aqui aparece algum papel de liderança de comunicação como o Gerente do Projeto com funções típicas de Scrum Master. O envolvimento com os clientes e demais stakeholders é bem informal e direto. Os desenvolvedores fazem de tudo um pouco.

Backlog

A lista de itens que o time deve construir é menos formal e mais fluída. O “backlog” pode ser uma lista simples de funcionalidades discutidas diretamente com o cliente e o time. A priorização é feita pelos desenvolvedores com o cliente de forma informal.

Reuniões

No Crystal Clear, as reuniões não são tão comuns, mas podem começar a surgir para organizar o trabalho. 

  • Reuniões diárias: Foco em alinhamento rápido e informal à semelhança da Scrum Daily ou Team Kanban Meeting. A periodicidade deve ser diária.
  • Revisões de Entrega: apresentação do progresso sobre a construção do produto / serviço e receber feedback do cliente. A periodicidade depende do tamanho da iteração. Normalmente semanal ou quinzenal.
  • Retrospectivas: É uma reunião opcional neste nível em que breves reflexões para avaliar o que está funcionando bem ou o que pode ser melhorado. Acontece no final de cada iteração. Normalmente semanal ou quinzenal.

Crystal Yellow (Cristal Amarelo)

Normalmente para equipes entre 7 até 20 pessoas. Envolvem risco moderado, por exemplo, a falha de um projeto pode impactar financeiramente a empresa. 

Papéis 

Ela já exige um papel de coordenação formal, pois é normal que haja um afastamento entre os clientes e os desenvolvedores. Estes, inclusive, costumam ser um pouco mais especializados. Como o Crystal foi criado para o desenvolvimento de software, no Yellow, já aparecem papéis como testadores e designers. 

Backlog

A lista de itens a fazer é formalizada e é comum que uma pessoa passe a fazer o papel de responsável pelo “backlog”. 

Reuniões

Todas as reuniões que acontecem de forma informal no Crystal Clear acontecem no Yellow, porém são mais formais e costumam ser obrigatórias. Também se adiciona a reunião de Planejamento da Iteração que é semelhante à Sprint Planning do Scrum ou a Reunião Interna de Reabastecimento do Time do Kanban em que o time decide quais serão os próximos itens em que trabalharão em seguida. A ideia é alinhar expectativas entre os desenvolvedores e stakeholders, além de distribuir o trabalho entre os desenvolvedores. A periodicidade depende do tamanho que o time definiu para iteração, porém costuma ser semanal ou quinzenal.

Crystal Orange (Cristal Laranja)

Equipes que têm entre 20 até 50 pessoas e falhas aqui podem representar uma perda significativa para a organização. 

Papéis 

Do Orange em diante é comum que a grande equipe seja dividida em subequipes menores para poder melhorar a comunicação e distribuir o trabalho. Podemos dizer que dentro de um cristal laranja há vários cristais amarelos e transparentes. Também é comum aparecer alguns papéis menos técnicos como líderes de subequipes e gerentes de risco.

Backlog

O backlog aqui é formal e único à semelhança do LeSS. Obviamente no nível Orange, há pouco detalhamento com relação à implementação do item, as subequipes é que irão detalhá-los conforme a necessidade e proximidade da implementação. 

Reuniões

No Crystal Orange é comum que os times adotem algumas reuniões que já apareceram nos outros crystals, porém com foco no alinhamento único entre todas as subequipes. Quando essas reuniões acontecem, os itens de trabalho costumam ser discutidos sem grande detalhamento, pois a implementação acontece dentro das subequipes. Além disso, é possível que as subequipes queiram manter as reuniões de Crystal Clear e Yellow para melhor desempenharem seu trabalho. Essas reuniões são: Planejamento de Iteração Global, Revisões de entrega Global e Retrospectiva Global.

Ele recomenda que a reunião diária seja executada sempre no nível de subequipes como aparece no Crystal Clear. Inclusive, o nome dela é Reunião Diária por Subequipes

Aparece mais uma nova reunião não obrigatória chamada de Reunião de Checkpoint que são pontos de contato entre todas as subequipes ao longo da iteração para discutir progressos, desafios e remover impedimentos do fluxo de trabalho. Semelhante à Workflow Kanban Meeting. Ela costuma ser semanal.

Crystal Red (Cristal Vermelho)

Agora já estamos falando de equipes enormes com 50 até 100 pessoas. O risco de falha aqui pode inviabilizar a existência da empresa ou trazer prejuízos significativos a seus clientes. 

Papéis 

A especialização dos papéis técnicos é mais detalhada. Papéis não técnicos como gerente de riscos são formalizados.

Backlog

O Backlog aqui permanece único e totalmente formal. As entradas e saídas são estruturadas para garantir que o trabalho seja feito em sincronia. Cada subequipe pode ter seu próprio backlog de trabalho, mas todos precisam ser coordenados a partir de um backlog global.

Reuniões

O Checkpoint passa a ser obrigatório e deve ser executado regularmente. Todas as reuniões globais do Crystal Orange são mantidas e as reuniões do nível Yellow acontecem nas subequipes. Além disso são acrescentadas:

  • Reunião de Priorização que visam reavaliar e ajustar as prioridades do backlog global, alinhando com os objetivos da empresa e necessidades dos clientes.
  • Gestão de Riscos começa a aparecer para identificar e mitigar riscos antes que eles possam impactar a construção do produto ou do serviço.

Crystal Brown (Cristal Marrom)

Inaugurando os cristais que o Alistair apresenta com menos detalhes em seus livros: Crystal Clear, Agile Software Development The Cooperative Game e no seu antigo blog que só está disponível na Wayback Machine, temos o Crystal Brown. Ele é focado em times com mais de 100 pessoas. Normalmente lida com risco de vida e impactos financeiros gigantescos envolvendo mais de uma empresa.

Papéis

Não há muita informação sobre papéis neste caso, mas é provável que estejamos falando em bastante especialização tanto de papéis técnicos quanto não técnicos. 

Backlog

O backlog é normalmente gerido por um time dedicado a isso, pois envolve muitas revisões, avaliações e auditoria.

Reuniões

As informações sobre as possíveis reuniões desse nível são esparsas. O Chat GPT jurou de pés juntos que nesse nível aparece a reunião de Conformidade/Auditoria. Creio que seja factível porque em projetos de altíssimo risco existam alguns pontos para avaliar se o time e suas subequipes estão seguindo as regulamentações e normas que visam reduzir os riscos a que o produto esteja exposto. Essa necessidade é comum em setores fortemente regulados como bancos, saúde, energia elétrica, telefonia, entre outros.

Crystal Violet (Cristal Violeta)

Também pouco detalhado pelo autor, o Crystal Violet é destinado a equipes com mais de 1000 pessoas e, normalmente, multirregionais. Os riscos tratados aqui são catastróficos e podem afetar milhares de pessoas. Por exemplo: setor de geração e transmissão de energia, grandes bancos e gestão de barragens.

Não há muitas informações sobre os papéis e não encontrei nada sobre novas reuniões. O Chat GPT apresentou a reunião de Integração de Equipes, porém confesso que não achei nada no material do Alistair. Já a gestão do backlog se assemelha mais a uma gestão de portfólio do que de um produto único.

Conclusão

O Crystal foi uma ideia interessante porque já pensou em trabalho escalado desde o início. Altamente adaptável. Infelizmente não teve muita adoção pelo mercado e seu autor também não deu muita ênfase na venda da sua ideia. 

Uma curiosidade foi que anos após, durante um evento em Belo Horizonte (MG) tive a oportunidade de almoçar com o Alistair. Falei sobre esse trabalho da pós-graduação e ele fez questão de tirar uma foto minha com ele mostrando o gráfico dos canais de comunicação. 

O Crystal pode não ter ganhado muito espaço, mas você pode ganhar seu espaço na agilidade através do Scrum e Kanban. Nós oferecemos os treinamentos de Certified ScrumMaster (CSM) e Certified Scrum Product Owner® (CSPO) . Já no Kanban indico os treinamentos de Team Kanban Practitioner (TKP) ou Kanban System Design (KSD).

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Uma frase que ficou muito popular é que quando adotamos a agilidade, passamos a entregar mais valor. Agilidade é entregar valor. Mas sem definir o que é valor, sua transformação será frágil, não ágil. Então, o que você pode fazer…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…