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.

Olá pessoal,

o post que trago hoje é adaptado do original "Five Things a Product Owner Needs to Know", disponível nesse link.

Muitas vezes a importância do papel do Product Owner (PO) pode acabar sendo menosprezada em relação aos outros atores presentes em um projeto Scrum. Se isso acontecer, é certo que o projeto não terá o sucesso esperado, por isso esse papel é tão importante quanto os demais e é preciso que o profissional esteja apto a desempenhá-lo.

Todo o texto desse post é direcionado para o PO e traz 5 dicas que com certeza irão contribuir para o sucesso no desempenho de seu papel em projetos Scrum. Vamos direto a essas dicas!

1. Confiança é a chave

o PO detém o conhecimento das regras de negócios das histórias do backlog. Porém, por não possuir experiência de desenvolvimento, pode ser que existam histórias no backlog com conhecimentos técnicos que sejam difíceis de entender. A dica aqui é contar com o apoio da equipe de desenvolvimento para explicar os detalhes técnicos de tais histórias, para que o PO possa priorizá-las corretamente.

E mais, se a equipe de desenvolvimento (a partir daqui irei chamar de “time”) sugerir mudanças que o PO pode não ter pensado, provavelmente elas trarão benefícios que podem acelerar o desenvolvimento, tornar o código mais confiável, aumentar a performance do produto. Ou seja, ouvir o feedback do seu time, pois ele pode ser um complemento valioso para o produto.

2. O trabalho do PO é servir o time

O objetivo final do desenvolvimento é lançar um excelente produto em tempo. O PO deve tentar estar disponível e responder o quanto antes às dúvidas da equipe.

Se o time está trabalhando com Sprints de 2 semanas (10 dias de trabalho), imagine que se houver um impedimento que paralise o trabalho por 1 dia pode significar que 10% do tempo disponível para o trabalho foi jogado fora.

3.    Perspectivas de usuário são essenciais

É essencial para o PO entender as pessoas que irão usar o produto. Quanto melhor for o entendimento do usuário final, melhor poderá ser o direcionamento do produto, suas funcionalidades e regras de negócio. Nada é mais importante do que o tempo gasto entendendo o usuário final.

Embora pareça difícil, o objetivo é conseguir atingir o melhor equilíbrio entre o que você sabe que o produto precisa e o que é valor para os usuários.

4.    Às vezes o time falha

Mesmo que o time seja muito produtivo em uma Sprint e esta seja um sucesso, isso não significa necessariamente que a próxima também será. Os altos e baixos do processo de desenvolvimento são normais, imprevisíveis e podem ocorrer devido a diversos fatores internos e externos.

A verdade é que o sucesso ou falha da Sprint não é tão importante quanto à capacidade do time de entregar valor. Portanto, não há porque se desesperar se nem todas as histórias forem aprovadas ao final de uma Sprint.

Equipes Scrum estão sempre tentando melhorar a cada Sprint. O PO deve confiar no seu time e ter consciência que eventualmente as falhas podem ocorrer porque eles resolveram testar novas técnicas, ou definiram uma meta muito ambiciosa.

5.    PO é diferente de gerente de projeto

Essa dica é para que o PO não queira tentar abraçar o mundo todo com seus braços. Isso é impossível!

O PO não precisa e não deve se preocupar com o calendário do time, como eles alocam seus trabalhos, ou como planejam as Sprints. Seu trabalho é somente definir as prioridades e prover feedback as necessidades do time.

Somente os desenvolvedores entendem completamente os detalhes de seu trabalho. Se o PO tentar controlar aspectos do desenvolvimento além dos que foram aqui mencionados, então o projeto pode estar fadado a um alto nível frustração e infelicidade.

Deixar o time ser auto-organizável e confiar em sua maneira de trabalhar irão poupar tempo e tornar mais fácil a vida e o trabalho de todos.

Gostou das dicas? Discorda de alguma? Tem mais alguma a acrescentar? Sinta-se convidado a comentar e compartilhar seus pensamentos e ideias conosco.

Até o próximo post!

The post O que o Product Owner precisa saber appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá a todos! 

Hoje vamos falar sobre um tema muito controverso e, por vezes, muito criticado dentro do Scrum. Vamos falar sobre formas de utilizar o Scrum sem algumas das cerimônias que são preconizadas pelos criados do método. Essa forma de utilização já ganhou até apelido no mundo ágil, o ScrumBut. Neste Agile Brazil, estivemos com o palestrante Alexandre Magno, e ele falou sobre o assunto, então vamos lá.

Vamos começar com uma definição, segundo a revista Engenharia de Software Magazine 50:

“ScrumBut ocorre quando o Scrum expõe uma disfunção ou uma falha difícil de ser corrigida e que leva a empresa a modificar o Scrum com o intuito de tornar invisível o problema”

Normalmente as empresas saem dos métodos tradicionais de engenharia de software e passam a usar o Scrum acreditando nas melhorias e benefícios da agilidade, entrega contínua, adaptação e correção rápida, e todos os preceitos que conhecemos. Mas como podemos descobrir se alguma das cerimônias do Scrum pode estar atrapalhando o pleno funcionamento da organização?

Em primeiro lugar, não podemos retirar algo do Scrum só porque achamos ruim, ou chato, ou demorado. Tudo deve ser medido. Nada que não é medido não pode ser confirmado como problema. Isto é, se você não tem certeza que uma reunião ou outra atrapalha o andamento de um projeto, não ache que retirando essa reunião o andamento do projeto correrá bem. Tudo deve ser medido e devidamento documentado.

Uma ideia, que já foi aplicada aqui na empresa, foi levantar uma hipótese e testá-la. Em um dos projetos aqui, a hipótese levantada foi de que o planning 2 tradicional não tinha efeito prático no andamento das histórias. No caso do projeto em questão, a equipe estava trabalhando em histórias distintas, que é outro ponto que diferencia do Scrum tradicional, e as histórias não tinham uma especificação clara. Por isso, eles precisavam especificar as histórias ao decorrer da Sprint. Resumindo, eles estavam fazendo o planning 2, mas eles faziam durante a Sprint. Depois disso tudo, eles puderam verificar uma melhoria nas entregas.

Eles conseguiram identificar um problema, uma “falha” no Scrum, embora eu ache o termo falha muito forte. Com isso, podemos ver que o Scrum aceita mudanças. O Scrum é um framework e adaptação é seu lema. Então porque não podemos adaptar o framework? Mas é claro que isso deve ser feito com cautela.

A comunidade scrum.org descreve uma sintaxe particular para o ScrumBut, da forma:

(ScrumBut)(Razão)(Solução)

Vamos verificar como isso funcionaria no caso citado acima:

“(Nós usamos Scrum, mas)(não precisamos nos reunir no inicio da Sprint para fazer o Planning 2)(pois fazer ao decorrer da Sprint foi mais vantajoso e prático)”

Outros casos válidos, já testados aqui foram:

“(Nós usamos Scrum, mas)(histórias de design nem sempre são bem definidas)(então algumas histórias não precisam de definição de pronto)”

Mas é claro que, casos como esses devem ser evitados:

“(Nós usamos Scrum, mas)(não fazemos reunião diária)(porque é chato e parece ser perda de tempo)”

“(Nós usamos Scrum, mas)(retrospectiva são perda tempo)(então não fazemos)”

Claro que devemos estudar cada caso cuidadosamente. O que funciona aqui na empresa, pode não funcionar na sua empresa e assim por diante.

E você na sua empresa? Faz algo um pouco diferente do Scrum? Compartilhe com a gente como foi sua experiência.

The post Você conhece o ScrumBut? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No post de hoje eu divido com vocês um pouco da minha experiência de dois anos em uma equipe que trabalha em tempo parcial.

A primeira pergunta a surgir, dos mais incrédulos, poderia ser: mas isso funciona?

Eu respondo. Sim!! Isso funciona!! O grande segredo é como fazer para funcionar.

Mas vamos por partes. Primeiro, vamos listar alguns riscos que são comuns de ocorrer devido a essa condição.

• A) Somente um membro da equipe tem conhecimento sobre uma determinada funcionalidade, e esse membro não se encontra quando o restante da equipe precisa dele;
• B) Momentos em que nenhum membro da equipe que trabalhou no dia anterior se encontra presente no dia atual para participar da reunião diária e dizer o que aconteceu no dia anterior;
• C) Membro da equipe se encontra sozinho para tomar decisões importantes.

Bem, para superar esses riscos e conseguir fazer o Scrum funcionar, nesse cenário, precisaremos estar atentos a alguns valores:

– Comunicação: É necessário que haja uma comunicação muito clara dentre todos os envolvidos no projeto, mas sobretudo dentre os membros da equipe. Esse precisam estar em um nível EXCELENTE de comunicação. Não pode haver aquele pensamento de "será que devo dar minha opinião?". Sim! Você deve dar sua opinião! Todos querem ouvi-la. Não pode haver dúvidas e todos devem estar com o mesmo entendimento sobre tudo para poder seguir pelo mesmo caminho, mesmo quando nem todos estiverem presentes. Lembre-se que existirão momentos em que o caminho deverá ser seguido somente por você, que estará sozinho. Portanto, nunca saia de uma Reunião de Planejamento ou Reunião Diária com alguma dúvida.

