Políticas Kanban em equipes ágeis: será que precisa ser (tão) padronizada?
Compreenda como agregamos valor às equipes ágeis por meio da autonomia no processo.
Conteúdo produzido por Amanda Bressan Fogaça
Há 4 anos, o Laboratório Bridge tem dedicado esforços para potencializar a sua transformação ágil. Dentre diversos processos e ferramentas implementadas, a busca pela gestão do conhecimento e a necessidade de centralização das informações tem se tornado mais presente. Hoje, temos 14 equipes ágeis de desenvolvimento distribuídas dentro de 3 projetos de contextos e maturidades completamente diferentes. O documento de políticas Kanban das equipes ágeis serve como centralizador das rotinas de cada equipe e suas diretrizes.
Nesse blog vamos te contar sobre a elaboração destes documentos e o valor deles na prática. Vem com a gente! 👇
- O que é o documento de políticas Kanban das equipes ágeis?
- Por que focar em documentação?
- A padronização que não foi (tão) padronizada
O que é o documento de políticas Kanban das equipes ágeis?
O documento de políticas Kanban tem como objetivo explicitar as regras de funcionamento do fluxo de trabalho de cada equipe e suas práticas realizadas no board, servindo como peça chave para o treinamento de novos membros e facilitando a gestão do conhecimento da organização.
Ele também serve de apoio para o Agile Coach da organização conseguir compreender as diferentes rotinas e especificidades das equipes, mesmo não estando próximo de todas elas cotidianamente. Antes do documento, o Agile Coach precisaria contatar o Scrum Master para compreender peculiaridades do board e/ou planilha Kanban da equipe. O documento veio para tornar esse processo de busca mais rápido e acessível.
A estrutura do nosso documento de políticas Kanban possui as seguintes especificações:
- Unidade de estimativa utilizada pela equipe. Damos autonomia para a equipe escolher qual a unidade de estimativa faz sentido para o seu contexto (horas, pontos ou dias, mas isso é papo para outro post 😉);
- Modelo de trabalho da equipe (multidisciplinar ou não);
- Coeficientes para cálculo aproximado de previsibilidade da capacidade da equipe, se existir;
- Visualizações disponíveis no board da equipe no Github;
- Colunas do board da equipe e suas descrições, visto que as equipes possuem autonomia para detalhar as etapas do seu fluxo de trabalho (desenvolvimento, code review interno, code review externo, filas, etc.);
- Regras do board (fluxo de demandas, delimitação do WIP, sentido das colunas, etc);
- Glossário de labels utilizadas pela equipe para identificar suas tarefas no board.
Por que focar em documentação?
Esse documento facilita:
⭐ a compreensão do processo da equipe para novos membros (olha o onboarding aí, minha gente)
⭐ a troca de conhecimento e experiência entre as equipes (caso alguém tenha dúvida e queira entender como o processo está rodando na outra equipe)
⭐que o Agile Coach e os supervisores dos projetos consigam compreender mais de perto a realidade e os processos de cada equipe sem a necessidade de questionar o Scrum Master
A padronização que não foi (tão) padronizada
Por mais que todas as equipes do Lab sigam o mesmo método de trabalho, o próprio método ágil indica que elas sejam autogerenciáveis e adaptáveis. Isso significa que mesmo diante de processos previamente estabelecidos, as equipes ágeis são autônomas para modificar ou ajustar esses procedimentos.
Ou seja, ao considerar o cenário do Bridge onde cada equipe possui :
👍 um contexto diferente
👍uma maturidade diferente
👍e pessoas diferentes (lembra daquele valor do manifesto ágil: pessoas MAIS QUE processos?)
Percebe-se que, o que funciona para uma equipe não necessariamente vai funcionar para outra. E está tudo bem!
Mesmo definindo critérios claros de aceite para estes documentos, as equipes puderam desenvolvê-lo de acordo com o funcionamento da rotina de cada uma e suas necessidades (nível de detalhamento, nome das seções, ordem delas, imagens, etc). Nas imagens abaixo é possível visualizar 3 documentos de equipes diferentes que possuem uma estrutura similar, entretanto com características próprias:
Supernova – políticas do kanban descritas dentro da planilha kanban da equipe. Optaram por centralizar tudo em um só lugar.
RNG – documento objetivo
Legacy – documento completo, contendo fluxo criado no miro para explicação das etapas do fluxo de desenvolvimento
Este artigo demonstra a implementação dos valores do manifesto ágil na rotina das equipes ágeis do Laboratório e principalmente do valor: indivíduos e interações MAIS QUE processos e ferramentas.
Afinal, do que adianta criar um modelo de documento padrão para todas as equipes se ele não permite adaptabilidade para cada contexto? 💡 Fica a dica! O documento só vai fazer sentido se estiver adaptado ao perfil e necessidades da equipe e/ou organização.
Ágil é permitir que as equipes sejam autônomas e autogerenciáveis para se adaptarem de maneira rápida às mudanças.
Curtiu aprender mais sobre a organização das equipes ágeis do Bridge? Então continue nos acompanhando para conferir novos conteúdos!
@laboratóriobridge no Instagram 😉
Você pode se interessar por:
O Laboratório Bridge atua no Centro Tecnológico da Universidade Federal de Santa Catarina (CTC/UFSC), com equipes formadas por bolsistas graduandos, pós-graduandos e profissionais contratados. É orientado por professores do CTC e do Centro de Ciências da Saúde (CCS/UFSC).
Desde 2013, desenvolvemos sistemas e aplicativos para gerenciamento da gestão pública, com parcerias firmadas com o Ministério da Saúde, a Agência Nacional de Vigilância Sanitária (ANVISA) e o Ministério da Educação.
