O Time Scrumhalf procura sempre colaborar com o ecossistema de startups e de agilidade, ajudando as empresas e demais interessados em transformação ágil, e demonstrando como o apoio de pessoal qualificado e a utilização de ferramentas adequadas podem fazer a diferença na transição de um negócio.

Foi uma mentoria dinâmica e bastante abrangente. As empresas participantes apresentaram suas questões sobre agilidade e como implantar em suas empresas, aproveitando a experiência do nosso CEO, José Augusto, para tirarem suas dúvidas. Aproveite e conheça o SEED-MG e algumas de suas startups. Muitas soluções bacanas sendo construídas, algumas já em plena operação.

The post Mentoria no SEED-MG appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

• • Você realmente usa o Scrum?
  • O quão aderente você é ao framework?
  • Suas equipes têm dificuldade em lidar com os conceitos do Scrum?

As repostas a essas perguntas determinam o quanto essa nova versão do guia pode ter influência no que você e sua equipe fazem.

No dia do lançamento os autores, demais responsáveis e diversos especialistas fizeram algumas lives sobre a nova versão. Participamos de algumas para colher visões diferentes e opiniões sobre o assunto.  Vamos discorrer sobre as principais mudanças e ao final discutir um pouco o que ocorreu.

O Novo Guia

O guia propriamente dito encolheu. Saiu de mais de 20 páginas para 16. Além disso, foi lançado com o propósito de democratizar o Scrum, ou seja, a linha mestra de seu lançamento foi a sua redução e alguns ajustes que foram feitos para permitir que o guia seja utilizado por outras atividades que não desenvolvimento de software. Ou seja, a principal ideia da redução do tamanho, e que também se manifestou em outros aspectos, é tornar o guia menos prescritivo, focando mais em sua essência ágil. Um exemplo claro disso é o caso da Reunião Diária. Em sua nova versão desaparecem as 3 perguntas basilares dessa reunião – o que fiz ontem, o que farei hoje e obstáculos encontrados – para focar na sua essência como uma reunião de micro-planejamento de atividades.

Da mesma forma, os autores acreditam que as modificações agora introduzidas tornam o guia mais abrangente, no sentido de comtemplar outras áreas, que não somente a TI, visto que atualmente o Scrum já é largamente utilizado em outras atividades que não sejam desenvolvimento de software.

As seguintes alterações realizadas merecem destaque.

Time

Agora temos somente um time: o Time Scrum. Anteriormente o Time era definido por um PO, um SM e o Dev Team (ou time de desenvolvedores). Em sua nova versão, o Dev Team dá lugar aos “Devs” (desenvolvedores). Assim, um Time Scrum passou a ser formado por PO, SM e Devs. Time agora só existe um. Uma tentativa de diminuir as barreiras internas e aumentar o comprometimento do grupo como um todo, promovendo a coesão.

Papéis e Responsabilidades

Seguindo a mesma toada, os papéis que já eram definidos por responsibilities agora se resumem a accountabilities.  Em português ambos os termos seriam definidos como responsabilidades. No entanto, segundo os autores, o termo Papel (Role) foi removido pois estava sendo incorretamente usado como cargo em muitas organizações. De certa forma me parece que novamente se buscou a flexibilidade. Ao remover o Papel e definir responsabilidades para participantes do time, abriu-se também a possibilidade de haver outras responsabilidades associadas aos participantes do Time, além das definidas no guia. Entretanto, o Time continua sendo formado por um PO, um SM e Devs.

A Meta do Produto

Visando evitar que o Time seja um fabricante de features simplesmente, rodando Sprints com o objetivo de executar o máximo possível de trabalho, eventualmente perdendo a perspectiva de real valor para o cliente, o guia agora introduz o conceito de Meta do Produto. A Meta do Produto serve para manter o time orientado ao que efetivamente o cliente deseja – Foco.

Ao mesmo tempo, isso permite também a criação de boas Definições de Concluído – DOD (Definition of Done) – utilizadas para avaliação do incremento do produto, visto que devem ser sempre criadas com a visão do atingimento da Meta do Produto.

