Não quero ser injusta com esse comentário mas, quanto mais estudo metodologias ágeis, mais vejo como as equipes que as buscam trabalham de maneira doentia pra precisar usar sistemas “band-aid” como o scrum.
Curto a ideia de sprint. Acho que, como um todo, claro que dá para tirar boas ideias. Mas o problema é sistêmico. Holacracia traz, do meu ponto de vista, um modelo mais intencional e integrado. Mas as pessoas não querer mudar, elas querem milagres do dia a dia.
O que eu mais gosto no scrum é o propósito da melhoria contínua. Mas o que me incomoda é esse ar de inovação sendo que, pelo menos para mim, deveria ser um princípio de qualquer trabalho, e não algo “novo”. Quer dizer, antes disso, as equipes não agilizavam essas ideias?
Uma vez almocei com um instrutor de scrum que estava aprendendo GTD, e ele achava que o GTD era uma solução de longo prazo que não atendia as “demandas urgentes” das empresas. Aí tipo, em vez de ir na raiz do problema (deixar chegar na urgência), coloca um band-aid (metodologia ágil).
No livro do Alexandre Magno, primeiro instrutor certificado de Scrum no Brasil, ele também traz essa raiz do problema, o que é essencial:
Então, não é que metodologias ágeis não funcionem. Claro que funcionam – apenas não são a solução para todos os problemas, como a maioria dos gestores e das empresas espera.
Mudar efetivamente “dá trabalho”, envolve ir na raiz dos problemas, e no fundo ninguém quer fazer isso porque leva tempo, demanda envolvimento, mudança de processos, e é mais fácil buscar uma solução rápida para apagar incêndios.
A minha proposta seria entender o que gera os incêndios e ir na causa para efetuar mudanças efetivas, estruturais e sistêmicas.
Gostei. Os gestores não admitem, mas querem bala de prata. Isso, nos sabemos, que não existe. Bom te encontrar comentando sobre gestão de projetos com reflexões e não como os caras evangelizadores e repetidores de guias e plsybooks. Segue um like pro seu artigo.
Post indispensável!!! Isso contece muito mesmo, é uma busca insana que muitas vezes beira o “reinventar a roda”. E de verdade, também não acho que o problema seja o método, o problema é quando as empresas/gestores utilizam de maneira indiscriminada. É quase uma alienação!
Todo o contexto é ignorado. Ignora-se o fato de que todos estão participando da mudança, e não apenas o time que as propõe. Clareza seria fundamental, pois isso é que gera engajamento: reconhecer o propósito das coisas.
Thais Godinho, não existe metodologia pior ou melhor, certa ou errada, nova ou velha. O que existem são necessidades de toda ordem e contextos diversos, cabendo a quem neles estão inseridos, avaliar o que faz mais sentido pata a organização naquele momento. Meu nome é Rodrigo Lopes e também estou aqui pra inspirar pessoas e fazer com que posssam trabalhar de forma organizada. Objetivo: Que tenham qualidade de vida e entregas contundentes. Abraços
Perfeito, Thais!
Thais, você acha que é possÃvel conciliar o scrum com o GTD? E se sim, como?
Sim, entraria na parte de organização do projeto.
Eu trabalho na parte da manhã finalizando os compromissos de dia inteiro da agenda e depois passo para a lista de próximas ações por contexto e prioridade.
Na parte da tarde, nos intervalos dos compromissos, trabalho na Sprint do dia (uso o Scrum e o OKR para trabalhar diariamente nos projetos relacionados a objetivos).
Estou fazendo esse teste porque sempre procrastinava nas próximas ações relacionadas a projetos.
Mas Thais, numca foi dito que Scrum é a solução de todos os problemas, não existe bala de prata e se algum dia te falaram isso, desconfie da veracidade!!
Quanto ao artigo também não entendi sua conclusão. Mudar envolve ir “na razão do problema e isso da trabalho”.. Sua proposta pra resolver o problema é “ir na causa”, descobrir a causa… Uai, no é exatamente a mesma coisa??
Causa raiz!! Causa! Core do problema.. Tudo vai trazer muitooo trabalho, mas é precisos coragem pra enfrentar e aplicar a melhoria.
Tive bastante raiva do GTD até pouco tempo atrás, quando enfim fiquei em paz com a ideia de executar projetos, num sistema que é uma mistura de GTD + blocos de tempo + Kanban. É muito fácil cair na armadilha do micro-gerenciamento do GTD e não chegar a lugar algum.
Acabei encontrando o SCRUM na minha tentativa de me separar do GTD, mas vi que era loucura demais; parece se importar mais com o fluxo de trabalho desesperado do que qualquer qualidade, aà deixei pra lá e adaptei o método que usava antes.
PS: acho engraçado como metodologia virou sinônimo de método…
Veja bem Adriano, o scrum como um metodologia ágil (também chamada adaptativa), não busca qualidade, busca respostas, o objetivo dela é testar, testar, testar , errar e aprender para tentar achar uma resposta não conhecida de um problema conhecido (ou até mesmo desconhecido). Por isso a crÃtica da Thais é muito pertinente. Não adianta usar scrum para resolver problemas para respostas conhecidas. Se já há soluções claras, boas ou melhores práticas conhecidas de um problema, esta metologia não é para isso.
É Thais, talvez esteja na hora de parar de estudar tanto “metodologias ágeis” e estudar mais sobre Agile em si! A começar que milagre a gente busca na religião (apesar de o “mercado da fé” e a relação de “acólitos” e “não-praticantes” serem tão semelhantes junto ao Complexo Industrial Ãgil); e, a proposta de cada metodo e ferramenta (que parte, apesar de terem originado posteriormente o termo, são anteriores ao Manifesto Ãgil) nunca foi tapar feridas ou ser bala de prata para algo, mas propor uma quebra de paradigma, trazendo “novos conceitos” sim, só que para a TI que por até então (década de 80-90) atuavam como a indústria fordista; e assim como houve crise na indústria, no ramo de software não foi diferente. Portanto alguns desenvolvedores passaram a olhar para o Lean da Toyota (olha da onde vem o conceito de melhoria contÃnua que você disse gostar), e experimentaram por cerca de 2 décadas tais ferramentas e métodos antes de se juntarem (ao menos 14 signatários) e criarem o famigerado Manifesto Ãgil. As ferramentas são somente isso: “ferramentas”. E uso esse termo pq XP, Kanban, OKRs entre outros são métodos por ex, já o Scrum é um Framework que tem como base o empirismo, e ainda assim as pessoas teimam em utilizar enquanto metodologia e de forma prescritiva! Já o Ãgil, é uma cultura, um modelo de pensamento, que em seu 1o valor já deixa claro sobre o que mais se trata (…mais pessoas dq ferramentas…). De baixo do guarda-chuva da agilidade temos diversas ferramentas para nos auxiliar: desde as ferramentas para operacionalização, criação e desenvolvimento de projetos, produtos e serviços, modelos de gestão (MM3.0, por ex), modelo organizacional como a Holacracia que vc mesma citou… enfim… há uma verdadeira sopa de letrinhas tal qual acontece no Lean (pq será? #fikdik) e jamais uma ferramenta sozinha e isolada, ou até mesmo combinadas porém sem o devido entendimento – o tal do “mindset agil” – poderá ser tida enquanto solução para algo. Engraçado como parte da resposta para seu tÃtulo e inÃcio do texto estão justamente nos textos grifados dos livros (apenas fora do contextoum pouco).
Portanto, não há problema com o Scrum, com “as metodologias ágeis” (como o mercado e alguns desavisados falam apesar do erro semântico por trás do jargão) ou o Ãgil em si: afinal, é problema da faca que ela quebra sempre na ponta quando tentamos utilizá-la para apertar parafusos?
[]’s e que a força da agilidade esteja com você!
Mas Marcondes, foi exatamente isso o que eu passei com o texto. Recomendo ler com mais carinho da próxima vez. 😉
Oi, Thais! Trabalho com marketing de produto há 4 anos e o scrum é quase lei em muitas das empresas. Te falar, que gosto da organização e dos rituais pra trabalho em equipe, mas se você pega um chefe/scrum master que acha que entende a metodologia, mas caga para o que funciona ou não pra equipe, ela é MUITO nociva. Essa experiência em particular que tive foi um terror pra mim – hello sintomas de burnout – mas vejo que depende muito de quem está a frente do método também. Atualmente também estou numa equipe que utiliza e as coisas tem caminhado tranquilamente e de forma eficiente, respeitando as pessoas. Vai entender rs
ThaÃs, pelo que entendo, há uma confusão sobre onde aplicar metodologia ágeis (ou adaptativas). Scrum não vai servir pra tudo, assim como as demais metodologias ágeis, como você mesma identificou. O objetivo dessas metodologias é buscar respostas para problemas complexos, é testar hipóteses, fazendo muitos testes, e buscar aprender com os erros, entender e responder em um curto espaço de tempo. Por isso a ideia de “ciclo curto de feedback”, porque elas buscam aprendizado. E por isso são ferramentas para inovação, porque tem esse esse objetivo de testar muito e aprender, gastar recursos intencionalmente com erros, pois o sucesso desse tipo de projeto deve ser medido por quanto se aprende. É o mesmo foco de se fazer pesquisa na universidade. Então é isso mesmo, a “causa-raiz” deve ser a primeira a ser identificada. Se busco soluções de problemas conhecidos e respostas conhecidas, é uma aboradagem inútil.
É exatamente essa a crÃtica. 😉 A quem acha que faz milagre.