Imaginemos uma equipe que acabou de contratar um novo programador e que logo nos primeiros dias, sejam apresentados todos os sistemas, procedimentos, bancos de dados, códigos, ferramentas, comandos, etc. e como resultado final se espera que o novo membro entenda e aplique tudo o que lhe foi passado. É meio complicado, não?

Geralmente é assim que funciona dentro desses processos muito prescritivos, pois possuem um "conjunto mínimo" de boas práticas que a equipe deve implementar logo de início, ou seja, uma avalanche de artefatos, processos e ferramental que cai sobre a equipe para garantir o sucesso do processo e em paralelo, a gestão espera resultados satisfatórios com a nova maneira de trabalho imposta.

Neste ponto, a organização enxerga tais processos como um apoio único para o sucesso do projeto, achando que muita prescrição e ferramental pesado irá trazer a solução para o caos, o que não é verdade. Vamos refletir um trecho do PMBOK que diz: "…Compreender e aplicar o conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é suficiente para um gerenciamento eficaz…"

São tantas práticas e algumas podem não ser tão produtivas e/ou eficazes para garantir o sucesso. Isso se resume ao fator de variação da equipe (tamanho, experiência, etc.) e fator de variação da organização (cultura, investimento, etc.).

Compartilhando uma experiência onde se tentou implementar um processo muito prescritivo, lembro-me que toda reunião que a equipe fazia era necessário criar uma ata de reunião, ou seja, inicialmente a equipe consumia cerca de 20 minutos para elaborar a ata e depois, cerca de 45 minutos para finalizá-la, descrevendo tudo que foi falado, providências, pendências, etc.

Não estou fazendo apologia sobre não usar a ata de reunião, tudo tem prós e contras, porém, para nossa realidade naquele momento era desnecessário e improdutivo, entretanto, a equipe era pressionada a seguir fielmente a metodologia implantada.

Minha crítica está associada ao "conjunto mínimo" de práticas exigidas nestes processos, e mesmo não sendo tão produtivas, fazem parte do contexto de trabalho da equipe, e com o tempo, consome sua motivação e produtividade.

Então, qual é o processo ideal para minha equipe?

Há um ditado no mundo ágil que diz que menos é mais. Está em dúvida? Falta experiência? Foge do controle de riscos? Etc, etc. Então, inicie com menos e acrescente a medida do possível.

Onde o Scrum pode ajudar sobre o assunto?

O Scrum diz que a equipe de desenvolvimento deve ser autorizada pela organização a conduzir e gerenciar sua forma de trabalho e isto sem sofrer influência de qualquer pessoa externa a equipe. Então, eu já consigo enxergar um início de produtividade e motivação aqui, pois ao invés de ser pressionada pela organização, a equipe começa a escolher seus próprios meios e ferramentas para conduzir seu trabalho. Em outras palavras, é o início da construção de suas próprias práticas e métodos para atingirem seu objetivo dentro do processo, que com o tempo, aumenta gradativamente a maturidade da equipe.

Outra melhoria (eu o considero como melhor) é que a equipe dentro do Scrum se beneficia de oportunidades (retrospectiva da Sprint) de discutirem/avaliarem a forma como foi conduzido seu trabalho com propósito de melhorar os pontos negativos para o próximo ciclo (Sprint). Ou seja, diferentemente como vimos mais acima onde a equipe é obrigada a conduzir o trabalho dentro de um processo mesmo não tendo bons resultados, no Scrum a equipe decide entre si em utilizar ou não um determinado artefato, ferramenta, processo, etc. No meu exemplo, a equipe poderia decidir em não usar a ata de reunião, ou escolher/criar uma nova prática para tal.

Em meu ponto de vista, ninguém irá escolher a melhor forma de trabalhar do que quem realmente põe a "mão na massa". Isso eleva a satisfação do time no trabalho, cativando sua motivação, pois se inicia também uma relação de CONFIANÇA, o que é um ponto chave para a motivação.

Post de autoria do autor convidado: Rafael Amaral.

The post Scrum e o Gerenciamento do Trabalho da Equipe appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Sabemos que utilizar e acompanhar um desenvolvimento de software numa metodologia é extremamente importante para o sucesso do projeto. Melhor ainda é quando vemos que tudo está caminhando conforme o planejado, isso acontece principalmente no início do projeto.