O guia agora deixa claro que para cada um dos artefatos seguintes há uma orientação associada: Product Backlog orientado à Meta do Produto; Sprint Backlog orientado à Meta da Sprint; e Incremento orientado à Definição de Concluído. Se você usar o Scrumhalf, já tem lugar para tudo: Product Goal na descrição do projeto, Sprint Goal na descrição da Sprint, e DOD nas configurações do seu projeto.

Ainda no mesmo caminho, o de dar transparência e gerar foco, o guia passa a incluir no planejamento de uma Sprint, além das costumeiras questões de o que fazer e como fazer, a necessidade de se mostrar o porquê fazer. Isso demonstra o compromisso do Scrum em promover o alinhamento de todo o Time em uma só direção.

Auto-gerenciamento

Em suas versões anteriores o guia definia que a equipe, ou os Devs, eram auto-organizados. Desta feita, o guia passa a definir a equipe como auto-gerenciada, de certa forma estabelecendo que a própria equipe pode definir quem executará cada uma das tarefas. Talvez passe só como uma reescrita, mas pode vir a ter outras consequências. Vamos ver como será o impacto dessa mudança, se houver.

Nossa Impressão

É sem dúvida louvável a redução do tamanho do guia, bem como a intenção de torná-lo menos prescritivo. As mudanças de uma forma geral são simples e eficazes, mesmo que sejam de certa forma somente uma nova roupagem para práticas existentes, como no caso da mudança de auto-organizada para auto-gerenciada.

A grande decepção, no entanto, ficou por conta da abrangência do guia, principalmente no que diz respeito ao linguajar utilizado. Durante o seu lançamento, tivemos a oportunidade de perguntar, por exemplo, “porque o guia insistia em Devs, se isso é um termo exageradamente TI”. A resposta veio bem aquém do que se esperava. Os debatedores alegam que vários Times de diversas áreas foram consultados e que os profissionais se consideravam Devs, ou seja, desenvolvedores, porque desenvolvem algum tipo de produto ou serviço. Sinceramente, não convenceu. Agilistas que trabalham com equipes que não são de desenvolvimento de software sempre encontram dificuldade ao ter que utilizar termos diferentes do que está definido no Scrum, para poderem melhor adaptar o framework à realidade de suas áreas. Uma real modificação nesse sentido seria muito bem vinda.

Finalmente, considerando o mercado atual e a própria organização do trabalho no Scrum, o efeito da remoção dos papéis, substituindo-os por responsabilidades somente, terá pouco efeito prático, em nossa opinião. Acabará servindo para patrocinar acaloradas discussões na rede, pelo menos. Basta, p.ex., dar uma olhada nessas definições de responsibilities e accountabilities.

Espero que o feedback dos utilizadores venha a influenciar uma próxima versão do guia, tornando-o realmente mais adequado a outras áreas profissionais.

Você já leu o novo guia? O que achou?

The post O que mudou no Scrum? Scrum Guide 2020 – 5 Pontos Principais appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Normalmente algumas preocupações se destacam: como conseguiremos coordenar o trabalho estando o time distribuído? Como conseguiremos trabalhar sem a mesma interação social que tínhamos no ambiente de trabalho único? E o impacto para as pessoas?

A agilidade, especialmente o Scrum, que recomenda que os times trabalhem juntos, em um mesmo local, pode obviamente ser adaptada para que esse local seja “construído” virtualmente. Bastam algumas ferramentas e acordos entre o time, para que tudo funcione bem, até melhor do que antes, no que diz respeito à produtividade.

Recentemente, em uma edição do Agile Beer, levantamos esse debate e foram muitos feedbacks de profissionais de empresas espalhadas pelo mundo. Procuramos organizar tudo e juntando com outros relatos apresentados em artigos que acessamos, preparamos um compêndio de sugestões para te ajudar a tratar com facilidade essa novidade. Nem tudo precisa ser implementado. Aliás, algumas soluções se sobrepõem. Selecione e adapte as que melhor ajudarem suas equipes.

Faça reuniões virtuais, mas limite a quantidade

Muitos profissionais reclamam do aumento de reuniões no trabalho remoto. Natural, pois algumas reuniões que eram presenciais e o profissional nem passava perto, agora vão direto para o seu desktop. Ficou mais difícil dizer que não vai poder ir, pois agora a reunião vem. Além disso, ficou mais fácil marcar reunião, pois não precisa sala, recurso audiovisual ou providenciar água e café. Cada um que se vire.

