Quais pontos no seu trabalho o uso do Scrum lhe trouxe benefícios?

Essa foi a enquete que fizemos recentemente no facebook do ScrumHalf. Embora poucos fãs tenham se animado em responder a enquete a resposta com maior número de votos foi:

Confiança na Equipe.

Resposta aderente ao 5o princípio do Manifesto Ágil:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

(Construa projetos com indivíduos motivados. Dê a eles o espaço de trabalho e apoio de que necessitam, e confie neles para ter o trabalho pronto).

E a confiança é uma das chaves para motivar os indivíduos de um Time. O trabalho em iterações curtas promove um ambiente sustentável e de confiança, por uma série de motivos:

1. No Scrum cabe ao PO dizer  "O que" quer que seja feito na sprint e ao Time "Como" será feito o trabalho. Dê o espaço de trabalho e o apoio que necessitam que o Time será capaz de se auto-organizar para definirem a melhor forma de "Como" entregar.

2. O PO planeja a sprint junto com o Time. É preciso ter confiança em ambas as partes para que um planejamento seja realmente feito em Equipe.

3. O Time se compromete com a sua velocidade, sabendo o que pode entregar dentro do timebox combinado. Então, porque não confiar no trabalho do Time? Confiar que eles irão entregar o combinado?

4. Ao final da sprint o Time apresenta ao PO o trabalho implementado. Essa atitude fortalece o compromisso que o Time assumiu com o PO. Que Time vai querer falhar a entrega do combinado, quando lhe foi confiado um trabalho?

5. A retrospectiva é uma ótima oportunidade para promover melhorias no processo. Se ainda não se alcançou 100% de confiança essa é a hora de avaliar o que ainda não está legal para melhorar.

Quer mais justificativas e oportunidades de confiança que essas?

The post (Português) Confiança: 5 justificativas para confiar no seu Time Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Hoje iremos falar sobre comunicação e trabalho em equipe dentro de um projeto. Reparem que não limitei o tipo de projeto: Ágil ou tradicional. Ter uma equipe que se comunica e trabalha junta para o projeto é essencial para garantir a qualidade do sistema e a produtividade do time.

Nos quadrinhos podemos enxergar a situação de dois membros da equipe se comunicando por ferramenta de bate-papo, sendo que está um do lado do outro. Imediatamente me veio a cabeça o 6º princípio do manifesto ágil: “O método mais eficiente e efetivo de transmitir informação para a equipe de desenvolvimento está na conversa cara-a-cara”.

A comunicação ampla e aberta dos membros de um projeto aumenta a visibilidade dos problema, das soluções e diminui significativamente o retrabalho. Para uma boa comunicação é necessário conversar. Conversar muito. Com todos do projeto. Sobre os mais variados temas. De preferência pessoalmente.

No entanto, só conversar não adianta. É preciso ter foco nas reuniões. Também é preciso que decisões importantes e pontos-chave do projeto sejam anotados para serem consultados caso exista qualquer dúvida em relação aquele ponto. Adicionalmente, todas as decisões do projeto devem ser avisadas a todos o mais rápido possível, para que as opiniões possam ser emitidas e todos os interessados no projeto caminhem para o mesmo objetivo. Uma prática comum em times ágeis é o uso de wiki para compartilhamento de informações entre todos os membros da equipe.

Uma outra vantagem da comunicação na equipe, principalmente presencial, é que ela une o time. Em primeiro lugar é preciso transformar os empregados em uma equipe. Trabalhar no mesmo projeto não significa trabalhar em equipe. Trabalho em equipe não é somente compartilhar do mesmo ambiente com a pessoa durante a jornada de trabalho. Criar cumplicidade entre os membros do projeto é um trabalho complexo. Deve ser incentivado a pequenos passos. Sentir-se confortável para trabalhar, confiar e conhecer os outros membros é essencial para um bom trabalho em equipe. E trabalhar em equipe aumenta e muito o potencial e a produtividade de um time.

Trabalhando com pessoas é preciso interação. É preciso conhecer as competências, as habilidades e as deficiências de todos os membros da equipe, incluindo o PO e o ScrumMaster. Criada essa atmosfera, teremos um time coeso, que conhece sua capacidade e possui mais precisão e confiança para estimar custo e prazo. Além disso, o time se torna altamente adaptável, apto a responder rapidamente a mudanças e a novos requisitos, se tornando verdadeiramente ágil.

