Posts tagged: UFSC

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.

• A Transformação Bridge de Cascata para Ágil

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:

• Três vezes Bridge no Agile Trends Gov!

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.