Reuniões demais cansam o time e afetam negativamente a produtividade. Um bom caminho é combinar com o time o que demanda reunião, estabelecer limites para a duração das necessárias, e até fixar um dia/período específico para reuniões que não sejam já previstas no processo de trabalho adotado.

Estabeleça um horário confortável e comum

O trabalho remoto na residência acaba por mudar tanto a rotina do indivíduo como a do seu lar. Adaptações nos horários e interações familiares acabam sendo necessárias. Porém, nem todas as famílias são iguais e tem as mesmas demandas. Não dá para ficar marcando reuniões ou tentando trabalhar junto sempre no horário que te agrada. Pode ser que esse horário não agrade aos demais do seu time.

Uma boa prática é estabelecer um horário diário em que todos do time devem estar disponíveis para o trabalho, um horário comum, que facilite a troca de informações, mas não incomode demais a rotina das pessoas. Afinal de contas, agora a casa é a empresa e a empresa é a casa. Reúna seu time e acorde esse horário. Defina um horário para trabalho, mesmo que reduzido, mas onde todos possam interagir à vontade. Defina intervalos bondosos para refeições, de modo que atenda aos diversos lares.  Isso vai diminuir a ansiedade do seu time e permitir que todos consigam organizar melhor as suas vidas.

Crie ambientes comuns

Algumas empresas fazem com que os seus colaboradores todos se conectem do início ao fim da jornada de trabalho utilizando uma ferramenta de comunicação. As vezes até utilizando vídeo. Isso pode acabar sendo um pouco over, e passar um sentimento de desconfiança e tentativa de controle muito ruim para todos. Se alguns se sentirem incomodados dessa forma, e isso despertar uma polêmica que pode ir da concepção do Pan-óptico ao efeito Hawtorne, algumas alternativas podem ser tentadas.

A existência de ambientes comuns para trabalho e descompressão pode ajudar. Algumas empresas têm adotado algumas soluções nesse sentido como:

• Criação de uma sala comum de trabalho, sem obrigatoriedade de conexão, simplesmente provendo um espaço virtual que as pessoas podem utilizar quando julgarem interessante;
• Realização de uma reunião diária, a exemplo do Scrum, em sala virtual comum a todos. Isso dá a oportunidade para as pessoas participarem de uma breve interação, combinarem encontros virtuais posteriores se necessário, e coordenarem seus esforços, sem tornar a reunião algo invasivo, visto a sua brevidade;
• Criação de uma sala de café virtual, onde os membros da equipe se conectam quando querem tomar um café e relaxar um pouco. Isso tenta substituir o “cafezinho”, tão comum no nosso ambiente de trabalho, aonde assuntos diversos são conversados.

Disponibilize os equipamentos e ferramentas necessários

Nem todos do seu time tem os recursos adequados para trabalhar de casa. Alguns precisam de uma cadeira melhor, outros de uma câmera, alguns até de uma mesa ou uma conexão Internet melhor. Verifique com o seu time o que lhes falta para o trabalho remoto e tome as possíveis devidas providências. Para muitas empresas o custo de manutenção dos locais de trabalho tradicionais reduziu bastante, permitindo um apoio maior aos seus times. Adicionalmente, os indivíduos passaram a ter custos que eventualmente não tinham. A empresa podendo, deve ajudar. Se não puder, converse com o time e faça os devidos acordos.

Nesse novo cenário, algumas ferramentas podem ajudar bastante na coordenação e organização. O ScrumHalf, p.ex., possui todos os recursos para apoiar o trabalho remoto, desde Backlog, Quadro Kanban virtual, facilidades para conduzir reuniões de Revisão e Retrospectiva, recursos para fazer o planejamento de entregas remotamente, e até salas de chat restritas aos projetos – War Rooms – para a interação da equipe e registro das conversas. O trabalho remoto acaba exigindo uma maior documentação das decisões e recursos como esse podem facilitar muito a vida do seu time.  Softwares adicionais de comunicação, principalmente de videoconferência, certamente serão necessários.

Atenção à Documentação