The post Comunicação e trabalho em equipe appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Recentemente a Forbes publicou um artigo muito interessante, cujo título traduzido é “A Causa Contra Agilidade: 10 Objeções Gerenciais Perenes”, onde o autor discute 10 objeções à Agilidade, sendo 6 delas apontadas em outro post (“Limitações do Desenvolvimento Ágil de Projetos”).

Meu objetivo é ampliar essa discussão, entrando no debate entre os autores dos posts mencionados acima. Se eu fizesse isso apenas nesse momento acabaria com um texto muito longo. Assim vou dividir essa discussão em 6 posts, sendo esse o primeiro. Mais do que reproduzir esse debate, meu objetivo é incrementá-lo. Para facilitar o entendimento apelidarei o primeiro post (o da Causa Contra a Agilidade) como “A Defesa” e o segundo (o das Limitações) como “A Acusação”.

A Acusação, antes de colocar seus pontos, alega de que não há estatísticas confiáveis comprovando que projetos desenvolvidos com metodologias ágeis são mais bem sucedidos do que aqueles desenvolvidos com metodologias tradicionais.

A Acusação não começou bem… Aqui nesse blog já escrevi sobre uma pesquisa (“CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos“) do Standish Group. Nesse relatório o instituto aponta que o aumento do número de projetos desenvolvidos com metodologias ágeis é uma das 4 razões para o aumento do número de projetos bem sucedidos.

Mas vamos para a primeira objeção, o assunto desse post, … A Acusação alega: “Agilidade é somente para uma equipe de craques”. Ela menciona que Agilidade foi desenvolvida por pessoas experientes, inteligentes e bem sucedidas. Na visão dela pessoas como Martin Fowler ou Jeff Sutherland seriam bem sucedidas no desenvolvimento de projetos utilizando qualquer metodologia.

A Defesa, por sua vez,  contra-argumenta, dizendo que enquanto os métodos tradicionais pressupõe que as pessoas precisam de uma gerência rigorosa por não serem competentes o suficiente, as metodologias ágeis pressupõe o contrário, de que as pessoas são competentes, desde que livres das amarras de uma hierarquia burocrática.

Penso que competência é fundamental, independente da metodologia. A Agilidade apoia-se em um conjunto de 12 princípios. Um deles diz que software deve ser entregue em ciclos de poucas semanas. Outro que software funcionando consiste na primeira medida de progresso. Sem competência esses princípios não serão alcançados e isso será verificado logo no começo do projeto (em detrimento dos métodos tradicionais cujo sinal de alerta emerge em decorrência de orçamento estourado ou cronograma atrasado), quando medidas corretivas podem e devem ser tomadas.

A Acusação, ainda nessa objeção, convida o leitor para pensar em qual seria o resultado de um projeto desenvolvido em sua empresa por uma equipe auto-organizada constituída de funcionários medianos sem uma supervisão próxima. Outro princípio desconhecido pela Acusação  diz que as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Esse princípio resulta de um estudo publicado pela Harvard Business Review onde os autores descobrem que foram justamente equipes auto-organizadas constituídas pelos próprios funcionários de organizações como Cannon, Honda e Toyota que permitiram a essas empresas inovarem com rapidez sem a perda de qualidade e flexibilidade de forma a competirem em mercados cada vez mais competitivos. Assim tenho certeza que se o leitor for de uma empresa com esse tipo de cultura reponderá positivamente à pergunta da Acusação.

Entendo que a Defesa perdeu uma grande oportunidade aqui. Se as pessoas que desenvolveram o Manifesto Ágil são caracterizadas pela Acusação como craques (a tradução correta seria “estrelas”, mas penso que craque está mais próximo da cultura do país do futebol), então ela deveria perguntar por que esses craques sentiram a necessidade e desenvolveram metodologias ágeis, se as tradicionais, que eles utilizavam, os levavam ao sucesso?

