Scrum é um método de ágil para gerenciamento de projetos. Como a maioria dos métodos ágeis, ele foi baseado no manifesto ágil, de 2001. Segundo o próprio nome, um dos objetivos principais é trazer agilidade para o gerenciamento de projetos, aumentando o nível de resposta a mudanças.
Aplicado inicialmente no desenvolvimento de software, área onde tradicionalmente os projetos sofrem constantes mudanças de escopo, devido a mudanças no ambiente de negócios, inovações, legislação, concorrência e outros fatores, Scrum vem sendo aplicado em outras áreas, atingindo bons resultados, na maioria dos casos.
Ainda assim, implantar Scrum nem sempre é uma tarefa simples. Diversos fatores contribuem para simplificar ou, em alguns casos, complicar o processo. No mínimo, são pontos que precisam de atenção. Entre eles, vale destacar:
Síndrome da bala de prata. Não existe solução mágica! Saiba reconhecer se Scrum é o método mais adequado para o seu projeto ou organização, entendendo quais situações onde ele se aplica melhor e tem os maiores benefícios.
Projetos de inovação, com alto grau de mudanças, escopo não muito bem definidos ou que precisam de resultados no curto prazo são fortes candidatos.
No outro extremo, situações em que existem fortes requisitos contratuais, amarrando fortemente prazos e escopo – ou quando a organização já possui maturidade e experiência com projetos semelhantes (implantações de sistemas, por exemplo) – podem ser candidatos para uma abordagem mais “tradicional”.
Prazo de entrega e custo dos projetos. Uma das criticas comuns ao Scrum é que não existe uma data para o término do projeto. Embora seja sim possível ter estimativas com Scrum, aqui existe a necessidade de uma mudança de paradigma.
Toda estimativa, seja de prazo ou de custos, por mais realista e bem feita que seja, ainda é uma estimativa, possui uma margem de erro e fatores de riscos associados. Algumas abordagens mais tradicionais de gerenciamento de projetos tentem a se proteger das mudanças, criando processos, às vezes complicados ou mesmo burocráticos, para tornar alto o custo da mudança.
Métodos ágeis tratam a mudança como parte natural do processo, onde a mudança e o aprendizado da equipe e do cliente levam a um produto final melhor. A equipe se compromete com aquilo que vai realmente entregar e nada além. À medida que essas entregas são realizadas com sucesso, o cliente vê o resultado e adquire confiança de que a equipe pode não prometer com tudo o que ele deseja, mas entregará aquilo com o que se comprometer. É um começo, pois trabalhar com objetivos realistas é melhor do que a frustração de não alcançar esses objetivos. Ainda assim, pode não ser aplicável para todos os tipos de projetos.
Não despreze a engenharia de software. Outra critica comum ao Scrum, especialmente em desenvolvimento de software, é que com ele não existe documentação do projeto e / ou produto. Na verdade, Scrum é um método ágil de gerenciamento de projetos, que não restringe quaisquer outros tipos de atividades que podem e devem ser realizadas.
Qualquer que seja o método de gestão adotado, levantamento de requisitos, análise, projeto, codificação, testes e documentação devem estar sempre presentes, pois são disciplinas de engenharia de software, e embora não estejam formalmente previstas, a organização deve adotar seus próprios mecanismos para garantir a qualidade do produto.
A diferença fundamental é que todas essas disciplinas /atividades são realizadas em ciclos menores (sprints), e de forma incremental.
Gerentes funcionais. Outra questão que deve ser considerada é a posição do gerente funcional no Scrum. A equipe passa a ter autonomia para definir o que será e o que não será desenvolvido em cada sprint e o papel do gerente funcional pode mudar consideravelmente quando isso acontece. Na maioria dos casos, ele não define mais o cada funcionário fará e passa a atuar mais como facilitador, provendo os recursos necessários para que a equipe alcance os resultados do projeto, ajudando os scrum masters na realização de seu trabalho de remoção de impedimentos.
Nesse sentido, passa a ter um papel menos ligado as atividades diárias, e mais ligado ao desenvolvimento dos profissionais, aumentando a capacidade de resposta da própria equipe. Alguns gerentes podem resistir a esse tipo de mudança, encarando como perda de influência, e por isso essa questão precisa ser muito bem alinhada, com uma clara (re)definição de papéis.
Mantenha a disciplina sempre. O Scrum não possui muitos processos de controle e mesmo as reuniões previstas tem objetivos muito bem definidos. A reunião diária foi desenhada para ser a mais objetiva e rápida possível (15 minutos, no máximo).
Ainda assim, é importante garantir que os (poucos) processos sejam seguidos, para que os resultados sejam mantidos no longo prazo, para que impedimentos sejam levantados e removidos, para que exista o canal de comunicação constante com o cliente, e para que ocorra a evolução do próprio processo.
Após a fase inicial, existe uma tendência de “relaxar” em alguns processos, não realizar algumas reuniões, em especial quando o time trabalha muito próximo (times pequenos) e com grau de interação alto. Não caia nessa tentação, mantenha a disciplina.
Além desses pontos, algumas dicas podem ajudar no processo de implantação:
Capacite a equipe, crie uma base de profissionais qualificados. Uma forma simples de reduzir a resistência é capacitar pessoas chave que possam disseminar as práticas e conduzir a fase inicial de implantação. Esses agentes de mudança serão os primeiros scrum masters.
Comece simples, crie um case, mostre resultados. Dependendo da cultura da organização, pode ser difícil tentar mudar completamente o processo de trabalho. Começar com um grupo menor, ou mesmo com um projeto mais simples, mostrando os resultados atingidos, poderá facilitar a aceitação da mudança. Não tente fazer tudo de uma vez.
Adicione complexidade aos poucos. Se o grau de resistência à mudança for alto, é possível iniciar com algumas reuniões e práticas e incluir novos processos quando os anteriores forem assimilados pela equipe. Por exemplo, pode-se iniciar com reuniões de planejamento no inicio do sprint, mais reuniões diárias e uma reunião simples ao final do sprint, combinando review e retrospective.
Quando essas práticas forem assimiladas, novos processos podem ser introduzidos. Um dashboard, ainda que simples, dá visibilidade ao processo, e é altamente recomendável desde o inicio.
Busque apoio externo (treinamento / consultoria), quando possível.
Defina claramente o cliente. Defina o Product Owner e tenha certeza que ele representa os principais stakeholders e tem autoridade para tomar decisões: um grande desafio em alguns projetos é definir o cliente. Diversos stakeholders podem ter expectativas em relação ao produto final, e nem sempre essas expectativas estão alinhadas. Sempre que possível, defina alguém (Product Owner) que represente os interesses dos diversos stakeholders, alinhando e centralizando as expectativas sobre o que deve ser efetivamente entregue. Tenha esse elemento sempre próximo ao time e certifique-se de que ele tenha autoridade suficiente para tomar decisões.
Comunicação, comunicação, comunicação. Fato: com scrum, o número de reuniões aumenta muito. Também aumenta o grau de interação entre os membros da equipe e entre cliente e equipe. Mas a equipe pode e deve realizar suas próprias reuniões de planejamento técnico e todas as outras que forem necessárias. Importante também manter os stakeholders alinhados com a evolução dos sprints – o dashboard ajuda, mas as vezes não é suficiente. Use todos canais disponíveis para comunicar o projeto – e-mails, blogs, newsletters etc.
Mensure a velocidade da equipe. A cada sprint, a evolução do trabalho da equipe deve ser registrada, para que se possa ter uma noção clara do ritmo das entregas – se o objetivo será alcançado, ou se existe algum problema impedindo que o objetivo seja atingido. Esse histórico irá gerar uma base sobre a qual a própria equipe poderá melhorar com tempo, identificando gargalos e tomando ações de melhoria.
No planejamento, seja realista. Depois de alguns sprints, a equipe começa a enxergar melhor a sua própria capacidade de resposta. É sempre importante ter os pés no chão durante o planejamento, assumindo entregas que sejam desafiadoras, mas que a equipe seja realmente capaz de atingir. Nada mais frustrante que chegar ao final de um ciclo e não alcançar o objetivo definido.
Mais na Wikipedia: Scrum (development) e Agile Manifesto.