A interação do time agora será um pouco mais caótica, mesmo você tendo tomado alguns cuidados como descrito acima. Como visto, nem sempre as pessoas estarão disponíveis integralmente no seu horário de trabalho e a ausência de alguma informação pode criar um impedimento desnecessário. O melhor nessa nova realidade é dar um pouco mais de atenção à documentação, sempre lembrando que alguém mais do time poderá precisar trabalhar no que você está trabalhando agora. Sempre se pergunte o que você precisaria saber se fosse trabalhar naquela tarefa sem conhecer profundamente o problema. Que informações você precisaria? Elas estariam registradas em algum lugar já? Se positivo, indique. Caso negativo, registre-as.

Priorize Histórias Técnicas

É claro que você está construindo um produto ou executando um serviço para o seu cliente e você precisa entregar valor tangível para ele. Mas todos sabemos que qualquer projeto acaba acumulando histórias técnicas, que mesmo não sendo de percepção direta para o cliente também estão produzindo valor para ele. Se possível e não for comprometer as entregas a serem feitas, procure colocar na frente histórias técnicas. Pelo menos até a sua equipe se sentir mais à vontade com o trabalho remoto e com a interação remota com o cliente. Histórias técnicas demandam menos interação e podem inclusive ajudar o time a ganhar confiança no novo modelo de trabalho.

Esteja Presente para o seu Time

Deixe claro para o seu time que você está sempre pronto para ajudá-los. Independentemente dos horários acordados, combine que, se houver alguma emergência ou algo que prejudique realmente o andamento do trabalho, e que você possa ajudar a resolver de alguma forma, o acordo pode ser rompido e podem te chamar.

Se necessário, estabeleça no acordo um código de cores. No horário verde a chamada é livre, no amarelo somente se houver impacto sensível no resultado e no vermelho somente se for uma emergência mesmo. Dê exemplo de cada um dos casos, para ajudar o seu grupo a entender como se comportar. É importante para todos saberem que há suporte e que o fato de estarem fisicamente isolados não significa que estão largados e precisam resolver tudo sem auxílio de ninguém.

A realidade que vivemos demanda resiliência e criatividade. Mais do que manter a produtividade da nossa equipe, devemos contribuir para seu bem-estar e satisfação. Em um momento de dificuldades é que as verdadeiras oportunidades se revelam. Aproveite para melhorar a qualidade de vida no trabalho, mesmo sendo remoto. Sua ajuda e interesse podem fazer toda a diferença com o seu time.

E você que já está remoto, que prática você utiliza para tornar esse trabalho remoto agradável e interessante? Conte para a gente nos comentários.

The post Trabalho Remoto – 7 Dicas para Ajudar o seu Time appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Acho que realmente alguns Devs têm a visão alinhada com o expressado pelo autor no seu artigo, e, por isso, resolvi debater um pouco mais os tópicos por ele elencados. Entendo que algumas pessoas possam realmente encontrar nesses tópicos motivos para “detestarem” o Scrum, mas acredito que uma outra visão sobre tais razões possa transformar esse ódio em amor.

A análise feita por Willem-Jan Ageling, autor do artigo, foca em novas responsabilidades encaradas pelo Dev ao trabalhar usando Scrum. Melhor então darmos uma olhada nessas “novas” responsabilidades, dissecando o problema para entendê-lo melhor.

• No Sprint Planning – Determinar uma meta do Sprint, em cooperação com o Product Owner. A equipe de desenvolvimento precisa avaliar se eles podem cumprir a meta do Sprint, pois isso impulsiona o Sprint

Será que existem equipes tradicionais, ou não-ágeis, onde o gerente não pergunta sobre prazos, ou o que será possível ser feito até determinada data de entrega? Sinceramente, nunca vi isso acontecer. Muito pelo contrário. Sempre presenciei esse questionamento ser feito de forma repetitiva, gerando inclusive discussões acaloradas, e roubando o tempo, e muitas vezes a tranquilidade, do time. Essa questão nunca pode ser abandonada, pois não há como uma organização, que estabelece metas e objetivos, trabalha com KPI e OKR, não ter alguma ideia de quando chegará aonde. Na verdade, acho que o Scrum ajuda muito o time nesse sentido, definindo um momento específico para tal discussão, de certa forma limitando-a, e evitando que roube mais tempo do time.

