Uma das disfunções mais comuns encontradas em Equipas Scrum é a transformação da Daily Scrum num relatório de estado, onde cada Desenvolvedor fornece o estado do item de trabalho que está a desenvolver e, no final, ninguém realmente sabe como estão a sair em relação à Meta da Sprint. Todos nós que já passámos por Equipas Scrum percebemos que esse não é o melhor caminho… Com o tempo, os Desenvolvedores tornam-se cada vez menos dispostos a colaborar, cada um fechado no seu próprio mundo, até que um dia nos perguntamos se realmente temos uma Equipa Scrum ou apenas um grupo de pessoas que por acaso trabalham juntas no mesmo espaço.

Mas como podemos nos prevenir contra isso? Ou, se isso já está a acontecer hoje, como podemos começar a remediar?

É importante lembrarmo-nos aqui do propósito da Daily Scrum. Esse é um evento de planeamento e tomada de decisão rápida, que acontece todos os dias da Sprint e conta com a participação de todos os Desenvolvedores da Equipa Scrum. O propósito é inspecionar o progresso do trabalho em direção à Meta da Sprint e adaptar o Sprint Backlog conforme necessário para otimizar as chances de alcançar a meta.

Aqui estão algumas sugestões para promover maior foco e colaboração na sua Daily Scrum:

1- Foco na Meta da Sprint: Lembre-se de que a Meta da Sprint é o compromisso do Sprint Backlog. Sendo assim, é a melhor bússola que os Desenvolvedores podem usar para guiar as suas interações durante a Daily Scrum. Perguntem-se: "Vemos algum obstáculo para alcançar a nossa Meta da Sprint?" e, se a resposta for positiva, "Como podemos removê-lo hoje?"

2- Foco no fluxo: Para promover uma entrega contínua de valor, devemos gerir ativamente o fluxo de trabalho no nosso sistema. Temos algum gargalo em alguma parte do nosso processo? Itens bloqueados? Esquecidos, despriorizados ou simplesmente à espera de algo para poderem avançar? Perguntem-se também: Qual item está há mais tempo no nosso fluxo (incluindo possíveis itens bloqueados)? O que podemos fazer para fazer esses itens avançarem hoje?

3- Foco na entrega de valor: Em vez de se concentrarem nas tarefas a serem desenvolvidas por cada Desenvolvedor, perguntem-se coletivamente: "Quais itens do nosso Sprint Backlog estão mais próximos de serem finalizados?" e "O que podemos fazer para concluí-los hoje mesmo?". Lembre-se de que a ideia de valor é uma suposição até que algo esteja efetivamente nas mãos do utilizador. O que podemos fazer para que isso ocorra o mais cedo possível?

4- Foco na melhoria contínua: Outro ponto de potencial alavancagem das Daily Scrums é serem um checkpoint para ações de melhoria identificadas na Sprint Retrospective, que também podem ter sido incluídas como parte do Sprint Backlog para a Sprint. Desenvolvedores podem perguntar-se: "O que estamos a fazer em relação aos itens de melhoria que identificámos?" e "Há algo mais que podemos melhorar hoje?"

5- Foco em conversas relevantes: Por último, mas não menos importante, certifique-se de que as conversas durante a Daily Scrum sejam focadas na inspeção do trabalho e que o evento não se transforme numa sessão de resolução de problemas. O timebox aqui é o seu melhor aliado. Independentemente do tamanho da sua equipa, esforcem-se para manter o evento dentro dos 15 minutos de duração do timebox. Sessões posteriores podem e muitas vezes são usadas para exploração e resolução de problemas.

E aqui vai um parabéns para aqueles que lembraram que Foco é um dos 5 Valores do Scrum! TODOS os Valores do Scrum podem ser usados para melhorar a qualidade da Daily Scrum (e todos os outros eventos) em geral. 🙂

E então, como vocês usariam os outros 4 valores para melhorar ainda mais a sua Daily Scrum? Que outras ideias já experimentaram nas suas equipas? Qual foi o resultado?

Por: Rodrigo Pinto

Já ouviu falar sobre o papel de um agilista? É comum pensar que ser um agilista é fácil: não é gerente de ninguém, não é responsável pela entrega e não precisa ter uma licenciatura ou conhecimento técnico específico, mas ganha um salário de milhares de euros. No entanto, essa é uma visão superficial do que realmente é ser um agilista!

Recentemente, uma pessoa entrou em contacto comigo no LinkedIn e disse que não esperava lidar com todas as questões que surgem dentro da equipa como agilista, o que me inspirou a escrever este artigo para falar sobre o que não lhe contaram dos desafios de assumir esse papel.

