• • 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.

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.

The post Classificando Histórias de Usuário – Revisitando User Stories no Scrum III appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Costumamos chamar esses itens de alto nível de Épicos. São histórias que dão uma visão geral do pretendido, mas que ainda são muito grandes, no sentido de demandarem muito tempo para sua realização, e contam com poucos detalhes, não possuindo toda a informação necessária para que o time as realize. Um exemplo simples de uma história assim seria O Diretor quer controlar o estoque para otimizar o uso dos recursos financeiros. Essa história é de fácil compreensão ao apresentarmos o novo produto, no entanto demandará muito mais que uma Sprint para ser completada e não possui detalhes suficientes para ser implementada pelo time.

Os épicos precisam ser detalhados com o propósito de permitir o trabalho do time. De uma forma geral, não há a preocupação em trabalharmos como na análise estruturada, guardando o épico e explodindo sucessivamente seus subprodutos. O que fazemos na prática é dividir o épico em histórias menores que cubram todo o desejado no épico, podendo após isso descartá-lo.

Surge então a dúvida mais do que normal: Qual o nível de detalhamento ideal? Que granularidade buscamos? Para responder a isso lançamos mão de um acrônimo proposto por William Wake, INVEST – Independent, Negotiable, Valuable, Estimable, Small e Testable. Vamos olhar sucintamente cada uma dessas características.

Independente

O ideal é que possamos trabalhar em uma história independente das demais. Assim, podemos trabalhar nela a qualquer momento, sem depender de outras. Nem sempre isso é possível, mas deve ser buscado. Ou seja, procuramos minimizar as dependências.

Negociável

Uma história deve poder ser trabalhada em conjunto, pelo cliente e pela equipe. Assim, o conceito deve ser bem definido e os detalhes são resolvidos posteriormente em conjunto. A essência deve ser capturada, deixando os detalhes como parte da implementação.

Valiosa

Uma história tem que prover valor para o cliente. Ao dividir histórias devemos nos preocupar em manter a visão total de sua implementação, de forma que o cliente perceba o seu valor e suporte o desenvolvimento da história. Temos histórias chamadas “técnicas” aonde o cliente tem muitas vezes dificuldade para enxergar valor, mas falaremos sobre isso em outra oportunidade. De uma forma geral, devemos evitá-las, procurando inseri-las como partes de outras histórias onde o cliente perceba valor. Nem sempre isso é possível.

Estimável

Para que o time possa programar o seu trabalho e o cliente possa priorizar a realização das histórias, elas precisam ser estimadas. Quanto maior a história mais impreciso e difícil é estimar.

Pequena

Histórias devem ser pequenas. Devem poder ser feitas com poucos homem-hora, alguns dias de trabalho somente. Adicionalmente, pequenas são estimadas mais facilmente e com maior precisão.

Testáveis

Tudo o que é feito pelo time deve poder ser verificado e validado. Um bom exercício é definir o teste antes de trabalhar na história. Se há dificuldade em definir testes, a história pode não ter sido bem entendida ou estar no nível de abstração incorreto.

É fundamental para todos da equipe Scrum entender que o trabalho é realizado por histórias e, portanto, a qualidade das mesmas definirá a eficácia e a eficiência da equipe. Ainda, o trabalho na definição das histórias, as necessárias discussões e levantamentos, e outras atividades correlatas, servem para a aquisição de conhecimento pelo time, e até pelo próprio cliente.

Voltando ao nosso simples exemplo inicial, poderíamos substituir nosso épico O Diretor quer controlar o estoque para otimizar o uso dos recursos financeiros  por:

• Diretor deseja registrar a entrada de mercadorias para permitir as vendas e limitar o uso do almoxarifado
• Vendedor precisa registrar a saída de mercadorias para permitir a reposição do estoque
• Controlador deseja verificar e ajustar a quantidade de mercadoria existente para efetuar o balanço de material

Histórias menores, que cobrem a necessidade inicial apresentada no épico, e permitem e orientam o trabalho do time. Com histórias assim, atendendo ao INVEST, será mais fácil estimarmos.

No ScrumHalf você pode classificar histórias como Épico. Você consegue dividir suas histórias dessa maneira? Qual a sua maior dificuldade? Conte para a gente. Quem sabe não pensamos em algo juntos…

Nos próximos posts da série falaremos mais sobre estimativas, características/tipos de histórias, e outros assuntos mais avançados. Continue nos acompanhando. Até breve e bom Scrum!

The post Como Particionar Épicos? INVEST – Revisitando User Stories no Scrum II appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.