• No Sprint Planning – Criar um Sprint Backlog. Isso envolve selecionar os itens do Backlog do produto que ajudam a cumprir a meta do Sprint e criar um plano para entregá-los.

Na realidade, entendo que o Dev Team somente ajuda o PO, ou esclarece suas dúvidas, para que ele selecione as histórias a serem contempladas. É de interesse maior do PO e de sua responsabilidade definir uma meta com o time e definir o que será feito para cumprir tal meta. Já com relação ao plano necessário, acredito que haja dois aspectos. O primeiro é que essa prática de planejar o que irá ser feito no curto prazo é extremamente produtiva. De uma forma geral, ela evita o “hacking”. Ou não conhecemos Devs que ao ouvir a primeira notícia sobre alguma necessidade do cliente já querem sentar e sair programando? Esse pequeno planejamento, ajuda sensivelmente a evitar o efeito toupeira e fomenta a colaboração e a coordenação entre os membros do time, sob pena de ao não fazê-lo gerarem retrabalho e terem muita dificuldade de coordenação. Ou seja, na minha visão, tal responsabilidade sempre existiu. Apenas, algumas pessoas, ou times, esquecem da sua necessidade e acabam pagando um alto preço posteriormente.

• Durante a Sprint – Garantir que os Itens do Backlog do Produto atendam à Definição de “Done” (DoD) e aos critérios de aceitação.

O time poderia trabalhar de forma diferente? Isso me parece ser inerente ao trabalho do Dev. Senão deixou o Dev de estar trabalhando para satisfazer a necessidade de algum cliente, para ser um diletante.

• Durante a Sprint – Certificar-se de que o Backlog do Sprint sempre mostra o estado atual do progresso do trabalho nos Itens do Backlog do Produto e no plano da Sprint.

Essa responsabilidade não me parece trabalho extra, mas somente uma questão de disciplina, atenção ao framework e utilização de ferramenta adequada. A reunião diária, já prevista no Scrum e que não deve ser abandonada, já tem como parte do seu escopo a apresentação do fiz, farei e problemas. Isso, por si só já permite uma atualização da situação dos trabalhos. Se, adicionalmente, o time usar uma ferramenta para acompanhamento, como o próprio Scrumhalf faz, onde as tarefas trabalhadas sejam atualizadas pelo próprio realizador e gerem automaticamente informações, como o gráfico de Burndown, a transparência e a visibilidade ficam garantidas, sem nenhum esforço extra.

• Na Daily Scrum – Avaliação diária do progresso em direção ao objetivo do Sprint. Isso inclui a atualização do plano conforme refletido no Sprint Backlog.

Realmente, a Reunião Diária – Daily Scrum – é algo que toma um tempo do time. Mas, no entanto, esse tempo, que deve ser muito curto, em torno de 15 minutos ou menos, seria muito maior caso o projeto contasse com um gerente formal e os membros do time tivessem que fazer seus relatórios de andamento para ele. Adicionalmente, é fundamental lembrar que a Reunião Diária é o que viabiliza a auto-organização do time, diminuindo os tradicionais atritos com a gerência e aumentando a satisfação no trabalho.

• Na Revisão da Sprint – Discutir a Meta da Sprint e como eles conseguiram alcançá-la.

Isso realmente não é algo comum fora do Scrum. Entretanto, além de tal discussão não dever tomar muito tempo, deve-se lembrar que, entre outros motivos, essa discussão promove a transparência e acaba evitando, ou substituindo, as constantes discussões e debates do time com a gerência, quando usando uma gestão não-ágil.

• Na Revisão da Sprint – Mostrando o que eles criaram e respondendo perguntas.

Nunca vi isso ser deixado de lado também. O Dev não pode só codificar e esquecer. A não ser que hajam outros membros para fazer a demonstração das funcionalidades implementadas, anotação de eventuais bugs, etc. A vantagem no Scrum é que isso é feito de forma organizada, mais rápida, e contando com a participação de todo o time permite que todos fiquem atualizados, reduzindo a solução de continuidade no trabalho em tarefas subsequentes.

• Na Revisão da Sprint – Participar da discussão sobre o que fazer a seguir.