Vamos discutir a realidade deste cargo tão importante no mercado de trabalho atual e as habilidades necessárias para ser um agilista ou Scrum Master de sucesso.

Distorções são um fenómeno presente em diversos mercados, inclusive no financeiro, em que um investimento que parece ser de baixo risco pode gerar um retorno muito alto. No entanto, essa situação não é verdadeira ou tende a equilibrar-se com o tempo. No mercado da agilidade, há também distorções, como a ideia equivocada de que para ser agilista não é necessário ter licenciatura, conhecimento técnico ou responsabilidade pela entrega, mas ainda assim receber um salário de muitos euros por mês.

Essa distorção pode atrair muitas pessoas para a profissão, mas com o tempo, a tendência é que a simetria seja restaurada. É importante que as pessoas compreendam a realidade do trabalho de um agilista e que estejam preparadas para lidar com as questões complexas que surgem na rotina da profissão.

Desmistificando a remuneração do Agilista

Muitas vezes, há uma compreensão equivocada que o papel de Agilista é lucrativo e de fácil acesso, sem exigir responsabilidade sobre entrega ou mesmo formação acadêmica. No entanto, a remuneração desse profissional em Portugal e pode ir de €40K a €80K por ano (fonte Glassdoor.com). É importante desfazer esse mito e demonstrar que a remuneração é influenciada por fatores como expertise, resultados e valor entregue ao cliente e à equipa.

O ônus e bônus de ser um Agilista

O papel exige competências específicas para resolver problemas e conflitos, além de ser capaz de mediar debates e gerir situações difíceis. Um Agilista deve ser capaz de remover impedimentos que afetam o desempenho da equipa, o que muitas vezes envolve trabalhar com equipas externas e lidar com situações complexas.

Além disso, ele deve ser capaz de gerir conflitos internos na equipa, mediar debates de ideias e feedbacks. O papel do agilista no desenvolvimento ágil de software vai muito além de apenas seguir um processo. É preciso ter competências e habilidades específicas para lidar com as pressões e os desafios que surgem no dia a dia de um projeto ágil.

Gerenciamento de conflitos e pressão

A mentalidade de assimetria é prejudicial para o trabalho em equipa e pode gerar conflitos internos. Por isso, é importante que todos os membros da equipa tenham a formação e as competências necessárias para contribuir de forma significativa para o projeto.

Além disso, o agilista precisa estar preparado para lidar com pressões externas, como as dos gestores e stakeholders. Normalmente, estes procuram dar feedbacks e pressionar a equipa para cumprir prazos e metas. Nestes casos, o agilista precisa ter competências de comunicação e liderança para lidar com essas pressões e manter a equipa motivada e focada nos seus objetivos.

Porém, é importante lembrar que a pressão e os prazos fazem parte do desenvolvimento ágil e que o agilista deve estar preparado para lidar com esses desafios. Afinal, a efetividade da equipa é sua responsabilidade e, para alcançá-la, é preciso saber lidar com as dificuldades que surgem ao longo do caminho.

Em resumo, ser um agilista requer muito mais do que seguir um processo. É preciso ter competências de liderança, comunicação e resolução de problemas para lidar com as pressões e os desafios que surgem durante o desenvolvimento ágil. Com estas competências, o agilista pode ajudar a equipa a alcançar os seus objetivos de forma efetiva e colaborativa.

O papel do Scrum Master como líder da equipa ágil

O Scrum Master é uma liderança dentro da equipa ágil e, como tal, deve dar o exemplo e agir de acordo com os valores e princípios do Agile. Isso significa ser responsável pelas entregas, pelo horário e pela organização da equipa. O Scrum Master não pode dar-se ao luxo de chegar atrasado ou não cumprir com as suas obrigações, pois isso compromete a efetividade da equipa e vai contra os ideais do Agile.

Assim, para ser um bom líder dentro da equipa, este Agilista deve chamar as pessoas à responsabilidade, ser um exemplo de comportamento e estar disposto a lidar com a pressão e as dificuldades que surgem no contexto do desenvolvimento ágil. Além disso, é importante lembrar que a liderança não é uma posição de privilégio ou assimetria, mas sim de responsabilidade e comprometimento com o sucesso da equipa como um todo.

A importância do conhecimento técnico para o papel do Scrum Master

Muitas vezes diz-se que para ser Scrum Master não é obrigatório ter formação superior ou conhecimento técnico em desenvolvimento de software. No entanto, isso não significa que o conhecimento técnico não seja importante ou que deva ser negligenciado. Na verdade, ele pode trazer grandes benefícios para o profissional e para a equipa.