– Transparência: Está ligado ao ponto anterior. Não deve haver segredos e tudo deve ser compartilhado dentre os membros da equipe.

– Combinados/Regras: Para que o processo funcione provavelmente será necessário estabelecer alguns combinados. Em meu projeto por exemplo, combinamos que, sempre que uma pessoa vai pra casa e não finalizou a história em que estava trabalhando, e não irá trabalhar no dia seguinte pela manhã, esta deve avisar a todos da equipe o que ela fez, o que falta fazer e quais foram as dificuldades encontradas. Para avisar utilizamos o e-mail ou o a descrição da própria tarefa no Scrumhalf. Dessa maneira, outro membro da equipe poderá dar prosseguimento no dia seguinte.

– Comprometimento: Esse valor é importantíssimo para que qualquer equipe Scrum funcione. Em equipes de tempo parcial eu diria que é essencial.

– Scrum Master disponível: O que fazer quando você está sozinho, tem uma série de atividades a fazer, e vai precisar de alguma informação ou recurso? Apele para o Scrum Master! Ele vai tentar se comunicar com quem precisa (seja membro da equipe ausente ou seja o PO), conseguir aquela especificação que faltou, etc.

– Quadro de Tarefas sempre atualizado: Manter o Quadro de Tarefas atualizado é a melhor maneira de não se perder nas histórias e saber quem está fazendo o quê.

– Confiança: Você se encontra sozinho e precisa liberar aquela versão que será apresentada no dia seguinte. Respire e mantenha a calma que, se tudo o que eu escrevi aqui em cima estiver sendo feito, vai dar tudo certo! Scrum é isso. Criamos as condições necessárias para o sucesso. O restante da equipe confia em você.

– Fé: Tem que ter fé. Fé no processo, no seu trabalho, na sua equipe.

É claro que os casos que listei não são os únicos empecilhos. Assim como em qualquer projeto, mesmo os com equipe de tempo integral, diversos outros problemas podem surgir e devemos contorná-los da melhor forma possível.

Dando atenção aos pontos que mencionei, você minimiza os riscos e cria soluções para os problemas que irão surgir. Suas chances de sucesso aumentam muito!

Aproveite o espaço do comentário e deixe sua opinião, principalmente se você já trabalhou em equipes de tempo parcial. Compartilhe conosco sua experiência.

Um abraço e até o próximo post.

The post Equipe em tempo parcial e Scrum: uma questão de fé! appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Falarei um pouco das dificuldades em se ter uma equipe de design que provê recursos para outra equipe, a equipe de desenvolvimento da aplicação. Então vamos lá.

Eu já havia falado em outros posts sobre a importância do time nas sprints tanto nas estimativas quanto na velocidade da equipe. Mas hoje vamos focar na integração das sprints da equipe de design com as sprints da equipe de desenvolvimento da aplicação, aproveitando que estamos passando por isso atualmente.

Estamos reformando completamente o design de uma aplicação, colocando novas features, mudando totalmente a arte das telas, mudando os menus, substituindo formas de apresentação, e etc. Para que tudo seja devidamente implementado, minimizando os desperdícios, criamos uma forma de se trabalhar que vou compartilhar com vocês como tem sido essa experiência.

Em primeiro lugar, como tínhamos a aplicação já funcionando com o design antigo, a equipe da qual faço parte ficou responsável por criar o novo design enquanto a equipe de desenvolvimento da aplicação não foi interrompida e deu continuidade no trabalho de melhoria a aplicação. Assim, criamos toda a arte conceitual, e depois começamos a fazer os htmls, css e javascripts que eram necessários para a visualização e comportamento das telas.

Após algumas sprints da equipe de design, o desenvolvimento da aplicação antiga foi interrompido e a equipe de desenvolvimento da aplicação começou a trabalhar na aplicação das novas telas. Continuamos as novas sprints de design, mas agora metade do nosso esforço (ou um pouco menos) é destinado a solucionar problemas de integração que a equipe de desenvolvimento encontra durante a aplicação do novo design.

Um problema que tivemos foi por causa da nossa sprint ser de duas semanas. Por conta deste timebox, só podíamos fornecer as novas modificações ao fim de duas semanas, e por conta disso, muitas histórias de desenvolvimento não ficam prontas ao final da sprint deles. Então, reduzimos o timebox para uma semana, e toda semana conseguimos fornecer as correções solicitadas pela equipe de desenvolvimento da aplicação, necessárias para que as histórias fiquem prontas ao final da sprint deles.

A migração ainda está ocorrendo, mas tem funcionado muito bem conosco.

Essa foi minha experiência, e você, faz diferente na sua empresa? Compartilhe conosco!

The post Integração da sprint de design e de desenvolvimento appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.