Faz tempo que ouço esse termo “Scrum para Gestão Ágil de Projetos”. O que é uma contradição. Scrum é para Desenvolvimento de Produtos.
Mas qual a diferença? O que você realmente pretende com Scrum? Gerir um projeto de uma forma ágil? Leia o PMBOK, tem lá uma parte ágil. 🙂
Em Desenvolvimento Ágil de Software, fala-se de Desenvolvimento de Produtos, porque sabe-se que Software não é algo que se constrói, coloca em produção e ninguém mais precisa cuidar. Um antipadrão é construir o software num time de projeto, e depois fazer uma KT (knowledge transfer – como se conhecimento se transferisse facilmente) para um time menos preparado de suporte ou manutenção. Um time de produto, um time ágil efetivo, trabalha tanto no desenvolvimento de novas funcionalidades quanto em melhorias, dívidas técnicas (dívidas, não débito, pois possui juros) e bugs.
Scrum fala muito de Empirismo. Ou seja, muito de descoberta existe durante o desenvolvimento do produto, e isso serve como feedback para desenvolver um melhor produto, de acordo com as expectativas do cliente, do negócio, do usuário. Como se planejaria isso no início de um projeto? Dificilmente.
Ok, mas preciso gerir um projeto, o que eu faço? Tudo bem utilizar Scrum, é um método que vai ajudar sim a ser um projeto mais ágil, com menos riscos, maior engajamento das pessoas, clientes e usuários. Mas entenda, não é o propósito real do Scrum. Tente buscar a troca de projetos para produtos. Mesmo que se fale em projeto, pense em produto.
O Nexus é o exoesqueleto para escalar Scrum. Ele guia o coração da questão de escalar – continuamente identificando e removendo dependências criadas pelo aumento da complexidade. Ele é construído no framework do Scrum e valores existentes. O resultado é um grupo efetivo de desenvolvimento acima de 100 pessoas utilizando as melhores práticas da indústria. Para maiores iniciativas, criando famílias de produtos ou interoperando unidades funcionais, foi criado o Nexus +, uma unificação de mais de um Nexus.
Backlog do Produto
Uma lista ordenada de uma única fonte de requisitos para o Nexus. O trabalho de todos Times Scrum individuais é contido neste único Backlog do Produto.
Time de Integração
Um Time Scrum cujo trabalho primário é coordenar e guiar o trabalho dos Times Scrum Nexus. O Time de Integração consiste de um Scrum Master, Dono do Produto, e pessoas com habilidades necessárias.
Reunião de Planejamento da Sprint Nexus
Um evento que cria um plano para o próximo trabalho de Sprint para todos os Times Scrum dentro do Nexus. Esta reunião é estruturada para extrair as dependências, habilitar o trabalho coordenado, e entregar um Incremento integrado.
Backlog da Sprint Nexus
Um plano de alto nível que coordena o trabalho para todos os Times Scrum dentro do Nexus, ressaltando dependências entre times.
Reunião Diária Nexus
Uma reunião de planejamento diário onde os representantes dos Times Scrum de um Nexus avaliam e replanejam o trabalho no Backlog da Sprint.
Revisão da Sprint Nexus
Um evento que coordena totalmente o progresso por inspecionar o Incremento integrado e fazer adaptações apropriadas para o trabalho futuro planejado.
Incremento Integrado
O incremento da funcionalidade criada por todos os Times Scrum ao final da Sprint. A definição de “Pronto” é compartilhada entre os múltiplos Times Scrum.
Retrospectiva da Sprint Nexus
Um evento onde o Time de Integração e representantes dos Times Scrum do Nexus avaliam e melhoram como o Nexus opera.
Em seu blog, o autor Ken Schwaber comentou no dia 01 de fevereiro que mais materiais estão por vir nas próximas semanas (nada ainda surgiu). E também deixou um recado:
“Aqueles de vocês que tem investido e tentado metodologias comerciais para escalar tais como SAFe vão descobrir que esse workshop poderá preencher bem a lacuna que você notou quando teve que realmente estabelecer e rodar um desenvolvimento de software escalado.” Ken Schwaber
Relação de epifitismo de uma bromélia com uma árvore. Fonte: meioambiente.culturamix.com
O Scrum precisa de Kaizen (melhoria contínua) numa relação de epifitismo, do mesmo modo que uma bromélia precisa de uma árvore para se sustentar. Uma relação epífita é quando uma espécie A precisa de outra espécie B para sobreviver, mas não prejudica a espécie B. A foto acima mostra uma bromélia que precisa de uma árvore como base.
Vamos às definições:
Scrum (n): Um framework no qual as pessoas podem resolver problemas complexos adaptativos, enquanto de uma forma produtiva e criativa entrega produtos do mais alto valor possível. http://www.scrumguides.org/
Kaizen: Melhoria contínua de um fluxo completo de valor ou de um processo individual, a fim de se criar mais valor com menos desperdício. http://www.lean.org.br
Scrum é um framework, não é metodologia, nem processo. O objetivo de ser um framework está em trazer práticas de gestão ágil para se encaixarem outras práticas (de gestão e de engenharia). As principais práticas do Scrum são:
Trabalhar em Sprints (iterações)
Realizar Reunião de Planejamento
Reuniões Diárias
Realizar Reunião de Revisão (entrega)
Realizar Reunião de Retrospectiva (na minha opinião é a prática mais essencial pois é o evento para a melhoria contínua)
Ter um papel responsável pelo valor do produto (Product Owner)
Ter um papel responsável pelo processo (Scrum Master)
Ter um papel responsável pelo desenvolvimento (Time de Desenvolvimento)
Note que o Scrum atua apenas no nível de gestão. O framework é simples de entender, mas não é fácil de utilizá-lo, por isso é essencial a melhoria contínua em sua adoção. Um dos motivos de que um time passa por problemas na adoção do Scrum é porque o time utiliza apenas o framework (que é de gestão) sem utilizar outras práticas ágeis, principalmente de engenharia. Nas reuniões de retrospectiva, utilize a melhoria contínua para evoluir nisso, tanto para práticas gestão quanto de engenharia. Algo muito interessante de investir são em práticas emergentes.
Veja que Scrum não é somente para software, tanto que em seu guia nada se diz sobre software. Ou seja, Scrum não define user stories, integração contínua, ou qualquer outra prática ágil de desenvolvimento de software. Essas práticas estão no XP (eXtreme Programming), que é uma metodologia ágil de desenvolvimento de software, sendo mais prescritiva que o Scrum (obviamente).
Muito se fala que se não adotar o Scrum exatamente, então está se fazendo ScrumBut. Ano passado (2014) no Agile Brazil em Florianópolis, eu estava trocando uma ideia no estande da Adaptworks quando falei que o “Scrum é But por natureza” (querendo dizer que devemos adaptar inclusive próprio Scrum). No mesmo momento, o Alexandre Magno falou: “Não! Scrum é Inspect&AdaptBut!”. Realmente, O Scrum define um mecanismo de inspeção e adaptação, mas proíbe que seu framework seja modificado.
Melhoria contínua no Scrum foi um dos assuntos da palestra O Julgamento do Scrum do Alexandre Magno no Agile Brazil 2013, por sorte eu estava lá assistindo, em Brasília! Essa palestra me fez reconhecer que precisamos refletir a utilidade do Scrum em cada contexto, assim como qualquer outra abordagem ágil. Seguem os slides desta palestra:
Adicionalmente, o Alexandre Magno traz a ideia de Práticas Emergentes, de resolver o problema existente com práticas criativas. Eis a palestra:
E seguem os slides dessa palestra Práticas Emergentes:
“Não é necessário mudar. A sobrevivência não é obrigatória.” William Edwards Deming
Dionatan Moura 
Você precisa fazer login para comentar.