Um Scrum Master que entende de desenvolvimento pode ajudar a equipa a lidar com desafios técnicos, a identificar possíveis melhorias no processo de desenvolvimento, a tomar decisões mais informadas e a compreender melhor as necessidades do produto. Além disso, o conhecimento técnico pode ajudar o Scrum Master a comunicar-se melhor com os desenvolvedores, a compreender melhor as demandas da equipa e a ser um líder mais efetivo.

Por isso, é importante que o Scrum Master não negligencie o conhecimento técnico. Isso não significa que o profissional precise ser um programador experiente, mas sim que ele deve ter uma boa compreensão do processo de desenvolvimento e das tecnologias envolvidas.

Além disso, o Scrum Master deve estar familiarizado com diversos conceitos e competências relacionados à agilidade e ao desenvolvimento de produtos, tais como ciclo de vida do produto, OKR, métricas de produto e de fluxo, gestão de portfólio, design thinking, negociação em startup, modelo de negócios, design organizacional, equipas de alta performance, feedback, soft skills, técnicas de retrospectiva, team building e equipas remotas.

Portanto, embora não seja obrigatório ter conhecimento técnico para ser Scrum Master, investir na sua formação técnica e em competências relacionadas à agilidade pode ser um grande diferencial para o profissional e para a equipa que ele lidera.

Conclusão

Em conclusão, é importante lembrar que ser um Scrum Master ou um Agilista não significa apenas ter um título ou uma posição de liderança numa equipa. É necessário comprometimento, responsabilidade e conhecimento técnico para desempenhar bem essas funções. A dinâmica de crescimento de carreira como um Agilista envolve investimento constante em aperfeiçoamento e aprendizagem em diversas áreas, desde competências técnicas até soft skills e conhecimento em gestão de produtos.

É possível sim ter uma boa remuneração e benefícios como um Agilista, mas é preciso estar ciente de que isso vem acompanhado de um grande investimento em si mesmo e no seu desenvolvimento profissional. Sair da dinâmica de assimetria do mercado de trabalho e comprometer-se com um crescimento sustentável e consistente é o caminho para se destacar como um profissional de sucesso no mundo Ágil.

Se está a começar a trabalhar com Kanban agora, é muito importante explorar e dominar os elementos indispensáveis para um quadro Kanban. É importante testá-los e compreendê-los, assim entendendo quais deles fazem mais sentido e em que situações são essenciais à sua implementação e quais não fazem sentido para o seu contexto de trabalho.

Por isso, separamos os oito elementos indispensáveis para um quadro Kanban gerar realmente valor para toda a equipa, para as entregas e para a organização. Confira:

1. Itens de trabalho

Antes de abordar o quadro Kanban em si ou as etapas do fluxo, é importante falar sobre os itens de trabalho, isto é, quais itens serão trabalhados dentro do fluxo e o que são estes itens. De maneira resumida, os itens de trabalho são as unidades de valor dentro do fluxo de trabalho, mas o que elas são de fato vai variar de acordo com cada time. Existem equipes que determinam o item de trabalho como “construir tela X” e outro item sendo “testar a tela X”.

Porém, esta não é a forma mais adequada de se definir o item de trabalho. Isso se deve ao fato de que a equipe tem que pensar no que é solicitado e não exatamente em quais serão as ações para que aquela solicitação aconteça. Por exemplo, quando você vai a um restaurante, você pede um prato e não os processos que levam para que o prato seja feito, certo?!

Para uma melhor compreensão, o item de trabalho é aquilo que é solicitado à equipe e aquilo que é entregue pela equipe, isto é o item de trabalho no Kanban. Dentro deste raciocínio, podem haver vários tipos de itens, como itens de melhorias, itens de correção e outros, isto deve ser compreendido antes mesmo de começar a montar o quadro.

Assista mais sobre esse assunto neste vídeo aqui.

2. Pontos de entrada e saída

Falando no fluxo de trabalho, existe o momento em que uma demanda entra no fluxo de trabalho e passa a ser processada pela equipa, este momento é o Ponto de Entrada. E existe também o momento em que este item de trabalho sai do fluxo, ou seja, quando ele termina de ser executado pela equipa… Este momento é o Ponto de Saída.

É preciso que a equipa possa determinar quais são essas situações, pois isto representa um conceito chave do Kanban: o Trabalho em Progresso ou o Work In Progress - o famoso WIP, como é conhecido em inglês. Ou seja, esses são itens que estão em progresso, que passaram pelo ponto de entrada, porém ainda não passaram pelo ponto de saída e estão no campo de trabalho que está a acontecer.