Em 1993 Jeff Sutherland se preocupava com a baixa produtividade no desenvolvimento de software, um problema que as metodologias tradicionais não endereçavam. O Scrum nasce dessa preocupação e, nas palavras de Jeff, “…deriva da teoria de sistemas adaptativos complexos e foi influenciado pelas melhores práticas na indústria japonesa… Scrum não é um método de desenvolvimento ou um processo formal, consiste num algoritmo de compressão das melhores práticas no desenvolvimento de software observadas por um período de 50 anos.”

Com as palavras de Jeff termino esse post. No próximo discutirei a objeção cultural das organizações à implementação de metodologias ágeis e, em particular, o Scrum.

Aqui fica o meu abraço pra você.

The post Acredite: Agilidade, e o Scrum em particular, não são somente para uma equipe de craques appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Olá pessoal, o post de hoje fala sobre os principais valores que podemos notar numa metodologia de desenvolvimento ágil, como o Scrum.

Feedback

O primeiro valor é o feedback, pois a compreensão dos usuários é uma das atividades mais difíceis e importantes dos desenvolvedores, afinal, ela é responsável por todos os esforços que vem a seguir.

O problema é que nem sempre o PO tem como prever corretamente as funcionalidades de que necessita, por isso é fundamental uma forte interação com os desenvolvedores ao longo do projeto. Por esta razão o Scrum é organizado em Sprints curtas de desenvolvimento (tempo médio de duas semanas).

Comunicação

As equipes Scrum devem reconhecer esses pontos e ter coragem para enfrentá-los da melhor forma possível. Um pensamento errado é “ficar na torcida” para que determinado problema nunca ocorra, pois os problemas ocorrerão. E pior, geralmente ocorre exatamente aquele que tanto tememos. O correto, por parte da equipe, é saber que problemas irão ocorrer e ter a confiança necessária para adotar soluções que possam reduzir ou eliminar as consequências dos problemas.

The post Valores do Desenvolvimento Ágil appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Ao longo desse mês todos os post do blog do ScrumHalf foram dedicados aos princípios do Manifesto Ágil em comemoração e homenagem aos 10 anos que já se passaram desde sua elaboração.

Fechamos hoje esse ciclo de comemoração, falando sobre o 12^o e último princípio do Manifesto Ágil: Em intervalos regulares, a equipe reflete sobre como se tornar mais eficiente, depois aprimora e ajusta seu comportamento em conformidade (At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly).

Nada mais justo! Já que estamos no final desse ciclo de comemoração fecharmos falando sobre retrospectiva.

Em intervalos regulares é importante que seja feita uma reflexão de tudo que aconteceu para aprimoramento e ajuste do processo de trabalho. Adotar uma metodologia ágil não é trivial, cada projeto terá suas barreiras para implantação e necessidade de adaptação para adequação, portanto é a reflexão que permitirá que seja dado o ajuste necessário para melhoria do processo.

Falando em termos de Scrum, é fundamental que ao final de cada sprint além de software funcionando a equipe avalie o que correu bem ao longo da sprint finalizada e quais são os pontos que devem ser focados para melhoria na próxima sprint. Fazer uma retrospectiva ao final de cada sprint contribui para que o projeto mantenha o ritmo sustentável, pois caso contrário os problemas acabam por sucumbir qualquer esforço na tentativa de ser ágil. É preciso que o processo seja ajustado em conformidade com a cultura do ambiente de trabalho para prover meios adequados e que facilitem a execução do trabalho pela equipe.

Os três pilares que sustentam o Scrum são: Transparência, Inspeção e Adaptação. E a reunião de retrospectiva fortalece esses três pilares ao final de cada iteração, pois é preciso transparência para inspecionar o que deve ser adaptado.

Fazendo uma retrospectiva desse mês dedicado a comemoração dos 10 anos do Manifesto Ágil, podemos dizer que o trabalho de preparo dos posts que foram publicados aqui no blog por cada membro da equipe de desenvolvimento da GPE só agregou benefícios, fortalecendo ainda mais os conceitos e valores do desenvolvimento ágil e também provendo aos nossos seguidores um material completo de estudo sobre o Manifesto Ágil e seus princípios. Agora vai ser difícil não adotar essa metodologia, não é não?!

The post 12º Princípio do Manifesto Ágil – Retrospectiva appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.