Achei extremamente interessante o artigo publicado no site ProfissionaisTI apontando 10 situações que pode (e certamente irá) levar ao fracasso da Metodologia Ágil Scrum para Desenvolvimento de Software.Parabéns para a ProfissionaisTI pelo rico material. Ao final segue a bibliografia.
1) Dificuldades em se estabelecer a visão ou as fronteiras da visão do produto, gerando Sprints intermináveis e impossibilitando estabelecer prazo
Certa vez um executivo, ao qual eu me reportava, disse: “Vitor, está provado que esse lance de Scrum funciona muito bem na execução. Mas ele não consegue estabelecer prazo”. Eu disse a ele que o problema era que nossos usuários-chave não conseguiam responder a uma pergunta básica: “De onde quero que meu produto parta até onde eu quero que ele termine?”
Sem isso, você sempre vai trabalhar pensando no curto prazo, no imediatismo e tem grandes chances de ter um projeto interminável – o que por si só já soa incoerente, pois projeto é um esforço temporário para a construção de um produto ou serviço.
Não caia na cilada de muitos agilistas que dizem que projeto ágil não tem estimativa de prazo e nem cronograma. No mundo Agile existe uma série de técnicas e artefatos que permitem prover este tipo de informação (recomendo fortemente leituras dos autores Mike Cohn e Ken Schwaber).
2) Focar no que não agrega tanto valor ao produto
Certa vez uma gerente de produtos que participava de um workshop meu, disse: “Esse lance de Sprints até que é legal, mas algumas entregas que são feitas simplesmente não me importam muito e acabam não resolvendo meu problema”.
Respondi sobre a palavra-chave do que a Sprint deve produzir: VALOR. Não adianta pegar um projeto e fracionar em 10 Sprints, sendo que a maior parte delas não agrega valor ao produto e apenas nas últimas é possível ter feedback do cliente final.
Muitos agilistas principiantes acabam “fatiando” o produto em diversas entregas, mas erram no valor agregado nestas entregas.
3) Distanciamento entre Product Owner e o restante do Time Scrum
Ora, se um dos princípios do Manifesto Ágil é que indivíduos e interações devam prevalecer sobre processos e ferramentas, não faz nenhum sentido ter um Product Owner que não se comunica com o Time.
Se não há sinergia, sintonia e o conceito de “Whole Team”, o fracasso é certo!
4) Interferências externas ou mesmo do Product Owner impondo o que deve caber ou não dentro de uma Sprint, sem obter o feedback do time de desenvolvimento
O famoso “Top-Down” ou mais conhecido como “goela abaixo”. Flexibilidade e a negociação são belas artes do Scrum. Se os integrantes do Time Scrum não tiverem domínio destas artes ou não tiverem força para brecar ruídos externos que atrapalhem estas artes, corre-se o risco de comprometimento da qualidade.
5) Negociar qualidade
Deixa-se de lado o valor da Sprint e entrega-se o que dá para entregar apenas para cumprir um prazo, pouco importando se a qualidade é boa ou não.
Negociação é uma arte do Scrum, mas negociar qualidade é PROIBIDO !
Se o tempo realmente é uma restrição, foque sempre numa entrega de VALOR e QUALIDADE
6) Sprints curtas demais obrigando o Time Scrum trabalhar em ritmos insustentáveis
Outro caso de comprometimento da qualidade e violação dos valores do Manifesto Ágil. Fazer horas-extras pode até ser bom e produtivo no primeiro dia. Mas depois fatores fisiológicos (cansaço, sono acumulado) e psicológicos (saudades do pai, da mãe, do namorado, da namorada, do cachorro, do jogo da TV) diminuem o rendimento, consequentemente podendo comprometer a qualidade.
Tente encontrar a duração ideal da Sprint, onde o time trabalhe em ritmo sustentável e entregue valor.
7) Time de desenvolvimento sem maturidade ou experiência para se auto-organizar
Neste caso, mais do que nunca, é necessário o apoio e coaching do Scrum Master para o desenvolvimento do time. Um time inadequado vai gerar um produto inadequado.
8) Scrum Master omisso, permitindo que a auto-organização torna-se caos
Muito manjado que o Scrum Master é um líder que serve o time – não chefia, não micro-gerencia – mentora e remove impedimentos. Mas não se deixe simplesmente ficar sentado passivamente assistindo tudo acontecer.
Não chefiar não significa não monitorar, não tomar atitude diante das dificuldades ou mesmo da disciplina do time.
Acompanhe o Kanban, escute ativamente o que está rolando no Daily Scrum, certifique-se de você tem o time ideal e de alto nível, mentore com a ajuda do time aqueles que estiverem num nível de maturidade/disciplina menor.
9) Scrum Master fazendo micro-gerenciamento, quebrando a sinergia e desmotivando a equipe
Aqui é a situação inversa. É o Scrum Master que acredita ser o chefe da equipe, delega e controla as atividades não permitindo o time ser auto-organizado.
É aquele cara que prega as atividades no Kanban e sai colocando os nomes dos responsáveis pelas tarefas.
É aquele cara que todo dia usa o Daily Scrum como reunião de reporte e querendo saber o detalhe de tudo o que está no Kanban.
10) Time Scrum (Product Owner, Scrum Master e Time de Desenvolvimento) não trabalhando com o conceito de time unificado (“Whole Team”)
O famoso “Eu ganhei, nós empatamos e vocês perderam”.
Gasta-se mais tempo se preparando para se isentar de possíveis fracassos e menos tempo na interatividade que um time de alto nível deveria ter.
No Scrum acertam todos juntos, erram todos juntos e nas retrospectivas das Sprints o time sempre terá a oportunidade de refletir sobre o que deve ser mudado e melhorado para atingirem um alto nível de coesão.
Bibliografia
MASSARI,Vitor. Scrum: 10 situações de quando ele poderá (e certamente irá) fracassar. Disponível em: <http://www.profissionaisti.com.br/2013/09/scrum-10-situacoes-de-quando-ele-podera-e-certamente-ira-fracassar/>. Acessado em: 22/09/2013
1) Dificuldades em se estabelecer a visão ou as fronteiras da visão do produto, gerando Sprints intermináveis e impossibilitando estabelecer prazo
Certa vez um executivo, ao qual eu me reportava, disse: “Vitor, está provado que esse lance de Scrum funciona muito bem na execução. Mas ele não consegue estabelecer prazo”. Eu disse a ele que o problema era que nossos usuários-chave não conseguiam responder a uma pergunta básica: “De onde quero que meu produto parta até onde eu quero que ele termine?”
Sem isso, você sempre vai trabalhar pensando no curto prazo, no imediatismo e tem grandes chances de ter um projeto interminável – o que por si só já soa incoerente, pois projeto é um esforço temporário para a construção de um produto ou serviço.
Não caia na cilada de muitos agilistas que dizem que projeto ágil não tem estimativa de prazo e nem cronograma. No mundo Agile existe uma série de técnicas e artefatos que permitem prover este tipo de informação (recomendo fortemente leituras dos autores Mike Cohn e Ken Schwaber).
2) Focar no que não agrega tanto valor ao produto
Certa vez uma gerente de produtos que participava de um workshop meu, disse: “Esse lance de Sprints até que é legal, mas algumas entregas que são feitas simplesmente não me importam muito e acabam não resolvendo meu problema”.
Respondi sobre a palavra-chave do que a Sprint deve produzir: VALOR. Não adianta pegar um projeto e fracionar em 10 Sprints, sendo que a maior parte delas não agrega valor ao produto e apenas nas últimas é possível ter feedback do cliente final.
Muitos agilistas principiantes acabam “fatiando” o produto em diversas entregas, mas erram no valor agregado nestas entregas.
3) Distanciamento entre Product Owner e o restante do Time Scrum
Ora, se um dos princípios do Manifesto Ágil é que indivíduos e interações devam prevalecer sobre processos e ferramentas, não faz nenhum sentido ter um Product Owner que não se comunica com o Time.
Se não há sinergia, sintonia e o conceito de “Whole Team”, o fracasso é certo!
4) Interferências externas ou mesmo do Product Owner impondo o que deve caber ou não dentro de uma Sprint, sem obter o feedback do time de desenvolvimento
O famoso “Top-Down” ou mais conhecido como “goela abaixo”. Flexibilidade e a negociação são belas artes do Scrum. Se os integrantes do Time Scrum não tiverem domínio destas artes ou não tiverem força para brecar ruídos externos que atrapalhem estas artes, corre-se o risco de comprometimento da qualidade.
5) Negociar qualidade
Deixa-se de lado o valor da Sprint e entrega-se o que dá para entregar apenas para cumprir um prazo, pouco importando se a qualidade é boa ou não.
Negociação é uma arte do Scrum, mas negociar qualidade é PROIBIDO !
Se o tempo realmente é uma restrição, foque sempre numa entrega de VALOR e QUALIDADE
6) Sprints curtas demais obrigando o Time Scrum trabalhar em ritmos insustentáveis
Outro caso de comprometimento da qualidade e violação dos valores do Manifesto Ágil. Fazer horas-extras pode até ser bom e produtivo no primeiro dia. Mas depois fatores fisiológicos (cansaço, sono acumulado) e psicológicos (saudades do pai, da mãe, do namorado, da namorada, do cachorro, do jogo da TV) diminuem o rendimento, consequentemente podendo comprometer a qualidade.
Tente encontrar a duração ideal da Sprint, onde o time trabalhe em ritmo sustentável e entregue valor.
7) Time de desenvolvimento sem maturidade ou experiência para se auto-organizar
Neste caso, mais do que nunca, é necessário o apoio e coaching do Scrum Master para o desenvolvimento do time. Um time inadequado vai gerar um produto inadequado.
8) Scrum Master omisso, permitindo que a auto-organização torna-se caos
Muito manjado que o Scrum Master é um líder que serve o time – não chefia, não micro-gerencia – mentora e remove impedimentos. Mas não se deixe simplesmente ficar sentado passivamente assistindo tudo acontecer.
Não chefiar não significa não monitorar, não tomar atitude diante das dificuldades ou mesmo da disciplina do time.
Acompanhe o Kanban, escute ativamente o que está rolando no Daily Scrum, certifique-se de você tem o time ideal e de alto nível, mentore com a ajuda do time aqueles que estiverem num nível de maturidade/disciplina menor.
9) Scrum Master fazendo micro-gerenciamento, quebrando a sinergia e desmotivando a equipe
Aqui é a situação inversa. É o Scrum Master que acredita ser o chefe da equipe, delega e controla as atividades não permitindo o time ser auto-organizado.
É aquele cara que prega as atividades no Kanban e sai colocando os nomes dos responsáveis pelas tarefas.
É aquele cara que todo dia usa o Daily Scrum como reunião de reporte e querendo saber o detalhe de tudo o que está no Kanban.
10) Time Scrum (Product Owner, Scrum Master e Time de Desenvolvimento) não trabalhando com o conceito de time unificado (“Whole Team”)
O famoso “Eu ganhei, nós empatamos e vocês perderam”.
Gasta-se mais tempo se preparando para se isentar de possíveis fracassos e menos tempo na interatividade que um time de alto nível deveria ter.
No Scrum acertam todos juntos, erram todos juntos e nas retrospectivas das Sprints o time sempre terá a oportunidade de refletir sobre o que deve ser mudado e melhorado para atingirem um alto nível de coesão.
Bibliografia
MASSARI,Vitor. Scrum: 10 situações de quando ele poderá (e certamente irá) fracassar. Disponível em: <http://www.profissionaisti.com.br/2013/09/scrum-10-situacoes-de-quando-ele-podera-e-certamente-ira-fracassar/>. Acessado em: 22/09/2013
Comentários
Postar um comentário