Porém, este "mar de rosas" raramente é o tal "felizes para sempre" dentro do ciclo de vida do projeto. As opiniões mudam, a visão sobre o negócio muda, os stakeholders dificilmente concordam/aceitam o que lhes são apresentados, e, em consequência disso, os requisitos também mudam, tudo muda. Sem falar nos casos em que várias pessoas dentro da organização opinam (de forma diferente até sobre a mesma visão) sobre o produto, deixando a equipe do projeto de cabelos em pé!

A partir desta situação, começa então gerar o caos dentro do processo que antes parecia tão "organizado" e alinhado ao projeto e que agora se tornou um pesadelo gerenciar as estimativas, cronograma que não pode estourar, custos, replanejamento, recursos humanos, etc.

Normal, não? Porém, as metodologias tradicionais podem não ter o suporte necessário para o "gerenciamento" dessas mudanças. Isto ocorre devido às burocracias que fazem parte deste contexto, em que na maioria das vezes, dão ênfase a tantos artefatos e deixam de lado a parte mais importante, o porquê de sua existência, o produto em si.

Onde está o socorro?

No Scrum!

O manifesto ágil diz que:

• Software funcionando vem antes de documentação abrangente
• Colaboração do cliente vem antes de negociação de contrato
• Resposta às modificações vem antes de um plano em andamento

Ao contrário de que muitos pensam, o sinônimo de "Agilidade" não fará com que seu produto seja entregue na metade do tempo de uma metodologia tradicional, ou de um dia para o outro. Ser ágil dentro do Scrum, por exemplo, quer dizer à (não se limita):

• Responder rapidamente a modificações e solicitações
• Aperfeiçoar a previsibilidade
• Controlar/limitar os riscos
• Ser auto-organizável, sem depender de terceiros, o que pode ser dito como ser proativo, e
• Buscar uma contínua perfeição de trabalho para entrega de produto de mais alto valor possível

Os processos ágeis valorizam as modificações (mesmo que tardia) para vantagem competitiva do cliente. Se você consegue responder rapidamente às mudanças de requisitos, provavelmente consegue retorno mais rápido, em consequência, obtém como resultado um produto de mais valor para seu cliente.

O Scrum não é um processo e sim um framework onde se pode empregar vários processos ou técnicas. Sendo assim, é possível aplicá-lo dentro de um processo já existente na sua organização, aderindo para as novas terminologias.

Como exemplo, colocar em prática os eventos Scrum. Tais eventos são projetados para garantir a previsibilidade e a transparência, de modo a criar uma rotina que garante reuniões centralizadas reduzindo a necessidade de outras e o desgaste de tempo desnecessário dentro do processo. Também, promovem a inspeção de modo que o Time Scrum avalie com frequência o progresso em rumo ao objetivo, adaptando-se (como equipe auto-organizada) sempre que necessário, o que faz com que o Scrum seja totalmente adequado para a solução dos problemas mencionados no segundo parágrafo.

O Scrum é leve e por isso não é preciso abandonar um processo já em uso, basta fazer uma adaptação abrindo mão da tal "da cultura". Essa mudança diz respeito à (o que não se limita):

• Mais cooperação por parte de todos envolvidos e menos formalismo
• Proatvidade da Equipe de Desenvolvimento e autorização para gerenciar seu próprio trabalho
• Apoio e contato direto da participação do stakeholder de forma centralizada e representada por um único integrante na pessoa do Product Owner

Seu processo atual não está dando conta do recado? Que tal transformar cada porção do tradicional modelo de "Ciclo de vida" numa Sprint?

Você pode "inventar" o Scrum de várias formas, aplicando os papéis, eventos, artefatos e regras do mesmo, enriquecendo seu processo tradicional com a eficácia das práticas Scrum.

Ser Scrum é desprender-se das coisas que engessam o processo e valorizar os pontos positivos de forma que eles evoluam cada vez mais.

É criar e conduzir de forma produtiva o trabalho necessário para construção do produto.
 

Sobre o autor desse post: Rafael Amaral, há 6 anos trabalhando com desenvolvimento web em Juiz de Fora, Professional Scrum Master I certificado pela Scrum.org, desenvolvendo sites, sistemas e soluções para o seu negócio através da plataforma web.

The post Scrum nos processos tradicionais appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.