Essa semana vou falar sobre um assunto que acho muito legal. Já tinha lido em alguns blogs sobre isso e também vi em um dos keynotes de 2015 do Scrum Gathering Rio com o pessoal da Knowledge21: Os mitos e falácias da agilidade.
Para quem ta migrando do ambiente tradicional para o ágil, esse post pode ser um divisor de águas, abrindo a sua mente para ir atrás de mais mitos para derrubar e aprofundar seu conhecimento dentro do mundo ágil. Para quem já trabalha com agilidade, penso que é muito importante estarmos sempre revendo os conceitos e reciclando o conhecimento, pois contextos novos aparecerem e temos que saber lidar com eles.
Aqui vão alguns mitos e falácias da agilidade que já li ou vi em algum canto e vou comentá-los:
Product Owner (PO) não participa de retrospectiva
Quem já ouviu por aí: “Não envolver o PO da retrospectiva, pois essa cerimônia é apenas para a melhoria de quem ta ali, trabalhando diretamente com o código.”
Infelizmente, vejo vários times fazerem. Acredito que esse é um dos maiores erros que um time pode cometer. Lembrem-se, um time de scrum é composto por 3 peças fundamentais: Scrum Master (SM), Product Owner (PO) e Time de Dev.
A cerimônia de restrospectiva é o momento ideal para o time resolver os problemas que ocorrem dentro da equipe, seja um problema técnico ou não. E acreditem, dificilmente é técnico. Portanto, é extremamente importante a presença de todos, pois, se um time está impedido por causa de um terrível PO, isso precisa ser resolvido.
Já vi acontecer bastante do time ter um PO de uma empresa diferente (alguém da empresa do cliente, por exemplo). Sei que não é a situação ideal, mas se isso ocorrer, ele(a) deve ser envolvido na reunião.
Agilidade é um processo
Outra besteira muito comum que vejo por ai: “a agilidade é um novo processo que veio para substituir o tradicional”. Temos que entender que a ideia de ágil está muito mais ligado a cultura do que processos. Uma cultura onde a colaboração e a melhoria contínua são essências para que cresçamos em todos os aspectos seja como indivíduo, como time e/ou como organização
No ágil não tem documentação
Ta certo que o manifesto ágil fala “software em funcionamento mais que documentação abrangente”, mas isso não é motivos para não ter NENHUMA.
Quando pensamos em alguns métodos ágeis (scrum, por exemplo), algumas cerimônias como planejamento da sprint ou lições aprendidas precisam ser documentadas para que o time possa ter ideia do que vai ser feito e das coisas boas e ruins que ocorreram ao longo do projeto. É interessante pensar que os documentos são como se fossem um Minimum Viable Product (MVP), ou seja, apenas o minimo necessário de informações o irão compor.
Aplico Scrum, portanto sou ágil!
Quem aí já ouviu falar que é ágil só porque utiliza o Scrum? Como falei anteriormente, agilidade não é um processo e sim uma cultura. E que isso significa? Ter uma cultura ágil foca principalmente em entrega contínua, colaboração, valor para o cliente, melhoria contínua, entre outros. Portanto, usar scrum não faz de você um agilista.
Carro chefe da agilidade é o scrum
Geralmente, a porta de entrada para os métodos ágeis é o scrum. Mas saiba que ele não é o único. Existem vários métodos que se baseiam nos princípios ágeis, tais como Extreme Programming (XP), Feature Driven Development (FDD), Kanban, entre outros.
Scrum ou outros métodos, faça sua escolha!
Calma!! Não significa dizer que você só pode usar o scrum ou qualquer outro método, apenas. Sabia que o scrum é um framework, ou seja, ele é flexível e adaptável de acordo com as suas necessidades. É muito viável utilizar Scrum com o Kanban e também Scrum com o XP. E por que não os 3? :). Com relação ao scrum, é preciso apenas respeitar suas principais cerimônias: sprint planning, sprint review, sprint retrospective, daily meeting.
Ser ágil significa não seguir o plano
Tá certo que o manifesto ágil fala para respondermos rápido à mudanças. Mas isso não significa que não temos um plano para isso. É comum estarmos sempre pensando em entregar aquilo que foi planejado, mas quando isso não tem mais valor para o cliente? Afinal de contas, ele também é um ser humano e pode ter enxergado que o que foi planejado para aquela sprint, simplesmente, não tenha um retorno de investimento para ele naquele momento. O que fazer então? Cancelamos a sprint? Negociamos algumas funcionalidade para serem feitas depois? Precisamos responder a mudanças rapidamente.
No scrum, planejamos de um modo que seja minimamente viável para o time de desenvolvimento trabalhar, o resto deixamos de modo mais macro para planejar no momento que será desenvolvido. A seguir, os níveis de planejamento realizados no framework para entendermos que temos planos sim:
5 níveis de planejamento do scrum
Scrum só funciona para área de TI.
Outro erro muito comum! Como falei no tópico 2, agilidade é uma cultura. De acordo com o State of Scrum de 2015, áreas como operações, produção e pesquisa e desenvolvimento são as áreas utilizam bastante o Scrum. Legal né?
Estado do Scrum de 2015 pela Scrum Alliance
Utilizo bastante a agilidade na minha área também (design), ou seja, priorizar o que vai ser feito de acordo com o que tem mais valor, ao invés de projetar todo o sistema e depois não ser utilizado ou ter que ser alterado. Então, Não. A agilidade funciona bem em qualquer área! Basta saber adaptá-la de acordo com a sua necessidade!
Esses foram de alguns mitos e falácias da agilidade que já vi por ai, o que acharam? Acho muito interessante está procurando sempre sobre eles para evoluir o conhecimento sobre o mundo ágil. E quais são os que vocês conhecem? Deixem aí no comentário. 🙂 Um abraço.