Apesar de sempre ter promovido esse tipo de discussão nos projetos que participei, especialmente nos que gerenciei, antes da agilidade, reconheço que muitas vezes o time é deixado de lado no momento dessa discussão. No entanto, em função disso, é normal o time perder muito tempo depois, reclamando e discutindo porque algo está sendo feito. Ou seja, o exercício de pensar o que deve, ou deveria, ser feito é efetivamente realizado. A grande diferença aqui é que o dev poderá exteriorizar o seu pensamento e ouvir o dos demais companheiros. E, deve-se lembrar, a responsabilidade, como a maioria delas no Scrum, é coletiva, do time, não individual.

• Na Retrospectiva da Sprint – Inspecionar como foi a Sprint e criar um plano de melhorias.

Essa realmente é diferente. Kaizen, ou melhoria contínua, é uma responsabilidade que o Scrum leva muito a sério. Demanda um pequeno tempo do time, mas traz benefícios enormes, inclusive permitindo que ao longo do tempo cada vez mais o Dev foque na sua atividade principal, visto que o “processo” em si está funcionando bem. Cabe ao Scrum Master tornar essa cerimônia produtiva e agradável. Seus resultados, que em um caminho não-ágil também deveriam ser apontados por uma boa gerência, sempre serão implementados da mesma forma, independente do modelo de gestão. Quero dizer com isso, que se algo precisar ser mudado, revisto, terá que sê-lo. E alguém terá que fazer o serviço.

• Criação e manutenção da Definição de “Pronto”.

Verdade. Agora o time deve se preocupar com isso. Mas vejamos bem. A definição de pronto, pelo menos na cabeça do Dev, já existe. Senão, como ele iria parar de trabalhar em algo? A diferença aqui é que agora o time, frisando que é o coletivo, deve criar uma definição compartilhada, que seja entendida por todos. E, na verdade, isso que inicialmente pode parecer algo pesado, após negociado evita uma série de conflitos e é de fácil manutenção, podendo, p.ex., ser um subproduto, quando necessário, da Retrospectiva.

• Aprender, explorar e incorporar os Valores Scrum de Coragem, Compromisso, Foco, Abertura e Respeito.

Isso só ocorre, ou pelo menos de forma marcante, no momento da transição de um método não-ágil para o Scrum. É, nesse momento da transição, uma mudança cultural importante. Mas depois de algum tempo passa a fluir no sangue dos agilistas e não é nenhum fardo. Afinal de contas, a vida não é mais bonita assim?

Para resumir, montamos a tabela abaixo. Nesta tabela, representamos cada uma das responsabilidades, na mesma ordem do texto, e procuramos indicar a necessidade de sua adoção em um projeto qualquer, independente do modelo de gestão utilizado. Ao lado, procuramos demonstrar o impacto caso seja negligenciada. Em Scrum, procuramos mostrar a principal influência do Scrum no trato da responsabilidade e, finalmente, indicar aoned uma ferramenta pode facilitar sensivelmente o trabalho do time, caso seja aderente ao Scrum. Essa tabela é empírica, sem rigor científico, sendo somente fruto do que observamos ao longo dos projetos que participamos, direta ou indiretamente. O único propósito dessa tabela é compilar os dados, sob a nossa ótica, relativos a uma lista tão extensa, sintetizando-os, de maneira ainda que superficial, para permitir uma visão global por parte do leitor.

Bem, procuramos acima complementar a análise feita pelo colega Willem, visando dar aos Devs, ou a qualquer elemento de um time Scrum, uma outra perspectiva sobre as suas “novas” responsabilidades. O uso de elementos adicionais no time, para cuidar de determinados aspectos, ou a redistribuição de algumas atividades, podem sem dúvida ajudar, aliviando algum trabalho. Evidentemente, descontado o aspecto comunicacional deixado claro por Fred Brooks, em seu livro seminal The Mythical Man-Month, mais gente normalmente ajuda a deixar o fardo mais leve.

Concluindo, acho que o principal ponto é que o Scrum na verdade arruma uma série de coisas que na realidade já são realizadas de outras formas em atividades não-Scrum, e, quando acrescenta algo, é porque realmente é necessário e traz benefícios muito grandes para o time, e em última análise para o próprio Dev. Você consegue pensar fora da caixa e enxergar esses aspectos de forma positiva também?

The post Conheça 11 Motivos para o seu Time Amar o Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.