3. Etapas do Fluxo de Trabalho

Quando um item de trabalho entra no quadro e começa a ser trabalhado, ele irá passar por alguns processos que vão variar de acordo com a equipa e as suas demandas. Portanto, quando este item passa pelo ponto de entrada, a equipa deve especificar com o maior detalhamento possível as etapas que existem, por exemplo: etapa de análise; etapa de teste; etapa de revisão; entre outras.

Isso fará com que a equipa mapeie e execute melhor o fluxo de trabalho. Se um item receber um status apenas de “em processo”, isto faz com que a leitura do quadro Kanban se torne um tanto simplória… afinal, o que de facto significa este “em processo”? Por isso, determinar as etapas do fluxo de trabalho é uma parte indispensável para identificar filas, gargalos e pontos de melhoria no quadro Kanban.

4. Políticas Explícitas

Seguindo este raciocínio citado acima, se os itens de trabalho devem ser separados por etapas, então como definir quando um item irá passar de uma etapa para a outra? É agora que entram as Políticas Explícitas.

São elas que definem quais as regras para que um item se mova de uma etapa para a outra dentro do quadro Kanban. No entanto, não existe regra na hora de criar as Políticas Explícitas. Quais serão essas políticas ficará sempre a cargo da equipa, pois isso varia muito de acordo com cada contexto.

5. Limite WIP (Work In Progress)

Um dos principais elementos do Kanban - fundamental para que a ferramenta gere valor de facto, é o limite de WIP, ou seja, o limite do trabalho em progresso. Ou seja, a equipa deve ter uma capacidade máxima de quantos itens ela pode trabalhar simultaneamente, assim como cada membro desta equipa deve também ter o seu próprio limite de itens de trabalho em progresso.

Dessa forma, a equipa poderá estabilizar o fluxo e estabelecer uma dinâmica de sistema puxado. Lembrando que, geralmente, esse limite é estabelecido por colunas, assim cada etapa do item de trabalho terá uma quantidade máxima de itens simultâneos. E, vale ressaltar que, no Kanban, o limite de itens de trabalho em progresso também é algo que deve ser criado e alinhado pela equipa, tornando-se também uma política explícita.

6. Raias horizontais

As raias horizontais são linhas traçadas ao longo do quadro Kanban e servem para estabelecer um contexto. Elas podem servir como um elemento visual, para separar os itens de trabalho ao longo das etapas. Por exemplo, uma raia pode ser referente a um determinado projeto, enquanto que a raia abaixo se refere a um outro projeto, assim estabelecendo contextos diferentes. Dessa forma, o quadro torna-se mais visualmente compreensível, além de poderem servir até para métricas e/ou políticas explícitas futuras da equipa.

7. Decoradores

São elementos visuais que comunicam algo, servindo quase como uma legenda dentro de um quadro Kanban. Um exemplo de decoradores são os “avatares” que denominam quem está a cuidar daquele determinado item no quadro. Outro tipo de decorador comum também é um sinal de alerta sobre um item de trabalho, podendo representar que aquele item está com um “block”, um bug, etc. Eles também variam de equipa para equipa, conforme a necessidade ou aquilo que os membros julgarem necessário.

8. SLE - Service Level Expectation

Dos elementos citados aqui, este é talvez o mais complexo e, por vezes, o mais negligenciado pelas equipas que usam Kanban há pouco tempo. Como o nome já dá a entender, o Service Level Expectation (SLE) refere-se à expectativa de prazo para realizar uma determinada entrega, desde o momento em que entra no fluxo, até sair do fluxo.

Ele é feito de maneira probabilística e dá o prazo junto com a percentagem de probabilidade de que esta data será cumprida. Para se chegar neste dado, é necessário aceder às métricas da equipa. Através do Cycle Time histórico, a equipa realiza a entrega, analisa o tempo que foi necessário para que o item seja processado e então determina qual o SLE.

Com isto, a equipa chegará a várias informações úteis, como eficiência, expectativas de entrega para o cliente, mensuração do tamanho dos itens de trabalho, entre outras.

E agora, como melhorar?

Claro que, destes elementos, alguns podem ser mais fundamentais do que outros - dependendo do seu contexto. O limite de WIP, por exemplo, quando utilizado de maneira adequada num quadro Kanban, traz excelentes resultados para a equipa e para a empresa.

Se quiser saber mais como potencializar as suas entregas de forma rápida e profissional usando Kanban, clique aqui agora mesmo para saber mais.

menu
Abrir bate-papo
1
Olá 👋
Podemos ajudá-lo?